ClustrMap

Archive for the Deployment Category

After quite some requests I’ve spend some time to work out a new task sequence and updated file package for my original post “Configuring Windows RE with MDT 2012 Update 1”. The first version I published back for MDT 2010 required manual configuration in order to work properly, the updated post for MDT 2012 was built on top of that work but re-writing almost everything in order to make it a lot easier to use. I also included a proof-of-concept ready to use WinRE image (a modified WindowsPE image).

This updated version includes a new scenario that I’ve seen many try to implement after finding my post and then stumble upon various issues.

In a nutshell, I’ll describe in short what happens during the task sequence (obviously edits can be make to adjust to your needs)

Windows is deployed onto the system, but using a different partition layout: 2 partitions, the first is 10GB and marked as Recovery partition using Type 27, and the second is the remaining volume space for Windows.

After Windows has been installed, during the State Restore phase, a script will copy the custom WinRE image to the Recovery partition, and configure windows using ReAgentC.exe to use a custom WinRE environment.

Once all the steps in State Restore have been finished, Windows will reboot into WindowsPE (litetouchPE) and capture the Windows installation that was just installed to the Recovery partition.

This allows for very fast recovery of the system if the operating system is really messed up, as long as the bootmgr is still able to boot and the hardware is healthy. This solution is very similar to the recovery partitions that the big brand OEM’s supply with their systems.

The original task sequence I created would sysprep the system before rebooting into PE to capture the image, but this would disjoin the computer from the domain (if joined to a domain), and also cause an OOBE to appear after the task sequence was completed. This scenario would be fine for workgroup computers, or a system builder who wants to provide a recovery solution with their pc’s to their customers. However I’ve been contacted by quite some fellow admins working for large companies also wanting to setup something similar, but not have the machine disjoin from the domain.

The extra task sequence that’s provided in the script file package now actually does just that, it will work for enterprise usage… at a cost (I can’t see a way around this, but we’ll come to that in a minute).

Once all the tasks in the state restore phase have been completed, it will move on to the [Custom] Capture Image group, now instead of sysprepping the system it starts a different script.

This script does the following: It removes the drive letter R: from the recovery partition (this normally happens during sysprep), remove auto-logon/resume task sequence upon windows logon, re-enable system restore function, remove registry entry for last logged on user; this is not the policy setting “do not display last user name” (that way when the computer boots up for the first time it does not display pcname\administrator) and last.. but most importantly it sets the registry setting to disable the computer password change.

After that it reboots into WinPE, and captures the image and it’s done. Once you boot into windows you’re still joined to the domain and if you recover the image right away you’re still joined to the domain.

I would like to point out, that the last item, disabling the computer password change is not a recommended setting. However this is the only way to keep the system joined to the domain without losing it’s AD trust after restoring the recovery image after 30 days (if anyone knows an alternative I’m all ears). If you want to implement a solution like this, I would recommend you to read the following two Technet blog articles:

In this post I describe how I use a powershell script to automate the domain join process in MDT/SCCM to the correct OU based on the comptername.

While installing operating systems, software and troubleshooting the installation processes are one of the things I really enjoy doing, it frustrates me when I see a poorly implemented environment. Our environment unfortunately is one of those, so I’ve spent quite some time in order to get to a point where it’s starting to become fun again.

The Hospital I currently work for has a lot of OU’s, every department has it’s own OU for workstations (114 OU’s just for workstations). Since we didn’t have an automated method to place the computer automatically in the correct OU during deployment, it always meant there was manual work required; either create the computer object in AD before installing Windows, or move the computer account afterwards from the computers container.

At least we have a simple enough naming standard for the workstations, which is built in the following method: “Division number”-“department abbreviation”-“last 2 digits of the year when PC was bought”-“4–digit number, starting with 0001 as first PC bought that year”. To give an example, My workstation would be 0–ICT-12–0011 (11’th PC bought for the IT department in 2012), and the computer object for that PC would need to be placed in the workstation OU for the ICT department. When I went to look for some ready to use scripts to determine the OU based on a computer name I only found a handful of vbscripts that generally used a predefined number of control characters, for example the first 2 letters of the PC name. This was not a viable option for me, since I need to actually do a three step check on the name to place the computer in the proper OU. The following process is that we need in our environment.

Lets take 0–ICT-12–0011 as example

Check the first 2 characters of the name, if this matches 0–,1–,2–,3–,4– or 5– then go to next step

Since the PC name starts with a digit matching a division, it then needs to find the correct department; in my case it now needs to match 0–ICT

Once it matches a division and department, it also needs to verify the last 4 digits of the name, if this starts with the letter “K” (we have a few more exceptions) it means it’s a kiosk/panel PC which have their own OU…

Based on the last 4 characters of the name, we can determine wether we need to be placed in the workstation OU for ICT, or in the Kiosk OU for Division 0, since the last 4 characters are 0011, it means it’s a WS.

