none
MDT Wizard fails to start after PXE booting from WIM RRS feed

  • Question

  • New to MDT, learning as I go, so thanks for any advice.

    Installed Windows 10 ADK, installed MDT 2013 Update 2.

    Created deployment share, imported a previously created custom WIM that I want to deploy, created a std client task sequence for that WIM etc, added a couple of entries to customsettings.ini rules, added user credentials to BootSettings.ini.

    Updated (full) the deployment share to generate boot WIM for WinPE, imported that WIM into WDS.

    PXE booted a client via WDS, selected the imported boot WIM, client starts booting, screen flashes past the processing of the two rule sets, then nothing, just a blank screen with the MDT background BMP.

    Tried running "cscript x:\deploy\scripts\litetouch.wsf /debug:true /debugcapture" in F8 command console - first thing that appears is a prompt saying "An existing in-progress deployment was found etc. Start a new one?", so I click "Yes", then the process starts again, the bootsettings.ini is processed, then the customsettings.ini, and then this time a completely blank Wizard.hta window appears.

    Any pointers?? (If you need logs, please enlighten me as to their location...)

    Tuesday, July 12, 2016 9:34 PM

Answers

  • So I think I've finally cracked it - and it was indeed a (WEIRD) permissions issue.

    Even though I checked the Share and NTFS permissions, that my MDT user was a member of the local admins group, and that local admins group had Full Control in the Share and NTFS, and I checked the access in the "Effective Access" tab, it was only after I gave the 'Everyone' group READ in the Share and in the NTFS does it actually start working (oh, and you can actually switch to the mapped Z: drive).

    • Marked as answer by Tonofun Thursday, July 14, 2016 8:16 AM
    Wednesday, July 13, 2016 12:46 PM
  • Either your PXE boot images are not the new fixed boot images or there is some saved environment on the local machine. You might want to start with a clean disk or delete the minint folder.

    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Thursday, July 14, 2016 1:43 AM
    Moderator

