Hello,

I'm running into the following problem which I'm certain isn't an issue with the SDK but checking to see if anyone else ran into this problem and found a solution.

I have a PS script to find all the updates made available to an endpoint via CM2012 and initiate the installation using the SDK.  The following two lines in the script is what I'm using and they work...most of the time.

$MissingUpdates = @(Get-WmiObject -ComputerName $ServerName -Credential $credential -Class CCM_SoftwareUpdate -Filter ComplianceState=0 -Namespace root\CCM\ClientSDK | foreach {[WMI]$_.__PATH})
Invoke-WmiMethod -ComputerName $ServerName -Credential $credential -Class CCM_SoftwareUpdatesManager -Name InstallUpdates -ArgumentList (,$MissingUpdates) -Namespace root\ccm\ClientSDK

The times where it's not working I receive a "System.UnauthorizedAccessException" error message.  Problem is after reviewing two different endpoints, one where it works and one where it doesn't work, I'm at a loss as to what could be blocking the script to invoking the method 'InstallUpdates'. 

I'm using a domain admin account to run the script and have verified that the account is showing up in the Administrators group on the problematic endpoint.  I've also manually added the account to the Administrators group (just to be safe), within the WMI Control (and afterwards restarted the WMI service), DCOM permissions to local/remote launch, to the WMI DCOM Application, changed the PS execution policy and used wbemtest.exe to see the error...

Number: 0x80070005
Facility: Win32
Description: Access is denied.

The error 0x80070005 lead me to check the DCOM permissions per WMI Troubleshooting article out on MSDN.

Inspite of all these checks, still can't invoke the method successfully.  Both endpoints are running Windows Server 2008 R2. 

Any insight would be appreciated.  Thanks!

Just because the account is a domain admin doesn't mean it has any permissions in ConfigMgr. You should be using a ConfigMgr admin account.

Correct.  I forgot to mention that the domain admin account is a member of several other security groups which grant it access to various ConfgMgr objects within CM2012.  So while it's not a ConfigMgr admin, it does have the correct permissions to create/edit/delete software update deployments and packages...among a few other things.

Have you tried the above with an account that is a full ConfigMgr admin?

I will give that a try and report back.

Looks like it worked.  I moved a couple servers back into our DEV environment where the domain account was a full ConfigMgr admin and it was able to execute the method successfully.  Now I need to determine what specific access in CM2012 allows the account to execute the method as we can't have the domain account a full ConfigMgr admin in our production environment due to compliance regulations (long story).

Since this method is running on client systems, as long as the acct is in the local administrators group on the client, you should be set.

have you looked at any logs on the client to see if it's reporting anything? maybe updatesdeployment.log, as well as the security event log...

This error can occur when the client is either not running, or has started but hasn't initialized its COM subsystem, or if the client endpoint hasn't yet been started. Some client SDK methods simply cannot be invoked from a remote machine (doesn't look like that's the case here, though).

Been a little while since I provided an update...we managed to move the endpoint back into our production environment and changed the permissions to our account as a full ConfigMgr Admin.  Unfortunately we're still receiving the same message..."Access is Denied".  It was suggested to me to look at some of the policies on the endpoint but I'm not sure which/what policies to review to ensure all the correct security permissions are replicating down.

The UpdatesDeployment.log doesn't contain any information as to why I'm receiving the error.  It will show "EnumerateUpdates for action (UpdateActionInstall) - Total actionable updates = <numerical_value>" but nothing else when I make the WMI call to the method.

One more update...we checked the Security Events on the endpoint and everything shows up as a "Audit Success" with our account.

Are you trying to invoke remotely software updates installation?

Best,

Kaido

• Edited by Kaido1000MVP, Moderator Thursday, January 24, 2013 1:22 PM

Are you trying to invoke remotely software updates installation?

Best,

Kaido

Yes.  We have it working successfully in our development environment using the same ConfigMgr account where the permissions are like-for-like with our production environment.

I've also run into this same issue with CM12 and it appears to only happen for certain software updates. I use the UDA.CCMUpdatesDeployment COM object with my CM07 clients and I don't see this issue, granted one is COM and the other is WMI.

• Edited by M Granstrom Tuesday, June 25, 2013 8:40 PM Clarifying

I've also run into this same issue with CM12 and it appears to only happen for certain software updates. I use the UDA.CCMUpdatesDeployment COM object with my CM07 clients and I don't see this issue, granted one is COM and the other is WMI.

