Deploying a Windows 10 1607 Reference Image with Microsoft Deployment Toolkit 8443

Continuing on from my previous post (Building a Windows 10 1607 Reference Image with Microsoft Deployment Toolkit 8443) I’ll be continuing my series of deploying Windows 10 1607 with Microsoft Deployment Toolkit build 8443.

In this post we’ll be building a task sequence to deploy the reference image created previously and we’ll also be tackling domain joining, drivers, and post-imaging tasks.

Update 02/05/2017: Please note that this post is also relevant to Windows 10 1703 (Creators Update) with a few minor changes, which I’ve posted about here.

Creating the Deployment Task

These steps will create a Task Sequence that will:

  • Format the hard disk.
  • Install the Windows 10 1607 reference image.
  • Join a domain via a PowerShell script.
  • Install updates from a local WSUS server.
  1. Go to Deployment Workbench > Deployment Share > Task Sequences.
  2. Right click on Task Sequences and select New task sequence.
  3. Enter a unique ID for the Task Sequence: DEP-REF-W101607.
  4. Enter a unique name for the Task Sequence: Deploy – Reference W101607.
  5. Select the Standard Client Task Sequence template.
  6. Select REF-W101607 as the Operating System.
  7. Select Do not specify a product key at this time to activate via a KMS server or use an evaluation license, otherwise use the other options to enter the applicable product keys.
  8. Enter an Organization name.
  9. Select Use the specified local Administrator password and enter the desired password.
  10. Click Next > Next > Finish to complete the wizard.

Joining the Client to the Domain Using PowerShell.

MDT can perform a Domain Join action itself, but to keep things more manageable, here we’ll be using PowerShell. The script below was sourced from BJTechNews.org.

$strUser = "contoso.com\domain_join_user"
$strDomain = "contoso.com"
$strPassword = ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force
$Credentials = New-Object System.Management.Automation.PsCredential $strUser,
$strPassword
$strOU = "CN=Computers,DC=contoso,DC=com"

Add-computer -DomainName $strDomain -Credential $Credentials

Copy the script above into a new notepad file and edit it to match your environment configuration. Save it as domainjoin.ps1 in the location: \\WDS01\DeploymentShare$\Applications\_scripts.

Configure the Task Sequence

  1. Go to Deployment Workbench > Deployment Share > Task Sequences.
  2. Right click on Deploy – Reference W101607 and select Properties.
  3. Navigate to State RestoreWindows Update (Pre-Application Installation).
  4. On the Options tab of the Windows Update (Pre-Application Installation) action, uncheck the Disable this step. Do the same for the Windows Update (Post-Application Installation) action below the Install Applications action.
  5. Select the Install Applications action, and click the Remove button at the top of the Task Sequence actions view.
  6. Navigate to State Restore > Recover From Domain.
  7. Click on the Add button at the top of the Task Sequence actions view and go to General > Run PowerShell Script, click to add the action.
  8. In the Properties tab of the action just created enter: Script – Domain Join in the Name field.
  9. In the Properties tab of the action now enter: %deployroot%\Applications\_scripts\domainjoin.ps1 in the PowerShell script field.
  10. Click Apply to save the changes.
  11. Go to the OS Info tab of the main Task Sequence window and click Edit Unattend.xml – this will create a catalogue file and may take some time.
  12. When the catalogue has been created, the Windows System Image Manager will open.
  13. Navigate to 4 specializeamd64_Microsoft-Windows-Shell-Setup__neutral_31bf3856ad364e35_nonSxS.
  14. Select CopyProfile in the Properties window and change it to True.
  15. Save the Unattend.xml by clicking the save icon. you may get a prompt about validation errors, these are save to ignore – click Yes.
  16. Close the Windows System Image Manager and click OK to close the Task Sequence Properties window.

Testing the Task Sequence

Now we’re going to test the Task Sequence using a Virtual Machine. Open Hyper-V or your virtual machine software and create a VM with the specifications below:

  • 2x vCPUs
  • 4GB RAM
  • 40GB minimum Hard Disk
  • Network Adaptor with access to the MDT and WSUS server.
  • The LiteTouch_x64.iso from the \\WDS01\DeploymentShare$\Boot folder added as a boot device.
  1. Start the Virtual Machine and boot into the deployment environment from the LiteTouch_x64.iso.
  2. Select the Deploy – Reference W101607 task sequence.
  3. Enter VM-DEP1 as a Computer name.
  4. In the Capture image section, select Do not capture an image of this computer.
  5. Click Next to start the Task Sequence.
  6. When the Task Sequence completes, the VM will shut down.
  7. Boot the VM again and it should boot into a fully updated installation of Windows 10 1607.
  8. Log in with a domain account. Microsoft Office 2016, Adobe Reader DC, VLC media player and Google Chrome should be installed, and the profile should be customised as you specified.

