jleclerc

Sorry for the delay in my follow-up. It turns out it was mainly a "me" problem. During my initial configuration phase, I configured a GPO for the autoenrollment of client certificates but for testing purposes I limited the deployment of my new sccm gpo to a single test OU. By the time I enabled the automatic client push, I had forgotten about that. Don't I feel stupid Linked my sccm gpo to the appropriate OUs and eventually the client computers obtained a certificate and sometime after sccm succeeded in pushing out the client. As users came back from the weekend, the number of deploy sccm clients has been increasing. Microsoft states: "If the site server cannot contact the client computer or start the setup process, it automatically repeats the installation attempt every hour for up to 7 days until it succeeds." so FN-GM was right about the possible need to delete old discovered that doesn't have a client yet, SCCM may have already given up on trying to install the client. On a side note, I noticed that no XP machines showed up in sccm. Turned out to be that our XP systems were not getting the autoenrollment certificate. Did some research and found out that it's a known issue when using a Windows Server 2012 issuing ca. Disabling the IF_ENFORCEENCRYPTICERTREQUEST interface flag resolves the issue. To disable the IF_ENFORCEENCRYPTICERTREQUEST interface flag use the following command on the issuing ca: certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST Source: Windows Server 2012 CA will not allow Windows XP to autoenroll To answer my own questions: 1) Any idea what my problem might be? automatic client push couldn't push the sccm client because our sccm solution was configured to use ssl and the clients where not getting their certificate. By the time I was checking, sccm had already given up pushing the client. Deleting 1700 devices in sccm that didn't have the client and letting sccm rediscover them and attempt to push the client resulted in lots of log entries which was useful. Some clients had no trace information on the install attempts (turns out to be a rare thing) while others had relevant information in their ccmsetup.log file 2) Any idea exactly which sccm log files would contain information about the automatic client push? Check the ccm.log file on the server as the SMS_CLIENT_CONFIG_MANAGER component is the one that handles the client push. Also, as free780 stated, check the ccmsetup.log file on the client computer, you will sometimes find more relevant information there than on the server logs. If you don't see the ccmsetup setup and log file, check several other client system. The odd thing is that the server pushes the client installer via the admin$ share BEFORE there's a needs for the certificate to be in place on the client computer. So I'm not sure why on a few clients I wasn't seeing anything. 3) When a device is discovered, is the client automatic client push installation immediate? or is it schedule to happen later? The push is immediately attempted but that doesn't mean you'll see it immediately. Thanks for the help.

Hi, FN-GM: - Deleting one of the discovered device and letting sccm rediscover it is something I tried already. Unfortunately that didn't work for me. - Before I left work friday I deleted all the devices that didn't have the client installed. As far as I can tell, the ones that have been rediscovered still don't have the client. free780: - The two accounts in question that I use are domain admin accounts. The policy is set to allow domain admins access to the client computers. The client computers are configured to allow access to the sccm server access to the admin$ and c$ share. The domain admin group is part of the the local administrators group on the client computers and the sccm server. That's interesting I just checked a few random client computers. some of them now have the c:\windows\ccm folder and the modified date on it is 3 hours ago. So now I'm actually seeing activity client side which is not something I saw before. Looking at the server log file ccm.log, I'm seeing lots of activity now. I'll give a day or so but so far it's looking good. I'll post of follow-up later. -jleclerc

I'm out of ideas trying to get automatic site-wide client push installation to work on SCCM 2012 SP1. The discovery seems to work fine, manually pushing out the client works fine but the automatic client push doesn't seem to work. In point form here's the situation: - Had an SCCM2007 Essentials deployment but used only for hardware inventory. We decided to retire it and not migrate the data. - Using SCCM 2012 SP1, single site server with SQL 2012 Standard - Boundaries are configured for our AD site and IP subnets - Boundary Groups containing the Boundaries are set to "Use this boundary group for site assignment" with the correct "assigned site" (there's only one option available) - Domain admin account used as the client push installation account. - For the purpose of testing some of the client computers that are discovered but aren't automatically getting the agent installed are located on a subnet that the sccm server will allow through it's firewall without restrictions - Right-clicking on any of the PCs in devices and choosing "Install Client" works perfectly. - We have some apple computers on site and manually installing the sccm client on the macs works fine. As it should. - The Client Push Installation Properties for the site is as such: Enabled Selected Workstations. Did not select Servers and Configuration Manager site system server (Note that the sccm server already have the client installed and working) Domain controller install is set to Never. Installation property only has the SMSSITECODE defined - Tried two different domain admin accounts - Can't even figure out what logs the automatic client push is suppose to use. Assumed it would be ccm.log but I can't find anything about any attempts to deploy the client automatically. - Check the client computers (where the automatic client push is suppose to happen), it's got no ccmsetup folder and recorded all ip traffic to/from it (specifically from the sccm server), nothing. Note that this computer has an sccm client for our old sccm installation. The old ccmsetup folder was delete prior to testing. - One suggestion I read was to deleted all the device that don't have the client and let sccm rediscover it, did that, still no automatic client push. - On one of my google searches, found a suggestions about checking the v_CP_Machine db view. The only entries in that view are the devices that have the clients installed. So that's not the issue either. I'm open to suggestions. Any idea what my problem might be? Any idea exactly which sccm log files would contain information about the automatic client push? When a device is discovered, is the client automatic client push installation immediate? or is it schedule to happen later? I'm tapped out, it's a good thing it's friday

Hi Matthew, A patch will keep the same KB number regardless of the operating system it's destined for. However there is no KB2835393, KB2804576 or KB2840628 for Windows 2012. These are .NET Framework 4.0 patches and Windows 2012 comes with .NET Framework 4.5. I'm looking at my WSUS server and the Server 2012 .NET Framework 4.5 patches for July patch Tuesday would be: KB2833958 and KB2840632 Try removing those two patches and let us know. -Joey

I was in the middle of deploying a new sccm2012 sp1 solution, so naturally I figured I made a mistake with the work I was doing. Turns out Norphy was right on. The same StateSys.log messages showed up every hour in the logs. Don't know about the task sequence problem as I haven't configured those yet but I was also having problems with Application Management ==> Applications. Attempting to modifying anything within an application's configuration resulted in a generic error. Attempting to add a new application also resulted in an error at the end of the wizard. I uninstalled patch KB2835393 and KB2804576, but the problem was still present. Investigated further and found a third .NET Framework 4.0 patch got installed on the same patch Tuesday, KB2840628. Uninstalled that third patch, rebooted sccm and the problems went away. Thanks a bunch Norphy. -Joey