This November I will be in New York for a unique, 2 day workshop in New York on how to Deploy Windows 7 with WDS and MDT 2010 Lite Touch. This workshop will show you how to get the most out of the free deployment tools from Microsoft and give you invaluable guidance on how to migrate to Windows 7. You can expect a lot of live demos, tips and tricks.
What you get:
– 2 days with real information from real world deployment experts
– A workbook packed with guidance and additional material
– Videos of the demos that you can play over and over again
The Multicast feature in WDS can be used to transfer any file over the network. In my work, since I present trainings from time to time, I need to deploy (large) virtual machines to a bunch of the clients, and for that I use multicast.
Step 1 – Create the WDS name space (enabling a folder for multicast)
In this example I have stored compressed (winrar) version of my virtual machines in a folder called D:\Exported_VMs on my server. One of the vm’s is named DC01.rar.
So we need to create a new namespace name for files in the D:\Exported_VMs folder (note that the folder needs to exist to create the namespace). Use the following command:
WDSUTIL /New-Namespace /NamespaceType:AutoCast /Server:MDT01 /FriendlyName:”Really Large Files” /Namespace:”Really Large Files” /ContentProvider:WDS /ConfigString:D:\Exported_VMs
Step 2 – Get the files via multicast on the client
Then, on the client, to get the large files via multicast First, allow the wdsmcast.exe in the firewall rules (inbound rule), and run the following command.
Note that target folder must exist, otherwise wdsmcast fails.
The wdsmcast client runs best, and is only supported, in WinPE, but you can also start it in the running operating system. That however is not supported and has proven, at least in my testing, not being as reliable as running it in WinPE.
I had the opportunity to go onsite for a training this week, and when preparing the machines for the training they all crashed when the hyper-v role was deployed. After some investigating we narrowed it down to the video driver, when using the Standard VGA driver everything worked, but as soon as we added the (Intel) video driver – the machine crashed.
These were Intel i5 CPU machines, and we already had the 975530 hotfix deployed (needed for i5 and i7 CPU’s). But we still got the crash.
SP1 (beta) for Windows Server 2008 R2 solved the problem, and we had no issues for the entire training,,,
If you have certain domain policies, like renaming the administrator account or setting a legal disclaimer at login, those policies will break MDT 2010. Group Polciies that deploy application may also fail if they are executed when the task sequence is running.Here are some workarounds…
Option 1 – Use a Staging OU
Use a Web Service to move the computer account to a staging OU during deployment, and move it back to the production OU when deployment is completed. Maik Koster has a great post about that:
Option 2 – Prevent the Group Policy to apply as long as the deployment is running
I have seen quite many ways for this, all from creating additional variables to check for, to modifying the built-in script. The simplest solution I have found is simply to add a WMI filter to the Group Policy, so that it does not apply until the deployment is done.
The obvious way would be to check for the existenece of the C:\_SMSTaskSequence folder, but due to the way WMI filter works (or rather not works) it’s better to check for the existence of the C:\Windows\Temp\DeploymentLogs folder. That folder is not created until deployment is completed.
Create thw following WMI Filter and link it to the Group Policy
Select * From CIM_Directory Where Name = ‘C:\\Windows\\Temp\\DeploymentLogs’
Note: Make sure that you don’t have such folder in the wim you are deploying…
Option 3 – Postpone the domain join process
I do like option 1 the best, but yet another solution is to postpone the domain join process. Here is a good article by Keith Garner that explains how to do this.
The Windows 7 and Windows Server 2008 R2 SP1 Beta helps keep your PCs and servers on the latest support level, provides ongoing improvements to the Windows Operating System (OS), by including previous updates delivered over Windows Update as well as continuing incremental updates to the Windows 7 and Windows Server 2008 R2 platforms based on customer feedback, and is easy for organizations to deploy a single set of updates.
The Windows 7 and Windows Server 2008 R2 SP1 Beta will help you:
Keep your PCs supported and up-to-date
Get ongoing updates to the Windows 7 platform
Easily deploy cumulative updates at a single time
Meet your users’ demands for greater business mobility
Provide a comprehensive set of virtualization innovations
Provide an easier Service Pack deployment model for better IT efficiency
The public beta is best suited for IT pros, tech enthusiasts and developers who need to test the service pack in their organization or with the software they are developing.
In order to download and install the Windows 7 and Windows Server 2008 R2 SP1 Beta you must currently have a Release to Manufacturing (RTM) version of Windows 7 and Windows Server 2008 R2 already installed. The Beta is available in English, French, German, Japanese and Spanish.
Please be aware of that the rule processing has changed a bit, meaning you may need to add rules for wizard panes you did not have to in the RTM version of MDT 2010.
As a good example, my good friend Mikael Nystrom (fellow MVP) just called on his way back from a customer, where he had to troubleshoot (and fix) an upgrade they tried.The error they got after upgrade was the infamous “Error: 500 = Variable is undefined” message. After adding the /debugcapture switch Mikael figured out it was a variable missing.
In this case the SkipPackageDisplay=YES was missing in customsettings.ini. The customer didn’t have any packages, but in MDT 2010 Update 1 they still needed to set the variable to skip the pane.
If you plan to upgrade to MDT 2010 Update 1, do the following,
1. Make a copy of your deployment share (if possible to a lab server)
2. Install MDT 2010 Update 1
3. Upgrade the deployment share
4. Test
5. If test is succesful, repeat step 1,3 and 4 for the other deployment shares
Quite a few people have asked me how to retrieve the computer description value from the MDT database or the deployment wizard, then store it in Active Directory and on the local machine, system properties. So, I decided it was time for a new blog post…
This sample does not require a web service; however, if you don’t mind using a web service, you can always use Maik Kosters excellent guide:
1. Get the Computer Description value. 2. Store the Description value on the computer object in Active Directory 3. Store the Description value on the system properties of the local computer
When you start the deployment wizard, the configure computer name screen will look like this:
Option 2 – Setting the value in the MDT database
If you have set the value in the MDT database, you need to query the ComputerIdentity table (because the built-in view doesn’t list the description value) or update the view. In this example, I query the ComputerIdentity table directly.
You need to add a custom property into customsettings.ini for the description property. I selected to also to set the ComputerDescription value. We are consistent with using the wizard that sets that value. Another option is to take care of that in the scripts, checking for either Description or ComputerDescription values. Still, it’s a bit easier simply to set ComputerDescription as the Description value we get from the database. Configure your customsettings.ini with the following:
Step 2 – Store the Description value on the computer object in Active Directory
Download the sample scripts.
Copy ZTISetComputerDescriptionInAD.wsf to the scripts folder in your deployment share.
Create a custom action in the State Restore phase; any place will do; I added the action to the Custom Tasks group. Use the following settings: Type: Run Command Line Name: Set Computer Description in Active Directory Command: cscript.exe “%SCRIPTROOT%\ZTISetComputerDescriptionInAD.wsf” Runas: Load the user’s profile: Selected
Note: The account you use must have permissions in Active Directory to modify computer object attributes.
Step 3 – Store the Description value on the system properties of the local computer
Download the sample scripts.
Copy ZTISetComputerDescriptionLocally.wsf to the scripts folder in your deployment share.
Create a custom action in the State Restore phase; any place will do; I added the action to the Custom Tasks group. Use the following settings: Type: Run Command Line Name: Set Computer Description Locally Command: cscript.exe “%SCRIPTROOT%\ZTISetComputerDescriptionLocally.wsf”
When deploying Windows XP there a few tricks you can use to do the following.
1. Have a single image for all your machines
2. Inject storage drivers offline, eliminating the need for rebuilding your image.
The areas that you may want to use unsupported tweaks for are the following:
HAL Replacement
In 2005 I wrote my first general purpose script for HAL replacement, and back in 2008 it was still the most downloaded script on the myitforum website. The most up to date script for HAL replacement (that I know of) is maintained by Michael Petersen in Denmark
If you create an image on a machine with Intel CPU you quickly find that it will bluescreen when deploying it to a machine with AMD Cpu. The reason is that the intelppm service doesn’t work very well with AMD Cpu’s (who would have guessed 🙂 ).
One workaround is to have a script detecting the CPU type, and disable that service when deploying to AMD machines.
Another method is simply deleting the IntelPPM.sys file in C:\Windows\System32\Drivers
Note: If deploying via MDT 2010 and/or ConfigMgr 2007 you need to update the script to reflect the correct path of the registry hive.
Offline injections of Mass Storage Drivers
In Windows XP, injecing storage drivers offline is not supported, unless you use ConfigMgr 2007, then it suddenly is … Mr David Ruhle has put together a nice script that does offline injection for Windows XP…
Another fun day at work… Spend some time troubleshooting the Install Language Packs Offline feature in MDT 2010 Zero Touch.
First of all, the MDT 2010 documentation is incorrect, the Install Language Packs Offline feature is supposed the be added before the Setup Windows and ConfigMgr action, not after.. But that one I knew about already…(it will be updated for docs in MDT 2010 Update 1),
The issue I was having was the ZTIPatches.wsf run successfully, but no language packs where installed. The ZTIpatches.log file revealed an error code 14 in it (but still said successful). No luck there…
But after reviewing the BDD_pkgmgr.log.txt (thanks Ashwin for pointing out), I found something interesting… see below
2010-06-23 22:50:59, Info CBS Failed to submit the Windows Error Report. [HRESULT = 0x800705aa – ERROR_NO_SYSTEM_RESOURCES]
00000d40 (F) STATUS_NO_MEMORY #4690359# from CCSDirectTransaction::PrepareForCommit(…)
2010-06-23 22:50:59, Error CSI 00000d40 (F) STATUS_NO_MEMORY #4690359# from CCSDirectTransaction::PrepareForCommit(…)[gle=0xd0000017]
The answer… Memory… The virtual machine I was testing on only had 512 MB of memory, after increasing to 1024 MB everything worked fine… So, shorthand, the Install Language Packs Offline features requires more than 512 MB of RAM, even on x86 Windows 7.
