none
A connection to the deployment share could not be made - reference account is currently locked out RRS feed

  • Question

  • Hello, I've been struggling with this one on and off for about 6 months now.  The message "a connection to the deployment share could not be made" occurs after the user account (that's supplied during the task sequence) gets locked out.  I haven't the slightest idea why this keeps happening, and it seems to happen intermittently and on all hardware types (desktops/laptops).  The user account is a domain admin account and I've granted explicit NTFS/Share permissions to the deployment share.  For whatever reason, the account keeps getting locked out during deployment.

    Here's a copy of the bdd.log:

    https://drive.google.com/file/d/0B5G9Zwc89uMCSDk2OHprcjQ3bm8/view?usp=sharing

    I'd really appreciate if someone could offer some insight as to why this happens.  We use a vanilla task sequence and cherry pick applications that reside on a file share.  We've generally had good success using this method as maintaining thick images is too much work/maintenance.

    In this case, the target machine is a Dell Latitude E6530 and I am deploying Windows 8.1.  This message seems to always occur after the OS has deployed/windows updates have finished and some other part of the task sequence is trying to take place.

    Any help is appreciated.  Thanks!

    Wednesday, October 21, 2015 10:27 PM

All replies

  • Locked out is likely a domain policy based on the number of retries.  That being said you also might not want to have your Antivirus program installed so early.

    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:28 PM
    Moderator
  • Hi TY, thanks for the reply.  I forgot to mention that we do OS provisioning/app provisioning in a workgroup (no domain join) to avoid any possible problems during deployment.  Also, these lockouts always occur during some part of application deployment.

    What impact will AV have on account lockout status?  We do install Symantec Endpoint Protection before most other applications.  Our lockout policy is set to 5 attempts (before lockout).

    Wednesday, October 21, 2015 10:39 PM
  • My first instinct is to push the AV to later because I hate having difficult to troubleshoot random issues.  That might not be the issue but, it would be what I consider a 'best practice'.

    Getting your account locked out could be as simple as entering in a wrong password (MDT does quite a few retries).  You could still have a connection to the share because you started in a full OS.

    Personally you might see if you can get an exception for your deployment guys that sets the lockout policy to something higher (25 is probably a good number and if you have an adequate password policy then is just as secure as 5).


    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 11:15 PM
    Moderator
  • I will try pushing AV out to the very end of the task sequence, but I'm skeptical about this being the problem.

    We have a separate domain account for MDT, and I can increase the retry count to 25 before lockout.  I don't see how that will make a difference because the logs on the MDT server show a high number of retries.  Can you explain why increasing this number will help?

    I can tell you that when we got this message, it came up after finishing a successful VS2012 installation.  I have this installing as a bundle - it installs update 4 from a file share immediately after.

    Another oddity, after hitting "retry" it continued installing the remaining programs; during the final round of windows updates it threw an audit failure on the MDT server windows security logs for this user account.  It didn't lockout the account, just had the one audit failure "unknown user name or bad password."  Glancing at the machine during windows updates, it also had a message in the taskbar saying that it couldn't connect to the network drive.  I looked in windows explorer and saw two drives mapped to the deployment share:  X and Y.  Any idea why there would be two mapped drives there?  Or why it's saying it can't connect to the network drive even though it clearly did?

    Thursday, October 22, 2015 2:23 PM
  • Are all of the shares consistent permissions?

    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.

    Thursday, October 22, 2015 8:47 PM
    Moderator
  • Besides the possibility of an AV throwing a wrench in things, you'll get better performance if you don't install the AV early because it'll slow down the deployment, scanning a bunch of safe installations and files being copied onto the computer.

    Are you using specific accounts to run commands?

    I ask because MDT uses the Administrator account and sets autologon with that account during the whole deployment process.


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

    Thursday, October 22, 2015 9:00 PM
  • To answer Ty's question first, the share permissions (and NTFS) are consistent.  I just double checked this a moment ago.  I have a separate deployment share setup for creating/capturing reference VMs.  We don't have any linked deployment shares.

    Dan, your reason for AV at the end of the TS makes good sense.  I'll definitely move that back to the end of the TS. 

    To answer your question, we do not use specific accounts to run steps, commands or scripts.  I try and make our workflow as fluid and painless as possible :)

    One other theory that I have...the applications that we install via the wizard have working directories that are pointing to a DFS share rather than the servername\sharename. I wouldn't think this to cause an account lockout but I guess stranger things have happened.  On a side note, we are not using DFS for the deployment share. And just to reiterate, the lockouts don't occur until after the OS has deployed and it reaches the application install part of the TS.  

    Anyone ever had issues using DFS shares for application installs in MDT?


    Friday, October 23, 2015 2:02 PM
  • I don't think DFS would be an issue, I say that because my production deployment share sits on two servers and I use DFS-R to replicate from the main server to the secondary. I will say I've never tried having imported apps sitting on a different server, but it seems to be working for you because they are installing. This is an odd one


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

    Friday, October 23, 2015 2:42 PM
  • DFS shouldn't matter at the time you are doing the app installs.  This is strange.  You might want to do a premier support case.

    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.

    Friday, October 23, 2015 6:31 PM
    Moderator
  • Thanks for the feedback guys.  I'd pursue premier support if they didn't charge an arm and a leg.  Also, I can't reproduce the issue on a test VM which makes troubleshooting that much more difficult.  This isn't a show stopper for us, it's just an annoyance.

    FWIW, after digging through the BDD.log I realized that the second drive (Y:) is getting mapped to the dfs share so that it can change directory and install the specified application. In this case, the logs tell us that it was able to access Y: and install VS2012 successfully, at which point the domain account became locked out.   And both the DC + MDT server reveal that the lockout is occurring on the target machine.

    Anyone else have some words of advice?

    Friday, October 23, 2015 9:24 PM
  • At this point I don't know of any bugs with MDT where it would use different credentials than what were provided.

    You may end up looking at the event 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.

    Tuesday, October 27, 2015 12:54 AM
    Moderator
  • Hey guys, I have an update on this.  After running into this problem on more than one occasion, I think we've narrowed it down to the problem occurring during postOS task sequences only.  We don't seem to have lockout problems when doing a full deployment task sequence with the same domain account, even when selecting applications to install.  Looking at the domain controller where the lockout occurs, we are seeing the following in the security event logs:

    Kerberos pre-authentication failed.

    event ID 4771

    failure code:  0x18

    Can anyone tell me if a post-OS task sequence actually does domain credential validation (check for valid pw) in the wizard?

    Friday, May 20, 2016 3:19 PM
  • How are you initiating the PostOS task sequence? Do you manually connect to the deployment share and then run litetouch.vbs? If so, what user is logged on and how are you connecting to the share?
    Monday, May 23, 2016 10:41 PM
  • No it doesn't do any verification.  So if you enter the wrong password and you have a silly number of fails lockout policy then this is what you will see.

    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.

    Monday, May 23, 2016 10:44 PM
    Moderator
  • Fwiw, I believe the lockouts were occurring because the local MDT scripts were starting to execute BEFORE the machine obtained an IP and connection to the deployment share.  I've found that this problem is much more prevalent on virtual machines (where NICs are slower to catch up during boot), so that would seem to confirm this theory.

    Anyway, I added a delay to one of the MDT scripts like this:

    https://4sysops.com/archives/resolving-a-connection-to-the-deployment-share-could-not-be-madeerrors-in-mdt/

    Been about a year now w/o any problems.

    Thursday, June 1, 2017 6:44 PM