I'm working on a Powershell script to update service accounts on named SQL instances in a failover cluster. I'm trying to use the SMO and WMI to update this so that I can update the service account on the active node and have it populated to the other passive nodes (as would happen if I updated manually in the configuration tools). I'm getting hung up on trying to execute the script on my local machine but updating a remote server. The error I see appears to be security related based on my Google searches and is successful if I run the script locally on the remote machine with elevated permissions (as administrator).

The code:

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.SqlWmiManagement") | Out-Null
$mc=New-Object -TypeName Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer "SQLHOST01"

$srvcs= $mc.Services | Where {$_.name -like "*INSTANCE01*"} | Where {$_.Type -like "Sql*"}

$srvcs | ft name,servicestate,serviceaccount

foreach ($s in $srvcs){


Exception calling "SetServiceAccount" with "2" argument(s): "Set service account failed. "
At line:11 char:5
+     $s.SetServiceAccount("FOO\Bar","strongpass")
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : FailedOperationException

Using: Windows 2008 R2 (remote) SQL 2008 R2 (remote) Windows 7 with SQL 2012 sqlps module (local)

Update: The account I am executing the script under has administrator rights on the remote machine.

The primary question here is how can I make my call from the client machine act as if it were running under elevated permissions on the remote machine?

  • Are you certain you have the correct rights on the target server? The account you are using on the remote machine must have the SC_MANAGER_ALL_ACCESS right to access the Service Control Manager, and there are other rights you'll need for the specific services in question. msdn.microsoft.com/en-us/library/windows/desktop/… shows the rights you might need. The easiest way to get around this is to ensure the account you are running the app under has Administrator access to the remote server in question. – Hannah Vernon Nov 28 '12 at 23:30
  • You do not need to "elevate" your permissions when accessing the SCM remotely - that really only applies to interactive applications. – Hannah Vernon Nov 28 '12 at 23:32
  • The reason I believe it requires elevated permissions is that the script runs successfully when I execute it locally on the remote machine, but only when I run Powershell as Administrator. In all cases, I'm running the script under the same account, which has Administrator rights on the remote machine. – Mike Fal Nov 29 '12 at 1:12
  • this is probably a stupid question, but have you tried it on your local machine in elevated mode against the remote machine? – Hannah Vernon Nov 29 '12 at 1:20
  • Yup. Running it as administrator on my local machine. – Mike Fal Nov 29 '12 at 1:21

I ran into the same problem, looks like its an SMO bug (1st link) (however I have not tried the CredSSP stuff from the second link below)



Please let me know if that works..


Try single quotes in your powershell script. I beat my head against this for an hour before i switched that out, and it worked like a charm.

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.