My findings after a large ConfigMgr deployment with Site servers worldwide

Last month I did a large ConfigMgr deployment. Last years I did dozens of implementations, but this one was special. This because beside The Primary Site server installation, ten (10) remote Site servers must be installed as well. I did this before also, but only twice on global scale. This time remote Site servers were placed in almost all continents, which is very cool if you ask me :-)

When having locations worldwide (with around 3.000 systems to manage), you must think about low bandwidth and/or high latency issues. Therefore your design must fit, so synchronization works, and OS deployment can be done in almost all continents worldwide. After a few weeks implementation all went fine. In this blogpost I will mention my findings so far. Hope they will be useful.

 

Special tasks provided during implementation:
-Application Catalog (doesn't work out-of-the-box always)
-Asset Intelligence - Licensing (easy to configure, nice to have)
-Asset Intelligence - Software (empty by default, but useful when configured)
-Compliance Settings - Configuration Items and Baselines (empty by default, but useful when configured)
-Monitoring Content transfer (different locations)
-Pull Distribution points (very useful if you ask me)
-Software Metering (doesn't work out-of-the-box always)

Special collections created for overview:
-Departments (all departments)
-Locations (all locations)
-Operating Systems (all operating systems)
-System Type (all system types)
Queries on Computer name, Model and System Type are used.
With all queries available and nested collections, you can create anything you want! :-)

Special tasks provided during OS deployment:
-BIOS Configuration Utility (HP)
-Define Active Directory OU Location
-Define and set Default Timezone
-Keep data & Format disk task sequence
-Set BIOS Password when not available (HP)
-Set Default Management Point (Affinity)

Very cool to see both Pull Distribution points and Management Point Affinity working. Furthermore Rate Limits on Remote Site servers are great to configure bandwidth usage. You can do so much in ConfigMgr, that almost everything is possible :-)

Have a look at "Most wanted features in ConfigMgr requested by customers" for functionality (still) missing in ConfigMgr.

Websites used during implementation:
-SCCM 2012 – Inventoried Software is empty?
-Monitor Virus guard definition level from SCCM 2012 compliance management
-Enable TPM for BitLocker usage during OS deployment on endpoints (part 2)
-How to add devices to different OU’s during deployment
-Chassis Types and query-based Collections (part 2)

Management Point Affinity in ConfigMgr 2012 R2 CU3

Sometimes there are multiple Management points installed for high availability or communication reasons. With Distribution points you set boundary groups to decide with one to use. With Management points they will be randomly selected. This can be seen in ClientLocation and LocationServices logfiles. With Cumulative Update (CU) 3 however there's a possibility to set the Management point also. In this scenario you have MP1 and MP2, where MP1 is forced (for example). Let's have a look at the logfiles after applying the key:
 
Key: HKLM\SOFTWARE\Microsoft\CCM:AllowedMPs
Type: Reg_Multi_SZ
Value Data: <Management point>
 
ClientLocation.log
-Rotating assigned management point, new management point is: 'MP1'
-Assigned MP changed from 'MP2' to 'MP1'
This will be applied daily. (every 25 hours)
 
LocationServices.log
-The MP name retrieved is 'MP1'. MP 'MP1' is compatible
-The MP name retrieved is 'MP2'. MP 'MP2' is compatible
-Retrieved MP 'MP1' from Registry
-Attempting to retrieve lookup MP(s) from AD. Lookup Management Points from AD: 'MP1' and 'MP2'
-Not persisting assigned management point 'MP2' because it is not in the list of allowed MP's
-MP list is forced, ignoring MP 'MP2'
-Default Management Points from MP: 'MP1'

This can be handy when you want to enforce Management points for static systems. For roaming systems this is not recommended, because it will still be communicate with the Management point, even when on another location. Still great to see that Management point can be enforced, when no use of a Secondary site is made.

More information: MS TechNet Blog