Optional Post Image Tasks

Consider what additional tasks you want to be performed after the image has been deployed. Third party anti-virus software is most likely best installed and updated after the main imaging process. You may have configuration tasks that are performed via Group Policy which could be moved to the Deploy Task Sequence and removed from Group Policy, speeding up boot and log in times.

Setting the Default Application Associations

You may want to set the default application associations for your reference image. You can do this a variety of way but here is how you can configure them as part of the Deploy Task Sequence.

  1. Using the deployed image on your VM, go to Settings > System > Default apps.
  2. Set the Default apps as required.
  3. Open PowerShell as Administrator by clicking on the Windows button, typing “PowerShell” then right click on the PowerShell icon and select Run as Administrator.
  4. In the PowerShell window type the following and press enter:
    Dism /Online /Export-DefaultAppAssociations:C:\AppAssoc.xml
  5. After a few seconds you should see The operation completed successfully in the PowerShell window.
  6. Navigate to C:\AppAssoc.xml.
  7. Copy AppAssoc.xml to \\WDS01\DeploymentShare$\Applications\_scripts.
  8. Open the Deployment Workbench and go to Deployment Share > Task Sequences.
  9. Right click on the Task Sequence Deploy – Reference W101607 and select Properties.
  10. Click on the Task Sequence tab and navigate to Postinstall > Configure.
  11. Click the Add button at the top of the Task Sequence actions view and go to General > Run Command Line.
  12. Enter Set Default App Associations in the Name field, and in the Command line field enter:
    Dism.exe /Image:%OSDisk%\ /Import-DefaultAppAssociations:%DEPLOYROOT%\Applications\_scripts\AppAssoc.xml
  13. Click Apply to save the changes.
  14. Run the Deploy Task Sequence and the default apps you specified should be configured.

Driver Management

Now that we’ve created a reference image and deployed it on to a VM, it’s time to prepare to roll the image out on to physical hardware, which means setting up drivers. There are a few ways to do this, but here I’ll show the method I’ve been using which has worked very well for a variety of manufactures and models of devices, all running Windows 10 1607 without issue.

The first thing you’ll need to have is the model numbers for all the devices you want to roll out the image to. You can find this out by booting the device in to the deployment environment using either the LiteTouch_x64.iso boot disc or the network using PXE, here’s a previous post I wrote on how to set up PXE booting: PXE Booting for Microsoft Deployment Toolkit.

When the device is booted into the deployment environment, press F8 to get a command prompt, and typing out the following command:

wmic computersystem get model

The output of the command is the model number you’ll need.

A Word on Obtaining Drivers

The next thing you’ll need is the actual driver files that are required by your devices. I would like to stress that you should only add drivers that Windows 10 does not install itself during deployment. I’ve found Windows 10 is very good at installing missing drivers from Windows Update, but it can take some time and I wouldn’t recommend it as a solution for a full roll out. Building the drivers into MDT makes the process much quicker.

The find out what drivers you’ll need, deploy the reference image to each type of device you have and using Device Manager, see what’s missing. You can Check online for updates from Microsoft Update from the Update section in Settings which should find and install the relevant drivers, then you can check the Update History and see what you need to import into MDT. I would not advise adding the Drivers classification to WSUS as it will bloat the database and make it unmanageable.

To successfully import the drivers you’ll need the .inf files. Most large manufacturers (HP, Lenovo, Dell) do a decent job of providing drivers that can be extracted from an .exe and used in MDT, although there are always a few drivers for laptops especially that are .exe’s and can have costed me some time and sanity. You can save yourself a lot of time by using the Microsoft Update Catalog to search for and download the specific drivers that Microsoft Update installs, and import the downloaded .cab files into MDT.

