Configuration Manager 2012 Gotchas

19 Sep

I have been rolling out a lot of SCCM 2012 deployments lately.  It seems that the addition of Endpoint Protection integrated into SCCM is very enticing to a lot of customers paying someone else for virus protection and pretty much pays for the project in the first year.  That being said here are a few of the common issues I seem to be seeing:

1. BITS 2.5 is not installed on Server 2003 servers – The SCCM client now requires BITS 2.5 as a prereq and it seems that most clients do not have it on their servers.  If they already have a previous version of SCCM then pretty easy to remedy but if not it can be a little tricker.  In a later post I will detail what I have been doing to help the customer get their Server 2003 servers updated.

2. Windows XP SP2 – Another requirement of the SCCM 2012 client is that any XP machine needs to be at Service Pack 3.  Every customer I have visited has had at least some XP SP2 workstations still active on their network.

3. Uninstall passwords for anti-virus agents – The Endpoint Protection agent in SCCM will uninstall some of the more common virus protection agents automatically (Symantec, Trendm McAfee) but most customers have a policy that enforces a password to be entered for uninstallation and if this is still set the Endpoint Protection uninstall/install will fail. Usually this is easily fixed by turning off the uninstall password setting and allowing the clients to get the new policy but when that doesnt work you can easily push registry settings via SCCM to disable the password.  Once that is done the uninstall and following install of Endpoint Protection will complete successfully.

4. Existing WSUS servers in environment – To use the Software Updates features of SCCM you need to install the Update Point role on a WSUS server. The SCCM client will then attempt to set the local policy on the workstation or server to point to this new WSUS server.  The problem is that if there is already a WSUS server and domain level GPOs in the environment pointing to the existing server, these will override what SCCM is trying to set.  When the SCCM client initiates a scan it will fail with an error about a conflicting policy.  There are a few things that can be done here, one is to roll out the SCCM client in a short time period to all workstation and servers and then disable the domain level GPO settings. Be careful that the SCCM client is installed on all systems before disabling the domain level GPO because otherwise the client will have no WSUS settings and may go out to Microsoft and get some updates that you dont want it to have (IE9 for example). The workaround is to set the “Configure Automatic Updates” policy to disabled in a domain level GPO.  With this set the clients cannot go out to Microsoft but all functionality in SCCM still works perfectly.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: