Walkthrough: Upgrading to Windows 10 1703 (Creators Update) with Microsoft Deployment Toolkit

If you’re looking to deploy the latest version of Windows 10 1703 (better known as the Creators Update) as a fresh install, please check out this post. This post is designed to walk through installing and configuring Microsoft Deployment Toolkit and to create a Task Sequence to upgrade to Windows 10 1703 from a previous version of Windows.

The Windows upgrade process has come along way in recent years, so in certain circumstances it may be worth while running an upgrade, rather than a wipe-and-load. Additionally with Windows 10’s frequent updates being the case now, rather than doing upgrades via WSUS which may not be preferable depending on your environment, it may be better to do upgrades in a more controlled way.

Installing & Configuring Microsoft Deployment Toolkit and Dependencies.

We’ll be using Microsoft Deployment Toolkit (MDT) version 8443, which at the time of writing is the most recent release and fully supports Windows 10 1703.

Here’s the links to download the software we’ll be installing:

First, we’ll install the Windows 10 1703 ADK. The setup will need to download additional files so it may take some time depending on your internet connection.

IMPORTANT NOTE: If you have SecureBoot enabled, you’ll get a “Program Compatibility Assistant” dialog displayed and after installation, WIMs will fail to mount and unmount. This is a known issue and there is a workaround.

On the Select the features you want to install screen select:

  • Deployment Tools
  • Windows Preinstallation Environment (Windows PE)
  • Imaging And Configuration Designer (ICD)
  • Configuration Designer
  • User State Migration Tool (USMT)

Now install MDT by running the setup file downloaded earlier, there is no specific configuration during the install wizard. After it’s installed we need to create the Deployment Share.

Create the Deployment Share

  1. Open the Deployment Workbench from the Start Menu.
  2. Right click on Deployment Shares.
  3. Select New Deployment Share.
  4. Enter the path for the Deployment Share: E:\DeploymentShare.
  5. Enter the Share name: DeploymentShare$.
  6. Give the share a descriptive name.
  7. On the Options screen, accept the defaults as you can change them later.
  8. Complete the wizard to create the share.

We now need to add an Operating System to work with.

Add an Operating System

  1. Mount the Windows 10 1703 .iso in File Explorer.
  2. Go to Deployment WorkbenchOperating Systems.
  3. Right click and select Import Operating System.
  4. In the wizard, select Full set of source files and then enter the root of the mounted .iso as the Source directory.
  5. For the destination directory name enter Windows 10 Enterprise 1703 x64 and complete the wizard.
  6. Go to the Operating Systems node again and rename the OS you just added to Windows 10 Enterprise 1703 x64.

Note: The upgrade process will not work with custom images, so you cannot build a reference image like in my previous post and use that to upgrade a computer to the latest version of Windows with all updates and applications. However, you can configure the MDT Task Sequence to install applications and run Windows Update.

Importing Applications (Optional)

You may want to add some applications to install, here I’ll cover how to add Microsoft Office. MDT recognises Microsoft Office and provides automated/silent install options.

  1. Go to Deployment WorkbenchDeployment Share > Applications.
  2. Right click on Applications and select New Application.
  3. In the New Application Wizard, choose Application with source files.
  4. Give the application the name: Microsoft Office.
  5. Enter the Source directory of the installation files.
  6. Enter the Destination directory: Microsoft Office.
  7. For the Command line enter anything – we’ll revisit this soon.
  8. On the summary page, click Next and after the files are copied click Finish to complete the wizard.

Configure the Application – Microsoft Office

  1. Right click on Microsoft Office, go to the Office Products Tab.
  2. Choose the desired Office Product to Install from the drop down menu.
  3. Check the desired Office language.
  4. Enter a product key, unless you will be activating Office via KMS in which case leave the Product Key option unchecked.
  5. Check the Customer name option and enter the desired information.
  6. Check the Display level option and select None in the drop down menu.
  7. Check the Accept EULA option.
  8. Check the Always suppress reboot option.
  9. Click Apply.
  10. Go to the Details tab and the Quiet install command should now read:
    setup.exe /config proplus.ww\config.xml

Microsoft Office is now set up to be installed silently by a Task Sequence. Please note that this will install Microsoft Office along side any previous versions. If you wish to customise the installation to a greater degree and remove older versions, the Office Customization Tool can be launched from the Office Products tab. This process can also be done for Microsoft Visio and Project applications.

We need to now create the Task Sequence that will upgrade the currently installed version of Windows to Windows 10 1703.

