3

I have a SQL Server 2014 Agent Job (Type: "Operating system (CmdExec)", Run as: "SQL Server Agent Service Account", Owner: sa) that executes the following command:

powershell -ExecutionPolicy Bypass -Command "$objServiceManager = New-Object -ComObject 'Microsoft.Update.ServiceManager'; $objService = $objServiceManager.AddService2('7971f918-a847-4430-9279-4a52d1efe18d',2,''); $objService.PSTypeNames.Add('PSWindowsUpdate.WUServiceManager');"

The service account that SQL Server Agent is running under has sysadmin privileges to the instance, but does NOT have Admin access to the server.

If I RDP into the server as the Agent's service account, I can execute the command successfully from a command prompt:

enter image description here

But, if I execute the SQL Server Agent Job, it fails with an "Access Denied" error:

Exception calling "AddService2" with "3" argument(s): "Access is denied. 
(Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"
At line:1 char:79
+ $objServiceManager = New-Object -ComObject 
'Microsoft.Update.ServiceManager'; $o ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ComMethodTargetInvocation

You cannot call a method on a null-valued expression.
At line:1 char:170
+ ... efe18d',2,''); 
$objService.PSTypeNames.Add('PSWindowsUpdate.WUServiceManager');
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull

I have found that if I set the "Run as" for the job to a proxy account that has sysadmin privileges on the instance AND Admin access to the server, it succeeds, but that's not really relevant to my question.

EDIT: I'm executing everything as CmdExec, and not Powershell, because I need to execute an unsigned Powershell script (not included in my code, since it's not causing a problem). I get the same error if I change the Type to Powershell.

My question: Why does the same command fail as a job, but succeed from the console when both executed from the same user account on the same server?

  • This seems to be the same issue as this one on AskSqlServerCentral: SQL Agent CmdExec proxy ignored. I believe it has to do with Impersonation, but have not had time to fully investigate / prove / etc. – Solomon Rutzky Jan 27 '16 at 19:37
2

Potential Workarounds

  1. Since you're running PowerShell through SQL Server CmdExec from an agent job, you could try calling a PowerShell script with your saved PS logic in it rather than running raw PowerShell commands to see if that makes a difference for a potential workaround.

  2. Try explicitly putting the full OS path on the server to point to PowerShell.exe and then pass your PowerShell commands after that in case the issue has to do with environmental variables not working correctly for PowerShell within the CmdExec shell.

My question: Why does the same command fail as a job, but succeed from the console when both executed from the same user account on the same server?

Potential Reasons

  • It could be an issue when calling PowerShell.exe thru the SQL Server Agent job with the CmdExec shell and how it interprets security context of the account it's run from or as (e.g. the service account) when it tries to run PowerShell.exe that way so it's not able to authenticate the execution access to the EXE due to this.
  • Check and read up on the version of PowerShell installed, the version of SQL Server installed, and the Windows OS all these are on and run from for "known" issues related to version incompatibilities in this respect - it may be a known issue depending on ALL the specifics in this environment.

A working way I run PowerShell from SQL Agent Jobs

You will need to:

  1. Create the [user account object] service account in AD (<DomainName>\<ServiceAccount>)
  2. Create a SQL login i.e. the service account in #1 (<DomainName>\<ServiceAccount>)
  3. Create a SQL credential with that same (<DomainName>\<ServiceAccount>) account credentials,
  4. Create a SQL Server Agent Proxy account to use for the "Run As" from the SQL Agent job to execute PowerShell

Below is a script of the T-SQL part of this process which I run after doing the above 4 steps, and it always works in my environment to accomplish what seems to be similar to what you've explained that you're trying to accomplish. I also have to ensure the AD account has a strong/complex password, and set it to never expire.

--- // Create login on SQL Instance for domain\PSSQLJobs service account if it does not exist
IF NOT EXISTS (
        SELECT *
        FROM sys.server_principals
        WHERE NAME = N'domain\PSSQLJobs'
        )
BEGIN
    CREATE LOGIN [domain\PSSQLJobs]
    FROM WINDOWS WITH DEFAULT_DATABASE = [master]
        ,DEFAULT_LANGUAGE = [us_english]
END

USE [master]

IF NOT EXISTS (
        SELECT *
        FROM sys.database_principals
        WHERE NAME = N'domain\PSSQLJobs'
        )
    CREATE USER [domain\PSSQLJobs]
    FOR LOGIN [domain\PSSQLJobs]
    WITH DEFAULT_SCHEMA = [dbo]

EXEC sp_addrolemember N'db_datareader'
    ,N'domain\PSSQLJobs'

GRANT CONNECT
    ON DATABASE::[master]
    TO [domain\PSSQLJobs]

USE [msdb]

IF NOT EXISTS (
        SELECT *
        FROM sys.database_principals
        WHERE NAME = N'domain\PSSQLJobs'
        )
    CREATE USER [domain\PSSQLJobs]
    FOR LOGIN [domain\PSSQLJobs]
    WITH DEFAULT_SCHEMA = [dbo]

EXEC sp_addrolemember N'db_datareader'
    ,N'domain\PSSQLJobs'

EXEC sp_addrolemember N'SQLAgentOperatorRole'
    ,N'domain\PSSQLJobs'

EXEC sp_addrolemember N'SQLAgentReaderRole'
    ,N'domain\PSSQLJobs'

EXEC sp_addrolemember N'SQLAgentUserRole'
    ,N'domain\PSSQLJobs'

GRANT CONNECT
    ON DATABASE::[msdb]
    TO [domain\PSSQLJobs]



--- // Create Credential *** Type in password of account into value of SECRET ***
USE [msdb]

CREATE CREDENTIAL PSSQLJobs
    WITH IDENTITY = 'domain\PSSQLJobs'
        ,SECRET = '*******'


--- // Create PowerShell Proxy account and give PSSQLJobs access to it
USE [msdb]

EXEC msdb.dbo.sp_add_proxy @proxy_name = N'ExecutePowershell'
    ,@credential_name = N'PSSQLJobs'
    ,@enabled = 1

EXEC msdb.dbo.sp_grant_proxy_to_subsystem @proxy_name = N'ExecutePowershell'
    ,@subsystem_id = 12

EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name = N'ExecutePowershell'
    ,@login_name = N'domain\PSSQLJobs'
  • How is the security context different, if both the job and the console command are executed as the same user? – CaptainSlock Oct 7 '15 at 17:36
  • I don't believe it's possible to update the execution policy for SQL Powershell without a registry change - something I'd rather avoid. I've tried it in the past and again now, without luck, and Google seems to confirm that it's not possible. Hopefully I'm wrong? – CaptainSlock Oct 7 '15 at 22:57
  • Also, while your response has been helpful (especially your script-thanks), it doesn't really answer my question. I want to understand WHY there is a discrepancy; I already have a workaround. There must be something I don't understand about how security is implemented in a SQL Server Agent Job and none of my Google and BOL time has been fruitful. – CaptainSlock Oct 7 '15 at 22:57
  • @CaptainSlock Did you ever determine what's going on with this in your environment or did my "updated" answer provide further clarification on potential reason why the security is different? Shot me an update when you get a chance. – Pimp Juice IT May 6 '17 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.