If for some reason the name would not match all criteria’s, I defined a “NonCompliant” OU which will contain all computers that do not follow the default naming policy, example: If I made a mistake while typing in the computername during the import computer object in SCCM and named it 1–ICT-12–0011, it would then be placed in the NonCompliant OU, since ICT is a department part of division 0, and not division 1.

I figured powershell would be a good candidate to tackle this for me, since I’m a lot more comfortable with that than with vbscript. So I started to write my own script to follow the exact steps I described above, due to the large amount of different OU’s I needed to define I ended with a 664 lines long script (also due to my formatting, however I find this very easy to read), but I figured I might as well share this in a more compact version that shows just how I applied this logic if you happen to need something similar in your environment.

The functionality of this script is very simple, it will define the task sequence variable ‘MachineObjectOU’ based on the OSDComputerName variable using If, ElseIf and Else statements. It also dumps all TS variables before, and after setting the MachineObjectOU variable to a file named ZTIVariablesExport.log in regular SCCM/MDT log path.

The script can be downloaded from the TechNet Gallery where I’ve also posted a small snippet of the code I’ve used. It can be used in the following scenario’s:

MDT standalone:

When using Windows PE 4.0 images, with the powershell component you can execute this script at any stage before the “Configure” step in the [Preinstall] node of a task sequence.

When using Windows PE 3.0 you’ll need to configure the task sequence (or your custom settings) in such a way that it does not join the domain by updating the unattend.xml file during the “Configure” step, since this will actually join the computer to the domain during the windows installation. By letting it default to a workgroup, and then run the powershell script during the [State Restore] node in the task sequence prior to the step “Recover From Domain” the PC will be placed in the proper OU during this part of the domain join process.

The only drawback for placing computers in a particular OU using the MachineObjectOU variable in MDT is that if the computer object is already present in AD, it will not be moved. Instead the PC will still be joined to the domain but the object will remain at the same location that it was already in. While you can do this with scripts as well, I really like Maik Koster’s web service (link) for this (and other) functionality.

ConfigMgr with MDT:

With ConfigMgr, configure a default OU (our staging OU) in the “Apply Network Settings” step in the [PostInstall] node (or when using UDI, configure the Domain Settings in the UDI designer) and during the [State Restore] node add this powershell script which will configure the MachineObjectOU variable, then execute Maik Koster’s ZTI_ExecuteWebservice.wsf script to move the account from the staging OU to the destination OU.

Updated @ 04/05/2013: Updated script files to include Domain Joined scenario.I still need to update this post to reflect all the information in this post.Important note: Thanks to the feedback, an issue has been found when using Windows ADK and deploying these task sequences, I’ve finally pinpointed the cause of the error and will soon update the file package to solve the issue (it has to do with the autofailover ability of Windows 7).

This post is an update of my previous post regarding the Windows Recovery Environment and how to configure it using MDT. My first post was based on MDT2010, this post has been revised to make use of MDT2012 (Update 1). If you’re not very well known with WinRE itself, I would recommend to read my original post regarding this topic: link

I will try to keep this post shorter than the original one, since most of the basics are still the same. Instead what I’ll discuss will be the changes that I’ve made to improve the overall ease of use. The last few months I’ve seen an increased number of emails asking for assistance with my original post on this topic, instead of always trying to help 1 person at a time and try to pinpoint their specific issues I figured I’d just create an update to this that’s less prone to errors.

I’ve spent quite some time in refining the scripts that I’ve used and added some basic logging that should make it easier to identify errors in case one of the tasks fails. I’ve also managed to consolidate all the different batch files, and the different diskpart scripts to 1 single batch file.

So in a bullet point list as of what’s new:

Scripts are now located in a subdirectory of the %scriptroot% folder named [\WinRE]

All script files have been consolidated into 1 single batch script [MDT-WinRE.cmd]

Support for cross-architecture deployments (meaning you can deploy a 64-bit Windows version from a 32-bit WinPE)

LTISysprep.wsf from MDT2012 U1 has been modified in order to function properly.

ZTIBackup.wsf from MDT2012 U1 has been modified, this time I’ve taken the time to carefully edit the file and only remove the unneeded sections. It’s no longer a simple rename action of the uselocal variable value in order to force it to use the local disk. All checks are still in place, it will now properly fail before starting ImageX to capture if there’s not enough disk space available to create the .wim file.

All variables that previously needed to be edited inside the various script files can now all be configured within the task sequence, as task sequence variables.

Disk Configuration will be handled by the MDT built-in Format and Partition disk step, you can adjust this to your needs.

I’ve created a Custom Recovery tool for inside Windows RE, this means that the Windows Setup is no longer used for the restore process, but instead ImageX will be used. Using this method will delete all data on the Windows volume, and no “Windows.old” folder will be created.

