First published on TechNet on May 18, 2015
A while back (and longer than I’d like to admit), I wrote a post on getting started with Windows Deployment for Windows Server or Windows client using the Microsoft Deployment Toolkit. I’ve helped many customers since then setup and use MDT in their environment. Many of these engagements are a result of Windows Server 2003 end of support quickly approaching and customers wanting to spend as little time as possible on the actual operating system build process. For those of us keeping track, this is set to occur on July 14 th , 2015 or 64 days from the writing of this post.
Some of you may asking what end of support means. To summarize, it means:
-
No updates. 41 critical security updates were released for Windows Server 2003 in 2014 alone. No updates will be developed or released after end of support.
-
No support. As an engineer, we’re not allowed to talk to you about any issues involving Windows Server 2003 after July 14 th (unless you’re trying to migrate off of Windows Server 2003).
-
No compliance. Windows Server 2003 servers will not pass a compliance audit.
Why do we always talk migration and not performing in-place upgrades?
-
Migration provides a transition path. A transition from x86 to x64. A transition from physical to virtual (and vice versa). Additionally, it provides more control.
-
Migration provide a clean operating system install. Migration allows you to target what you want to move over and don’t want to move over. It gives us the opportunity to get rid of stale data, settings, applications, and more from over a decade ago.
-
Migrations reduce the risk and downtime. The operating system installation and most migration tasks take place while the source server is still live. This also gives us the opportunity for verification and performance benchmarking prior to bringing the target server online. Lastly, it gives us a rollback option. If things do not go well, we can roll back to the source server.
Migrations are a good thing. Don’t get me wrong. We fully support in-place upgrades. But keep in mind the following when considering an in-place upgrade:
-
You cannot upgrade between architectures. Most Windows Server 2003 instances are 32-bit installs. Windows Server 2008 R2 and later are only 64-bit.
-
You cannot upgrade from Windows Server 2003 to Windows Server 2012 R2.
Migration is a great time to do some spring cleaning, to take the opportunity and step back to look at what the future state of your standard operating environment should look like, and to ensure the foundation (i.e. Windows Server 2012 R2) is healthy and optimized for your environment.
So why am I helping so many enterprises setup MDT in their environment?
-
Ease of automating the build process for Windows Servers (or clients)
-
Ease of integrating all the security updates until that point of time into a custom image
-
Ease of customizing the deployment
-
Removing end user configuration error
-
And it fully integrates into System Center Configuration Manager should you decide to pursue that venture at some point in the future
And the latest trend, MDT helps provide consistency across both virtual and physical servers.
-
Instead of maintaining an image for your physical servers and a template with an image for your virtual servers, the latest trend shows customers moving to a single deployment method where templates are used to setup the actual virtual machine settings and configuration, but MDT is used to deploy the image. Why do this? In short, it provides consistency across both virtual and physical environments.
-
Instead of two different processes, we have one.
-
Instead of maintaining the operating system in an image for physical servers and maintaining the operating system in the template for virtual servers, we maintain it in a single location.
So if you haven’t read my post on getting started with MDT, I certainly encourage you to do so. MDT won’t help your remediate your problem applications, but it will help you get Windows Server more quickly out the door with less manual steps needed as part of the build process. The getting started post is linked above or can be found here:
I’m expanding upon that original post by request by beginning with selection profiles. Selection profiles were mentioned in my original post as one of the reasons for a well-defined folder structure in MDT.
Paul D, this one’s for you. Sorry it has taken me so long. I hope you find as much value in this post as you did in the original post.
So what are selection profiles anyhow?
A couple quick facts about selection profiles:
- Selection profiles allow you to filter the content you have added to MDT.
- Selection profiles give you more control.
- Selection profiles only work with folders.
- Selection profiles allow you to select one or more folders you’ve created in MDT workbench to use for various activities.
- Selection profiles are found under the Advance Configuration node in the MDT Deployment Workbench.
We actually create some default selection profiles for you:
If you look around, you will find them referenced in various places.
Like in any of our default Task Sequences during driver injection:
Or under our Windows PE Drivers and Patches settings:
Linked deployment shares, Media…they all use selection profiles.
So why use selection profiles?
It’s all about control, control, CONTROL and who doesn’t want more control? J
You can:
-
Control which drivers and updates are used when creating your boot image
-
Control which drivers are used during driver injection in your task sequences
-
Control what is replicated to your linked deployment shares
-
Control what is included with your media deployments
With Selection Profiles, you can control what we use or don’t use based on our folder structure.
They’re super easy to create and setup. You do need your well-defined folder structure in place. You’ll quickly find that you can only select or not select at the folder level. To create custom select profiles, simply right-click on Selection Profiles, choose New Selection Profile, and walk through the wizard. Here are some examples I’ve recently experienced onsite of when selection profiles have come in handy:
In March of this year, I was onsite and when deploying an image, it would fail prior to the first reboot. MDT would format the drive, apply the image, and then we would see it hang when applying the unattend.xml suing DISM. It would sit there for a while and would then fail with the lovely and generic error shown below:
So what would your guess be?
I automatically thought drivers (after all, isn’t it always the drivers?) and we spent a good chunk of time eliminating that.
Then I thought our base image (we were in the process of building a custom image) was corrupt. More time spent there.
Then we recreated the Task Sequence just for grins.
But we still failed.
So I stepped back and looked at what we hadn’t eliminated yet through our process of elimination. And you know what the answer turned out to be? Packages.
The customer had added some packages for an image he created for a new operating system that were erroneously being injected during our installation in Preinstall phase shown below:
So what did we do to fix this? We placed the updates for the newer OS in a separate packages folder and the updates for the OS we were deploying into its own folder like so:
Then we created a selection profile like so:
Then updated our Apply Patches to use the new Selection Profile. Problem solved!
Another example, Windows PE automatically includes all network drivers, mass storage drivers, and packages as part of your boot media as shown below:
However, occasionally WinPE will require specific drivers just during the WinPE phase or will require specific drivers to be excluded just during the WinPE phase. As an example, wireless network drivers. We don’t support deploying an operating system over wireless. Why include them in your boot image. It could only cause potential problems. Instead, create a folder for WinPE drivers under Out-of-Box drivers that includes only the network and storage drivers required during deployment and create a selection profile for WinPE drivers. An example, when booting from the MDT boot image, a CMD shell would pop up just after the Post Install phase right before we reboot. This breaks the automation as we have to close the CMD window that is automatically opened. This is traditionally the result of a failure installing a device into WinPE and sure enough, we see the following failure in the wpeinit.log for a wireless adapter that we couldn’t care less about at this point during the deployment:
2014-12-04 19:13:34.247, Info ==== Initializing Network Access and Applying Configuration ====
2014-12-04 19:13:34.247, Info No EnableNetwork unattend setting was specified; the default action for this context is to enable networking support.
2014-12-04 19:13:34.247, Info Global handle for profiling mutex is non-null
2014-12-04 19:13:34.247, Info Waiting on the profiling mutex handle
2014-12-04 19:13:34.262, Info Acquired profiling mutex
2014-12-04 19:13:34.942, Info Install MS_MSCLIENT: 0x0004a020
2014-12-04 19:13:34.942, Info Install MS_NETBIOS: 0x0004a020
2014-12-04 19:13:35.239, Info Install MS_SMB: 0x0004a020
2014-12-04 19:13:35.784, Info Install MS_TCPIP6: 0x0004a020
2014-12-04 19:13:36.775, Info Install MS_TCPIP: 0x0004a020
2014-12-04 19:13:36.775, Info Service dhcp start: 0x00000000
2014-12-04 19:13:36.775, Info Service lmhosts start: 0x00000000
2014-12-04 19:13:36.978, Info Service ikeext start: 0x00000000
2014-12-04 19:13:37.103, Info Service mpssvc start: 0x00000000
2014-12-04 19:13:37.118, Info Service mrxsmb10 start: 0x00000000
2014-12-04 19:13:37.118, Info Released profiling mutex
2014-12-04 19:13:37.118, Info Spent 2859ms installing network components
2014-12-04 19:13:38.528, Info Installing device sd\vid_02d0&pid_4324&fn_1 X:\WINDOWS\INF\bcmdhd.inf failed with status 0x80070002
2014-12-04 19:13:41.076, Info Installing device usb\vid_0424&pid_7500 X:\WINDOWS\INF\oem0.inf succeeded
2014-12-04 19:13:41.545, Info Installing device root\kdnic X:\WINDOWS\INF\kdnic.inf succeeded
2014-12-04 19:13:44.310, Info Spent 7204ms installing network drivers
2014-12-04 19:13:44.310, Info STATUS: FAILURE (0x80070002)
The answer is again, selection profiles to control which drivers we’re using in our boot image. We can do this by:
1. Creating a WinPE Drivers folder under Out-of-Box Drivers in MDT Workbench and importing the necessarily network and storage drivers into this folder.
2. We then create a selection profile specifically for WinPE Drivers as shown below:
3. Instead of using the default All Drivers and Packages for drivers, we then use the newly created WinPE Drivers selection profile:
A third example involves driver conflicts.
What if you have similar hardware that uses very similar, but different drivers? Or you’re deploying a legacy operating system like Windows Server 2008 R2 or Windows 7 where the hardware requires specific driver versions that are not the latest driver versions you have added to the MDT Workbench for the more current version of the operating system that you are also deploying? Driver conflicts like this are difficult and time consuming to troubleshoot. If you run into a scenario where the hardware you are deploying to is either
-
Picking up the wrong driver
or -
Picking up the wrong version of a driver
Then selection profiles may help.
You can use any number of WMI queries to determine what is needed to run a specific step in a Task Sequence. On each Task Sequence step, we have an Options tab. This Options tab is important for many reasons.
-
We can disable a step in the Task Sequence
-
We can continue on error (useful when installing applications or Windows Updates and don’t necessarily want your Task Sequence to halt if one of them fails)
-
We can add any number conditions for that specific step. This is useful with drivers, but it can also be useful in a number of other ways such as application installs, partitioning schemes, and much more.
I often use the Query WMI option during the driver injection step to control which drivers I install based on the Selection Profile.
To find out your syntax for WMI, you can use the following command or reference MSINFO32:
WMIC ComputerSystem GET Model
Here’s an example for a Dell PowerEdge M710. Let’s say I have problems with this version of the driver causing conflicts for the other hardware I deploy. All my other drivers play nicely together, but when I add this specific one, it causes problems for my other machines. What would my steps look like?
1. Create the appropriate driver folder structure. In this case, create a separate folder for the problematic driver. I called mine M710:
2. Create a Selection Profile
3. Open my Task Sequence and add an additional Inject Drivers step.
Now why am I adding an additional step instead of just modifying the one that is already there? Well, in my case, I do not want a separate Task Sequence for this one problematic driver. I want this model to use this driver and all my other hardware to use the normal PNP driver injection. So what I’m going to do is run my Dell Driver Injection step first and then follow it up with the normal Inject Drivers step.
I like to rename my steps when adding additional steps so that I know what I am doing in my Task Sequence without having to click on the step. When I’ve finished adding my additional Inject Drivers step, it looks like this:
4. Run WMIC ComputerSystem GET Model to get the model information for the query or look it up online.
5. Write your WMI query. I write my WMI query as follows (numerous examples of WMI queries appear online):
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE %M710%
6. Add the query as a condition on the Options tab of the Inject Driver step and click Apply:
7. Test to verify it works as expected.
Here’s another example I’ve used quite a bit recently when using a single Task Sequence to deploy both physical and virtual servers. What if you want the VMWare drivers or software to install only on your virtual servers? You can use the following query for any Inject Drivers, Format and Partition Disk, or Install Applications step:
SELECT * Model from Win32_ComputerSystem where Model = "VMware Virtual Platform"
Take a look at Bill Spears’ post for another option using the Rules tab (aka the customsettings.ini) in MDT: http://blogs.technet.com/b/askcore/archive/2013/05/09/how-to-manage-out-of-box-drivers-with-the-us...
Selection Profiles with Media Deployments
I’ve had several advisory calls and onsite engagements here recently where I’m surprised to learn that the engineers are not familiar with Media Deployments.
Media can be found under the Advanced Configuration section of MDT:
Media should be more aptly named, “Offline Media” because that is exactly what it is. Media will allow you to deploy your same custom image in an environment without any network connectivity or internet access. When you create a media deployment, you use a selection profile to tell MDT what all you want included in the media. Let’s walk through this.
Here’s my scenario. I have several remote branch offices where I need to deploy Windows Server 2012 R2. These branch offices have a lousy internet connection. It would be painful to install any operating system over the network and since these branch offices only have a server or two, I really do not want to place a Linked Deployment Share locally. Media would be a good fit for this scenario.
1. First create a selection profile. Selection Profiles are important with Media deployments as we can limit what we include as part of our media and decrease the size of the Media deployment. I know at a bare minimum I need an operating system and a Task Sequence, but other than that, it is up to me on whether I select additional applications, drivers, packages, etc. I want my Media deployments to match my network deployments as much as possible. Therefore, I want the same custom operating system to be installed with the same applications and packages and I also want to make my drivers available as well.
My selection profile looks as follows:
I also have my Windows Server 2012 R2 Packages selection and my Window Server 2012 R2 post-deploy applications selected, but this cannot be seen due to scrolling.
2. Right-click on Media and select New Media. This pops open the New Media Wizard. Supply a path where you want the media to be created (it cannot be the MDT share), and choose the Selection Profile you created in step #1.
3. Click Next a couple times and Finish to complete the wizard.
4. When it is done, you’ll have something that looks like the following under Media. It may look like it is done creating, but it is not. You can think of this as creating the necessary folder structure:
5. Right-click on your media and choose Update Media Content to generate the offline media. This takes some time.
6. After it completes, if you use File Explorer to browse the folder location, you should have something that looks like the following:
So what do we have here?
LiteTouchMedia.iso – Bootable ISO that can be burned to DVD (if not too large) or mounted in a VM.
Content folder – This folder contains everything you need to create a bootable UFD or USB hard disk. This is the more common scenario. It does require that you format the device NTFS if your image size is over 2GB due to FAT32 limitations. But once you have it formatted correctly, all you need to do is copy the contents of the Content folder directly to the USB hard drive. Then simply insert the USB at boot and as long as the hardware is capable of booting from USB, you will see the familiar MDT LiteTouch wizard and can continue your deployment without any connection to the MDT deployment share :
As you can see, selection Profiles are quite useful. Don’t be afraid to use them to control as little or as much as the deployment process as you like.
For more MDT goodness, make sure to check out Hilde’s MDT blog posts:
And don’t forget Hilde’s posts for more great deployment fun:
Cheers,
Charity “Deploy Happy” Shelbourne