Access check failed against user CCMExec.log

[Vitiate]

Hi,

 

I am hoping someone with some in-depth knowledge can help me out. I have spent the last week attempting to get around this issue. My goal is to trigger policy updates and other "advanced" functions within the CCM agent from a SCORCH based powershell script.

 

The CCM agent is installed on a workstation computer.

The service account I am using is configured to be an administrator account and has full access to the WMI and DCOM interfaces.

I have also added the local service account to the CCMADMINS during the CCM agent installation.

The CCM registry key "Administrators" contains the service account.

The local Administrator account (the original one) is able to trigger policy updates without an issue remotely.

When I try and trigger a policy update CCMEXEC,LOG shows me:

 

<![LOG[Access check failed against user 'serviceaccount']LOG]!><time="08:31:03.563+420" date="12-22-2014" component="CCMEXEC" context="" type="2" thread="4052" file="comobjectsecurity.cpp:400">

 

 

The code I am running is:

 

 

$Namespace = "root\ccm\Policy\Machine\ActualConfig"

$Class = "CCM_ClientAgentConfig"

$Current_ClientAgentConfig = Get-WmiObject -Namespace $Namespace -Class $Class -ComputerName $server -ErrorAction Stop -credential $cred

 

The error that comes back:

 

 

VERBOSE: Performing the operation "Invoke-WmiMethod" on target "SMS_Client (TriggerSchedule)".

Invoke-WmiMethod :

At Trigger-Policy-Updates.ps1:24 char:1

+ Invoke-WmiMethod -computername $server -Class SMS_CLient -Name TriggerSchedule - ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: ( [invoke-WmiMethod], UnauthorizedAccessException

+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.InvokeWmiMethod

 

 

Does anyone know how to get the service account into the authorized administrator list?

 

Help me please, you are my only hope....

[Peter van der Woude]

I'm more intrigued by the credentials parameter that you're also throwing in you're code. Where does it get it's value from?

[Vitiate]

I'm more intrigued by the credentials parameter that you're also throwing in you're code. Where does it get it's value from?

 

 

$username = "serviceaccount"

$password = convertto-securestring -AsPlainText -force -String "PassWorD"

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $password

$server = "ServerName"

This works 100% of the time if I use the "Administrator" account. It works for any wmi query I throw at it other then the ccm ones.

[Peter van der Woude]

Ok, that was not in your previous post... I'm just wondering why you would throw a user in the credentials. Why not simply giving the service account, running the runbooks, the required access? Also, why not simply using the ConfigMgr IP (see: http://technet.microsoft.com/en-us/library/hh967537.aspx)?

[Vitiate]

The environment is multi-tiered. The SCCM server is managing several hundred servers that are in multiple domains and workgroups. The Config Manager IP is not able to list the missing updates deployed to a server and patch them incrementally identifying the status of each patch. The project that I am working on allows me to patch hundreds of servers in a dependent manner. If server 1 depends on server 2 it will not go down for a patch until server 1 has reported a flawless patch cycle. When it is working in the lab it works beautifully. It was not until I moved outside the lab that I ran into this issue.

 

No process survives contact with production.

[Peter van der Woude]

But the ConfigMgr IP has bultin activities for client actions that you can simply use, instead of custom code.