I’ve configured a custom hotkey to directly start the custom recovery tool, this is [F1]. You can manually assign a different boot key by editing the MDT-WinRE.cmd script (look for /Bootkey).

I’ve noticed a lot of people had issues once they had restored their image with a duplicated boot menu entry. This meant that upon startup they would see two identical boot menu entries for Windows 7, adding a boot delay of up to 30 sec. The script that restores the recovery image onto the HDD will configure a new BCD meaning that this issue has been resolved.

This time I’m also providing a pre-built WinRE.wim for both x86 and x64 machines. Note: these will be driver-less, however they will contain the CustomRE tool and have all the packages as required, you can use as reference to see what I did if you want to create your own. These images are ready to use, unless you need to add drivers, or other language packs since I only choose to use the en-US language.

The task sequence template has been revised and I’ve updated the descriptions of various tasks.

It’s now no longer required to use Audit-Mode, hence I’ve removed providing a unattend.xml file; you can use the default unattend.xml file that’s created by MDT.

If you need to use USMT to migrate data from the user profile(s) and possibly even restore it, this is all completely possible, however you will need to add this functionality yourself by adding the proper commands to the scripts.

As for the actual links to the files, scroll to the bottom of this post. They will be hosted on my SkyDrive account, I’ve marked them as public so anyone should be able to download them.

Next I’ll provide some screenshots of how the changes look like.

Below you can see the new Task Sequence, along with the different variables. Important: Do not forget to adjust the Install Image inside the task sequence so it points to one of your own images, when opening the task sequence you will be pointed out there is an error regarding this.

If you want to trigger the recovery environment from within Windows itself, you can do it from within this menu.

After you select the “Return your computer to factory condition” you are prompted whether or not you want to create a backup of your data, regardless of your answer; when you have restored Windows and boot into Windows for the first time, you’re prompted whether you want to restore your files from a backup or not. When you confirm that you want to recover the pc, the pc will reboot right away and start WinRE and load the custom recovery tool. There will be no WinRE menu.

This is the default WinRE menu that is present when you start windows by pressing [F8] and using the “Repair my computer” option. However, now there’s an additional item at the bottom that will be able to start the custom recovery tool.

The HTA that I’ve created that will function as the “front-end” for the recovery process, has been configured to display no borders, and fill the screen. Below is a screen capture from within WinRE. This screen will be started right away without the WinRE menu (previous picture) when you boot the pc and press [F1] or start WinRE from within Windows’s Recovery control panel item.

Once you start the recovery process, it will look as followning.

The message below would be displayed if the recovery process succeeds, if a failure occurs for whatever reason, it will display a message box that will return the error code.

Please drop me a line through one of the channels to contact me on the [About Me] page whether everything’s working properly or not, this info can help me to make improvements. Next to that it gives me an idea what the interest is in this particular topic.

As for what to do with the files inside the package, it will contain two different folder structures.

The DeploymentShare folder contains the files in the appropriate structure that should be placed inside the root of your deployment share. Note: The task sequence file that I’m providing actually needs to be manually replaced with a task sequence that you create yourself. This means you create a new task sequence, and take note of the TSID you give it, go to the DS\Control\TSID folder and replace the ts.xml file with the one I’m providing. You can see a WinRE folder at the root level of the DeploymentShare folder, I’m using this location as the new default folder that will contain the WinREx86.wim and WinREx64.wim image files (these files are available for download as well), if you do not want to host these files inside the DS, you will need to alter the path for these images in the task sequence variable [RecoveryImagePath].

The WinRE.wim source files folder will contain all the files in it’s appropriate file and folder structure to create the WinRE.wim image manually. This also gives you insight into the specific tasks being executed when the recovery process starts, allowing you to edit this if you need to adjust this. Note: The CustomRE.exe executable is a simple launcher for the RecoveryWizard.hta file, all it does it load a file with that specific name and wait for the process to terminate before it closes itself. This is a requirement because the CustomRE tool defined within WinREConfig.xml has to be an .exe type of file in order to read the product name, and description and the icon, otherwise you might end up with a very weird looking menu entry. The code I used for creating this file is included as well.

This post will explain a limitation of cross-architecture deployments of Windows 7 using MDT2012 along with a work-around.

After receiving an email from someone who was having issues deploying a Norwegian version of Windows 7 64-Bit using the LiteTouchPE 32-Bit environment (and had no problems at all when deploying it using LiteTouchPE 64-Bit) I quickly came to the conclusion that the actual setup.exe process that was executed when running in LT-PE x86 was from a set of source files that was from a different language. This is an error that I’ve seen often enough back in MDT2010 where you’d import a new custom .wim image to the deployment share without the setup source files and the image being deployed is actually a different language from those that are already present in the deploymentshare.

This was also one of those topics that came by on the technet forums rather often, and the simple solution was by re-importing the custom image with the setup files (in the appropriate language). However, cross-architecture deployment was not possible back with MDT2010, but now that it is, this very same subject resurfaces again due to the built-in logic of finding setup.exe.