Create a Task Sequence

  1. In Deployment Workbench, go to Task Sequences.
  2. Right click and select New Task Sequence.
  3. For the ID enter: W10-1703-UP.
  4. Name it Upgrade Windows 10 1703.
  5. Select Standard Client Upgrade Task Sequence.
  6. Select the Operating System Windows 10 1703 x64.
  7. Do not specify a product key at this time.
  8. Enter an Organization name.
  9. Do not specify an Administrator password at this time.
  10. Complete the wizard.

Now we’ll configure the Task Sequence.

Configure the Task Sequence

  1. Right click on the Task Sequence just created and select Properties.
  2. Go to the Task Sequence tab on the Properties window of the Task Sequence.
  3. Go to the Post-Processing folder and select Windows Update (Pre-Application Installation).
  4. On the right side of the Properties window, go to the Options tab.
  5. Uncheck the Disable this step tick box and do the same with Windows Update (Post-Application Installation).
  6. Go to the Install Applications item.
  7. If you skipped the Importing Applications section, please disable the Install Applications item and go to step 10, if not please continue.
  8. In the right side of the Properties box, select the Install a single application option and click the Browse… button.
  9. Select Microsoft Office and change the name Install Applications to Microsoft Office.
  10. Click Apply and close the Task Sequence.

Next we’ll create a domain user account for MDT.

Create an Active Directory User for MDT

  1. Go to Active Directory Users and Computers.
  2. Create a user called mdt_admin.
  3. On the server where the deployment share is hosted, give mdt_admin Full Control share permissions and Full Control permissions to all the files and folders under the deployment share.

Now we’ll configure the Bootstrap.ini and the Rules.ini files to control certain aspect of the deployment environment. The settings below enable auto log in and skip the welcome screen, so these should only be used for lab/closed environments.

Configure Bootstrap.ini

  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. Add the settings below to the Bootstrap.ini.
  4. Close and Save the Bootstrap.ini
[Settings]
Priority=Default

[Default]
DeployRoot=\\SERVERNAME\BuildShare$
UserDomain=contoso.com
UserID=mdt_admin
UserPassword=p@ssw0rd
SkipBDDWelcome=YES

Configure Rules.ini

On the Rules tab of the Deployment Share properties window, add the settings below. A lot of the settings are specific to my lab environment such as my location in the world. The [Virtual Machine] section near the top is one example of how to manage drivers and auto fill computer names.

[Settings]
Priority=Model, Default, SetOSD
Properties=OSDPrefix

[Virtual Machine]
DriverGroup001=Virtual Machine
DriverSelectionProfile=nothing
OSDComputerName=%TaskSequenceID%

[Default]

_SMSTSORGNAME=Deploy Share
_SMSTSPackageName=%TaskSequenceName%

OSInstall=Y
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerBackup=YES
SkipBitLocker=YES

TimeZoneName=GMT Standard Time
KeyboardLocale=0809:00000809
UILanguage=en-GB
UserLocale=en-GB
KeyboardLocale=en-GB

SkipUserData=YES
SkipDomainMembership=YES
SkipLocaleSelection=YES
SkipTimeZone=YES
SkipSummary=YES
SkipFinalSummary=YES
FinishAction=SHUTDOWN
WSUSServer=http://wsus01:8530
SLShare=\\mdt01\deploymentshare$\Logs
EventService=http://admin01:9800

 

Run the Upgrade Task Sequence

Now it’s time to run our Upgrade Task Sequence.

For my demo here, I’ll be using a “lived-in” Hyper-V virtual machine running Windows 10 Professional 1511 x64 – OS Build 10586.164. It has Office 2016, Adobe Reader, Google Chrome, Adobe Flash, and Firefox installed, it’s connected to a domain and has local user profiles from domain users on it with customised settings and personal data. It’s also localised to the UK.

The VM is configured as such:

  • 2x vCPUs
  • 4GB of RAM
  • NIC with access the the local network and domain, MDT and WSUS server.
  • Virtual Hard Drive of at least 80GB, on an SSD.
  1. With the VM running Windows normally, log in as a user with access to the MDT Deployment Share.
  2. Navigate to \\SERVERNAME\DeploymentShare$\Scripts and run the LiteTouch.vbs script.
  3. After a short delay you will be presented with the Windows Deployment Wizard and a list with the Task Sequence you created earlier.
  4. Select Upgrade Windows 10 1703 and click Next.

The Task Sequence will now run, upgrade to Windows 10 1703 x64, update from the WSUS server, install Microsoft Office applications (if you added them), run Windows Update from the WSUS server once again, and then shutdown.

When the device is logged into, all user data, settings and programs should be migrated and available as before. The full Windows version should be Windows 10 1703 x64 OS Build 15063.483 – the current version with all Windows Updates as of 27th July 2017.

