It’s been almost a year since the last release but I just uploaded DISM GUI 3.5 to the Codeplex site this morning. It contains a few background bug fixes and a few new features. For this version I have kept it compatible with the Windows 7 WAIK and DISM version.
- Added Edition Servicing tab
- Added the ability to apply and unattend file
- Added application servicing tab
It’s not a major release but adds most of the features available in the Windows 7 DISM program. You will notice that there is no “online” functionality to allow it to operate on the running OS. That is something I had planned to put in but was proving hard than I thought with the current version. I’m hoping to include that in version 4.0
Speaking of version 4.0. I don’t have a timeframe to release it yet but I do have some of the features planned.
- Online mode – Allow DISM to be used against the currently running OS.
- Windows ADK compatibility – The next version will rely on the Windows ADK and DISM version included in it.
- WinPE compatibility – I am planning on making the next version work inside WinPE.
- Powershell backend – This one is still up in the air but I may convert the backend to the new Powershell cmdlets instead of relying on DISM.exe.
- There might be more features added but this is what I am planning now. If you have a suggestion add it to the Codeplex site.
We recently got in a new HP Proliant BL460c Gen8 blade with the HP 530FLB NIC. It’s a great piece of hardware but using the NIC in WinPE is not much fun. We recently started using MDT to deploy Windows servers now but no matter what I did I could not get the NIC driver to load in WinPE.
Even though the drivers were imported into MDT and I had rebuilt my boot images it would not load. Finally I ran HP’s driver installation utility from inside WinPE and it came up. That’s when I discovered that the NIC needs the HP Virtual Bus Device driver loaded before it can load the NIC driver. Looking at the PnP IDs that the driver supports I noticed they all start with b06bdrv\l2nd instead of the usual pci_<VenID>. This is because the NIC virtual sits on top of another device.
So why not just load the HP Virtual Bus Device in MDT? That’s what I did but the HP Virtual Bus Device is a system-class driver and by default MDT does not copy system-class drivers into the boot images.
Sure you can configure it to add them but then your boot images will get much larger. My solution was to instead put a copy of the HP Virtual Bus Device (evbd.inf) driver into my MDT boot image using the “Extra directory to add” feature in MDT. I also imported the NIC drivers into MDT as I normally do.
Once the boot image loads press F8 to open a new command window. Navigate to the folder you added to the MDT boot image (it should be right off the root) and enter drvload evbd.inf. After a few seconds the driver will load and the NIC should now be active. It’s not an ideal solution but since we don’t deploy a lot of these servers it works for me. This same process would also apply to some of the other Broadcom NICs used in HP blades and servers like the NC373i and NC382i.
I recently upgraded our MDT 2010 Deployment share to 2012 and ran into an issue with USMT 3. We still have some scenarios where we are deploying Windows XP so USMT 3 is required. Whenever we ran a task sequence that needed the USMT 3 files we would get an error that the files could not be found. I thought this was odd since the USMT 3 CAB file was in the correct location. Or at least it was for 2010.
In MDT 2010 you just had to leave the USMT30_x86.CAB file in the DeploymentShare\Tools\X86 folder and MDT took care of the rest. With MDT 2012 you need to create a USMT3 folder in DeploymentShare\Tools\X86 and then unpack the CAB file into this folder. It will not unpack the CAB file for you anymore. Now MDT will be able to find the USMT files and continue.
Hopefully this helps out anyone else that has done an upgrade from 2010 to 2012.
So you are still doing Windows XP to Windows XP migrations using MDT but you have deployed Office 2010. You realize that USMT 3.0 doesn’t support Office 2010 and user’s settings are not getting carried over. Sure USMT 4.0 supports Office 2010 but it doesn’t support Windows XP as a target. What do you do now?
Well it turns out you can use the XML rules files from the USMT 4.0 update with USMT 3.0. All you need to do is put them in the correct location in the MDT Deployment Share. Just make sure that you place the MigApp.xml file in the DeploymentShare\Tools\x86 folder and USMT 3.0 will use the updated files.
I don’t know if this is supported by Microsoft but we have been using it for the past few weeks for some XP to XP migrations and it has worked out well for us.
I was asked by a commenter (here you go Alan!) on expanding on how I use a Make and Model query to automatically assign applications to a specific hardware models. It’s a very easy and powerful feature of MDT and it makes installing those OEM supplied utilities a lot easier.
I’m going to assume that you already have your SSM packages created in your MDT Applications. If not refer to my post on them here.
The first thing you need to do is configure the MDT Configuration Database. There are many articles on the internet that already cover this (including the MDT Documentation) so I won’t rehash that information. One I found particularly good was this one. After you have configured that database and the rules make sure you update your WinPE boot images. If you don’t they will not be able to take advantage of the make and model queries.
Now that your database is configured and you have configured your rules (all explained in the previous link) you can use MDT to dynamically assign applications based on model. In the Deployment Workbench go to Advanced Configuration > Database > Make and Model.
Right click Make and Model and choose New. On the first screen you need to define your Make and Model as is represented in WMI. It’s important that the Make and Model fields exactly match the Name (Model) and Vendor (Make) attributes store in the WMI database. For those that don’t know how to find this information you can use the WMIC tool to display it. The below command returns the Make and Model information from WMI. Note that Name = Model and Vendor = Make.
wmic csproduct get /value
After you enter in the Make and Model information click on the Applications tab. Click Add and choose the SSM application that you want to assign to this model. You can assign as many as you want. Each application that you add to this make and model will be automatically assigned when you choose a deployment task sequence.
Boot from you WinPE image and choose your deployment task sequence. When you get to the screen to choose your applications the ones you previously added to the Applications tab should already be checked.
This is a great way to deploy OEM specific applications in an automated process but you can also do this with any application in MDT.
During our Windows 7 deployment we needed to deploy a customized power plan to our clients. Windows provides an easy way to import and export power plans using the powercfg.exe utility. With a little VB scripting automating the import of the plan through MDT is easy.
Here is the script I was using to import our customized plan and set it to active.
Not much to it really. First we run the powercfg.exe utility with the –import command line to import the file that contains the customized plan. Each time you import a plan it gets a new GUID every time. Powercfg outputs the GUID when the import completes. We capture this line from the output, parse it, and then run the powercfg.exe utility again with the –setactive option to activate our new plan.
Now all you need to do is add a new step to your MDT TS to execute this script in the State Restore phase.
Not too long the decision was made to move to HP laptops from our old vendor. I was tasked with making sure our existing MDT environment could support the HP laptops (8460p and 2560p). Drivers were relatively easy but I did run into some issues with the HP Hotkey Support buttons. These are the buttons that control volume, screen brightness, mute etc.
The SoftPaq from HP consists of both drivers and an application all wrapped up in a single installer. My first attempt was to extract the drivers and then import them into the MDT database. This worked and the drivers installed during setup and I have no yellow bangs in device manager. However only some of the hotkeys worked. My next attempt was to keep the drivers loaded in the MDT database and I would run a silent install after Windows was installed to install the supporting application to control the keys. The installer is MSI based so I thought this would be easy. Make the application default in MDT based on these specific manufacturer and models and I would be golden. Clean, simple, and automated.
After mucking about with the MSI and included MST files I was able to get it to silently install but it never would load the application. The install would complete successfully but it refused to install the application. I even ripped the drivers out of the MDT database and I still had the same issue. If I ran it non silently it would install correctly but this was hardly ideal.
I knew there had to be a way of doing this in some kind of automated fashion. HP deploys these laptops by the thousands. I doubt they pay anyone to sit there and click next all day for this. After doing some more research I found the HP SSM and SDM tools. HP System Software Manager make it super easy to deploy Softpaqs to one or multiple machines. In order to deploy a Softpaq through SSM it needs to be marked as SSM compliant. Most of them are but every once in a while you run into one that isn’t.
First I downloaded the HP SDM and installed it on my MDT management server along with SSM. I used the SDM tool to download the Softpaq for the HP Hotkeys. You could use this for other Softpaqs but I am just going to focus on the Hotkeys for now.
Then I created a subfolder on my MDT server and copied the SSM.exe and SSM.bin files into this subfolder. You should create a share on this subfolder so you can access SSM from any other PC. Next I created a subfolder for the HP Hotkeys Softpaq and copied it into the subfolder. If you are going to deploy multiple Softpaqs I recommend creating a folder for each Softpaq.
Now run the SSM.exe file and accept the agreement. Click next on the welcome screen and you will be asked for the file store directory.
Set it to the subfolder you created to hold all your Softpaqs. If you are going to deploy multiple Softpaqs make sure you set it to the root subfolder. SSM will read each subfolder in the directory structure for Softpaqs. If you did not share this folder before you can let SSM do it for you. Personally I like to control what gets shared on my server so I did it manually. Click Next and then click next again to confirm.
You can set various client options on the next screen. I like to display a status bar while the update is installing. Once you set your options click next.
If you are deploying a BIOS with SSM you are REQUIRED to set a password. Check the box if applicable and click next. Click Next on the summary screen. Finally click the Build Database button to build the SSM database. This will create 2 MDB files that SSM will use to install the Softpaqs. Click Finish to save your changes. You now have a complete package that you can call from MDT to install the Sofpaqs silently.
Now that we have this package how can we use it from MDT? That’s the easy part. SSM has a command line mode that you can use to call it from MDT and install the Softpaqs silently.
Create a new application in MDT. When prompted for the application type set it to “Application without a source files or elsewhere on the network”. Your command line will be \\servername\Sharename\ssm.exe \\servername\Sharename /a /CSPWD:”password” /rb
/A – means accept and install
/CSPWD –password you set when configuring the SSM package
/RB – reboot after the updates complete.
Set your command line options as necessary. In my package I had no password and did not want to reboot so I just used /A. Now when deploying your image select this newly created application. After MDT finishes installing Windows the Softpaq will be added along with any other applications you may have chosen.
In my MDT setup I went one step further and used a Make and Model query to automatically assign any HP Elitebook 8460p or 2560p this Softpaq. This ensures that each time these model laptops are imaged they will receive this application without worrying if the tech forgot to assign it.
Hopefully this helps someone else out there and I’m not the only one that caught by this.
I recently had the need to set mandatory applications based on Task Sequences in our deployments. Even though I had not done that before I expected it would not be that difficult and after some
Googling Binging I found Chris Nacker’s article on this.
It looked pretty straightforward but one thing threw me off. When you get to the screen to select your applications the applications you specify as mandatory will not be checked in the wizard screens. This is because the CustomSettings.ini file is processed by the ZTIGather script before the wizard screens are displayed. Since your Task Sequence has not been chosen yet that variable is not set and the ZTIGather script does not process that section of the CustomSettings.ini. Once you begin your Task Sequence the CustomSettings.ini file is processed again and the applications are made mandatory.
If you place your applications in a section of the CustomSettings.ini (such as Model or Default) that gets processed before the wizard runs they will show as checked with no option to uncheck them.
So just remember just because they aren’t checked doesn’t mean they won’t be made mandatory.
I’ve recently begun using VMware Workstation to test image deployments with MDT 2010 and immediately ran into an issue with the default NIC that VMware Workstation 7 uses.
When you create a new VM and use the XP profile it defaults to using an emulated AMD PCNet NIC. If you choose a Windows Vista or 7 profile it defaults to using an emulated Intel e1000 NIC. None of my MDT LiteTouch images included the AMD driver so I had to go searching for it. I didn’t find the drivers on VMware’s site but I did find it on AMD’s site here.
Once you download the extract the drivers open up your Deployment Workbench. Import them into your Out-of-Box drivers into the correct folder (You are using folders in MDT 2010 right?).
Don’t forget to rebuild your Deployment Share to regenerate your WinPE images.
Now just import the WinPE images into your PXE server or update your boot CD. You can now boot your LiteTouch image on a VMware Workstation 7 VM.