With the release of Windows 10 1703 (Creators Update) ISO on the Volume Licensing Service Center, I’ve recently been looking into using the “final” code with Microsoft Deployment Toolkit (MDT) to build reference images and discover what issues are present. This post is a round up of differences and issues I’ve found with building and deploying Windows 10 1703 thus far, and some resolutions.
For a full walk through on installing MDT and creating a Windows 10 1703 (Creators Update) reference image, check out this post.
My lab setup is the same as with my previous Windows 10 1607 guide, although I’ve reinstalled my main PC (which I use an admin PC) with a fresh copy of Windows 10 1703. The MDT, WDS and WSUS servers are Windows Server 2016, as before. For more detailed information on how to setup a lab like this, please see my previous post.
To start building images with Windows 10 1703, you will need the following:
- Upgrade/Install the new Windows 10 1703 ADK. PLEASE NOTE that if you have SecureBoot enabled, it will fail to install. This is a known issue and there is a workaround.
- Upgrade/Install MDT Build 8443 – there has been no update for Windows 10 1703.
- After upgrading/installing, update the deployment shares and regenerate the boot images by Right Clicking the deployment share > Update Deployment Share > Completely regenerate the boot images.
- Download the Windows 10 1703 ISO from the VLSC site, mount it in Windows Explorer and Import it as an Operating System in MDT.
Here’s the differences I’ve found with Windows 10 1703:
There’s No RSAT for Windows 10 1703
Previously there were Remote Server Administration Tools (RSAT) for each big update to Windows 10. This is no longer the case! I encountered no issues installing the RSAT tools for Windows 10 1607 on my 1703 PC. If you’ve upgrade from 1607 to 1703, you may have to reinstall or re-enable them which you can do by pressing Win Key + X > Apps and Features > Programs and Features (under Related settings, see image) > Turn Windows features on or off.
Auto Logon No Longer Works With MDT and Windows 10 1703
Update 29/06/2017: KB4022716 and the following Cumulative Updates for Windows 1703 fixes (KB4025342 onwards on this page) this issue. You can add the update to MDT Packages and have it installed with the deployment. I have tested this and can confirm it fixes the issue. Thanks to Michael Niehaus (@mniehaus) for tweeting about this.
Update 03/05/2017: After a Twitter conversation with Michael Niehaus (@mniehaus) this has been confirmed to be a bug, although it only effects the second logon.
I first noticed this during testing the Insider builds with MDT and thought it might be fixed for the final version, but unfortunately it doesn’t appear to be. My workaround is to never set an Administrator password in the Task Sequence. This is not necessarily a problem for building the image, but for the deploying Task Sequence it can be worked around by setting the administrator’s account password near the end of the Task Sequence, either as a Command Line action:
net user administrator P@ssw0rd
Or with a short PowerShell script:
$Password = convertto-securestring "f0r3g@t3" -asplaintext -force $user = "Administrator" Set-LocalUser $user -Password $Password
Removing UWP Apps From Windows 10 1703
As I wrote about recently here, you can, if you so choose, remove the built-in UWP apps from Windows 10 1703 during the MDT Task Sequence with a PowerShell script. If you’ve been doing this with Windows 10 1607, you will need to check which apps to keep and remove with Windows 10 1703 as there are some new ones included.
WSUS Updates Getting “stuck”
I wrote about how to resolve this issue with Windows 10 1607/Windows Server 2016 here. This issue is not present in Windows 10 1703, so you do not need to add the Cumulative Update to the Packages folder in MDT for 1703, but remember that Windows Server 2016 still requires it. Please Note: I did have an issue with WSUS updates hanging on one of my builds. I used a Hyper-V Virtual Machine and mistakenly only assigned 1 vCPU. When increasing the vCPUs to 2, the issue was resolved.
Windows 10 Opens The Default Browser To MSN.com On Every Login
I wrote about this issue and how to resolve it here. This issue still occurs with Windows 10 1703. The OS is trying to determine what internet connectivity is available. The registry change in my post still works to prevent the browser opening on logon, or you can whitelist http://www.msftconnecttest.com/redirect in your firewall/proxy devices and this allows Windows to determine that it has open internet access and the browser does not open at login. The site above this site redirects to your regional msn.com.
I hope this post has helped you in some way, if you’d like to get in touch with me please leave a comment or tweet me.
Follow Mike on Twitter: @Digressive