So why does this happen? It’s simple when deploying Windows Vista/7/Server 2008/R2 this will be handled by running setup.exe along with an unattend file, but with a cross-architecture deployment (note: can only deploy x64 from x86, but cannot deploy x86 from x64 PE environments and only works for Windows 7/Server 2008R2) the 64-bit setup files are not able to be executed from a 32-bit PE environment. MDT will look in this scenario for an alternate setup anywhere in the other Operating Systems that have been imported into MDT that did include 32-Bit setup files (note: importing a x64 .wim file and providing 32-bit setup files will still report to MDT as a x64 platform).

At first when I saw this, I thought of a couple of solutions. However, after some more research I’ve came across a post regarding issues deploying Windows 7 with MDT2012 in combination with ADK (this replaces the WAIK/OPK for Windows 8). The following quote is a post of Michael Niehaus [link] (scroll down near to the bottom).

As mentioned before, this is an incompatibility between the beta ADK and Window 7 Setup.exe. This won’t be fixed in ADK or in Windows 7 Setup.exe, so in a future MDT release we will stop using Setup.exe to install Windows, which will avoid the issue.

This issue is also documented in the MDT 2012 release notes. We still suggest using Windows AIK for Windows 7 deployments, unless you are in a lab environment and are willing to put up with small issues like this.

Note that if you import your Windows 7 and Windows Server 2008 R2 images into Workbench without the full source files (just import the Install.wim), then you won’t see this popup when using ADK because MDT 2012 will automatically fall back to using ImageX to install the image instead of Setup.exe. (The change we are making in our next release is to make ImageX the default.)

Now seeing the statement regarding that the default behavior for Windows 7 and Server 2008R2 installations will be handled by ImageX instead of setup.exe, I would personally just suggest to already start planning towards this new change. There’s no drawback for using ImageX.exe vs Setup.exe since offline servicing will still be done after the image has been applied onto the disk (this adds the drivers, LP, patches and such).

I’ve already updated my deployment share that I use for development/testing to reflect this new change, I’ve re-imported all images as plain install.wim files so the entire deployment share does not include any setup files for Windows 7/2008R2 (this can be done for Vista/2008 as well if you wanted to, these do not support cross architecture deployment though). This change also gave me back about 300MB per imported Operating System in my workbench this can add up quickly if you’ve imported a lot of OS’s into the workbench. Note: I don’t even use the ADK yet for this particular share, I still use WAIK to be honest, I prefer this method over running setup, since you gain a time indicator that will tell you how long it’ll take before the image is applied onto the machine, but more importantly the install time is decreased significantly (image being applied within 5 minutes in my lab environment). This is also the method that ConfigMgr 2007 and 2012 apply custom wim images to clients, they dont use setup.exe for that either.

This post will give a more in-depth explanation how to properly setup the Windows 7 Recovery Environment. Quite some time ago I helped someone on TechNet forums the to set this up, however I never really gotten around to clean up the info I provided into an easy to read format and consolidate all the information into 1 single post. At the end of this post, I’ll provide a TS.XML file for MDT 2010. This will be a template so it’s easier to see what steps need to be done in order to get everything working. Also I’ll provide the necessary scripts at the end. This will also give you the general idea how to configure this with the beta of MDT 2012. Once MDT2012 has been released as a final build, I’ll provide files for that as well.

While by default Windows 7 has “WinRE” installed on it, this is only the default Windows PE environment with a couple of recovery options, to enable a full system recovery from HDD further configuration is required. The purpose of this post however is to show how you are able to make a fully functioning recovery partition like the big OEM’s have, but then with the built-in tools from Microsoft. This means that you’re able to revert to the fresh Windows installation at the time the pc was first put to use.

This also could help providing mobile workers with a method to re-install their system, without needing to be in the office. For an enterprise scenario like this, where you often have to deal with domain joined systems, further configuration is needed and goes beyond the scope of this post. If this is something you seek to do, feel free to contact me (contact details are on the about me page) and I’ll be happy to point you in the right direction.

This post will cover how to successfully get WinRE working with MDT, with single disk configurations. While it’s possible to configure it to work with multiple HDD’s, this will make this entire post far more complex. Again, feel free to contact me if you need assistance for that scenario.

The reference documentation for the Windows Recovery Environment can be found here. It’ll explain how to customize the PE environment with your own custom tool if you would want to use that instead. Or define a bootkey on which WinRE should respond and several other things (default is F8). However the various pages often link to a different section again and you’ll find yourself jumping from page to page to find all the information you need.

For the following information, I assume you will have basic knowledge when it comes to imaging with Windows 7, and have some experience with ImageX and Dism to mount and modify a WinPE image to add drivers. I’ve followed most of the guidelines and recommendations set by Microsoft for setting up the recovery environment I once created for the company I used to work for. However I’ve deviated somewhat from these since it either worked out better, or since the default caused problems.