Now we have our drivers downloaded, we need to edit the Deployment Share’s customsettings.ini to tell it what drvier folder to use for what model.

  1. Go to the Deployment Workbench and right click on the Deployment Share, select Properties.
  2. Go to the Rules tab in the Properties window.
  3. Enter the following under the [Settings] section, and click Apply to save the changes:
    [Model Number]
    DriverGroup001=Windows 10 x64\Model Number
    DriverSelectionProfile=nothing
    OSDPrefix=PC

    You’ll need to enter the above text for each model. Below is an example of my customsettings.ini for reference.

    [Settings]
    Priority=Model, Default, SetOSD
    Properties=OSDPrefix
    
    [HP 250 G5 Notebook PC]
    DriverGroup001=Windows 10 x64\HP 250 G3
    DriverSelectionProfile=nothing
    OSDPrefix=HP
    
    [80J2]
    DriverGroup001=Windows 10 x64\Lenovo E50
    DriverSelectionProfile=nothing
    OSDPrefix=LEN
    
    [Virtual Machine]
    DriverGroup001=Virtual Machine
    DriverSelectionProfile=nothing
    OSDPrefix=VM
    
    [Default]
    _SMSTSORGNAME=Mike Galvin | OSD Solutions
    _SMSTSPackageName=%TaskSequenceName%
    UserDataLocation=NONE
    ComputerBackupLocation=\\wds01\DeploymentShare$\Captures
    BackupFile=%TaskSequenceID%_#year(date) & "-" & month(date) & "-" & day(date)#.wim
    OSInstall=Y
    TimeZoneName=GMT Standard Time
    KeyboardLocale=0809:00000809
    UILanguage=en-GB
    UserLocale=en-GB
    KeyboardLocale=en-GB
    BitsPerPel=32
    VRefresh=60
    XResolution=1
    YResolution=1
    WSUSServer=http://wsus01:8530
    SkipAdminPassword=YES
    SkipCapture=NO
    SkipRoles=YES
    SkipProductKey=YES
    SkipUserData=YES
    SkipComputerBackup=YES
    SkipBitLocker=YES
    SkipLocaleSelection=YES
    SkipTimeZone=YES
    SkipDomainMembership=YES
    SkipSummary=YES
    SkipFinalSummary=YES
    FinishAction=SHUTDOWN
    OSDComputerName=%OSDPrefix%-%SerialNumber%
    
  4. In the Deployment Workbench, go to Deployment Share > Out-of-Box Drivers.
  5. Right click and select New Folder, call the folder Windows 10 x64.
  6. Right click on the Windows 10 x64 folder and select New Folder, call the folder a suitable name for the model of device you’ll be adding drivers for. For me I’ll use HP 250 G3.
  7. Right click on the folder you just created and create folders for each driver type you’ll be adding, eg. Graphics, Chipset, Bluetooth.
  8. To import the drivers, right click on a driver type folder and select Import Drivers.
  9. Enter the source directory of the drivers and check the Import drivers even if they are duplicates of an existing driver check box.
  10. Click Next and complete the wizard. The wizard will copy all the files needed to the driver type folder.
  11. Repeat steps 8-10 for each driver type required.
  12. Now we must configure the Deploy Task Sequence to use the rules in the customsettings.ini.
  13. Go to Task Sequences and right click on the Deploy – Reference W101607 Task Sequence, select Properties.
  14. On the Task Sequence tab, go to InitializationGather local only.
  15. On the Properties tab, select Gather local data and process rules and enter customsettings.ini in the Rules file field.
  16. Click Apply to save the changes.

Boot the physical device into the deployment environment and run the Deploy – Reference W101607 Task Sequence. After it completes, check Device Manager and all devices should be successfully installed.

Adding Drivers to the MDT Boot Image

It may be necessary to add drivers to the MDT Boot Image for devices such as storage or network adaptors, although with the current version of MDT (8443) and all the devices I’ve deployed thus far I’ve not had to do this, but for completeness here’s how to do it.

First we need to determine if we need drivers installing:

  1. Boot the device in question into the deployment environment and press F8 to bring up a command prompt.
  2. Type ipconfig and if you have an ip address, you do not need to add network adaptor drivers
  3. Now, type diskpart, and when diskpart has loaded, type list disk. If the local hard drive is listed, you do not need to add storage drivers.

Should you need to add drivers:

  1. In the Deployment Workbench, go to Deployment Share > Out-of-Box Drivers.
  2. Right click and select New Folder, call the folder WinPE x64.
  3. Right click on the WinPE x64 folder and select New Folder, call the folder a suitable name for the model of device you’ll be adding drivers for. For this I’ll use HP 250 G3.
  4. Right click on the folder you just created and create folders for each driver type you’ll be adding, eg. Storage, Network.
  5. To import the drivers, right click on a driver type folder and select Import Drivers.
  6. Enter the source directory of the drivers and be sure to tick the Import drivers even if they are duplicates of an existing driver check box.
  7. Click Next and complete the wizard. The wizard will copy all the files needed to the driver type folder.
  8. Repeat steps 8-10 for each driver type required.
  9. Now we must create a Selection Profile for WinPE x64.
  10. Go to Advanced Configuration > Selection Profiles.
  11. Right click on Selection Profiles and select New Selection Profile.
  12. Enter WinPE x64 as the Selection profile name.
  13. In the folders list navigate to DS001:\ > Out-of-Box Drivers > WinPE x64 and check the box next to the folder.
  14. Click Next > Next > Finish to complete the wizard.
  15. Right click on the Deployment Share and select Properties.
  16. Go to the Windows PE tab and change the Platform drop down menu to x64.
  17. Go to the Drivers and Patches tab, and change the Selection profile drop down menu to WinPE x64.
  18. Check that Include only drivers of the following types is selected and both Include all network drivers in the selection profile and Include all mass storage drivers in the selection profile are checked.
  19. Click Apply to save the changes, click OK to close the Properties window.
  20. Right click the Deployment Share and select Update Deployment Share.
  21. Select Completely regenerate the boot images, and then Next. The boot images will be regenerated with the drivers included.
  22. Click Finish to complete the wizard.

You’ll need to add the newly generated boot images to Windows Deployment Services for PXE booting:

  1. Open Windows Deployment Services MMC.
  2. Expand Servers > wds01.yourdomain > Boot Images.
  3. Right click on the old boot image and remove it.
  4. Right click in the empty boot image window, and select Add Boot Image.
  5. Browse to E:\DeploymentShare\Boot\LiteTouchPE_x64.wim and click through to complete the wizard.

Boot your device via PXE and it should now have the network/storage drivers needed to carry out the Deploy Task Sequence.

Securing the Deployment Environment

If all has worked then you now have a fully functioning deployment solution. At this point I would suggest securing your Deployment Environment by removing the login details from bootstrap.ini that we added in the very first post.

  1. In Deployment Workbench, right click the deployment share and select Properties.
  2. Select the Rules tab and click the Edit Bootstrap.ini button.
  3. Remove the following from the Bootstrap.ini
    UserDomain=contoso.com
    UserID=mdt_admin
    UserPassword=p@ssw0rd
  4. Close and Save the Bootstrap.ini

This concludes the ‘real world’ deployment phase of the walk through. In this post I’ve talked about deploying the reference image, joining the client to a domain, performing additional post-imaging tasks, and installing drivers required for multiple device models.

I hope this has helped you in some way. If you have any questions or comments, let me know here or on Twitter!

Follow me on Twitter – @Digressive.

