none
Upgrade Task Sequence not working on Windows ADK 10 v1709 and MDT 8443 RRS feed

  • Question

  • I built a 1709 reference image and can deploy it without issue. Yay!

    But then...

    I built an upgrade task sequence. After hitting 100% on the Working on updates screen, the TS wizard comes up with errors. After having to hit cancel a few times the upgrade finishes but the TS doesn't complete gracefully. 

    Anyone else seen errors when creating a new upgrade task sequence? I've tabled it for now until MDT is updated.

    Here are the errors I see:

    A VBScript Runtime Error has occurred: 
    
    Error: 500 = Variable is undefined
    
    VBScript Code:
    -------------------
     IsThereAtLeastOneApplicationPresent 

    A VBScript Runtime Error has occurred: 
    
    Error: 500 = Variable is undefined
    
    VBScript Code:
    -------------------
    InitializeTSList


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Friday, October 27, 2017 7:10 PM

Answers

All replies

  • Hi,

    I faced the same issue today and I solved it with the following actions:

    In the Deployment share, Go to task sequence properties and then disable the step "Install Applications" and select continue on error. ( the error happened because the step was enabled and no applications are specified in the CustomSettings file.

    For the other error you need to specify the following variables in the CustomSettings file:

    Skiptasksequence=Yes

    TaskSequenceID="Your TS ID"

    Regards,

    Khodr.

    Sunday, October 29, 2017 9:36 AM
  • While Khodr's answer will avoid the prompts, I'm not confident in the result of the upgrade process...

    First, if you check c:\windows\temp\DeploymentLogs\Results.xml, you'll see some errors in there beginning with "SetNamedSecurityInfo() failed". They look like false positives, but the fact that they are there is concerning.

    I dug pretty thoroughly into what's going on. Post 1709 upgrade, the system is in a funny state that does not occur after a 1607->1703 upgrade. The biggest clue that something is pretty wrong is these two lines in the log file:

    LOG[Property PHASE is now = ]
    [This is Upgrade, setting Phase =  (empty)VALIDATION]

    That second line is printing out the value of the Phase environment variable immediately after it is set. It is set to the empty string "", and yet its value right after is "VALIDATION". When you can't reliably set an environment variable, things are bad. This leads to the vbscript errors you are seeing, and I'd wager has something to do with the Results.xml errors. Until Microsoft addresses the issue, I'd recommend avoiding a 1709 upgrade.


    Thursday, November 2, 2017 8:44 PM
  • Which is exactly what I'm doing. Interestingly when I tried to deploy 1703 (not upgrade) under the new 1709 ADK I had issues with MDT trying to start another instance during deployment. Once I went back to 1703 it worked just fine. I'm not under any pressure to start rolling out 1709 so I'll wait until a new MDT comes out.

    What seemed to trigger it for me was when Acrobat Pro DC started to install. I even moved the install further down the chain and sure enough when it started to install it seemed to kick up a second instance of MDT. Makes me think it was causing at logon commands to rerun. 

    Anyhow I'll wait for the new MDT before resuming testing.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Thursday, November 2, 2017 8:58 PM
  • Interesting. I had moved to the 1709 ADK just thinking that might resolve the issue with errors in Results.xml (I had first tried all of this with the 1703 ADK). What was your clue/indication that a second instance of MDT was starting? Sounds like I should probably revert back to the 1703 ADK as well.
    Thursday, November 2, 2017 9:42 PM
  • For me it would give the dirty environment found message

    "An existing in-progress deployment was found but is not in an expected state.  Would you like to ignore this in-progress deployment and start a new one?"

    But it did that while is was actually in the middle of the sequence, in my case it was installing Acrobat Pro DC when that message would suddenly come up.

    Exact same TS with 1703 ADK runs just fine. My original post at the top is what I was getting if I ran a simple upgrade task sequence. Either way I'm going to wait until the MDT update.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Friday, November 3, 2017 1:38 PM
  • Wow, that is really interesting. I built a couple images with 1709 ADK yesterday (some parts are hard to automate) - that's enough to get me to rebuild them with 1703...

    I'd like to try to reproduce just so we can get a bug filed and make sure it gets fixed or is fixed in the next MDT. Do you use any special command line switches on the install (obviously omitting any personalized license/activation info)?

    Friday, November 3, 2017 1:51 PM
  • No it's as simple as can be. "Setup.exe" I use the Acrobat Customization wizard to build the package to install as needed and only setup needs to be run, it then quietly installs. It's all been working perfectly until the 1709 ADK. Like I said going back to 1703 and all my imaging is back to running smoothly. 

    If I had time I'd setup another deployment server and do further testing, but I don't have the time.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Friday, November 3, 2017 1:59 PM
  • I see now that there is not an easy way to get the installer without paid subscription. It's probably worth filing a bug with the details at https://connect.microsoft.com/ConfigurationManagervnext/Feedback . If you know of an easy legit way to get the installer I'm happy to help reproduce it as I've got a non-production setup, so swapping back and forth between ADKs is relatively painless on my end.
    Friday, November 3, 2017 2:03 PM
  • I am so glad I am not the only one! This has been driving me crazy for several days now. Like the OP - I get a series of oddball dialogs with about 30 seconds to go in the TS. Same VB errors and the same clickfest trying to cancel out of the series of dialogs. I get this repeatedly

    VBScript Runtime Error has occurred: Error: 500 = Variable is undefined VBScript Code: ------------------- InitializeTSList

    And this

     VBScript Runtime Error has occurred: 
    
    Error: 500 = Variable is undefined
    
    VBScript Code:
    -------------------
    ValidateTSList

    What is bizarre is why the bloody TS list decides to pop on screen when the install has not yet completed?

    Seems this version of MDT is NOT ready for primetime with respect to upgrades. My 1709 TS for a full install works perfectly. I am going to stand down on anything to do with 1709 until I am confident that MDT actually works with 1709 - which is clearly not the case right now.

    Cheers,

    B

    Saturday, November 4, 2017 2:53 PM
  • I see now that there is not an easy way to get the installer without paid subscription. It's probably worth filing a bug with the details at https://connect.microsoft.com/ConfigurationManagervnext/Feedback . If you know of an easy legit way to get the installer I'm happy to help reproduce it as I've got a non-production setup, so swapping back and forth between ADKs is relatively painless on my end.

    Since I'm dealing with Acrobat/Creative Cloud in this particular issue, you can get the installers here - https://www.adobe.com/downloads.html

    But the issue with an upgrade not working correctly also remains and I don't have any software install in that TS it was just the standard upgrade task sequence. Looks like Bruce here is seeing exactly what I'm seeing as well.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Monday, November 6, 2017 2:38 PM
  • Since I'm dealing with Acrobat/Creative Cloud in this particular issue, you can get the installers here - https://www.adobe.com/downloads.html

    But the issue with an upgrade not working correctly also remains and I don't have any software install in that TS it was just the standard upgrade task sequence. Looks like Bruce here is seeing exactly what I'm seeing as well.

    Unfortunately the installers there are just web downloaders with no MSI embedded. I was able to google a bit though and find the full installers on an adobe page.

    However, I wasn't able to reproduce the issue. I updated the installer to run silently with Adobe's customization wizard. Both with 1703 and 1709 ADKs it installed fine, although it took 15+ minutes for both, which is quite bizarre considering it installed quickly via running setup.exe manually (not in a task sequence). Changing the installed app to something else (notepad++ for example) installed in the expected time.

    Also, the 1709 upgrade issue is definitely unrelated to the adobe thing, and easy to reproduce. Just a vanilla upgrade to 1709 from 1607 or 1703 will yield it. 

    Monday, November 6, 2017 7:30 PM
  • Thanks guys,

    I'm happy that I'm not the only one with this problem.

    Let the waiting for a solution begin.

    Thursday, November 9, 2017 9:40 AM
  • There are a lot of questions here, and I'm having a hard time keeping all the issues intact here. 

    Take for example the first problem here; IsThereAtLeastOneApplicationPresent.

    This is a function within the DeployWiz_Applicaitons.vbs script, yet for whatever reason the VBSCript interpreter is treating like an undefined Variable? it's not a variable, it's a function. Is it possible that the DeployWiz_Applications.vbs script didn't get copied down correctly? Or some other corruption on the server?

    Sorry I haven't had a chance to play around with a In-Place upgrade TS. IF you have a repro scenario, let me know.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Sunday, November 12, 2017 3:11 AM
    Moderator
  • The repro scenario is exactly as Dan described in his first post. A standard in-place upgrade from 1607 or 1703 to 1709 causes the dialogs Dan reported. Khodr mentioned that you can make them go away by adding ini entries to automatically select the task sequence and suppress the prompt for it. However, the fact that the prompt shows up is really just a symptom of a bad environment right after the OS upgrade step is done when we are bootstrapping back into the MDT environment. Another symptom is errors in results.xml when the sequence is done.

    I wouldn't worry too much about the specific errors showing up in the popup. The MDT environment, post upgrade, is in a bad state.

    Probably unrelated to this, Dan mentioned seeing some issues in a regular non-upgrade task sequence when trying the 1709 ADK. The symptoms are somewhat similar but the cause could be entirely different. I tried reproducing it but did not have any luck in my limited time working on it.

    I've filed a bug for the inplace upgrade issue and let the MDT manager at Microsoft (AaronCzechowski) know about it via twitter. The bug report contains some detailed analysis on how the MDT environment is broken. I'd encourage everyone to vote on it to get it more visibility:

    https://connect.microsoft.com/ConfigurationManagervnext/Feedback/Details/3143333

    Sunday, November 12, 2017 7:18 AM
  • Thanks Nick! I voted on it.

    Keith, sorry to muddy the water with that other issue I was seeing, but the first post pertains to this thread's subject and others appear to be having the same issue in regards to the upgrade task sequence breaking after upgrading to ADK 1709. I reverted back to 1703 and every works perfectly just like it did before the ADK upgrade.

    I "upgraded" the ADK like I have all other times. Uninstall previous version, reboot, install, reboot and update the deployment share forcing a rebuild of a new boot image.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Monday, November 13, 2017 2:41 PM
  • Thanks Nick! I voted on it.

    Keith, sorry to muddy the water with that other issue I was seeing, but the first post pertains to this thread's subject and others appear to be having the same issue in regards to the upgrade task sequence breaking after upgrading to ADK 1709. I reverted back to 1703 and every works perfectly just like it did before the ADK upgrade.

    I "upgraded" the ADK like I have all other times. Uninstall previous version, reboot, install, reboot and update the deployment share forcing a rebuild of a new boot image.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Dan,

    Are you saying you reverted back to ADK 1703 or Windows 10 1703? I am a bit confused.

    I have not yet even thought about rolling the ADK back. Will Windows 10 1709 even work with ADK 1703?

    If it does I would like to try a rollback from ADK 1709 to ADK 1703 and then test an upgrade from Windows 10 1607 to Windows 10 1709

    Cheers!

    Bruce


    Tuesday, November 14, 2017 3:21 AM
  • I tried to perform an In-Place Upgrade in my test environment, however I was *UNABLE* to repro the crash in the UI. You mention the ADK, but the ADK isn't a requirement for in-place upgrade, unless you are starting the task sequence from within WinPE!?!?! Not really clear to me.

    If you have a bdd.log file from a test run, can you publish online and/or email it to me at kg at KeithGa dot com?

    thanks!


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, November 14, 2017 3:34 AM
    Moderator
  • I tried to perform an In-Place Upgrade in my test environment, however I was *UNABLE* to repro the crash in the UI. You mention the ADK, but the ADK isn't a requirement for in-place upgrade, unless you are starting the task sequence from within WinPE!?!?! Not really clear to me.

    If you have a bdd.log file from a test run, can you publish online and/or email it to me at kg at KeithGa dot com?

    thanks!


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Keith

    Were you upgrading from Win 10 1607 to Windows 10 1709? What version of the ADK were you using - and most importantly - how are you starting your in place upgrade?

    Over here - I am manually firing up the LiteTouch.vbs file from within my MDT build share and then letting the TS fire up and start it's cycle.

    Appreciate some details on what you are running and how you are running it.

    Cheers,

    Bruce


    Tuesday, November 14, 2017 3:41 AM
  • If it does I would like to try a rollback from ADK 1709 to ADK 1703 and then test an upgrade from Windows 10 1607 to Windows 10 1709
    Regardless of which ADK you have installed (1703 or 1709) or which OS you start with (1607 or 1703), upgrading to 1709 breaks in the same way. I've tried all the permutations with the same results. If you're interested, you can dig into the connect issue I linked - the root of the problem is that when the 1709 upgrade completes, it is in a state that messes with the attempt to bootstrap back into the MDT. So I'm pretty certain the issue will happen even with older ADKs/starting points (e.g., 1511) whenever you do an inplace upgrade to 1709.
    Tuesday, November 14, 2017 3:55 AM
  • Actually, if you perform an in-place upgrade from within the old OS, WinPE and the ADK will NOT be executed, so I don't see HOW the ADK version is the problem (which is surprising to me since the ADK is ALWAYS the problem :)) .  Again, a good repro scenario and the bdd.log file would be super helpful.

     


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, November 14, 2017 4:04 AM
    Moderator
  • I tried to perform an In-Place Upgrade in my test environment, however I was *UNABLE* to repro the crash in the UI. You mention the ADK, but the ADK isn't a requirement for in-place upgrade, unless you are starting the task sequence from within WinPE!?!?! Not really clear to me.

    If you have a bdd.log file from a test run, can you publish online and/or email it to me at kg at KeithGa dot com?

    thanks!


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    The ADK only got first mentioned when Dan brought up the other, non-upgrade issue. It doesn't affect the results for the inplace upgrade. The in-place upgrade (for me) is being started by running LiteTouch.vbs from the deployment share via an administrator command prompt, right after mapping the share.

    I don't have logs I can grab and sanitize easily, but the ini entries should be enough to reproduce. My best guess for why you are not seeing the errors Dan described is that you may have SkipTaskSequence=YES specified? That will suppress the task sequence dialog but you'll still see errors in your Results.xml. Here's my CustomSettings.ini entries for a standard inplace upgrade to 1709. Bootstrap.ini is the standard for whatever share/credentials you setup for the share.

    CustomSettings.ini:

    [Settings]

    Priority=Default

    [Default]
    _SMSTSORGNAME=Contoso
    UserDataLocation=NONE
    OSInstall=Y
    AdminPassword=P@ssw0rd
    TimeZoneName=Pacific Standard Time 
    JoinWorkgroup=WORKGROUP
    HideShell=YES
    FinishAction=SHUTDOWN
    SkipCapture=YES
    SkipAdminPassword=YES
    SkipProductKey=YES
    SkipComputerBackup=YES
    SkipComputerName=YES
    SkipTimeZone=YES
    SkipApplications=YES
    SkipBitLocker=YES
    SkipDomainMembership=YES
    SkipUserData=YES
    SkipLocaleSelection=YES
    SkipRoles=YES
    DoNotCreateExtraPartition=YES
    ApplyGPOPack=NO
    SkipSummary=YES
    SkipFinalSummary=YES

    Tuesday, November 14, 2017 4:05 AM
  • Ah, I see the ADK 1709 is in the title of this post. Ideally that would be edited as, like we've discussed, the ADK version is irrelevant to the inplace upgrade issue.
    Tuesday, November 14, 2017 4:08 AM
  • My best guess for why you are not seeing the errors Dan described is that you may have SkipTaskSequence=YES specified? 

    I did NOT have the SkipTaskSquence set in my CS.ini, I did select a task sequence in the wizard. It did not complete (my test lab needs to be refreshed). I hope to spend some time in the next few days to setup a clean test.

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, November 14, 2017 4:11 AM
    Moderator
  • My best guess for why you are not seeing the errors Dan described is that you may have SkipTaskSequence=YES specified? 

    I did NOT have the SkipTaskSquence set in my CS.ini, I did select a task sequence in the wizard. It did not complete (my test lab needs to be refreshed). I hope to spend some time in the next few days to setup a clean test.

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Just curious, when you say it didn't complete, what did it do? Did it get past the point where the OS upgrade is done (the blue "working on updates" type screen eventually gets to 100%, then the PC restarts and boostraps back into MDT)? It is after the upgrade is complete, when bootstrapping back into MDT, that the error dialogs will pop up.
    Tuesday, November 14, 2017 4:15 AM
  • I'm about to go on vacation for a bit (be back after thanksgiving), so I won't be able to do more testing right now.

    When I did attempt the upgrade, I tried upgrading from 1703 to 1709 and it would (as Nick also described) launch the MDT wizard after the OS upgrade was applied.

    Ignore the Acrobat Pro stuff as that had nothing to do with the ClientUpgrade task sequence. I of course did NOT start an upgrade in WinPE, the wizard was initially launched within the working OS. It shouldn't make a difference but FYI all our systems are BitLocker encrypted.

    Nick seems to be reproducing the same issue I'm seeing so hopefully he can test some more.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, November 14, 2017 2:55 PM
  • Just FYI. my setup for reproduction is pretty straightforward and should be easy for others to reproduce too. I quickly made one deployment share with a standard client task sequence that installs windows 1607 or 1703, and then used it to image a VM in Hyper-V. Then I made another deployment share with a standard client upgrade task sequence that upgrades to 1709, and invoked LiteTouch.vbs from the imaged VM. (The invocation is from an admin command prompt after mapping the upgrade deployment share in the command prompt.)

    I don't yet *need* to have functional 1709 upgrades, so for now I'm just waiting for acknowledgment and a fix from Microsoft. The funny state MDT finds itself in exploits a hole in MDT's variable storage system, and there's a chance fixing that hole would fix all of this. (See the connect bug for more info on this.) I may pursue that if too much time passes while we wait.

    Tuesday, November 14, 2017 4:25 PM
  • Wow, this turns out to be the BIGGEST MDT regression bug for Windows 10 1709, Great Catch!!

    Solution: Add the following line to your setupcomplete.cmd script:

    :: Workaround for incorrectly-registered TS environment
    reg delete HKCR\Microsoft.SMS.TSEnvironment /f

    Details: https://keithga.wordpress.com/2017/11/15/windows-1709-in-place-upgrade-bug/

    Summary: Should be fixed in the next version of MDT too!


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com




    Wednesday, November 15, 2017 7:40 PM
    Moderator
  • Hey Keith,

    The link you provided just takes me to a wordpress login page. Is the entry maybe not published yet? I don't see it if I go to your main wordpress page either.

    Do we know why the TS environment is registered when 1709 upgrade completes? Perhaps that's in the details of your blog entry.

    Wednesday, November 15, 2017 8:05 PM
  • Keith

    I would also like to read about the solution.

    Cheers,

    Bruce


    Wednesday, November 15, 2017 8:15 PM
  • fixed URL

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Wednesday, November 15, 2017 8:26 PM
    Moderator
  • That link points to an unrelated blog post from 11 days ago...
    Wednesday, November 15, 2017 8:37 PM
  • Updated again (I'm having Wordpress problems today). :(

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Wednesday, November 15, 2017 8:46 PM
    Moderator
  • This analysis is pretty similar to what I filed as a bug two weeks ago and linked here Sunday; it's unfortunate that somehow got lost in the discussion here and that the analysis effort had to be duplicated. 

    I'm glad you were able to get the attention of someone at Microsoft to recommend a workaround.

    Wednesday, November 15, 2017 9:54 PM
  • Just so I am clear. Even when this bug kicks in - is the OS properly updated? Can I trust that the install is sound and one can consider the now upgraded target to be usable?

    B

    Wednesday, November 15, 2017 10:28 PM
  • The OS upgrade has completed, however if you have any *additional* steps in your task sequence, like installation of apps, or other settings, they might not get executed.

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Wednesday, November 15, 2017 10:34 PM
    Moderator
  • The OS is upgraded but I personally wouldn't put that out into production unless I had a TS that could completed successfully. Not to mention you can't automate it because it's going to throw out that error. At that point you may as well manually upgrade Windows or better yet use Windows Update/WSUS to push out the update.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Wednesday, November 15, 2017 10:36 PM
  • The OS is upgraded but I personally wouldn't put that out into production unless I had a TS that could completed successfully. Not to mention you can't automate it because it's going to throw out that error. At that point you may as well manually upgrade Windows or better yet use Windows Update/WSUS to push out the update.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Cannot upgrade via Windows Update or WSUS since Win 10 1709 will not honor the standard settings, removed apps etc that forms my preferred configuration of Win 10 1607.

    So I have to modify the wim etc within the 1709 image and the only way to upgrade properly is via MDT to be able to use the image.

    If I could trust WU/WSUS to install the upgrade and leave my base installation alone - I would be all over it.

    B

    Thursday, November 16, 2017 1:31 AM
  • Completely unrelated but it makes following these discussions difficult - is anybody else seeing all of technet with no real indication of which post is by which user? I can tell for those of you with signatures, but the usual top-left image/author area is always a generic icon with no name now...
    Thursday, November 16, 2017 2:08 AM
  • Completely unrelated but it makes following these discussions difficult - is anybody else seeing all of technet with no real indication of which post is by which user? I can tell for those of you with signatures, but the usual top-left image/author area is always a generic icon with no name now...
    Confirmed, been going on all day.

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Thursday, November 16, 2017 2:25 AM
    Moderator
  • Bruce,

    If I remember correctly, that's not an issue with 1709. What your talking about didn't start until 1703. If your base install was at least 1703, then future upgrades would honor all that you mentioned. Someone else here might be able to confirm, I still haven't had coffee yet.


    Daniel Vega

    Thursday, November 16, 2017 1:57 PM
  • Bruce,

    If I remember correctly, that's not an issue with 1709. What your talking about didn't start until 1703. If your base install was at least 1703, then future upgrades would honor all that you mentioned. Someone else here might be able to confirm, I still haven't had coffee yet.


    Daniel Vega

    Dan,

    I have read  that about 1703 but unfortunately - I am starting at 1607.

    I have at least three 1607 VMs that have been installed and customized using a specific set of TS scripts etc. These three have been "worn in" over the last 10 months via use in the lab environment - they have been patched normally and had a few apps installed to them like Chrome, Adobe Reader etc.

    When 1709 came along - I thought I would try the "in place upgrade" scenario and if I ran that using a stock ISO from MSDN etc - 1709 would add a whole pile of additional new crap to these installs, reset some settings and so on.

    So I had no choice but to break out my NT Lite toolkit and carve the iso into shape so it would only install what I need it to install.

    Running an in place upgrade now using this heavily customized wim/iso finally gets me back where I need to be. But if I allowed WU or WSUS to install the "stock" 1709 - I would have to spend hours touching up to 10 workstations to get them back to the tight, secure (and private) installs that I need to be in place.

    I am in no rush to deploy 1709 but if/when I do - I still need Windows 10 to behave and be as locked down as it is right now with our 1607 installs.

    It is also important to note that while 1703->1709 supposedly "honors" prior changes - 1709 will still install a host of other garbage that has no business being on an Enterprise machine (like Virtual Reality etc etc).

    It is sad that Microsoft simply does not "get" the business world and how "business" wants to run Window 10. For Win 10 Enterprise upgrades - I should never have to go through endless customization and MDT scripting etc to get a nice clean "business" ready install.

    It should just happen.

    B



    Thursday, November 16, 2017 3:18 PM
  • For anyone else just now finding this as I did, MDT 8450 is now available with this fix.

    https://blogs.technet.microsoft.com/msdeployment/2017/12/21/mdt-8450-now-available/

    -Matt


    There's no place like 127.0.0.1

    • Proposed as answer by Matt5150 Wednesday, January 24, 2018 11:49 PM
    • Marked as answer by Dan_Vega Thursday, January 25, 2018 2:21 PM
    Wednesday, January 24, 2018 11:49 PM
  • For anyone else just now finding this as I did, MDT 8450 is now available with this fix.

    https://blogs.technet.microsoft.com/msdeployment/2017/12/21/mdt-8450-now-available/

    -Matt


    There's no place like 127.0.0.1

    Yes, MDT 8450 (6.3.8450.1000) is indeed working just fine for me. So far everything is working fine. Until the next OS update...hopefully nothing will break.

    Daniel Vega

    Thursday, January 25, 2018 2:10 PM
  • Just a fair warning: while the upgrade goes off without a hitch, you're in for trouble if you then try to capture the upgraded image. It is broken when upgrading to 1709 due to appx packages not being fully removed. It is not an MDT problem but a Windows upgrade problem.

    See this link for details on the issue. Upvote the issue by following this link and allowing it to open in the feedback hub.

    Thursday, January 25, 2018 4:05 PM
  • Yes, MDT 8450 (6.3.8450.1000) is indeed working just fine for me. So far everything is working fine. Until the next OS update...hopefully nothing will break.


    Daniel Vega

    Well my 1709 installs and upgrades are still getting the Error 13 = Type Missmatch.  I must need to clean house.  I simply installed 8450 over the top of my current MDT install then fully regenerated the boot images.  Must have a script in there that didn't get updated, or something is in the existing TS's it doesn't like.

    There's no place like 127.0.0.1

    Thursday, January 25, 2018 4:56 PM
  • I simply installed 8450 over the top of my current MDT install then fully regenerated the boot images.  Must have a script in there that didn't get updated, or something is in the existing TS's it doesn't like.


    There's no place like 127.0.0.1

    I did the same - installed right over top of 8443. All my TS work perfectly now. And I also have a boatload of custom stuff.

    I have not attempted to capture the upgraded image - but that is not something I would do anyway.

    B

    Thursday, January 25, 2018 5:07 PM
  • I simply installed 8450 over the top of my current MDT install then fully regenerated the boot images.  Must have a script in there that didn't get updated, or something is in the existing TS's it doesn't like.


    There's no place like 127.0.0.1

    I did the same - installed right over top of 8443. All my TS work perfectly now. And I also have a boatload of custom stuff.

    I have not attempted to capture the upgraded image - but that is not something I would do anyway.

    B

    I was thinking the same thing.   That must be one heck of a complicated image to want to upgrade and recapture it, instead of starting from scratch.

    It turns out I have some mixed results.  2 of the machines I started last night upgraded with no problem.  2 show error 13, and the one VLS install from TS shows Error 13.  Going to have to test some more.

    -Matt


    There's no place like 127.0.0.1

    Thursday, January 25, 2018 5:16 PM
  • I was thinking the same thing.   That must be one heck of a complicated image to want to upgrade and recapture it, instead of starting from scratch.

    It's not that it is a complicated image, but rather images for which creation involves some manual steps that are difficult if not impossible to automate. So being able to upgrade and capture is a big deal, especially with a new windows release every 6 months.

    Microsoft recognizes the need and officially started supporting it in windows 10 1607. Unfortunately they've broken it in 1709.



    Thursday, January 25, 2018 5:24 PM
  • "creation involves some manual steps that are difficult if not impossible to automate. "


    Challenge accepted. :)

    There's no place like 127.0.0.1

    Thursday, January 25, 2018 5:34 PM
  • "creation involves some manual steps that are difficult if not impossible to automate. "


    Challenge accepted. :)

    There's no place like 127.0.0.1

    Ha, thanks for the offer. ;-)

    My point is that there are always going to be scenarios for which 100% automation is out of reach, whether due to technical or time constraints. When a new version of windows released every 2-5 years, having a small amount of manual intervention in your image creation process, while not ideal, was workable. Now, with a release every 6 months, it is significantly less so.

    I imagine Microsoft realizes this, and that's why they started supporting sysprep on upgrades, at least in theory...

    Thursday, January 25, 2018 5:47 PM
  • I ran into this issue as well and it was driving me insane. After running Get-AppxPackage|Remove-AppxPackage i was successful in capturing 1709 image. 
    Tuesday, February 13, 2018 5:57 PM
  • Yes, MDT 8450 (6.3.8450.1000) is indeed working just fine for me. So far everything is working fine. Until the next OS update...hopefully nothing will break.


    Daniel Vega

    Well my 1709 installs and upgrades are still getting the Error 13 = Type Missmatch.  I must need to clean house.  I simply installed 8450 over the top of my current MDT install then fully regenerated the boot images.  Must have a script in there that didn't get updated, or something is in the existing TS's it doesn't like.

    There's no place like 127.0.0.1

    Still getting this.  Created a new thread:
    https://social.technet.microsoft.com/Forums/en-US/491510d2-fbf9-424d-898e-4a3f43ac6021/error-13-type-mismatch?forum=mdt

    -Matt


    There's no place like 127.0.0.1

    Thursday, February 15, 2018 7:19 PM