I found that this code only works when run as an interactive user (admin or non-admin, it doesn't matter) or as the system account. I only see the error message mentioned in the original post when I try to elevate the script to an administrator using runas when another account is logged in interactively. Ultimately we used psexec -s to run the script under the system context and it's been working well for us.

We managed to find a workaround for the situation we were running into.  We not 100% certain what's causing the problem but we believe there might be a GPO affecting the permissions on the endpoints we're attempting to start the update installations on.

What we ended up doing, within the same PS script, is changing the 'InstallRestriction' setting in the "CCM_ClientAgentConfig" class to 0 which would allow anyone to perform the WMI call.  After we started the update installation, we would restore the original value.

Hi Jason, 

could you please tell us what "ConfigMgr admin" means?

We are facing this error but we don't know how to configure security.

thanks in advance. 

I know this thread is old but hoping AGS_MN might respond.  What exactly was the script method you described "What we ended up doing, within the same PS script, is changing the 'InstallRestriction' setting in the "CCM_ClientAgentConfig" class to 0 which would allow anyone to perform the WMI call. "

I haven't had any luck with the syntax of how do what you mention as a workaround.  

• Edited by wdjenkinsentisys Monday, October 13, 2014 10:13 PM

$Namespace = "root\ccm\Policy\Machine\ActualConfig"
$Class = "CCM_ClientAgentConfig"
$Current_ClientAgentConfig = Get-WmiObject -Namespace $Namespace -Class $Class -ComputerName $ServerName -ErrorAction Stop
$Current_ClientAgentConfig.InstallRestriction

The information above will grab the current setting.  I then changed the installrestriction value to 0 to make what I needed work.

Set-WmiInstance -InputObject $Current_ClientAgentConfig -ErrorAction Stop

Hope this helps.

Thanks for the reply AGS_MN.  Unfortunately still no luck.  

I tried:

#-----------------------------------------------------------------------

$Namespace = "root\ccm\Policy\Machine\ActualConfig"
$Class = "CCM_ClientAgentConfig"
$Current_ClientAgentConfig = Get-WmiObject -Namespace $Namespace -Class $Class -ComputerName '<myservername>' -ErrorAction Stop
$Current_ClientAgentConfig.InstallRestriction

Set-WmiInstance -InputObject $Current_ClientAgentConfig -ErrorAction Stop
#-----------------------------------------------------------------------
$Update=@([wmi](Get-WmiObject -computername '<myservername>' -Class CCM_SoftwareUpdate -Filter ArticleID='<articleid>' -Namespace root\CCM\ClientSDK).__Path)

if ($Update -is [Object])
{
Invoke-WmiMethod -computername '<myservername>' -Class CCM_SoftwareUpdatesManager -Name InstallUpdates -ArgumentList (,$Update) -Namespace root\ccm\clientsdk
}

#-----------------------------------------------------------------------

The code section you provided runs fine and clearly shows me that the "InstallRestriction" value is "0", but my section of code fails (System.UnauthorizedAccessException) 100% of the time when executed remotely (doesn't matter if my Powershell is elevated or not).  Runs fine when executed locally as either <domain>\<domainadminaccount> or .\administrator account.  So I can't figure out what is blocking me remotely.

• Edited by wdjenkinsentisys Tuesday, October 14, 2014 5:35 PM

Again thanks AGS_MN.  Just to be sure I also ran your code. 

$Namespace = "root\ccm\Policy\Machine\ActualConfig"
$Class = "CCM_ClientAgentConfig"
$Current_ClientAgentConfig = Get-WmiObject -Namespace $Namespace -Class $Class -ComputerName '<myservername>' -ErrorAction Stop
$Current_ClientAgentConfig.InstallRestriction

Set-WmiInstance -InputObject $Current_ClientAgentConfig -ErrorAction Stop

$MissingUpdates = @(Get-WmiObject -ComputerName '<myservername>' -Credential $credential -Class CCM_SoftwareUpdate -Filter ComplianceState=0 -Namespace root\CCM\ClientSDK | foreach {[WMI]$_.__PATH})
Invoke-WmiMethod -ComputerName '<myservername>' -Credential $credential -Class CCM_SoftwareUpdatesManager -Name InstallUpdates -ArgumentList (,$MissingUpdates) -Namespace root\ccm\ClientSDK

Only difference is the code (because of the -Credential) prompts me for username and password, but still errors the same as mine.

My testing so far has indicated that its a Windows 2003 issue.  When the targeted endpoint is 2003 it fails, if the targeted endpoint is 2008 it runs fine.  Doesn't matter if the origination endpoint is 2003 or 2008.  I'm stuck on how to reliably get the 2003 targets to run their SCCM updates remotely.

Has anybody managed to get this error resolved on Server 2003 machines? I am still encountering this same error and have not had any success in the solutions provided thus far.

I did notice in the CCMSDKProvider.log, the client logs the following error The caller is not allowed and/or supported to initiate the update installation.

Thoughts?

• Edited by Justen Hansen Thursday, October 30, 2014 4:24 PM

I ended up opening a support case with Microsoft on this issue.  The end result is that this issue is by design.  This only affects Server 2003 as the problem was created in a design change in the OS from 2003 to 2008.

If you actually log into the console of the 2003 server and then attempt to issue the InstallUpdates method, it will work as expected.

I'm not sure if there's any way to trick or create a console session through PowerShell....

Jon

Did anybody ever find a workaround for this?  Maybe creating a scheduled task?

Cheers All.

I came to this link looking for answers, but give this a shot guys.

On your local PC (client)

Set "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\lmcompatibilitylevel"
= 2  

My PC is set via policy to 4, then recently when I try to do remote WMI hooks and the regkey above is set to 4, it will fail.   I set this to 2 (after a MS support call) my WMI hooks will work again.

• Edited by Jonathan Reininger 15 hours 1 minutes ago

I came to this link looking for answers, but give this a shot guys.

On your local PC (client)

Set "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\lmcompatibilitylevel"
= 2  

My PC is set via policy to 4, then recently when I try to do remote WMI hooks and the regkey above is set to 4, it will fail.   I set this to 2 (after a MS support call) my WMI hooks will work again.

• Edited by Jonathan Reininger Friday, April 24, 2015 4:43 PM