5 thoughts on “Deploying a Windows 10 1607 Reference Image with Microsoft Deployment Toolkit 8443

  1. Pingback: Building a Windows 10 1607 Reference Image with Microsoft Deployment Toolkit 8443 | Stick To The Script!

  2. Awesome step by step details. Getting ready to deploy Win 10 in my environment and still undecided between v1607 and v1703.

    Questions
    [1] I’ve setup using the “total driver control” method by the Deployment Research people and seems to work for me. Is there any benefit setting it up in customsettings.ini ?

    [2] I’m working primarily with Dell computers and using their cab files to import drivers into MDT. I will be deploying some Alienware units and the drivers are all individual. For this, I ended up creating individual folders for each device I thought was needed. To use the “total driver control” method, I had to structure it as follows
    -Out-of-Box Drivers
    -Windows 10 x64
    – Alienware
    – Alienware Aurora R6
    – Intel 3160 Bluetooth
    – etc, etc, for other devices.

    I actually like setting up the individual folders after reading through the steps your listed. For the Alienware, I had to import the drivers for each device folder manually. Normally for other Dell units, I would simply import the drivers into a folder based on the model name and in essence all the drivers would sit in this single folder.

    My question is how do you know what to name the folders and if I were to point the cab files, how would it know to place it into the individual device folders? Hope I asked that question properly. Are you doing this manually or in some way automating it?

    Bookmarked your twitter to my list of sites to check daily. Thanks for such an informative site with clear step by step details.

    Like

    • Hi there, I’m really glad my posts have helped you and thanks for the kind words. To answer your questions:

      [1] I’m not aware of any major benefit of doing driver control the way I have in the customsettings.ini – it’s just another option. Doing it the way I have still ensures that the specific model of computer only installs the specified drivers. A long time ago, when I first started with MDT I used to do the “total chaos” method, it worked out ok for me at the time, but I would never recommend it now. The reason I haven’t changed to the “Total Control” method from deploymentresearch.com (great site and great people, helped me out a lot years ago) is that I just like having the settings centralised in customsettings.ini and I haven’t had a reason to change it yet.

      [2] I hope I’m understanding your question correctly, feel free to reply if I’m missing the mark. I don’t have a way of automating driver importing. I create folders for each device type under the system model folder just for my own reference, so if I need to change out a driver, I can without having to hunt through all the drivers for that system model. I just name the graphics cards driver folder “VGA”, and the audio driver “Audio” etc. Then, when I import the drivers I do them separately. I import the system’s graphics driver to the VGA folder under the systems model folder and then to audio drive to the Audio folder and so on. My structure looks like this for example:

      -Out-of-Box Drivers
      –Windows 10
      —-Optiplex 3020
      —–VGA
      —–Audio
      —–NIC
      —–Chipset

      Hope that answers your questions. Just my two cents, go for 1703, it’s been out for a good few months now and we’ll be getting 1710 soon anyway. 😉

      Like

      • Hi Mike

        Thanks for the quick response.

        Haha… total chaos method I am also very familiar with and glad I was able to move away from that.

        You got my question right. After reading about your organization for drivers, I’m going to move in that direction as well. It will definitely make it easier to sift through.

        Here is another question related to v1703. Am I correct to understand it is a CB version as of now? And supposedly in four months from release, maybe August or September, a CBB version of v1703 will be released?

        My reason for staying with v1607 was earlier reported issues with autologin during deployment and maybe some other stuff. I required something stable a couple of months ago as I had to make a decision at that time. I’m still open to v1703 as I like the added improvements over v1607.

        Right now, I’m hesitant and apprehensive as I have yet to fully deploy Windows 10. I did some test runs but still figuring out the configurations to make it work in a school environment.

        I’m not building any images but rather using the original vanilla install wim and adding configurations on the fly via MDT during deploy. I know people create hybrid images but I just hate images period…….after so many years of thick ghost imaging. I may consider a lite hybrid image for Windows 10 if warranted.

        Would appreciate any advice. Just to let you know, I’m going to ask alot of questions. 🙂

        Like

      • Hi there,
        No problem, I don’t mind questions, but just to let you know I may not be able to get back to you immediately. 🙂

        I believe you’re correct regarding 1703 going CBB very soon and 1703 is currently CB, more info on that from MSFT here: https://technet.microsoft.com/en-us/windows/release-info.aspx?f=255&MSPPError=-2147217396

        The auto logon issue with 1703 was fixed in the June Cumulative Update. You can add it to the Packages folder in MDT and have it installed with the OS. I made a post about it recently:

        https://gal.vin/2017/05/02/building-a-windows-10-1703-reference-image/
        https://gal.vin/2017/07/10/building-windows-10-1703-reference-image-walkthrough/

        I can understand your apprehension, at the end of the day it’s not a race though right? So there’s no need to rush into deploying if you’re not ok with the outcome. Personally I believe that if you’re not 100% on deploying Win10 yet, then don’t – do more testing, put it in the hands of some users who you can work with to resolve any issues. Ultimately it’s important to identify where the apprehension is coming from and tackle it.

        I used to use Ghost a lot too…I’m glad I don’t now. I still deploy large images (~15GB) because although it does take time to deploy the image, when it’s complete, it’s ready to go with no extra work. I don’t have a lot of extra applications to install on an individual PC basis. Again though, it’s what works for you and your environment. It can get to be a lot of work trying to keep a few large images up-to-date, but this is why I created my Image Factory PowerShell script. Once a month I run the script over night and in the morning I have new up-to-date images. I’m quite proud of the script, but I doubt it’s beneficial for a lot of other people. Still, here it is if you’re interested: https://gal.vin/2017/05/12/image-factory/

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s