none
MDT 2012 Update 1 - Error "The account is not authorized to log-in from this station"

    Question

  • Quick history:  I've used MDT 2010 update 1 for almost a year now.  I use the LiteTouch.vbs script to upload the image to the deployment share.  In 2010 during my process the computer was still joined to the domain when I started the process.  There were no errors in the process using MDT 2010 update 1

    Problem: One of the things I've found different about 2012 update 1, is that I have to unjoin the device from the domain prior to starting the Litetouch.vbs.  If I do not do this, the script fails and I get an error message that the device is joined to a domain and the script cannot continue.  So I drop the device from the domain and run the Litetouch.vbs script and the process completes.  I do not know if this is a change in the process from 2010 update 1 to 2012 update 1, or if my process is flawed to begin with?  Any suggestions would be helpful here.

    When the script completes, I get the final message that the process has completed.  It lists any errors that may have occurred, and it always says that there were no errors.  So I close the process and try to access network shared folders and other network resources no problems.  The device has rebooted and is joined to the domain.  Then I reboot the device.  After reboot and logging in as a domain admin, I am not able to access shared folders and devices on the network.  The error message that I always get is:

    "\\NetworkShareFolder is not accessible.  You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.  The account is not authorized to log in from this station."

    I have tried to remove the device from the domain and the account from the AD, and then re-add the same device to the domain.  I get the same result.  I have thought that it may be a problem with Group Policy, however I would be seeing this GP issue with all the devices on the network.  It is only occurring with devices that have finished the imaging process through MDT 2012 Update 1.  And all 5 devices I have tested offer the same results.  I used SMS Trace to look at the log files from the deployment and it shows no errors.  However I know that there is a problem with the deployment process otherwise the problem with network rights for the device.  I don't know if its a device SID issue, but my understanding is that the Litetouch.vbs runs a sysprep stripping the SID from the device before capturing an image.  Feel free to correct me here if I am missing something.  Thanks for assisting me with these questions. 

    --EXMO14


    • Edited by Exmo14 Tuesday, November 20, 2012 5:52 PM Spelling, Grammer, Clarification
    Tuesday, November 20, 2012 5:51 PM

Answers

  • This is resolved by adding this to CustomSettings.ini

    ApplyGPOPack=NO


    The issue is that you're likely using CIFS shares, which don't support SMB Signing.  I have no idea why MS would enable that 'feature' in the default GPO pack.

    Tuesday, January 22, 2013 8:58 PM

All replies

  • One of the things I've found different about 2012 update 1, is that I have to unjoin the device from the domain prior to starting the Litetouch.vbs. 

    You should really, really, really try to not capture images that were joined to the domain unless you're reusing it on the same machine later.

    Create a reference image, capture using lighttouch.vbs, and do domain join on deployment task sequence.

    Saturday, January 19, 2013 6:41 AM
  • I ran into the same issue you did and resolved it by changing a registry key. We also created a GPO that also catches any system that my deployment team may have missed. Open regedit, naviagate to HKLM\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters Under value name(RequireSecuritySignature) change 1 to 0. I believe that changing from MDT 2012 to 2012 Update 1 made this registry change. I can't say for sure but we no longer have this issue since the GPO is in place.

    Tuesday, January 22, 2013 6:11 PM
  • This is resolved by adding this to CustomSettings.ini

    ApplyGPOPack=NO


    The issue is that you're likely using CIFS shares, which don't support SMB Signing.  I have no idea why MS would enable that 'feature' in the default GPO pack.

    Tuesday, January 22, 2013 8:58 PM
  • I ran into the same issue you did and resolved it by changing a registry key. We also created a GPO that also catches any system that my deployment team may have missed. Open regedit, naviagate to HKLM\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters Under value name(RequireSecuritySignature) change 1 to 0. I believe that changing from MDT 2012 to 2012 Update 1 made this registry change. I can't say for sure but we no longer have this issue since the GPO is in place.

    That specific problem is fixed with ApplyGPOPack=NO like Zac H mentioned.

    It causes havoc with IBM and Oracle software, as well as windows in general.

    Wednesday, January 23, 2013 3:51 AM
  • This saved me hours for frustration. Worked like a charm. Thank you!!
    • Proposed as answer by Allen Frank Tuesday, September 10, 2013 6:05 PM
    Tuesday, September 10, 2013 6:04 PM
  • ApplyGPOPack=NO also worked for me! What a legend. I was losing my mind with this
    Friday, September 20, 2013 4:15 AM
  • thank you!!!
    Wednesday, December 11, 2013 5:21 PM