In the previous post I introduced Role Based Access Control in ConfigMgr 2012 as the new way to delegate administrative access to a ConfigMgr hierarchy. In this post I’m going to walk you through a scenario and show you how we can delegate the access in order to meet the requirements.
The Customer is a very large company, which has a Shared Service Center responsible for the ConfigMgr environment. Each OpCo has its own IT department which manage their own servers and workstations. In the past each OpCo had their own Primary Site, and they should now be able to operate the environment in a similar way, while the Shared Service Center manages the environment. With operating you should think about:
- Create Packages and Applications
- Create Task Sequences
- Specify their own Client Settings
- Create Deployments
- Install Distribution Points
The company wants to facilitate sharing between OpCo’s though, therefore objects created by OpCo’s should be able to be shared
One of the reasons to install multiple primary sites in a System Center Configuration Manager 2007 hierarchy often was due to the fact that Administrative access had to be separated between different departments within a company. Within large companies mostly a Central Primary Site would be installed, not servicing any clients, and under that Central Primary Site, several Primary Child Sites would be installed for each OpCo needing their own administrative boundary within the hierarchy.
With ConfigMgr 2012, this has changed for the better. Because Microsoft wanted to simplify the hierarchy for ConfigMgr 2012, they introduced several techniques to partition a Primary Site for use by multiple administrative departments. I often notice though that I have a hard time to convince people of the fact that for security reasons it’s not necessary anymore to create multiple primary sites within a hierarchy. There are of course reasons to create multiple primary sites and a Central Administration Site (CAS) above them, but they are often “non-technical” or due to scaling.
In ConfigMgr 2007 we used Object Access, where we could give a user or group access to either the entire class of object, like all collections. Or you could give access to only an instance of an object, like the All Windows 7 Computers collection. This was a nightmare to manage though, and quickly became very complex in large implementations. More information can be found in the Classes and Instances for Object Security in Configuration Manager for ConfigMgr 2007 article on Microsoft Technet.
During Techdays, the annual event organized by Microsoft in the Netherlands, i had the honor of presenting a session together with Peter Daalmans, Microsoft MVP on ConfigMgr. Our session, named ConfigMgr 2012: Notes from the field discussed what’s new in both ConfigMgr 2012 and ConfigMgr 2012 SP1 and included our best practices and tips & tricks which we discovered during several roll outs of the product in customer environments.
Although the presentation was in dutch, we created our slides in English for your viewing pleasure, click the link to download:
Update: Microsoft has released CU2 for Configuration Manager 2012 Service Pack 1, allowing you to use Boot images based on Windows 7 from the WAIK again (with some contstraints but workable). See the KB 2854009 article for more information. See this article written by Brandon Linton from Microsoft for more information on how to import your WAIK boot image: How to Create and Import a WinPE 3.1 Boot image for use in ConfigMgr 2012 SP1 CU2
VMware’s vSphere 4 doesn’t and will not support running Windows 8 and Windows Server 2012 as a VM on top of its ESXi hypervisor. The reason for this is that the BIOS for the VM’s running on top of vSphere 4 do not meet the Windows 8 Hardware Requirements. You can check vSphere compatibility for Microsoft Windows 8 here. For ConfigMgr this shouldn’t be a direct problem, because we can still install the ConfigMgr roles on top of Windows Server 2008 R2.
When installing ConfigMgr 2012 SP1 or upgrading to SP1, one of the changes introduced is that the Windows Automated Installation Kit (WAIK) isn’t used anymore, and we start using the Assessment and Deployment Toolkit (ADK). And this is were we have a potential issue, because the ADK contains a new boot image based on Windows 8 which will be used to create the new Boot images.
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.
In part 1, I showed you how to enable the Branding to Reg steps, and where you could find the information in the registry. Part 2 showed you how you can extend what information is branded into the registry, and in this part I will show you how you can use Compliance Settings and Compliance Baselines to read this information and create collections in ConfigMgr based on that information.
Using the information branded in the Registry we can use the Configuration Baseline to eventually create collections based on this registry information.
In part 1 of this series, I showed you how to enable the Branding to Reg steps, so that during a Task Sequence some information about the Task Sequence is stored in the Registry under HKLM\Software\Microsoft\MPSD\OSD. In this part, we are going to extend the information which is written to include some information we want to include.
The Branding to Reg and Branding to Reg x64 steps, call two scripts which can be found in the Scripts folder under your MDT Files Package source location. When you open the scripts, you will notice that you can modify which values are written, or which variables you explicitly don’t want written to the Registry during the Branding steps, like OSDJoinPassword for example.
I’m a big fan of integrating the Microsoft Deployment Toolkit into ConfigMgr, but notice that I’m having a hard time to convince my customers (and some fellow Deployment enthusiasts) of the added value. Personally I think that has something to do with the overwhelming added functionality you get. Take for example the MDT created Task Sequence, which looks very complex in the beginning, but once you get the know the MDT generated Task Sequence you will begin to see its added value. I firmly believe that you can have one task sequence per OS type, and from that Task Sequence you can install several configurations.
Ok, so what’s the goal in these series of blogposts.
This post will detail how you can use standard functionality provided in a MDT task sequence, to write some registry values based on variable settings which we can later use to determine under what circumstances a machine was deployed. We are going to modify our MDT Task Sequence in order to enable branding when not using User Driven Installation (UDI), define some custom variables to use and later use Configuration Items, and Configuration Baselines to create Collections based on this information which branded in the registry of clients.
So let’s start.
When you decide to install Applications during your OS Deployment using Configuration Manager, there are some caveats which must be taken into account
Applications installed during a task sequence must be installed completely silent, that means that no user interaction is allowed.
Some points of attention are:
- Task Sequence runs in the context of the System account
- There is no Explorer.exe running during a Task Sequence
- Installation must be fully unattended, no user interaction is allowed
- The installer may never initiate a reboot, it should return return code 3010 for example when a reboot is needed. ConfigMgr will then take care of the reboot when needed.
During many of my project building Task Sequences for customers I’ve build a way to test successful installation of an Application during a Task Sequence.Read More
With ConfigMgr 2012 there are 2 packages used to install the ConfigMgr client. The first package which is called the Configuration Manager Client Package can be found under the Packages node of the Software Library and is used during OSD in the Setup Windows And ConfigMgr step to install the ConfigMgr client. The other package, which is hidden is called Configuration Manager Client Upgrade Package and this package is used when the Client Upgrade feature of ConfigMgr 2012 is enabled. The fact that this package exist can only be determined by looking at the Content Status under Distribution Status in the Monitoring pane for example.
The Client Upgrade functionality provided in ConfigMgr 2012 can be used to upgrade existing ConfigMgr clients already assigned to your Site to a new version. The functionality is not suitable if you have many clients, because it’s an on/off option without any further control in terms of scheduling or collection scoping.
If for some kind of reason the Configuration Manager Client Upgrade Package gets deleted, you cannot recreate it by creating a new one from a package definition file, like you could do with the Configuration Manager Client Package.
Normally when the Configuration Manager Client Upgrade package is deleted, this should be detected and should be regenerated automatically, but if it doesn’t you can create a empty file with the name client.acu and place that file in the inboxes\hman.box folder at the top-level site (either your CAS or PSS). After that check your hman.log to check whether the Client Upgrade package gets updated.