Windows 8 MDT Deployment
Windows 10 deployment – Part 1: The Deployment Share
This article, the first of nine in my Windows 8 deplyoment, details setting
up a Deployment Share using the Microsoft Deployment Toolkit (MDT)
- MDT installation
- Windows Assessment and Deployment Kit (ADK) installation
- Setting up the Deployment Share
Windows
8 is officially upon us! With a plethora of new features and the
ability to run it on nearly any existing modern hardware, now is the
time prepare your organization. Over the next nine posts, we will cover
deploying Windows 8 using Microsoft Deployment Toolkit (MDT) and Windows
Deployment Services (WDS). Our end result will be a single task
sequence that will automatically image a computer to your specifications
(including automatically retrieving old names)! Best of all, this
solution is completely free and easy to setup!
Why use Microsoft Deployment Toolkit (MDT)? ^
Imagine
that you are told to build a house. You are given all of the tools and
supplies – just no blueprints. That is how deployment used to be.
Microsoft provided a suite of tools to deploy operating systems. Tools
like the Windows Assessment and Development Kit (ADK). However, these
are just tools with no connecting framework. If your IT department is
like mine, you don’t have the time to learn the intricacies of DISM,
ImageX, Windows SIM, and the host of other deployment tools.
This
is where MDT fits in. MDT provides guidance for each tool. For example,
when you need to build a boot image, MDT knows to call DISM and inject
the drivers. So while you can technically deploy an OS with MDT, don’t…
Save yourself the time and sanity!
MDT installation ^
To deploy Windows 8, we will need MDT 2012 Update 1. This can be downloaded here.
MDT can be installed on a client OS (Windows 7/8) or a server OS
(Server 2008 and above). For simplicity and because we will use network
deployments, our deployment share will be installed on a machine running
Windows Server 2012. When MDT is installed, a Deployment Share will be
created. This Deployment Share is the home of our applications, drivers,
operating systems, and task sequences. Let’s go through the setup
process!
After starting the setup, be sure that all features are selected. Select Next.
Leaving the install location on C: is acceptable as only the tools are installed there.
On the Customer Experience Improvement Program, make your selection and press next.
Help the MDT guys out and send them some data!
Windows Assessment and Deployment Kit (ADK) installation ^
To
get the most out of our Deployment Share, we will need a few additional
tools. Microsoft has made all of those tools (plus a few extras)
available in one download. Head on over here and grab ADK. Proceed through the setup with all of the default options.
Good time for a coffee break…
Setting up the Deployment Share ^
A
Deployment Workbench MMC has been pinned to your Start Screen or Start
Menu. Open up the Deployment Workbench. Once opened, right click on
Deployment Share and select New Deployment Share.
Once your share is setup, you can install this MMC on your primary workstations to Open the Deployment Share
We
will then accept the default values for the path (C:DeploymentShare),
share (DeploymentShare$), description (MDT Deployment Share).
Setting the Deployment Share description
When
selecting your Deployment Share location, be sure to place it in a
location that can accommodate several operating systems, drivers, and
applications. In our environment, the Deployment Share is just under
40GB. This includes 6 operating systems, drivers for 20+ models, and
several applications (including office).
On the options pane,
uncheck all options. In this series, we will be deploying the original
Windows 8 install image. If needed, these options can be specified
later.
Deployment Share Options
Continue through the wizard until it is finished.
Your new Deployment Share!
You
should now be able to expand the Deployment Share within the Deployment
Workbench. You have now installed and configured MDT (along with ADK).
In my next post, we work with MDT folder structure as well as import applications, drivers, and an operating system.
Part 2 of our Windows 8 deployment series will cover importing applications, drivers, and operating systems.
Event Log Management
- Real-Time Monitoring
- Descriptive Email Alerts
- Security Event Correlation
- Web-Based Reporting & API
Advertisement
Joseph Moody
Joseph Moody is a network admin for a public school system and helps manage 5,500 PCs. He is a Microsoft Most Valuable Professional (MVP) in Cloud and Datacenter Management and blogs at DeployHappiness.com.
Contents of this article
In
our first post, we installed and configured the Microsoft Deployment
Toolkit (MDT) Deployment Share. But what is a Deployment Share without
anything in it?
An empty Deployment Share
In
this part, we will import Windows 8 as our Operating System and add
Office 2010 as our application. We will also import drivers for a Dell
OptiPlex 390 as well as Dell Latitude E5520.
Operating Systems ^
In
this series, we will be using the default Windows 8 image (install.wim
file). While you can certainly build and capture an image to use in MDT,
I would recommend against this. By using the default image, you
automatically eliminate issues related to the image. As a bonus, you do
not even have to Sysprep the Windows 8 media! Finally, the granular
nature of MDT allows you to layer portions of a traditional image into
separate steps. This will greatly help you when troubleshooting. We will
be looking at these steps soon.
So how do we import an Operating System? Right click on Operating Systems and select Import Operating System.
The OS Importing Wizard within MDT
Select
“Full set of source files” and press next. Select the source directory
(either a CD/DVD drive or an extracted/mounted ISO). Continue through
the wizard.
Our imported operating system
Applications ^
So
now that we have our Operating System imported, let’s get Office
imported! To import an application, right click on the Application node
and select New Application.
The new application wizard
The
first thing that you’ll notice is that the New Application wizard and
Operating System wizard are very similar. In fact, the behind the scenes
importing process is nearly identical. The only big difference will be
the command details and the advance options.
To import Office, we
will select Application with Source Files and select next. Under the
Details window, be as specific as possible. This will allow you to
easily group applications later and can help you customize your
deployment in an extremely targeted manner.
If you will be importing multiple versions of Office, you will want to specify that in this window.
Specify
your source and destination folder name. Because we were specific in
the details window, we can accept the default destination folder name.
On the Command Details window, simply enter setup.exe as the command.
Later, we will add additional commands to this installation.
Continue through the wizard. After selecting Finish, you should see the Office 2010 application listed.
Now we are getting somewhere!
Customizing the Application ^
Chances
are that you will want to customize the Office installation. For
example, you may want to have the install run quietly, automatically
activate, or simply remove certain portions of Office.
To do this, right click on Microsoft Office 2010 and select Properties. Then select the Office Products tab.
Customizing the application
Instead
of letting Office decide on our options, we will manually specify them.
To do this, select the down arrow next to Let Office Setup decide. In
our environment, we used Pro Plus. We then specified other options such
as a Product Key, EULA acceptance, and a few other items.
As
a note, these options are directly written to the Config.xml file. If
you need to add advance options, you can select Edit Config.xml
If
you wish to customize Office further (for example, setting certain
components to install on First Use), you can do so by setting the Office
Customization Tool button. If you do this, be sure to save your MSP
file in the ApplicationsMicrosoft Office 2010Updates folder. For
this series, our deployment share is found at
C:DeploymentShareApplicationsMicrosoft Office 2010Updates.
To
save Windows Update time, you may also want to download Service Pack 1
for Microsoft Office 2010. You will then extract the update files into
C:DeploymentShareApplicationsMicrosoft Office 2010Updates.
Additional advanced instructions can be found here.
Drivers ^
In
this series, we are going to import drivers for two models (a desktop
and a laptop). To keep our drivers organized, right click on Out-of-Box
Drivers and select New Folder.
Import drivers
We will name our folder Windows 8.
If you will be deploying Windows 8 x64 and x86, you may want to create separate folders.
To
make driver model management easier, we will create a folder for each
model. To make sure our folder names match the exact model name, we type
“wmic computersystem get model” at a command prompt.
wmic computersystem get model
Our Out-of-Box Drivers folder will now look like this.
By organizing your drivers, you will save a lot of time later!
To download our drivers, we will head over to Dell’s Enterprise Deployment site and download the .CAB files for our two models. We will create a folder for each .CAB file to save them in.
After
our .CAB files have downloaded, we easily import them by right clicking
on each sub folder (ex: Optiplex 390) and browsing to the corresponding
folder where the .CAB file is saved.
The folder above contains the OptiPlex 390 CAB file.
A few minutes later, our driver folder is populated!
Populated drivers
For detailed enterprise wide best practices, see this article.
Conclusion
This wraps up part 2 of our Deploying Windows 8 series. So far, we have set
up MDT, imported Windows 8, configured Office 2010, and arranged our
drivers. In our next post, we will bring all of this together to create a Task Sequence!
Part 3: Task Sequence
This article, the third of nine in my Windows 8 deployment series, covers configuration of Task Sequences within Microsoft Deployment Toolkit 2012.
Ad
A Traditional Image vs. a Task Sequence
- What’s in a Task Sequence?
- Initialization
- Validation
- State Capture
- Preinstall
- Install and PostInstall
- State Restore
- Creating a Task Sequence
In our previous article, we imported Windows 8
as our operating system, designed a driver structure, and added an
Application to deploy. But these are all just components in an install.
In the same way that a blueprint pulls together all of the components in
a house, we need a way to tie together the components in a deployment.
This is where Task Sequences come in!
A Traditional Image vs. a Task Sequence ^
Most
organizations, at one time or another, have used traditional sector
based images. These images are mirror copies of a preconfigured hard
drive. All software, settings, installed drivers, etc are on this image.
The problem with this setup is that one image won’t fit all computers.
When this happens, an organization will have to create another image for
a specific set of machines.
A Task Sequence, on the other hand,
is a series of steps that automate the deployment process. For example,
you can have a single task sequence that dynamically pulls only the
drivers needed for the computer being imaged. This cuts down on images
created for specific computer models. With MDT, you can also specify
items like “everybody gets Office 2007 except these certain computers.
Give them Office 2010.” Application logic, like this, can allow you to
drastically reduce your image count.
What’s in a Task Sequence? ^
As
we mentioned earlier, Task Sequences are made up of distinct tasks.
These tasks are grouped into sections. Each of these groups apply in the
order shown below. Understanding these groups is the key to a
successful deployment with MDT. Let’s take a look at them!
A sample Task Sequence deploying Windows 8
Initialization ^
When
a machine first starts a Task Sequence, they will begin the
Initialization phase. This phase gathers information such as any
variables or specific items applied to this computer. As we mentioned
above, this is where the computer would determine if it needs to do
anything special (such as installing Office 2010 instead of Office
2007).
Validation ^
After
initialization has finished, the computer will check the BIOS for
compatibility (to ensure that OS can be installed) and will ensure the
minimal system requirements are met. As an interesting note, you can
increase the minimal system requirements to be more stringent. Want
Windows 8 to require 2 GB of RAM? No Problem – adjust it here!
In the picture above, the minimum memory is set to 2048 MB.
State Capture ^
With
the State Capture phase, you can migrate local data from the pre-imaged
machine to the post-imaged machine. This allows you to preserve user
information, local groups, network settings, and other critical items.
The Capture Network Settings task
Preinstall ^
During
this phase, the machine is prepped for the operating system
installation. The hard disk is formatted, drivers are injected, and
Windows Updates can be added. If you are taking advantage of BitLocker,
it can be enabled here.
The Format and Partition Task can automatically create the extra partition needed for BitLocker.
Install and PostInstall ^
These
two groups handle the actual operating system install and first use
configuration. During the PostInstall phase, you can do things such as
create a Windows Recovery (WinRE) option.
The PostInstall Restart command will cause the computer to boot into the newly installed OS.
State Restore ^
While
all of the other groups took place within Windows PE, the State Restore
phase takes place within the newly installed OS. In this phase, we can
install applications, join our machine to the domain, and other common
OS tasks.
The Install Application task will install Microsoft Office 2010.
Creating a Task Sequence ^
To
create a Task Sequence, right click on the Task Sequences container and
select New Task Sequence. On the General setting tab, be logical and
specific with the Task Sequence ID. Try to relate the ID to what the
Task Sequence is doing. Our Task Sequence name for Windows 8 Enterprise
will be WIN8ENTX64.
Being specific will allow for you to easily recall Task Sequence IDs when troubleshooting.
We
will select the default Task Sequence template (Standard Client Task
Sequence) and press next. On the Select OS page, we will select the
Windows 8 OS that we previously imported. Because we are using KMS, we
will not specify a product key at this time.
The first option allows us to use KMS
We
will then proceed through the remaining wizard selecting the rest of
the defaults and entering a default local administrator password. Once
the wizard has finished, we can now see our newly created Task Sequence!
Within the physical DeploymentShare, Task Sequences are stored in C:DeploymenShareControl
In this post, we brought together our Windows 8 operating system and our
application into a Task Sequence. We learned about the advantages of
Task Sequences over a traditional based image. In our next post, we are
going to granularly edit the Task Sequence in order to manage our client’s BIOS settings.
In this post in our Windows 8 deployment series,
we will edit the Windows 8 Task Sequence to include an application and
to provide additional security. We will also cover BIOS management
during the image process.
Part 4:
Ad
When we created our Windows 8 Task Sequence in the previous part, we used the Standard Client Task Sequence.
Standard Client Task Sequence
Microsoft
has done an awesome job making this template as versatile as possible.
If we want our setup to be as efficient as possible, we will most
certainly need to edit it. Let’s get down to it!
Adding in Office ^
In
Part 2, we created the Office Application. However, our Task Sequence
has no idea that it even exists. We will need to edit the Task Sequence
and add it. To edit your Task Sequence, right click on the Task Sequence
and select Properties. Once the General tab has opened, select the Task
Sequence Tab.
Task Sequence Initialization
Expand
the State Restore section and then click the Install Applications task.
Select Install a single application and then select Browse. Finally,
select the previously created application (Microsoft Office 2010).
If
you select Install multiple applications, end users can select the
applications to add to their computer before the machine images.
If
you wish to install multiple applications (for example Adobe Reader and
Office), you can do so. First, add in the Application (using the
directions in Part 2 of this series). After the application has been
imported, edit your Task Sequence. Select the Install Applications Task.
Then select Add – General – Install Application.
Adding an additional Install Application Task
After
the Install Application task is added, select Install a Single
Application and specify your new Application. If you find yourself
adding multiple applications, it is a best practice to give each task a
unique name. In the screenshot below, each Install Application task has
the application name specified afterwards.
This Task Sequence is used for Offline machines in our corporate environment.
Securing the Task Sequence ^
As
we discussed in part 3, a Task Sequence can be divided into two
sections; the Windows PE section and the actual OS. When the computer
has fully load the OS and is customizing it, the machine is in the State
Restore phase of the Task Sequence. Every task in this phase runs as
the local administrator. From a security stand point, this can be a big
deal. If your machines are doing a lot of tasks in this phase, a user
could easily walk up to the machine and perform malicious tasks (at
worse). At best, your users will log out the local administrator and log
in as themselves (which would kill the Task Sequence).Either way, we
need to stop this and to secure the State Restore phase. There are two
main ways to do this.
Locking the computer ^
The
easiest way is to lock the computer. To do this, add a new task at the
very beginning of the State Restore phase. To do this, select Add – then
select General – finally select Run Command Line. Name the Task “Lock
Workstation” and add rundll32 user32.dll,LockWorkStation as the command.
The Lock Workstation Task
If
the computer restarts during the State Restore phase (for example,
after applying Windows Updates), you will need an additional Lock
Workstation task. To make your life easier, simply copy the first Lock
Workstation task and paste it. Then move it to the proper location.
While this is the quickest option, user may still become confused as to
when the imaging process is finished.
Hiding the shell ^
The
second option is to prevent Explorer.exe from starting. By doing this,
the user only sees the Task Sequence and will not see the Start Menu,
Taskbar, etc. You can achieve this by adding a new task at the beginning
of the State Restore phase. This task should read taskkill.exe /im explorer.exe.
Remember that if the computer restarts, you will need to add this task
in again. Beginning in MDT 2012, a new CustomSetting command is
available named HideShell. I find this way preferable as the end user
can clearly see that the computer is still imaging.
BIOS update ^
In
my personal opinion, there is no better time to update the BIOS than
during the imaging process. To do this, we are going to treat our BIOS
updates as an application. First, download the needed BIOS updates for
all of your computer models. Create a folder under the Applications
folder (in the Deployment Share) and name it BIOS. Then create sub
folders for each model. Finally, rename each BIOS Update to
BIOSUpdate.exe. For documentation, I also add a text file to each
subfolder listing the BIOS version (example: A06)
Folder Structure for Storing BIOS Updates
Next,
edit your Task Sequence and open the PreInstall group. Add a new Run
Command Line Task and move it down until it is right above the Set Task
Sequence Variable task.
In our environment, the task is named BIOS Updates.
Because we are using Dell Machines in our test environment, we will add BIOSUpdate.exe -nopause –noreboot
as our Command Line. If you have other models, you will need to specify
a silent command and a no reboot command. Finally, set your Start in
location to Z:ApplicationsBIOS%MODEL%.
BIOS update
Now,
machine will automatically pull and install their correct BIOS update!
And they will automatically look in the correct folder – with just a
single task!
Conclusion ^
In
this post, we added an Application to our Task Sequence, secured our
deployment, and learned how to update the BIOS during Imaging. In our
next post, we will dive into all of the answer files that MDT uses.
These include the CustomSettings and Bootstrap.ini files. We will also
build our Windows PE boot images!
As always, if you have any questions or comments – please let us know in the Comments Section.
Part 5
In our previous post in my Windows 8 deployment series, we configured our Windows 8 Task Sequence.
This task sequence does a lot including installing our application,
Microsoft Office. We did not, however, specify items like: how to join
the domain or our language and time zone.
Contents of this article
With
the Microsoft Deployment Toolkit, items like this are not specific to
the operating system. Instead, these settings are kept in answer files
and injected at the appropriate time. In MDT, we will mainly deal with
two files: Bootstrap.ini and CustomSettings.ini. Both of these files can
be found in the Control folder under your DeploymentShare (ex:
C:DeploymentshareControl).
Both answers files with the DeploymentShare control folder
Bootstrap ^
The
Bootstrap.ini file contains the share path to your DeploymentShare as
well as credentials to connect to the DeploymentShare. This file is
copied onto your MDT boot media (Network Boot image, CD, USB drive,
etc). This means that anytime you make a change to this file, you will
need to use MDT to update the boot media. As a best practice, the user
you specify in your Bootstrap.ini file should only have read/execute to
the DeploymentShare.
A sample boot strap file
CustomSettings.ini ^
For
all intents and purposes, the CustomSettings.ini file is the general
answer file for MDT. Within, you can specify any broad setting that
machines in your environment will need. For example, you can specify
your Domain (along with the credentials to join the domain), the default
Task Sequence, and the status of BitLocker. When you first setup MDT,
your CustomSettings.ini file will look something like this:
Default CustomSettings File
While
this file is a good start, you will probably want some additional
rules. For example, when a Task Sequence has finished, it will give us a
Final Summary showing that everything is fine. To save us (and our
users a step), we will add a SkipFinalSummary=Yes to our CustomSettings
file. Now, we will only get a Final Summary if our Task Sequence has an
error.
As you continue to build on MDT, your CustomSettings file
will likely grow. Below is an example of a full CustomSettings file that
automates everything but the name prompt:
A very detailed CustomSettings file
If you use the file above as a template for your organization, you will need to add in the following values:
- AdminPassword: Your Default Local Administrator Password
- JoinDomain: Your Domain name (ex: Test.local)
- DomainAdmin: An account that has permission to add a computer to the domain
- DomainAdminDomain: Your Domain name (seems redundant)
- DomainAdminPassword: The password for the account above
Updating the DeploymentShare ^
When
I first started with MDT, I was very confused on when to update the
deployment share. I wondered if I should update when I add a driver or
should I update when I modify a Task Sequence. For a good few months, I
updated after every change just to be safe. Needless to say, I wasted a
lot of time that way.
So when should you update the deployment share? Only when something has changed that is needed on the boot media. This includes:
- Drivers needed to connect to the deployment share (network drivers, mass storage)
- When you have added in an extra tool (like DaRT)
- When you have changed something on the Boot.ini file
- When you have updated MDT to a new version (2010 to 2012, 2012 to 2012 Update1, etc.)
You
do not need to update the deployment share if you have updated a Task
Sequence, added in an Application, or changed the CustomSettings.ini
file. To update the deployment share, simply right click on your
Deployment Share and select Update Deployment Share.
Why it is not named “Update Boot Media” is beyond me…
The
first prompt will ask if you would like to optimize the boot image
update process or if you want to completely regenerate the boot image.
In most cases, select the default selection for your Boot image.
If you ever update your Deployment Share to a new version of MDT, be sure
to completely regenerate your boot images. Continue through the wizard
and your MDT Boot Media will automatically be generated.
Finally, we are almost ready to watch our deployment of Windows 8! So far, we
have built our Deployment Share, imported our software, configured a
Windows 8 Task Sequence, and setup our Boot.ini and CustomSettings.ini
answer files.
In our next post, we will be importing our boot media and configuring Windows Deployment Services. If you have any problems with your answer files or need clarification on specific settings, let us know in the comments.
Part 6
Windows Deployment Services (WDS) allows us to distribute Windows 8 on an enterprise wide scale. In part 6 of my Windows 8 deployment series, we will configure WDS and optimize our image deployment.
The
greatest thing about MDT is how what you need is always where you are
looking. In our last post, we finished by updating our deployment share.
By updating our deployment share, MDT automatically built our boot
media. We did not have to call DISM or any other tool in order to do
this. The second greatest thing is how versatile MDT is.
By
default, both a .WIM and an .ISO file are created when we update our
deployment share. This allows us to use a variety of deployment options
(CD, USB, and PXE). In your environment, you will most likely use PXE as
the primary means of deployment. As efficient as WDS is, you can deploy
a complete OS, necessary applications, and settings in under 30
minutes! Oh – and it’s free!
This production machine has just 2 GB of RAM and a traditional hard drive. Still imaged in 29 minutes!
How to install WDS ^
Setting
up and configuring WDS in Server 2012 is a snap when compared to
earlier versions. Within Server Manager, we will launch the Add Roles
and Features wizard.
We will then proceed through our wizard and select the Windows Deployment Services server role.
This role will also install the WDS RSAT console.
Continue through the wizard. Be sure that under Role Services, both Deployment Server and “Transport Server” are selected.
The Transport Server service provides multicasting capability.
Finally, press “next” and then “install”. After a few minutes, your server will have the WDS role installed!
If you will be configuring multiple WDS servers, export the configuration settings to automate setup.
Configuring WDS ^
Now
that WDS is installed, we will need to configure a few items. First,
launch the Windows Deployment Services MMC. Expand to your server, right
click, and select “configure”.
The WDS MMC
Once the Configuration Wizard is launched, proceed through the wizard. Be sure to select “Integrated with Active Directory”.
Integrating WDS with AD makes management much easier
Once you reach the PXE Server Settings menu, select “Respond” to all clients computers (known and unknown).
Selecting this option will allow you to use MDT in a nearly Zero Touch environment.
Continue through the rest of the wizard and launch the Deployment Workbench.
Enabling Multicasting with MDT ^
When
MDT is integrated into WDS, imaging is a whole lot easier! For one, you
don’t have to worry about multicast sessions or prestaging clients! To
configure MDT for multicasting, right click on your deployment share and
select Properties. On the General Tab, simply check the Enable
Multicasting for this Share button.
They certainly do make it easy!
After
pressing Ok, refresh your WDS console. Then expand the Multicast
Transmissions section. You should now see a new multicast session for
MDT.
This Auto-Cast session is only on and always activated. It is ready to deploy!
Importing the boot images ^
Finally,
we need to import our MDT generated boot images into WDS. This will
allow computers to PXE-stream our Windows PE setup. Within the WDS MMC,
right click on Boot Images and select Add Boot Images. If you do not see
your Boot Images listed, browse to your deployment share and open the
Boot folder.
Our X86 MDT generated boot image
For simplicity, I will only import the x86 boot image. The x86 boot image will deploy a 32 bit and 64 bit operating system.
A production view of a WDS server with boot images
Now that WDS is configured, we are ready to deploy Windows 8! In our next post, we will deploy Windows 8 and streamline the installation process. If you have any questions or comments, please let us know!
Part 7
We are finally ready to deploy Windows 8! In 7th post our Windows 8 deployment series, we will fine tune and optimize our deployment process.
The case for VM test clients ^
The fastest and most efficient way to test a deployment is through the use of VMs. With Hyper-V, you can host VMs on Servers, desktops or laptops.
VMs allow for anywhere access, remote visual control of the BIOS and
PXE options, and the ability to instantly revert back to a saved state.
Physical hardware certainly is still required to test and manage driver installations but your MDT life will be a whole lot easier with a VM as a test client.
Booting Up ^
So
we have a configured deployment share, WDS loaded with our boot images,
and a ready VM. We decided to keep most of the default options in our
CustomSettings.ini. Let’s see what happens:
Our Default CustomSettings.ini file
Once
we start our VM and tell it to PXE boot, it will contact our WDS server
and downloaded the specified boot image (LiteTouchPE_x86)
The TFTP transfer of the MDT boot media
After
30 seconds or so, your boot image should be downloaded. The Windows PE
OS will begin to load into a virtual X: drive. Because this X: drive
is stored within RAM, it is volatile. If you do any manual
customizations during the Windows PE stage, keep in mind that these
settings will be lost after a reboot. For example, a manual drive
mapping to a file share will disappear when the client is rebooted.
Depending on your version of Windows PE, this screen may appear differently.
Once
the Windows PE is fully loaded, MDT will launch the Windows Deployment
Wizard (BDDRun.exe). This wizard will look at the machine to establish
variables and check the CustomSettings.ini file for input. Because our
CustomSettings.ini file is pretty bare, a good deal of user input is
required. First, we must select our Task Sequence (even if we only have
one listed). Notice the number of windows that we will need to proceed
through (Task Sequence, Computer Details, Locale and Time, Ready).
Displayed here is the Task Sequence Name. The Task Sequence ID is not shown in the wizard.
After
selecting our Task Sequence, we are taken to the Computer Details
section. We can either accept the default generated name or provide
specific one. We can also provide information to join the domain. By
doing these two steps before imaging, we do not have to visit the
machine after the Task Sequence has completed.
The Computer Details windows in the Deployment Wizard
In
the screenshot above, notice that we now have a few additional steps
until the imaging starts. These extra steps are due to tasks in our Task
Sequence. For example, we do not have an Application Selection window
because we specified Office as our single application within the Task
Sequence.
The Install Applications Task in our Windows 8 Task Sequence
After proceeding through the next several screens and filling out any required steps, we are ready to image!
Deployment Wizard Input Summary
While
that process only took a minute or two, imagine the time wasted doing
this on a large scale or the possible mistakes that could be made (such
as the Time Zone selection). Let’s streamline this a bit by adding these
additional lines to our CustomSettings.ini.
SkipBitLocker=YESSkipBitLockerDetails=YESSkipDomainMembership=YESSkipLocaleSelection=YESSkipRoles=YESSkipSummary=YESSkipTaskSequence=YESSkipTimeZone=YESSkipUserData=YESTaskSequenceID=WIN8RTMX64DeploymentType=NEWCOMPUTERJoinDomain=TEST.localDomainAdmin=mdtdomainjoinDomainAdminDomain=Test.localDomainAdminPassword=passwordKeyboardLocale=en-USUserLocale=en-USUILanguage=en-USTimeZoneName=Eastern Standard TimeTimeZone=35
By adding the lines above, we went from 18 prompts requiring input down to just a single required prompt – the computer name!
Enter Computer name
With
MDT, you can steer down a User Driven Installation (person at the
client selecting the imaging options such as a specific task sequence)
or a Zero Touch Installation. With our current setup, all that is
required of us is the computer name. In our next post, we are even going to automate that.
Part 8
In Part 8 of my Windows 8 deployment series I will show you how the MDT Database allows you to nearly reach a Zero Touch Installation through the use of automatic naming.
With
the MDT database, we can dynamically alter our customsettings.ini file
for individual clients. For example, you can specify SkipBitlocker=Yes
as your default value. By using the MDT database, set SkipBitlocker=No
for any of your laptops.
Installing the database ^
MDT
requires the use of a SQL database, SQL Server 2012, for example. If you
do not have a SQL server in your environment, you can use SQL Server Express. In this guide, we will install SQL Server Express 2012 on our machine hosting the MDT Deployment Share.
After you launched SQL Server setup, select New SQL Server stand-along installation.
SQL Server Installation Center
Proceed through the installation and select the default Feature Selections.
SQL Server Feature Selection
Continue
through Instance Configuration and Disk Space Requirements windows by
accepting the default values. On the Server Configuration window, change
SQL Server Browser Startup Type from Disabled to Automatic.
SQL Server Browser is needed for Windows PE
Continue
through the remaining windows by accepting the default values and allow
the installation to finish. This process can take a little while. Once
the installation has finished, ensure that all SQL components installed.
On my first try, a component failed and I didn’t catch it until later.
The SQL Server Completion Summary
We
have a few last things to configure on our SQL server. Launch SQL
Server Configuration Manager and expand the SQL Server Network
Configuration node. Under Protocols for SQLExpress, enable Named Pipes.
Named Pipes allow for Windows PE to connect to a SQL Server
On
your SQL server, you will need to create an inbound firewall exception
for %ProgramFiles%Microsoft SQL Server90Sharedsqlbrowser.exe and for
%ProgramFiles%Microsoft SQL
ServerMSSQL11.SQLEXPRESSMSSQLBinnsqlservr.exe
Firewall exception for the SQL Browser executable
After this configuration is complete, restart the SQL server once.
Connecting SQL to MDT ^
Within
the Deployment Workbench, navigate to Database which can be found under
Advanced Configuration. Right click on Database and select New
Database.
Enter in your SQL Server name and SQLEXPRESS as the Instance name. Be sure Named Pipes is selected as the Network Library.
Connecting to the MDT Database
Create a new database and name it.
For simplicity, I named my database MDT.
On the SQL Share window, name your SQL Share. I prefer the default suggestion of DeploymentShare$
SQL Share
Proceed
through the rest of the wizard and ensure that the connection is
successful. This is shown on the Connection Confirmation window.
MDT is now successfully connected to our database.
In
part 5 of this series, we configured our CustomSettings.ini. In our
detailed example, we specified our Database rules. If you did not use
that detailed example, you will need to do one final step. Within in the
Deployment Workbench, right click on Database and select Configure
Database Rules.
As a best practice, only query what is needed within your environment.
Because
we are interested in computer-specific settings, we will uncheck all
other options. On querying what your environment requires will save you
time during the imaging process. Continue through the wizard.
Review the values
Once
connected, we can now get really granular with our deployments and even
automate the naming portion of our imaging process. In our previous
post, we eliminated all imaging prompts except for the name prompt. The
default name is automatically generated and looks like this:
Computer name
Let’s
create a computer account in MDT for this machine and give it a name of
TestPC-01. In the Deployment Workbench, expand the Database node. Right
click on Computers and select New.
The New Computer Prompt within MDT
For
the description, enter the computer name. Although this is optional, it
is much easier to maintain your Database when the description matches
the computer name. For the identification value, we will enter the MAC
address. It must be in the format of AA:BB:CC:DD:EE:FF (all letters must
be capitalized).
The Identity Tab is now filled out correctly.
Select
the Details tab and scroll down to the Identification section. For
OSDComputerName, enter your computer name and press OK.
OSDComputerName
After booting back up our machine again, check out the computer name:
Check the computer name
Pretty awesome! If you wanted to do this on a wide scale, you can easily grab your MAC addresses from DHCP or your serial numbers from Active Directory. Because most MDT tasks can be scripted with PowerShell, you can also import computers on a mass scale from a CSV file.
If
you have any questions or problems setting this up (or if you think
this is pretty neat), please let us know! In our final post, we will
cover troubleshooting MDT.
Part 9
The final part of our Windows 8 Deployment series will walk through the troubleshooting process for MDT and cover two common errors.
Contents of this article
- A connection to the Deployment Share could not be made
- Task Sequence constantly reboots
- Log file locations
- Remote logging in MDT
You’ve
finally done it! Your deployment share is completely configured and
your database is populated! You have been rolling out Windows 8 clients
and completely moved MDT into production so that the rest of your
department can manage it. One day, you go to image a client and get a
big nasty error! Or worse, your Task Sequence never even connects!
Something has changed and it is up to you to figure it out.
A failed Deployment Summary
Lucky for us, MDT logs everything. So let’s put on our Troubleshooting Hats and get down to business.
A connection to the Deployment Share could not be made ^
The
number one tool for troubleshooting MDT in Windows PE is the command
prompt. Getting to the command prompt it easy; it can be launched by
pressing F8.
The command prompt in Windows PE
If you are receiving error messages stating that the deployment share
could not be reached or that a connection to the Deployment Share could
not be made, launch a command prompt and run IPCONFIG to ensure the
network drive installed and that you have an IP address. If you do have
an IP address, you will want to check your BootStrap.ini file. To open
the file, type notepad (in the command prompt) and open
X:DeployScriptsBootStrap.ini
Notepad also gives you a Windows Explorer like access in case you do not have DaRT installed.
Make a note of your deployroot line and ping the server exactly how you have
it specified in the BootStrap.ini. If you specified your deployroot as
\MDT.Test.localDeploymentShare$, ping MDT.Test.local.
If you are still receiving an error connecting your deployment share, check the
share and security permissions on your deployment share to ensure that
the user specified in BootStrap.ini has read/execute.
Task Sequence constantly reboots ^
If your Task Sequence reboots before prompting for a name (or other
information), something has either gone wrong in your boot image or
something is incorrectly specified in your CustomSettings.ini. As a
test, roll your CustomSettings.ini back to the default state. If you
don’t have a copy of the default file, you can copy this one:
|
1 2 3 4 5 6 7 8 9 10 |
[Settings] Priority=Default Properties=MyCustomProperty [Default] OSInstall=Y SkipCapture=NO SkipAdminPassword=YES SkipProductKey=YES SkipComputerBackup=NO SkipBitLocker=NO |
Most
of the time, the issue is caused by someone specifying TaskSequenceID=
with a Task Sequence ID that doesn’t exist. Because the Task Sequence
doesn’t exist, the deployment can’t proceed and immediately restarts.
If your problem was not resolved by restoring a default customsettings.ini file, completely regenerate the MDT boot images.
The boot images are regenerated by updating the Deployment Share.
After
the boot images are rebuilt, be sure to import them into WDS or update
your physical boot media (if you are using CD/USB drives). This problem
is commonly seen when MDT receives an update.
Log file locations ^
MDT
can be a bit log excessive. There is literally a log file for every
script. For example, the script that joins a machine to the domain is
named ZTIDomainJoin. As you can guess, there is a corresponding log file
named ZTIDomainJoin.log.
Notice how each completed script has an individual log file.
Most
of the time, you will be looking in the BDD.log. This file is a near
aggregate log detailing the steps in the Task Sequence for a particular
client.
Finding the log files can be a bit tricky though as they
move. Depending on the stage of the Task Sequence, the logs can be found
at the following locations:
- X:MININTSMSOSD
- C:MININTSMSOSD
- %WINDIRTempDeploymentLogs
Let’s take a look inside a sample BDD.log.
BDD.log opened in Notepad
The log above is not the easiest to read is it. Because the MDT logs and
SCCM logs are based off of each other, you can actually use the SCCM Log
Reader (SMS Trace) to view the logs. Here is a screenshot of that exact
same log within SMS Trace:
BDD.log opened in Trace32
The log file above is much easier to read! As a bonus, errors and warnings
automatically color code themselves. If you do not have SMS Trace
installed, it can be downloaded here.
Remote logging in MDT ^
If you are like me, physically having to visit a machine is not fun. To
help with your troubleshooting, MDT can automatically write BDD.log to
your deployment share. To enable this feature, add this line to the
[Default] section in your CustomSettings.ini
SLShareDynamicLogging=\SERVERdeploymentshare$logs%OSDComputerName%
The logs folder centralizes MDT Loggings
Wrapping It up
This brings our Deploying Windows 8 series
to a close! In this post, we walked through two common MDT errors and
worked with logging in MDT. In this series, we completely setup a MDT
Deployment Share, imported our OS and applications, and completely
automated our imaging process. When setting this up in your environment,
let us know if you run into any trouble and how your Windows 8
deployment goes!
