Блог

Я пытаюсь заставить агент SQL Server запускать программу с аргументами (как шаг задания CmdExec операционной системы), но каждый раз, когда он запускает задание, я получаю следующую ошибку: процесс не удалось создать для шага 1 задания, причина: доступ запрещен).

Исследование, которое я провел в Интернете, показало, что это может быть проблемой с разрешениями. Я настроил новую учетную запись пользователя в Windows и предоставил ей полные разрешения для программы, которую я хотел запустить, затем сопоставил этот профиль пользователя с профилем SQLSERVERAGENT в MS SQL, но я все еще получаю эту ошибку.

Любая помощь в этом будет оценена.

вышеуказанные шаги сработали для меня

 Enable XP_cmdshell
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO
 

Создать учетные данные

 CREATE CREDENTIAL cmdshell_agent WITH IDENTITY = 'account_name', SECRET = 'password';
GO
 

Создать прокси

 USE [msdb]
GO
EXEC msdb.dbo.sp_add_proxy @proxy_name=N'tst_Proxy',@credential_name=N'cmdshell_agent', @enabled=1
GO
EXEC msdb.dbo.sp_grant_proxy_to_subsystem @proxy_name=N'tst_Proxy', @subsystem_id=3
GO
 

После этого используйте tst_proxy в задании агента sql для запуска задания. Задание выполнено успешно

У меня была та же проблема, и решение было до смешного простым: мой путь к .exe был отключен. Немного сбивает с толку то, что это отражается как ошибка «Отказано в доступе» (поскольку учетная запись агента на самом деле не знает, что файл не существует, просто он не может получить доступ к такому файлу).

Один простой шаг, который вы можете предпринять при устранении неполадок, — запустить точную команду в окне командной строки. Работает ли это так, как ожидалось? Как насчет входа в систему с использованием учетной записи агента?

Сначала вам нужно убедиться, что XP_CMDSHELL разрешен.

 exec sp_configure 'xp_cmdshell',1
go
reconfigure
 

1. Вам необходимо создать учетные данные для созданного вами пользователя.
2. Создайте прокси, ссылающийся на созданные вами учетные данные. Предоставьте этому прокси-серверу доступ к подразделу «Операционная система (CmdExec)».
3. На самом этапе задания убедитесь, что оно выполняется от имени этого прокси-сервера (выполняется как:).

Получил то же сообщение об ошибке. Оказалось, что у учетной записи агента SQL не было разрешений в каталоге Tools, где sqlcmd.exe находится в расположении. Предоставил разрешения на чтение и выполнение учетной записи агента SQL, проблема решена.

Если вы столкнулись с этой проблемой с планами обслуживания SQL 2014, даже если учетная запись RunAs и учетные записи служб работают нормально (как подтверждено в EXECUTE AS testing), попробуйте выполнить следующее:

Проверьте проверку подлинности локального подключения в плане обслуживания.

• если для него установлена учетная запись и это уместно, переключитесь на проверку подлинности Windows NT, сохраните план
• если он уже установлен на WinNT, переключитесь на учетную запись, сохраните план, вернитесь, переключитесь на проверку подлинности Windows NT, снова сохраните план.

Нигде не было протоколирования, которое могло бы это уловить. Я просто думал, где еще может быть задействована аутентификация, поскольку сбои были связаны с этим, но везде все было настроено должным образом….

Как сказала бы бабушка: «Это всегда в последнюю очередь, куда вы смотрите». 😏

Нам нужно убедиться, что учетная запись, через которую выполняется задание, имеет полный доступ к папкам / документам, участвующим в шагах задания.

Это должно решить проблему без добавления прокси.