none
Windows 10 x64 build 1703 issues.

    Question

  • Hi folks,

    I'm refreshing a WDS build of Windows 10 x64 build 1703 and running into some behavioural issues I'm unable to suitably resolve. Hopefully you can shed some light on these:

    1. Windows setup phase: It's talking to me and I don't want it to (i.e. how can this be disabled?). Building 20 machines over multicast and having them all drone at me like something derived from Attack of the Clones isn't what anyone in the team needs to endure.
    2. Windows setup phase: At the same stage as point 1, how can the "check for updates" be avoided? This is purely a time waster and I expect has no point to it on a corporate network where anonymous Internet access doesn't exist. That said, if it's actually doing multiple things behind the banner of checking for updates, then there's no real issue.
    3. Post setup: In-box apps are not provisioning. This is causing the start menu icons to show as their URI placeholders. I'm able to work around this with a poor man's "RunOnce" registry hack in the Default User profile to run the appropriate Add-AppxPackage commands to "manually" re-add the apps, however, I'd like to know what's changed and how to resolve this properly? This doesn't appear to be in alignment with the intent described as being new in 1703 where removed apps will no longer be automatically provisioned, as they weren't removed prior to the sysprep.

    Some points to note:

    1. The image was originally based on build 1607 and updated to 1703 via WSUS.
    2. I'm using the answer file built with build 1607 of WSIM. I don't expect this is an issue though, to be honest.
    3. The CopyProfile process is being used in the generalize phase - primarily to ensure the Start Menu looks the way we want it.
    4. Though already mentioned, I'll re-state it here: the relevant Windows apps are installed provisioned within the administrator account - as evidenced by Get-AppxPackage.

    Cheers,
    Lain

    Thursday, April 27, 2017 6:00 AM

Answers

  • Having downloaded the 1703 ISO from the Volume Licensing Service Center last night and applied the same customisation steps as from the failed endeavour based on the updated 1607 image above, everything worked as expected and apps are once again provisioning for new logons under 1703 as they were in 1607.

    It seems we can't go one feature update without some kind of breakdown in something that was previously working. Thankfully, the Windows Update agent is stable this time around (at least as far as I can tell at this early stage).

    I can only speak from my own experience here, but the progression from 1511 to 1607 and now 1703 has had me thinking more than once that too much of what enterprise values is being forsaken for this half-baked attempt at "consumerising" the Windows platform and development cycle. Either that, or the move to Agile/DevOps/whatever flavour of quick-sprint methodology being adopted in the background isn't proving to be all that successful as I can't recall such a successive stint of problematic service packs (as they were)/updates (as they now are) in my time, which is since NT4 SP2.

    1703 cements - for us, the fiasco that is having to re-create the reference image from scratch using the VL ISO for the latest build, which is just plain nuts. It's already at the point where trust in the feature updates - in the context of applying them to an existing base image, is so low that it's not worth investigating if they improve in the future.

    Cheers,
    Lain

    Tuesday, May 2, 2017 3:42 AM

All replies

  • Hi Lain Robertson,

    "The image was originally based on build 1607 and updated to 1703 via WSUS."
    Do you mean the reference image is an upgraded image?
    As far as I know, an upgrade image couldn't be syspreped. So it should be not available to prepare an image from an upgraded image. How did you do that, clone it?

    For the update issue, we could try the command line "setup.exe /dudisable".
    https://technet.microsoft.com/en-us/library/cc766446(v=ws.10).aspx

    For the "in-box" apps issue, have you removed those apps from the image before?
    " I'll re-state it here: the relevant Windows apps are installed provisioned within the administrator account - as evidenced by Get-AppxPackage"
    Have you logon with the administrator account?
    For Windows 10  1703, those apps won't be installed automatically if they have been removed before.

    Best regards

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, April 28, 2017 9:19 AM
    Moderator
  • Hi,

    You might need to check your sysprep comments again, as all the sysprep files are located in the usual location of %windir%\system32\sysprep. Furthermore, sysprep has no issues running at all.

    The original image was based on the volume licensed Windows 10 x64 build 1607 ISO. This was in turn updated with "Feature update to Windows 10 Enterprise, version 1703, en-us" (KB3012973) from WSUS.

    As I said already, the apps had not been removed from the reference image. As I also said, I'm aware that if you have removed them before they won't re-install, which is why I went out of my way to mention I had not removed them.

    Thanks for the setup reference, however, I'm not sure how this helps my in a WDS deployment scenario. What I need is a unattend.txt equivalent. Perhaps I need to bite the bullet and download the Windows 10 ADK (again) specific to 1703 and see if anything's been added to control this behaviour.

    As far as image preparation goes, the usual WDS approach was taken - as alluded to above:

    1. Build the original machine from the install.wim from the Windows 10 Enterprise build 1607 ISO.
    2. Enable the local administrator account and remove the setup-created profile and account.
    3. Apply the WSUS updates, which include the above-mentioned feature update to 1703.
    4. Use disk cleanup to remove the old version of Windows.
    5. Use the administrator account to customise the profile and operating system.
    6. Use sysprep /generalize followed by the WDS capture boot process to upload the image to WDS.

    At this stage, I'm putting the apps not provisioning down to something not working as intended with the 1607 to 1703 update and will work through the process again when 1703 is released to the Volume Licensing Service Center - which will be tomorrow our time.

    Cheers,
    Lain

    Sunday, April 30, 2017 10:19 PM
  • Having downloaded the 1703 ISO from the Volume Licensing Service Center last night and applied the same customisation steps as from the failed endeavour based on the updated 1607 image above, everything worked as expected and apps are once again provisioning for new logons under 1703 as they were in 1607.

    It seems we can't go one feature update without some kind of breakdown in something that was previously working. Thankfully, the Windows Update agent is stable this time around (at least as far as I can tell at this early stage).

    I can only speak from my own experience here, but the progression from 1511 to 1607 and now 1703 has had me thinking more than once that too much of what enterprise values is being forsaken for this half-baked attempt at "consumerising" the Windows platform and development cycle. Either that, or the move to Agile/DevOps/whatever flavour of quick-sprint methodology being adopted in the background isn't proving to be all that successful as I can't recall such a successive stint of problematic service packs (as they were)/updates (as they now are) in my time, which is since NT4 SP2.

    1703 cements - for us, the fiasco that is having to re-create the reference image from scratch using the VL ISO for the latest build, which is just plain nuts. It's already at the point where trust in the feature updates - in the context of applying them to an existing base image, is so low that it's not worth investigating if they improve in the future.

    Cheers,
    Lain

    Tuesday, May 2, 2017 3:42 AM