Please note: This guide will help you to create a task sequence with MDT 2010/2012, that installs Windows 7 (or Server 2008, method is exactly the same) in audit mode, configures WinRE accordingly and then syspreps the system. After this the system will reboot and start a capture of the system state onto the Recovery Partition. Once that’s completed, the system can be rebooted and be put to use, you will be presented with the Windows OOBE, and can either call the recovery environment from within Windows (Start Menu > type “Recovery” in search > Open Recovery > Advanced recovery methods > Reinstall Windows) or during the boot phase, right before Windows boots press F8, and select the “Repair my pc” option on the top. Once inside WinPE, select “Reinstall Windows”.

Windows Recovery environment requires a separate partition from the actual Windows Partition, the files WinRE.wim and Install.wim. You should be familiar with the .wim file extension. The WinRE.wim file can be found in the \Windows\System32\Recovery folder of a default Windows 7 or Server 2008 Install.wim image. The WinRE.wim image is not bound to a certain Windows Edition, however architecture type needs to be separated. This means if you use both x86 and x64 systems in your environment, you will need to extract both of these files. Please note; If you require special mass storage device drivers (for example sas/sata hba’s or raid controllers) you should include these in the WinRE.wim file, so the end-user does not have to load the driver manually.

The proper partition scheme according to Microsoft is

Recovery partition

System Reserved (Boot)

Windows

However, when I applied this partition scheme, I ended up with several unbootable systems that were build at that time. The moment the HDD’s had this partition scheme, the HDD’s would no longer be detected during the AHCI disk detection, when SATA operation mode would be changed to IDE, everything was working properly though. This was unacceptable for me, and since I have not yet found a fix for it yet (this occurred on both recent Intel and AMD systems on the onboard HBA) I’ve tried a different layout, which worked flawless in my case.

Recovery & Boot Partition

Windows

The added benefit of this is that you have one more primary partition that you can create on the disk compared to the recommended layout, since with a basic disk, a max of 4 primary partitions is possible. I’m personally not a fan of many partitions, since this makes migration to a new OS always harder (read: more work).

The Recovery partition will be given the ID of 27, which will hide the disk in the Windows Explorer, and make no actions possible on it in the Disk Manager MMC Snap-in. Since MDT lacks the option to set an ID with the GUI, I created a small diskpart script that does this for me. At this same time I copy the WinRE.wim file that I extracted to a network share, to the recovery partition into the folder “\Recovery\WindowsRE\”

After Windows boots into audit mode, ReagentC.exe is called to configure the paths of the WinRE.wim and Install.wim files. During this time you have the option to install any software you want to be included in the recovery image. After the system has been updated and all necessary software has been installed, Sysprep will be executed (default is with /generalize option, however if you do not plan on using cloning techniques to provision the same HDD image to other computers, this option can be disabled) and WinPE (LiteTouchPE) will be installed onto the HDD, and the computer will restart. Once inside the PE, the task sequencer will start to run a customized version of ZTIBackup.wsf that saves the image onto the recovery partition.

Both the modified LTISysprep and ZTIBackup scripts will be included with the rest of the files I’ve created to create this task sequence. You can find these files at the bottom of the post.

The provided task sequence will have descriptions in some of the custom task sequence steps, it’s possible the field is not large enough to display the entire text, so use your mouse to highlight it all and copy paste it into notepad for example. Every step that deviates from the regular “standard client install” template has been marked with [Custom] tags, and all steps that are not needed, have been disabled. Some steps will not work properly if enabled (Bitlocker will cause problems for example if you try to capture the OS from inside WinPE if the drive has been encrypted).

The easiest method to import the task sequence is to create a new task sequence in your workbench, and remember the Task Sequence ID. When you go to the folder \DeploymentShareName\Control\TaskID\ you will see both a unattend.xml and ts.xml file. Replace both of these with the files provided in the archive. All other files will need to be placed in the %Scriptroot% (\Deploymentsharename\Scripts). To avoid clutter, only 2 files will be placed in the root, since these require other mdt files to work properly, and the rest will be placed in a new folder named “WinRE”. The only change to the unattend.xml file is the addition of the boot into Audit mode setting, since this is a requirement for this task sequence template.

Once you open the task sequence after the ts.xml file has been replaced, you will notice there’s an error. This is normal since you will have to fix the Windows Image that has to be installed. See the screenshot below.

Please edit the following files with the appropriate servername and unc path.
WinRE\Configure-HDD.cmd, change the REimagepath and DS entry.

WinRE\Enable-WinRE.cmd, change the DS entry.

WinRE\Re-assign DriveLetter.cmd, change the DS entry.

The partition size can be edited in the file “DiskConfig.txt”, my default setting is 10GB. Make sure this partition is large enough if you decide to install many applications that need to be included in the system recovery image.