All replies

  • Log info is in the FAQ.

    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Tuesday, July 12, 2016 9:44 PM
    Moderator
  • Found an error in the bdd.log file relating to ZTIGather being unable to find the CustomSettings.ini file (btw, how do you copy the log file off? Trying to access the mapped Z: drive just gives me access denied for some reason), I've checked the permissions of the folder structure of the deployment share and it all looks fine to me - the Administrators group (of which the configured user account specified in UserID etc is a member of) has full control in the Share and in NTFS...

    

    Tuesday, July 12, 2016 9:54 PM
  • Take a look at your share permissions:

    https://keithga.wordpress.com/2015/10/02/mdt-uberbug11-security-vs-usability/


    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Tuesday, July 12, 2016 10:09 PM
    Moderator
  • Yes, thank you, I'd already checked that after finding the error 8000 code from ZTIGather in BDD.log

    The Share and NTFS permissions of the deployment share are all Full Control for the local Admins group on the MDT server.  The 'MDT' user account is a member of the local admins group also.  The 'MDT' user account is specified in the BootStrap.ini file as so:

    [Settings]
    Priority=Default

    [Default]
    DeployRoot=\\MDT-Server\DeployDomainBased$
    UserID=MDT
    UserDomain=WORKGROUP
    UserPassword=Passw0rd1

    Yet, it keeps reporting being unable to find CustomSettings.ini - and yes, the file does exist under the 'Control' folder.

    Tuesday, July 12, 2016 10:39 PM
  • Found an error in the bdd.log file relating to ZTIGather being unable to find the CustomSettings.ini file (btw, how do you copy the log file off? Trying to access the mapped Z: drive just gives me access denied for some reason), I've checked the permissions of the folder structure of the deployment share and it all looks fine to me - the Administrators group (of which the configured user account specified in UserID etc is a member of) has full control in the Share and in NTFS...

    

    Sorry I missed your how to copy the log off question.  Personally I would net use some share. Or copy to USB media inserted in the machine.

    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Tuesday, July 12, 2016 11:23 PM
    Moderator
  • I had forgotten to answer your question about how to copy the logs off above.  Send a link to your logs (even if you can't post clickable URLs yet).

    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Tuesday, July 12, 2016 11:24 PM
    Moderator
  • Thank you :)

    https://1drv.ms/u/s!Ap06gnH-WtYthYhYlvKYEKt2krD-hg

    I should mention that this is being done using a Hyper-V VM as my PXE client.  I've just discovered that when using a 'real' client (Surface 3, in a dock) that it doesn't even get this far, instead saying "A connection to the deployment share could not be made. Connection OK. Possible cause: invalid credentials"

    After seeing my VM progress past that point, successfully connecting to and logging into the deployment share using the exact same Boot image, I'm thinking that error message isn't very helpful...

    Is that a driver thing?  I've imported all the Surface 3 drivers, and the WinPE settings are set to All Drivers and Packages as the selection profile, and All Network and All Mass Storage in the selection profile.

    Wednesday, July 13, 2016 7:41 AM
  • I don't think it can be a driver thing - after the error message appears, I 'F8' to bring up the command console, and then I can 'net use z: \\mdtserver\DeployDomainBased$ /user:MDT Passw0rd1' and I get 'Command completed successfully' (tho I still get 'Access Denied' when I try to switch to the Z: drive - is that normal?)

    So I can connect to the deployment share myself just fine.

    I then kicked off 'Litetouch.wsf manually (no debug) and I can see that for some reason it's trying to connect to \\MDTServer\DeploymentShare$ instead of the actual path of \\MDTServer\DeployDomainBased$.

    How can this be different on the Surface 3 compared to the VM?  They're both booting from the same WDS boot image...

    Wednesday, July 13, 2016 8:04 AM
  • Ok, I appear to be past the issue of the Surface 3's and the 'unable to connect to deployment share' messages now - so I'm just left with the ZTIgather error 8000/unable to find customsettings.ini issue.
    Wednesday, July 13, 2016 9:53 AM
  • Is it normal for the mapped Z: drive to the deployment share to give you an "Access Denied" message if you try to use it?
    Wednesday, July 13, 2016 12:40 PM
  • So I think I've finally cracked it - and it was indeed a (WEIRD) permissions issue.

    Even though I checked the Share and NTFS permissions, that my MDT user was a member of the local admins group, and that local admins group had Full Control in the Share and NTFS, and I checked the access in the "Effective Access" tab, it was only after I gave the 'Everyone' group READ in the Share and in the NTFS does it actually start working (oh, and you can actually switch to the mapped Z: drive).

    • Marked as answer by Tonofun Thursday, July 14, 2016 8:16 AM
    Wednesday, July 13, 2016 12:46 PM
  • Ok - so I had a typo earlier today in my BootStrap.ini file:

    deployroot=\\MDT:Server\DeployFieldBased$ (notice the colon!)

    So it errored out "A connection to the share could not be made etc".  No bother I thought, I'll fix the ini file, completely regenerate the deployment share, then import the new boot image WIM file into WDS, job done.

    Only, I've done that 3 times now, and it's still referencing the server path with they typo in it!!  Have I missed something really basic?


    • Edited by Tonofun Wednesday, July 13, 2016 2:54 PM
    Wednesday, July 13, 2016 2:49 PM
  • Either your PXE boot images are not the new fixed boot images or there is some saved environment on the local machine. You might want to start with a clean disk or delete the minint folder.

    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Thursday, July 14, 2016 1:43 AM
    Moderator
  • Well there we go - a clean disk fixed it!  Thank you again for your advice. :)
    Thursday, July 14, 2016 8:16 AM
  • I had a very similar situation that turned out to be a WTF moment. The problem was just as you described, PXE boot a computer, the .WIM file downloads, the two screens flash downloading the .ini files and then the machine would sit at a blank background, with just a cursor. No welcome screen, no credential box, nothing. After many, many hours of screwing around it was determined that the SSD (system drive) we were using which contained windows 8.1 may be the culprit. We found that a brand new drive - with no OS - would work fine. The resolution for us was to wipe the original SSD with DBAN, then the process worked like a charm - PXE boot, .WIM download, welcome screen, wizard, and task sequence ran with no issues after that. 
    Wednesday, July 27, 2016 12:51 AM