For some odd reason for about a week, SCCM will not push the client to machines that were imaged. This something to do with Discovery or the client msi corrupted?  I redid repositories for WMI on one of the client machines that I am trying to push to as well as adding the service account to the local admin group, but this as always worked before.  Message below that I edited. I am not finding a whole lot, BITS is on in services.

Execute query exec [sp_CP_SetLastErrorCode] 16777880, 1~  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:04.547+300><thread=12652 (0x316C)>

Stored request "16777880", machine name "MACHINENAME", in queue "Retry".  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:04.620+300><thread=12652 (0x316C)>

Execute query exec [sp_CP_SetPushRequestMachineStatus] 16777880, 2~  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:04.760+300><thread=12652 (0x316C)>

Execute query exec [sp_CP_SetLatest] 16777880, N'08/11/2015 20:15:04', 180~  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:04.836+300><thread=12652 (0x316C)>

<======End request: "16777880", machine name: "MACHINENAME".  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:04.953+300><thread=12652 (0x316C)>

---> System OS version string "6.1.7601" converted to 6.10  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:05.792+300><thread=7072 (0x1BA0)>

---> Unable to connect to WMI (root\ccm) on remote machine "MACHINENAME", error = 0x8004100e.  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:06.177+300><thread=7072 (0x1BA0)>

---> Mobile client on the target machine has the same version, and 'forced' flag is turned on.~  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:06.291+300><thread=7072 (0x1BA0)>

---> Creating \ VerifyingCopying exsistance of destination directory \\MACHINENAME\admin$\ccmsetup.~  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:06.356+300><thread=7072 (0x1BA0)>

---> Copying client files to \\MACHINENAME\admin$\ccmsetup.~  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:06.623+300><thread=7072 (0x1BA0)>

---> Error setting ACL on TCF file, deleting file and failing install.  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:06.642+300><thread=7072 (0x1BA0)>

---> Failed to install CCM Client Bootstrap component on client (1)  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:06.654+300><thread=7072 (0x1BA0)>

STATMSG: ID=3014 SEV=W LEV=M SOURCE="SMS Server" COMP="SMS_CLIENT_CONFIG_MANAGER" SYS=servername.domain.com SITE=CHI PID=2984 TID=7072 GMTDATE=Tue Aug 11 20:15:06.671 2015 ISTR0="MACHINENAME" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:06.671+300><thread=7072 (0x1BA0)>

---> Deleting SMS Client Install Lock File '\\machine name\admin$\SMSClientInstall.CHI'~  $$<SMS_CLIENT_CONFIG_MANAGER><08-11-2015 15:15:06.710+300><thread=7072 (0x1BA0)>

Anyone ever come across this? I see same issues but different scenarios.  Client machines are Windows 7 64 bit.

The fatal error here is "Error setting ACL on TCF file, deleting file and failing install." I have no idea what would cause this failure though. You need to examine the target system and it's event logs to find out what is causing this. Perhaps some client side security software is getting the way. You can use procmon to try and discover the source of the issue also.

Is it able to create the ccmsetup folder properly? If so, check the ACL on this folder. Perhaps you have some non-standard security lockdowns in effect on the client system. 

What account is being used to install the client agent? Perhaps this account does not have the privileges to perform the necessary operations or a non-standard ACL is preventing it.

Why aren't you using OSD to deploy Windows?

Error setting ACL on TCF file, deleting file and failing install. - Check the account that you are using to push the client agent.

Failed to install CCM Client Bootstrap component on client  - For me it looks like the installation account has limited privileges to install the the client components.

Hi Jason,

the ccmsetup folder does not create at all on client side.

Will verify other

We make the SCCM site server a local admin on our clients to utilize "client push". Are you using the computer account or another account? If you are not using the computer account, give it a try as a test if you are pushing the client from the console.

Also, try reading through this, not sure if it will be helpful to you or not.

-Tony

• Edited by Tony Chirillo 17 hours 51 minutes ago
• Proposed as answer by Tony Chirillo 17 hours 51 minutes ago
• Unproposed as answer by Tony Chirillo 17 hours 51 minutes ago

using a service account  which has full administrator for security role

Just as a test, try making the site server computer account a local admin on the client and try pushing the client again.

-Tony

If you are using service account make sure service account has local admin access on the box you are trying to install client to. 

Actually the CCMsetup folder does get created however there is no contents inside the fo

service account is a domain admin and the domain admin group is part of the local administrator group

That's dangerous (having any account as a domain admin that is used on a normal basis).

You'll need to start troubleshooting on the clients themselves to see what is causing the failure per my previous post.

Hi Jason,

Explain why having the service account in the domain admin group is dangerous when given full admin access for security role in SCCM? When we pushed packages we have our domain admin accounts set as full administrators and packages push fine currently, just now the client seems to not want to push after a fresh image is made to a client machine.   I tried everything on the client, BITS started, WMI repositories rebuilt ect.. rebuilt, local firewall disabled, ports added, keep in mind, CCM setup folder appears, but it is empty, no contents to examine even in the event log.

We make the SCCM site server a local admin on our clients to utilize "client push". Are you using the computer account or another account? If you are not using the computer account, give it a try as a test if you are pushing the client from the console.

Also, try reading through this, not sure if it will be helpful to you or not.

-Tony

• Edited by Tony Chirillo Wednesday, August 12, 2015 2:00 PM
• Proposed as answer by Tony Chirillo Wednesday, August 12, 2015 2:00 PM
• Unproposed as answer by Tony Chirillo Wednesday, August 12, 2015 2:00 PM

Giving *any* account domain admins is dangerous -- this has nothing to do with ConfigMgr. Your domain admins group should at most contain two or three accounts.

Nothing you stated above as having changed has anything remotely to do with the symptom being experienced. You need to do some actual troubleshooting using something like procmon to monitor the activity happening on the client to see why the failure is occurring. Checking the Windows event logs may also help but may not.

Hi Mofayew, that seemed to work manually by copying the contents over and running the ccmsetup.exe as I checked the failed client machine this morning and end point along with software center appeared as normal.

Jason

Could Joe-ker use PSEXEC and run ccmetup.exe manually as local system? Would that be a close enough test to the actually SCCM behavior?

-Tony

He could, but that's still not the same thing that the client push process is doing or where its failing at. Based on the log snippet, it's failing when its trying to simply set the ACL properly on a file that it copied over to the target client. Ultimately, that doesn't have much to do with actually installing the client even, just getting the proper files in place to kick off the client install process.

Perhaps his AV is getting in the way here?

This was not resolved so not sure why you marked your post as the answer.

What is happening here is that the site created the file \\MACHINENAME\admin$\ccmsetup\MobileClient.tcf. The site then tried to set the ACL of that file to "Generic All" for the Administrators group, "Generic All" for "NT AUTHORITY\SYSTEM" and removing inheritance. This is what is failing.

You can try to do that same process and see if you "push account" really works. From the site, manually connect to the "Admin$" share of the client using the push account, and create a text file in the ccmsetup folder, and then try to change the permissions on the file.

My guess is that the push account does not have permissions for changing ACLs. Also, it could be that you have an anti-virus software that is preventing this process.