LTISysprepOEM.wsf. At line 108, you can choose to remove the ‘ at the beginning to enable the copying from a custom unattend.xml that sysprep should use to apply system settings for the end-user. Examples would be, time-zone, creation of user accounts, automate ( all or most of) the OOBE. Make sure to supply the unc path to the unattend.xml file. At line 121 you can remove the /generalize option if you do not plan on cloning the hard disk to other pc’s after the task sequence has completed.

You can download the zip archive that contains the files used for this task sequence here: link.

This post is about a somewhat hidden option of WDS, which allows you to modify the default behavior the WDS PXE provider/listener.

While this isn’t per se entirely new to everyone, I do find it worth elaborating the uses of this option.

There might be multiple scenario’s where you might find the need to be able to select from which server you actually want to PXE boot from, without specifying with the wdsutil a server that a device should boot to (specify /ReferralServer:<server name>).

The best example I can give you, is that you’re wanting to try to implement System Center Configuration Manager. So lets say you want to try to get to know the product, you’d run it in your lab or test environment which also already has a regular WDS(+MDT; fully optional though) server and it’s used to build your reference images on. Now you could stop the WDS service on that server or shut the server down entirely, but another option would be to allow you to select from which server you want to boot the client pc when it’s doing a PXE boot. There’s one small “requirement” for this setup though,

The “regular” WDS server, which uses the WDS PXE listener, needs to be the server that responds to clients first. So the response delay needs to be lower then the response time of the PXE listener of the SCCM PXE service point. This will ensure that the WDS PXE listener is used to “catch” the clients that are sending out PXE boot requests. Now to enable the usage of the server selection screen, you will need to edit a value in the registry.

You can paste the code below into a text file and save it as .reg to update the value for you, or browse to it manually and edit the value from 0 to 1. After this change the WDS service needs to be restarted.

Once this change has been made, the next time a client will boot from PXE, the screen will be slightly different. In the first screenshot below, I’ve already pressed F11 to start the discovery of PXE servers. Once it has found all servers, it will bring you to the second screen, notice how it lists the second server as [UNKOWN] ? the reason behind this is because it actually uses a different PXE provider (SMSPXE instead of BINLSVC). And SMSPXE cannot be configured from the registry like BINLSVC can, SMSPXE can only be configured from the SCCM console, and has less options available for configuration. That’s the reason behind leaving the “regular” WDS server as the primary PXE boot server.

I hope you found this informative, if you have any questions feel free to email me or leave a comment.

Andrew Barnes recently posted on his blog how to make use of BGinfo with the LiteTouch WindowsPE environment to show some very usefull local information (or simply change the background during certain steps in the task sequence if you wanted, since that works too). The main downside of BGinfo, or WindowsPE (depends which you want to blame) is that BGinfo will only work in the 32-bit/x86 WindowsPE environment. This is due to the fact that BGinfo is a 32-bit application and WindowsPE x64 does not have the Windows on Windows subsystem to provide compatibility with applications that are 32-bit.

This actually reminded me of a new feature which will be added to MDT2012, it’s cross-platform installation support. While this actually isn’t entirely “new” as this has been supported with the Windows Setup client from Windows Vista. There’s a catch though, from an 32-bit WinPE you can install both x86 and x64 images. On the other hand, with a 64-bit WinPE you can only install x64 images, x86 images will simply be filtered out. Since WDS uses pretty much the same Windows Setup, the same was supported for WDS as it was for normal media installations although in the latter one you would have to create your custom install.wim that would contain all the different windows editions.

I personally am a minimalist regarding pretty much everything, the fewer things my technicians are able to choose from the less support I have to provide. While I’m still testing out MDT2012 in my dev. environment to make sure all my custom scripts are still working as intended, eventually I plan to switch to this cross-platform installation method from a 32-bit WinPE with MDT2012 instead of having both an x64 and x86 boot image (it’s just the scripts of MDT2010 that didn’t contain the logic for this). There are a few pro’s and only one con I can think of with this new “feature”.

Pros:

Both x86 and x64 architecture task sequences are available from 1 WinPE boot image.

It’s possible to use BGinfo along with x64 installations (since you’re running from a x86 environment)

Since Trace64.exe isn’t available via an official download, you can use Trace32.exe for local logfile reading without needing to download Trace64.exe from a possible unsafe source.

Cons:

Since both x86 and x64 task sequences are available in the task sequence list, and depending on how many task sequences you have, you might be presented with a huge list of task sequences to choose from. Now for this part I’m actually writing this post.

You might have noticed that task sequences and applications when placed in folders, these folders will (for most users) open by default in expanded mode. At first I didn’t know where to look for a feature or function to leave the folders collapsed by default. There’s no option for that, at least not a “clickable” one. One method would be to change the MDT scripts, which I personally rather leave as they are, but the method I’ll describe here is far easier.

