none
Inplace upgrade to Windows 10 and HideShell=YES again RRS feed

  • Question

  • Lately I've been trying to set up Windows 10 inplace upgrade using a MDT LTI, but I can not get it to work. I have two problems.

    The first problem is if I use HideShell=YES in my customsettings.ini.

    In this case the upgrade succeeds and I can login to Windows 10, but only first time. No, I do not get a BSOD SYSTEM_LICENSE_VIOLATION on all subsequent boots, but the windows just rebooted every time without any error. In event log I see only eventid 1074 "The process winlogon.exe has initiated the restart..." with reason code 0x8002003 (operating system update).

    Ok, let's take a look at the HKLM\System\Setup. Hmm, the key SetupType exist, but has a value 0x2. The key CmdLine also exist and has a value C:\MININT\Scripts\setupcomplete.cmd. Now it is clear why windows rebooted every time. It just comply order from registry. But why these keys remains in the registry although CmdLine had to remove and SetupType change to 0x0? SetupComplete.cmd had to register himself in HKLM\System\Setup, call SetUpgradeStatus.wsf with SUCCESS parameter, call LiteTouch.wsf and call SetUpgradeStatus.wsf again with COMPLETED parameter. And this second call SetUpgaradeStatus.wsf had to clean HKLM\System\Setup hive. Why this did not happen?

    It is time to look at the BDD.log. This is a fragment of BDD.log begins at the start SetupComplete.cmd without a service information date, time etc to fit in the forum page:

    SetUpgradeStatus.wsf OSUpgrade:SUCCESS call

    <![LOG[Microsoft Deployment Toolkit version: 6.3.8298.1000]LOG]!>
    <![LOG[------  Register return code for Upgrade ------]LOG]!>
    <![LOG[Register Upgrade status as =  SUCCESS]LOG]!>
    <![LOG[SetUpgradeStatus processing completed successfully.]LOG]!>

    Immediately after LiteTouch.wsf call

    <![LOG[Property start is now = ]LOG]!>
    <![LOG[Microsoft Deployment Toolkit version: 6.3.8298.1000]LOG]!>
    <![LOG[ZTIUtility!GetAllFixedDrives (False)]LOG]!>
    <![LOG[New ZTIDisk : \\TESTW10\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0"]LOG]!>
    <![LOG[New ZTIDiskPartition : \\TESTW10\root\cimv2:Win32_DiskPartition.DeviceID="Disk #0, Partition #1"    \\TESTW10\root\cimv2:Win32_LogicalDisk.DeviceID="C:"]LOG]!>
    <![LOG[New ZTIDisk : \\TESTW10\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0"]LOG]!>
    <![LOG[ZTIUtility!GetAllFixedDrives =   C:]LOG]!>
    <![LOG[Found existing task sequence state information in C:\_SMSTaskSequence, will continue]LOG]!>
    <![LOG[Property LTIDirtyOS is now = FALSE]LOG]!>
    <![LOG[Creating RunOnce registry key to run LiteTouch.wsf for the next reboot.]LOG]!>
    <![LOG[Not running within WinPE.]LOG]!>
    <![LOG[DeploymentMethod = UNC]LOG]!>
    

    And so on with subsequent calls ZTIGather, ZTITatoo, etc. from LiteTouch.wsf. Up to final call LTICleanup.wsf. But what makes LTICleanup.wsf? Yes, it moves log files and deletes C:\MININT folder where all the scripts. So setupcomplete.cmd can not call SetUpgradeStatus.wsf again. At this time it does not exist.

    Ok, let's go ahead. Why LiteTouch.wsf runs this way? I think the problem is line 248:

    SetStartMDT
    If oFSO.FileExists(oEnv("SystemRoot") & "\Explorer.exe") and UCase(oEnvironment.Item("HideShell")) <> "YES" then
        Main = Success
        Exit Function
    End If
    

    If HideShell<>YES LiteTouch.wsf register himself in autorun and exits immediatly. It makes the rest of work at first administrator login. Otherwise condition is wrong, exit does not happen and all following code run. I tried to remove the HideShell condition and now SetupComplete.cmd run as expected. But I'm not sure that it will not affect on other scenarios.

    And now I've got the second problem (if you still remember how it all began). Now the first administrator autologon not working. I get "wrong username or password" on logon screen as the "Administrator" account is disabled. I can login as user from previous OS but LiteTouch.wsf can't clean up due to UAC. And it does not depend on patched LiteTouch.wsf or not.

    In BDD.log I see

    <![LOG[FindFile: The file x86\Microsoft.BDD.Utility.dll could not be found in any standard locations.]LOG]!>

    from ZTIGather called from UpgradeSummary.wsf and UpgradeSummary.wsf failed. But later, when I logged in as user, ZTIGather copies Microsoft.BDD.Utility from DeployRoot to users %temp% folder and register it. I do not understand why ZTIGather can't copy this file in the first case and can in the second one.

    Well. I made the perfect research, wrote the giant post and I am very cool, but I'm worried about one simple question. Many people here  use LTI for inplace upgrade to Windows 10 and all working fine for them. Why it does not work for me? Maybe I was wrong at the beginning?

    Friday, September 18, 2015 11:43 AM

Answers

  • I found what was the problem. The HideShell=YES was not to blame, but SkipWizard=YES was.

    In this case LiteTouch.wsf does not call wizard.hta and no one sets "DeploymentType" environment variable to "upgrade" and "IsOSUpgrade" to "1". As a result LTIApply.wsf runs in upgrade mode and LiteTouch.wsf - in refresh mode.

    I added "DeploymentType=UPGRADE" in my CustomSettings.ini and patched the LiteTouch.wsf to workaround.
    The fix is to add this lines beginning with the line 645:

    If UCase(oEnvironment.Item("DeploymentType")) = "UPGRADE" then
        SetPropertyDefault "IsOSUpgrade", "1", "We are performing upgrade"
    End If

    Wednesday, October 7, 2015 8:48 AM

All replies

  • Make all of this into a connect bug.  Include the logs and your details.


    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Friday, September 18, 2015 7:53 PM
    Moderator
  • So are you saying that you are upgrading a machine with the .\Administrator account disabled?

    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Friday, September 18, 2015 8:13 PM
    Moderator
  • Very strange. Just now I'm found that this thread has two reply. If I logged in to forum I can see only first reply from Ty Glander, but if not - two.

    This post is response to invisible for me now from Ty Glander:

    "So are you saying that you are upgrading a machine with the .\Administrator account disabled?"

    Of course, the builtin Administrator account is disabled like any Windows 7 and above. But LTI temporary enables it during upgrade.

    Monday, September 21, 2015 12:50 PM
  • Does MDT enable the Admin account during upgrade? Is the Unattend.xml file used during an Upgrade task sequence?
    Tuesday, September 22, 2015 10:43 PM
  • Probably yes. Because for some reason Windows 10 attempts to auto login as Administrator first time.
    Wednesday, September 23, 2015 8:32 AM
  • Windows 10 setup.exe does some stuff behind the scenes.  However MDT very explicitly does not set autologon for upgrades to 10.

    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Wednesday, September 23, 2015 5:38 PM
    Moderator
  • I found what was the problem. The HideShell=YES was not to blame, but SkipWizard=YES was.

    In this case LiteTouch.wsf does not call wizard.hta and no one sets "DeploymentType" environment variable to "upgrade" and "IsOSUpgrade" to "1". As a result LTIApply.wsf runs in upgrade mode and LiteTouch.wsf - in refresh mode.

    I added "DeploymentType=UPGRADE" in my CustomSettings.ini and patched the LiteTouch.wsf to workaround.
    The fix is to add this lines beginning with the line 645:

    If UCase(oEnvironment.Item("DeploymentType")) = "UPGRADE" then
        SetPropertyDefault "IsOSUpgrade", "1", "We are performing upgrade"
    End If

    Wednesday, October 7, 2015 8:48 AM
  • I found what was the problem. The HideShell=YES was not to blame, but SkipWizard=YES was.

    In this case LiteTouch.wsf does not call wizard.hta and no one sets "DeploymentType" environment variable to "upgrade" and "IsOSUpgrade" to "1". As a result LTIApply.wsf runs in upgrade mode and LiteTouch.wsf - in refresh mode.

    I added "DeploymentType=UPGRADE" in my CustomSettings.ini and patched the LiteTouch.wsf to workaround.
    The fix is to add this lines beginning with the line 645:

    If UCase(oEnvironment.Item("DeploymentType")) = "UPGRADE" then
        SetPropertyDefault "IsOSUpgrade", "1", "We are performing upgrade"
    End If


    Have you filed that as a connect bug? If not please do.

    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Wednesday, October 7, 2015 5:55 PM
    Moderator
  • This is happening to me even without SKIPWIZARD
    Wednesday, October 21, 2015 10:15 PM
  • This is happening to me even without SKIPWIZARD

    Start a new thread and include a link to this one.  Logs will be helpful too.  See my signature if you are unsure what logs.

    Logs are very important. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Also if you have made customizations please mention them when asking for help.

    Wednesday, October 21, 2015 10:33 PM
    Moderator