You may also want to add other application installs to your Task Sequence, such as these common applications, depending on your environment.

Google Chrome – Enterprise Installer

msiexec /I googlechromestandaloneenterprise64.msi /qn

Adobe Reader – Enterprise Installer

AdobeReaderDC.exe /sAll

You now have a functioning Microsoft Deployment Toolkit server, with a Deployment Share configured to upgrade to Windows 10 1703 x64.

If you’d like to get in touch with me, please tweet me @Digressive.

–Mike.

20 thoughts on “Walkthrough: Upgrading to Windows 10 1703 (Creators Update) with Microsoft Deployment Toolkit

  1. Hi Mike
    Thanks for the Great guides and work around’s 🙂
    Do you know if it is possible to make the in-place upgrade from windows 10 1511 to 1703 without the WSUS, only using the OS windows 10 1703 x64 imported in MDT?
    Kind regards
    Martin

    Like

    1. Hi Martin, To answer your question, yes it is totally possible to upgrade from Windows 10 1511 to 1703 using MDT. Some limitations – you can’t upgrade using a custom image, it must be an image imported into MDT from original install media. So you couldn’t create your own image with MDT with updates and programs pre-installed and then perform an in-place upgrade to it. Thanks for the kind words, hope this helps.

      Like

  2. Hi Mike
    Thanks for the quick reply, I did try with a original install media downloaded from MS Volume site – but had had a problem with the OS type I was upgrading from, ended up using the /compat IgnoreWarnings and it started to work 🙂
    Kind Regards
    Martin

    Liked by 1 person

  3. Hey Mike.

    Just wondering if this process works against a customized version of 1607 where I deployed a custom Start Menu, dropped a bunch of built in apps etc in the initial rollout of 1607.

    While I can test it out in a VM – I am hoping that an “upgrade” does not put back all the annoying built in apps etc

    I want to get my machines onto 1709 when available in late Oct – and would like to get some practice with this article.

    Cheers

    Bruce

    Like

    1. Hi Bruce, Apologies for not getting back to you sooner, I’m deep in a few projects right now. When I wrote this post, I tested with 1511, so I’m not sure about 1607 yet. I should think that most applications installed will be preserved – they were with 1511, although I do want to test this myself. The same goes for the customised Start Menu.

      Like

      1. Mike,

        Thanks for the update. I am going to create a new TS using your article as my guide this weekend and upgrade a VM that was initially created using my custom 1607 and see what the result is. Will post back one way or the other.

        Cheers,

        B

        Liked by 1 person

  4. Hi There,

    I’m curious about the custom image statement. Does this mean if I have an existing custom image of windows 10, that I cannot use this method to upgrade that system? My concern here is that I do have a custom image created and I want to be able to update this custom image when the next release of WIN10 comes out.

    Like

    1. Hi, Yes, that’s correct. In MDT, you cannot select a custom image for an upgrade Task Sequence. That is to say, it has to be an image imported to MDT from a full set of course files. The custom image’s I made just weren’t displayed as an option when creating the upgrade Task Sequence. To apply any updates to an image with an upgrade, they would have to be a part of the task sequence.

      Hope this helps!

      -Mike

      Like

  5. Mike,

    I had a chance to play around with this update process today – the method as outlined works great – but puts a bunch of new apps in play (which makes sense since they were not there in 1607). And then oddly it also complained of 45 additional apps it could not install for some reason. (Most likely the apps I removed from 1607). Did some good learning but I need the upgrade to behave as I need it to. Probably going to have to create an upgrade task sequence (with some custom scripting) that strips some crap on the fly when applying 1703 (or 1709)

    Cheers!

    Bruce

    Like

  6. Hey Mike,

    So I’ve acquired a copy of Windows 10 version 17004 to use as the upgrade option from my WIN10 1703 custom image. The upgrade goes through quite nicely, except it seems both Sticky Notes & the DesktopApp Installer apps do not make the upgrade. Both products are installed in my Custom Image (I have only removed the blatant non-enterprise apps from my custom image) and work as far as I know (not sure about the DesktopApp but I can open sticky notes without issue). I have ran through the upgrade process from my custom image twice; same result each time. I’ve been trying to get sticky notes working as that is a visual app used by several users and what I have found is that it seems this app was ignored during the upgrade process. If I run a Get-AppxPackage searching for Sticky notes, it references version 1.8.0.0 but if I try to install that package, it returns the “cannot find AppxManifest.xml”. The tricky part here is that the WindowsApps folder contains several stickynotes folders, but they show version 1.8.2.0. Also in the WindowsApps folder are 2 new folders; Deleted & DeletedAllUserPackages. Deleted is empty, but within DeletedAllUserPackages are more stickynotes folders, however these are versions 1.4. Its like the upgrade erased the existing folders (because I have 1.8.0.0 versions prior to the upgrade) but didn’t actually update the system to look at the new version. Any thoughts as to how I can fix this/get the apps working again? I have tried running the DISM restore health option but no change. Thanks!

    Like

  7. Hey Mike,

    Sorry for the spam! I think I have answered my previous question and so I wanted to give you an update.

    After applying the upgrade, I spent hours trying to get the apps to reinstall using all the appx powershell commands I could find as well as copying the stickynotes folders that were missing from the latest build from my working 1703 copy. Nothing worked, so on a whim I reverted my test box back to 1703. this time, before running the upgrade, I removed ALL packages (using get-appxpackage -allusers | remove-appxpackage). This of course removed everything from the build. I then ran my upgrade task via MDT which again finished successfully. Alas there were no store apps pre-installed however, I managed to get them all back and working (including sticky notes and the desktopapp installer) by running the standard restore command of:

    Get-AppxPackage -allusers | foreach {Add-AppxPackage -register “$($_.InstallLocation)\appxmanifest.xml” -DisableDevelopmentMode}

    All of my apps are back and working with the latest and greatest verison. Going through the event logs, I do see lots of errors initially, but following the logs I see the errors are cancelled out within the next few informational logs. The main errors I saw with this were relating to the VCLibs throwing errors because the above command tries to install all versions, but older versions will not install (so this error can be ignored). There were also some errors in the AppModel-Runtime log but again, these errors were cancelled out a few info logs above the error after the app was successfully re-installed.

    Unfortunately my pinned apps do not return (they were removed when the apps were removed before the upgrade) so I still have to deal with that issue but otherwise I think this test was successful. I don’t have a lot of knowledge on the windows store apps which is why I feel like I’m roaming around in the dark. If you happen to know a better way of doing this and making sure my apps work please let me know!

    Like

    1. Hi Paul, No worries. I’ll certainly write a post about managing the UWP apps if it comes up in the future. In your first post you mentioned Windows 10 17004? I assuming this is a typo and you mean Windows 10 1709, but I got more of less what you are trying to do, I’m afraid I just don’t have any advice at the moment. My focus was just to remove the apps I didn’t need from the core image. 🙂 Thanks for sharing your experiences here.

      -Mike

      Like

      1. Hey Mike,

        I actually managed to get a copy of build 17004 to test with. 1710 (or 1709) won’t be released until this coming Tuesday (Oct. 17th).

        Like

  8. Mike

    Another question on this one. Within the next month or so – I plan to move 3 of our workstations to 1709 (from a solid build of 1607) – so I am going to test a new TS to do that.

    But I am confused a little on how to actually run this “upgrade” (easily) on the workstations.

    In your article – you indicate a need to start the upgrade like this:

    “Navigate to \\SERVERNAME\DeploymentShare$\Scripts and run the LiteTouch.vbs script.”

    eEven tho I will be presiding over the upgrade – these workstations do not (and will not) have access to the MDT deployment share area. I was hoping to just be able to reboot a machine – and PXE boot out to WDS , have the standard LiteTouch x64 ISO boot and then see my standard list of Task Sequences that I can pick from – including an “Upgrade to 1709” choice.

    But when I do this on a VM – I do not see this “upgrade” task sequence? Does MDT not place upgrade task sequences on this list to be available for the PXE boot method or is there some other (better) way that I should setup for this in the future?

    Appreciate your insight.

    Cheers!

    B

    Like

    1. Hi Bruce,
      It seems that upgrading via an MDT Task Sequence can’t be done when booting to MDT. To run an upgrade the LiteTouch.vbs must be run either manually or some other way – and the client must have access to it. I would imagine that it can be triggered via SCCM but I don’t currently have use SCCM so I can’t test it. Unfortunately I don’t know of any other way to upgrade via an MDT TS. Of course the upgrade can be done via Windows Update/WSUS but obviously this lacks the control we get from a TS. Sorry I can’t help more!
      -Mike

      Like

  9. Mike,

    No problem. I will be doing the upgrades – so I can fire up the LiteTouch script manually. Since it’s the first time trying an upgrade scenario – I figured the TS would show up as part of the listing one would get during a clean install via WDS – but I can understand why it’s probably not a good idea to do it that way – since a guy probably should be “inside” the OS on the machine he is about to upgrade.

    Makes sense to me.

    Cheers,

    B

    Liked by 1 person

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