Condividi tramite

Running Configuration Manager 2012 PowerShell scripts as a Service Account or Local System

  • Articolo

The recent release of Microsoft System Center 2012 Configuration Manager Service Pack 1 introduced a PowerShell module that allows for the easy automation of Configuration Manager operational tasks. This provides good possibilities and opportunities for automating some of those repetitive daily tasks, but what happens when you need to schedule these cmdlets to run as a Service Account or under the Local System account?

Consider the following script: 

 

It imports the new PowerShell module and then changes directory to the newly created Config Manager drive. When I run this script under my own user account,everything works as expected:

  

But when i run the same script as a Service Account, or as the Local System Account it no longer works!

  

 A bit of further investigation reveals that the module has been imported, and the Config Manger Provider has been created, although the drive is not properly mounted. 

  

So what is happening here? It turns out that the Configuration Manager PowerShell module is digitally signed, and the user running the script must install the certificate that the module was signed with before they can use it. This can be done be launching Config Manager as the user that will be running the script. To do this, right click on the Config Manager console and choose ‘Run as a different user’:

 

 

Once the Config Manager console has opened, then go to ‘Connect via Windows PowerShell’ :

 

PowerShell will start and ask you if you want to trust the software form this publisher:

 

 

 

If you choose to trust the content then the PowerShell module is imported and the Config Manager drive is created in PowerShell:

 

If I then go back to and re-run my script, this time I find that it works!

 

Alternatively, if you are trying to schedule scripts to run as the ’Local System’ Account then it is possible to manually install the certificate to solve this problem. Right click the PowerShell Module file ‘ConfigurationManager.psd1’ and choose ‘properties’ and then ‘Digital Signatures’. From here choose ‘Install Certificate’

 Import the certificate into the ’Local Machine’ store

And place it in the ‘Trusted Publishers’ store.

 

 

Once the certificate is installed, the Local System account can now run the new Configuration Manager cmdlets!

Comments

  • Anonymous
    January 01, 2003
    Saw this tweet by Tore and thought this would be worth a mention here on how to do the same thing using PowerShell.
    Visit below link
    http://asaconsultant.blogspot.no/2014/05/configmgr-scripting-with-powershell.html

  • Anonymous
    November 20, 2013
    hi, does any one know how to achieve this using powershell command. thanks.

  • Anonymous
    February 19, 2014
    Why is this not working for any users? I tried to import the cert to CurrentUser store as well and it did not help, I get the message with my user: Object reference not set to an instance of the object. Up until I don't connect the user from the console trough powershell to the site at least once!

  • Anonymous
    April 09, 2014
    The following applies to SCCM2012SP1; might work for R2 as well.
    The "Untrusted Publisher" warning only appears if you open a PS console from the Configuration Manager Console. If you open a standard PS console, the module can be imported without this warning.
    In my experience, the module reads information from the registry which is only set once the Configuration Manager GUI has been started. Bizarrely enough, this information is taken from the user's Most Recently Used list of the Configuration Manager Console.
    In "HKCUSoftwareMicrosoftConfigMgr10AdminUIMRU1" (note that this is indeed the 64bit registry, while the SP1 module requires 32bit), the following REG_SZ values need to exist before the PSDrive can be created:
    * DomainName = ""
    * ServerName = ""
    * SiteCode" = ""
    * SiteName" = ""
    Once this registry information is set, the module can be imported and used automatically, without having to import a certificate.
    Why most of the modules still require the site code to be passed as mandatory argument, even though this could be taken as default from the enforced current drive, escapes me, though.

  • Anonymous
    April 14, 2014
    Just noted that the comments don't allow for strings enclosed in "less than"/"greater than" signs, so for the sake of completeness, here are the registry entries again in square brackets (all REG_SZ):
    * DomainName = "[Empty]"
    * ServerName = "[SCCM server's FQDN]"
    * SiteCode" = "SCCM SiteCode"
    * SiteName" = "[SCCM Site Name]"

  • Anonymous
    January 14, 2016
    I've just published a little cmdlet to fix the registry entries so you can run the Configuration Manager Cmdlets with the "Local System" account.http://code.avalon-zone.be/cmdlet-add-configmgr10registryentriesforlocalsystem/

  • Anonymous
    January 14, 2016
    I've just published a little cmdlet to fix the registry entries so you can run the Configuration Manager Cmdlets with the "Local System" account.http://code.avalon-zone.be/cmdlet-add-configmgr10registryentriesforlocalsystem/