The default behaviour of MDT is to show task sequences/applications in the root (obviously) and if you create one folder and place either ts’s or apps in there, this folder will be expanded to show the contents of it. However, if you create another folder inside these tier 1 folders, then these tier 2 folders will stay collapsed when the wizard prompts you to select a task sequence or application. To visualize this a bit more I’ll place a screenshot below; this is actually a screenshot of the MDT2012 Beta to show you that within a 32-bit Windows PE, now both my x86 and x64 task sequences are shown. Note: On the screenshot, I have not manually expanded any folder, the way it’s shown is how MDT will expand/collapse folders by default.

Knowing this, should help you prevent enormously large lists of task sequences and applications you need to scroll through. But what now if you actually would want to sort these? Keith Garner from XtremeDeployments created two tools to help you manually sort task sequences and applications using a simple UI. I encourage you to read his post at http://deployment.xtremeconsulting.com/2009/12/09/mdt-2010-application-ordering-new-tool/ for the working of the applications and their limitations. I noticed that the task sequence sorting tool link does not work anymore, however you can get both of the tools from his skydrive. While these tools have been written for mdt 2010, they work without problems on the mdt 2012 beta, my hopes are that they will not break with the final release :).

Note: Another usefull thing to know is when you change the order that Applications are listed, that’ll be the order that the applications will be installed. Normally you can only arrange the installation order of Applications by creating an application bundle.

I hope you enjoyed the read, if you have any comments about my writing style just drop a line; afterall I’m new to all this :).

Since I recently posted pretty much everything that needed to be done to get this working properly on TechNet forums, I figured I might as well write a proper guide for it now.
I can imagine that some are like “why would you even want to?” well, it’s rather simple… there are still end-users who use this OS. And some of them can’t install Windows themselves, so they bring their pc to a local pc store, or any other pc system builder (with the exception of the “A”-brand OEM’s). Depending on the size of these companies, some might actually still do everything manually when it comes to installing Windows. Some might still keep a Win2003 server with RIS around for Windows XP installs. When I was setting up our deployment server, we already had a running deployment solution with RIS/WDS running on a server 2003 in hybrid mode. Windows Vista and Windows 7 installs were very slow due to the slower network stack and larger file sizes of the images to deploy. At first I created a new server to install just the Vista/Win7 with WDS, and soon thereafter using MDT as well (MDT had some limitations for me at that time which I first needed to work around creating scripts). But I was still stuck with an old RIS server for Windows XP installs, and really wanted to stop using 2 virtual servers for the deployments so it’s less management. Windows XP Professional was all very easy to do on MDT, however Windows XP Home Edition causes me a few errors down the road. I’ll describe the error’s you’ll run into when trying to deploy windows XP Home Edition with MDT 2010 and how to fix them.
First off, when you try to Import a new OS from source files and select a Windows XP Home disk, you will get an error saying:

To fix this error, you will need to fool MDT thinking that the OS you’re trying to import is Windows XP Professional. To do this, you will need to rename a file in the root directory of the XP Home source files. One of the files below will suffice, however you can change them all if you want, the “highest” SP level that is changed from IC to IP will be the one that MDT will detect as an XP Professional source file directory.
• Win51IC > Win51IP (changing only this file, will make MDT recognize the imported OS as Windows XP Professional)
• Win51IC.SP2 > Win51IP.SP2 (changing only this file, will make MDT recognize the imported OS as Windows XP Professional SP2)
• Win51IC.SP3 > Win51IP.SP3 (changing only this file, will make MDT recognize the imported OS as Windows XP Professional SP3)

Above is an example where I only changed Win51IC.SP3 to Win51IP.SP3, notice how the default name MDT suggests is Windows XP Professional SP3?
Now you can continue to import the OS into the workbench.
The next error that you will run into is that MDT will try to auto-logon as the built-in Administrator account, named “Administrator”. While this account is actually marked as active, it’s not possible to log into this account unless booting from safe mode. Sometimes you might not actually see there is an error happening at this point and you will simply see this screen:

However, if you look closer and ALT-Tab you’ll see the following error:

To resolve this, you will need to change the auto-logon settings.

Update: 04/11/2012;

To simplify the auto-logon fix discard my previously written explanation as the following method is far easier. You need to edit the Unattend.txt file of existing task sequences and change the following value as displayed below. Alternatively you can enter the same value (Computer’s Owner) during the creation of a task sequence in the screen that asks for Owner (this is the field you need to fill in with this value), Company name and website.Note: Despite this value is written in English, it will translate correctly to all other languages of Windows XP Home you will install. I have verified this with multiple different language editions of XP Home, and the Autologon works correctly.

[UserData]
FullName=”Computer’s Owner”

We will need to edit the file “unattend.txt”, you can easily edit this file if you open the properties of the Windows XP Home task sequence (I presume you already created one after importing the OS, if you didn’t yet you will need to create one first) and go to the OS Info tab. From there click Edit Unattend.txt
The part we’re looking for is this;

