One of the most time consuming tasks when working with OS Deployment in ConfigMgr is implementing the drivers needed to support different hardware models. There are a couple of reasons for this:
- Determining if drivers installed correctly can only be determined by executing an actual Task Sequence, which takes a lot of time.
- Each Hardware Manufacturer has its own way of providing drivers. Finding the right driver can be a real nightmare and some Hardware Manufacturers make a real mess of the drivers they provide. On the other hand there are some manufactures which supply driver packages which you can import directly into ConfigMgr.
- Especially for laptops, which contain a lot of extra features in the hardware, manufactures make it a sport to keep the optimal configuration which consists of the needed drivers plus additional software as vague as possible, so it’s up to you to find out which drivers and driver applications make the laptop fully functional. Don’t we have a nice job 🙂
- Some HW manufacturers are known to change the hardware inside different batches of the same hardware model, make sure that you make agreements with your HW supplier that the HW doesn’t change with each delivered batch of machines, or you will continue to spent time on certifying HW models.
Before just simply starting I recommend you to create a strategy for implementing and maintaining the drivers within your company. What follows below are some guidelines which can help.
I’m currently working on a project where we implement a new ConfigMgr 2012 hierarchy in a forest where several ConfigMgr 2007 hierarchies already exist. The new ConfigMgr 2012 environment will be installed in a new domain within that existing Forest and we will not migrate any content from these ConfigMgr 2007 environments, but install every client using the OSD functionality of ConfigMgr 2012, but other deployment methods could be necessary for special scenario’s.
Even though this isn’t such a common scenario, I think the results of the test provide some insight on what you can expect in your own migration from ConfigMgr 2007 to ConfigMgr 2012, therefore I decided to share my findings. I hope it will be useful for someone reading this article.
Because one of the requirements for the implementation of ConfigMgr 2012 is that the impact on the existing environment should be as minimal as possible we did some test on what would happen if a ConfigMgr 2007 client would assign itself to a ConfigMgr 2012 environment and possible ways to prevent that.
- Install a ConfigMgr 2007 client when conflicting boundaries are configured on both ConfigMgr 2007 and ConfigMgr 2012
- Install a ConfigMgr 2007 client when there is only a boundary group with corresponding boundary defined in ConfigMgr 2012
- Install a ConfigMgr 2007 client and see what happens when it assigns to the ConfigMgr 2012 site and automatic client upgrade is turned on
- Install a ConfigMgr 2007 client and see what happens if only a boundary for Content Location in ConfigMgr 2012 is defined.
First there are some known and documented rules which we need to take into account:
A ConfigMgr 2012 client cannot attach itself to a ConfigMgr 2007 site. During Automatic Site Assignment, the ConfigMgr 2012 client will do a version check and when the site it tries to attach to isn’t at the correct level, it will fail to assign to that site.
In order to test the scenario’s, we build the following test environment
ConfigMgr 2007 Primary Site (pss1.nl.domain.local) in the NL child domain, with code N01
ConfigMgr 2012 Primary site (pss2.emea.domain.local) in the EMEA child domain, with site code E01