Premier Workshops – Windows 7 Deployment

For the next couple of days I’ll be attending a Microsoft Workshop for Premier Clients about Windows 7 Deployment.

Our host will be Rui Cascalheira, a Technical Account Specialist at MSFT Portugal.

I hope to get a lot of information to share here with everyone.

By the way, here are the topics we’ll talk about:

• Technical Highlights
• Understand the WIM File
• Discover the new Setup and Deployment Tools for Windows 7
• Create and Maintain the Windows Deployment Services Role
• Create and Deliver Custom Install Images
• Discover the Microsoft Deployment Toolkit
• Hard Link Migration from Windows XP to Windows 7

New Microsoft Deployment Toolkit Forum at TechNet

Microsoft as recently launched a new forum on TechNet Forum, specifically created for Microsoft Deployment Toolkit.

This forum counts with people from Microsoft that is currently working on MDT product group.

So please take a look at the forum and be free to ask your doubts and share your knowledge.

TechNet Forums: Microsoft Deployment Toolkit

MDT2010 – Moving Deployment Share from One Machine to Another – Important Aspects

This week I was finally ready to move my MDT 2010 Deployment Share from my virtual machine to my physical machine.

After some readiness and asked some Microsoft people the main idea passed was that MDT 2010 was designed to make possible to move de Deployment Share to another machine by just doing a Copy-Paste action.

Well…this is almost true.

But…like almost everything in life, this is not that linear.

From my experience after move and add the Deployment Share to the new machine there are always 2 action you need to take:

:: 1 ::

You’ll need to open you’re bootstrap.ini file (\\DeploymentShare$\Control\Bootstrap.ini) and change the DeployRoot entry
(Ex.: DeployRoot=\\OLDMACHINE\DeploymentShare$ | DeployRoot=\\NEWMACHINE\DeploymentShare$)

 

:: 2 ::

You’ll also need to change the Deployment Share Properties:

The field Network (UNC) Path needs to be changed

KMS – Activating Windows on Isolated Networks / Standalone Computers

In some particular cases you may not have the possibility to active Windows through the normal KMS process, because you have some machines that for example:
- Aren’t joined to a domain
- Don’t have DNS configured

But of couse, you still need to activate Windows on this machines. On more “complicated” way is using something, that I’ve not tested, called VAMT that make it possivel to run a tool on the isolated machine and than send the generated information through another machine. This is obviously causes more effort for the activation and on unattended deployment scenarios (LTI or ZTI) it’s not very convencional.

This week someone from the middleware team, finally installed KMS Server on the network and finally I could test this scenario because we have some kiosk type machine that need this kind of solution.

Windows Vista clients uses DNS queries to find where KMS Server is located, and in my scenario I couldn’t have DNS configured on the machine, so the challenge was, some how, to force the client to know where the server was.

So…after some search and a very very nice help from a Microsoft fellow (Nino Torres) we found a way to do this.
There’s a tool called slmgr located on ‘C:\Windows\System32′ that can be used to force Windows to know where the KMS Server is giving it the ipaddress and listening port.

On unattended scenarios you should use the vbscript (also located on ‘C:\Windows\System32) called slmgr.vbs.
To force the KMS Server information, you should run the following commands:

- cscript C:\Windows\System32\slmgr.vbs -skms kms_server_ip_address:portnumber
- cscript C:\Windows\System32\slmgr.vbs -ato

Example:
cscript C:\Windows\System32\slmgr.vbs -skms 10.0.0.1:1688
cscript C:\Windows\System32\slmgr.vbs -ato

The first line, sets in registry the information about the KMS Server IP Addres and the port his listening to.
The second line, forces the Windows Activation.

[CAUTIONS]
:: In most cases, isolated networks have firewall, so we need to open the way for KMS Server.
:: The default port for KMS Server is 1688
:: Don’t use slmgr for unattended installions because it shows message boxes, use slmgr.vbs instead

For more information about Volume Activation visit this Microsoft Website:
Volume Activation 2.0 Technical Guidance

Installing .NET Framework 3.5 SP1 Causes Windows Setup Error

For having my images up-to-date I started this week testing the deployment for .NET Framework 3.5 SP1.
At first everything looks ok, and the software installs silenty.

The problem was then deploying the image. For some reason during the setup I was getting this error message:

NETFramwork3_5_SP1_Error_001

Because I’ve made some other changes to the proccess I needed to have sure that .NET Framework 3.5 SP1 was the problem here, so I’ve disable this step on the Task Sequence and then created a new image again.
Now the problem didn’t happen.
h
After some research, asking people about it I’ve run out of options so I’ve installed .NET manually to see if I could understand where the problem was.
After installing I’ve reboot the system and then realized that after restart the .NET installation need to update something on the system (similar to the process after installing some hotfixes via Windows Update).

I’ve then enabled the .NET installation step again and add a Restart Computer step to my Task Sequence. Before this the space between installing .NET and Sysprep the machine had no reboot.

Create the image and now everything works correctly.

Reducing installation time after image deployment and sysprep

Those of you that experienced Windows XP deployment may notice, now with Windows Vista, that after sysprep and image deployment, the consumed time it’s a little higher than before.

These happens mainly for 2 reasons:
- First, because the new Vista Deployment is file based and not volume based (like for example Ghost) and it takes a little more time to decompress the WIM file, specialy if you’ve set the compression to high when creating the WIM.

- Second, because after the sysprep (OOBE) one of the actions on Windows Vista setup, is the collect of system assessment information using the Windows System Assessment Tool (WinSAT) mainly for rating the machine and select the best appearance for the operation system.
The assessment is made during the reference image creation, but Sysprep cleans this information.

This pass, can be “suppressed” specialy if you have an hardware controlled environment and don’t need Windows to check what to use.

Microsoft has made available an hotfix to avoid this behavior, and preserve the WINSAT information collected before the sysprep process.

More information about this hotfix can be found here:
http://support.microsoft.com/kb/958011

To apply this hotfix:

Tools Needed:
- KB958011 (download it through the website mentioned above)
- GimageX (optional) – this is a freeware tool and a GUI for Microsoft imageX to mount/unmount WIM files. You can download it at AutoIt Website

Steps:
- Mount your Windows Vista WIM
   (to c:\mount for example)

- Expand the KB958011 to a temp directory
  (ex.: expand Windows6.0-KB958011-x86.msu –f:* c:\temp)

- Apply KB958011 offline to the mounted Windows Vista directory
   (ex.: start /wait pkgmgr /n:c:\temp\Windows6.0-KB958011-x86.xml /o:”c:\;c:\mount\windows” /s:c:\sandbox)

- Wait a little so the hotfix is applied…

- Unmount (commit changes) the WIM file.

- Launch MS Workbench and edit your unattend.xml file

- After Windows SIM opens, reload your WIM file (on the left bellow pane)

- Again on the Windows Image pane, you’ll find a new component called Microsoft-Windows-Sysprep-SpWinSAT.

- Right-click on this new component and had it to Generalize pass.

- Change the PreserveWinSATData flag to True.

- Add a RunSynchronousCommand pass with the following command line:
winsat.exe moobe formal

- Save it all.

- Done.

In my particular case, this changes made me get less 11 minuts of Windows installation.

Hope this help you too.