We’ll add a command in here that will change the Auto-logon value to the correct username. For the English version of Windows XP Home, it will be “Owner”, you will have to find the correct username if you use a different language. This is the default account created by the setup.

Now, create a new text file, and make sure to include the following text. Then save it as Autologon.reg (or name it differently if you want, but then adjust the filename again in the GuiRunOnce section of the Unattend.txt

At last you need to ensure that this file will be present on every single Windows XP Home installation. There are several ways you can achieve this, for example creating a new task in one of the early TS stages. The method I used, was making use of the $OEM$ folder within DeploymentShare\Operating Systems\{OS Name}. An example of this is shown in the picture below.

Now that the autologon will work again, the task sequencer can continue just like a normal Windows XP Professional installation. I hope this information was helpful to those few people who might actually need to deploy Windows XP Home edition for whatever reason, and couldn’t get it to work with MDT and for that reason were still stuck with RIS. If you happen to run into an issue, feel free to leave a message or contact me.

I’ve tried to assist someone on the TechNet forums who was getting an error once he had created his reference image to his wishes and
ran sysprep to use it for further deployments and then try to boot into it. Here’s the link to the topic on TechNet;

The error looks like this (if you let it reboot, it will just come up again, over and over):

Windows could not finish configuring the system. To attempt to resume configuration, restart the computer.

We both realized quite soon that it had something to do with Live Essentials 2011, so I went to test a lot…

I think I’ve done about 5 installs of windows, clean installs, one of my old images that I have at my
test deployment environment at home and images that we ship out to ourcustomers,
I loaded all of these in VM’s and ran sysprep around 30 times, it starts to get old.. fast

At first I could not trigger the issue at my work pc’s, and the reason for that is because I don’t need to generalize the pc’s there (unless we
have a large order for a company). As soon as I manually ran sysprep with the generalize option, I was getting exactly the same error.
This was an image that I built in early July right after the Office 2010 OPK was released. It contained most updates up to this date Live Essentials 2010 and Office 2010 Starter.
If I ran sysprep /generalize right after the deployment of this image, without letting it self update and install WLE2011 there was no error.
I then ran WLE2011 to update the 2010 programs, and tried again and the image was still ok.
However, after applying the more recent updates after WLE2011 was installed on the machine, and I’d try to sysprep /generalize the error would be there!

It’s really simple to recreate this error, pick any flavor of Windows 7, x86 or x64, Starter all the way through Ultimate/Enterprise, they will all do the trick.
Do a clean rtm install, install WLE2011, either through WU (this will download the executable of 160mb containing the everything),
or download the web-dl installer from the WLE site, or install it through the OPK and then lastly run all the windows updates.
Once that is all done, sysprep your pc with the generalize option, and the error will be there.

Next I’ll list all the various combinations that will trigger this error, and what does not. And at the end of all this, I’ll provide you with a solution.
The error can appear if you fulfill any of these requirements.

Applies to any version of Windows 7 (I did not test this on Vista)

It will not matter which WLE2011 installer you use; whether it’s the OPK, wlsetup-all.exe or wlsetup-web.exe results are the same.

The error applies to any particular part of WLE2011, it’s not just one component as soon as any component has been installed, or all you become eligible for this problem.

If you have this problem, and have already installed WLE2011 prior to running Windows Update, it will not solve the problem by simply uninstalling WLE2011.
As soon as it has been installed, and still have updates to install, then
you’re out of luck.

Only updates that require you to reboot your pc, will cause the error.

The error will not show up if you do not generalize your
image.

At least there is a solution, [cut] apply the appropiate hotfix or sp1.

What makes it worth writing about this? Well the thing is, with this new reference driver nVidia has changed the installer, it’s no longer
using their old Installshield setup meaning the current command line switches will not work anymore.

What I’m not too fond of is that both nVidia and Ati (now AMD) provide no real explanation for proper command line switches to deploy these drivers.
My friend at nVidia sent me the internal document containing the entire command line switches and some other stuff.

Here are some of the general parameters for installing these drivers;

“[installerpath]\setup.exe /n /s /i /k /passive /noeula /nofinish”

Note: The above command will not work, it’s just a list of some of the available commands.

A short explanation of the parameters:

/n – This is the ignore reboot switch (will not reboot your pc after the driver has been installed).

/k – This is the force reboot switch (whether a reboot is required or not, your pc will be rebooted).

/i – Do not show welcome/reboot, but show package selection UI if needed and progress.

/s – Silent install, will not show any UI.

/passive – Passive install, this will not ask for any user input, but will show you a progress window.

/noeula – Allows you to skip the accept/decline EULA page.

/nofinish – Skip the summary page.

Well that’s it for now, I figured this was a nice post to start with, if you find this information useful feel free to check out my blog once in a while.