Back to basics #1 – Locking the computer during deployment

This is the first post in a series that will cover some of the more simple/basic tricks that you can do with MDT, but that are often overlooked.  I’ll be the first to admit that a couple of them I only learnt recently, even though I have been using BDD/MDT for years.

During the deployment of a computer, MDT will auto-logon Windows using the local Administrator account in order to run its task sequence; during this time, the computer is left logged on as administrator with the desktop unlocked for all to see.  Consequently, anyone who happens to walk past the computer during its deployment can use it with full administrative access.

The best way to protect your computer systems from any unwanted access is to simply lock the computer during the Windows phase of the deployment.  To do this, just add a “Run Command Line” action to your task sequence, and place the following command in the command line of this action:

rundll32 user32.dll,LockWorkStation



You can place the action at any point in the task sequence, as long as it is executed from within Windows rather than during any Windows PE stage.  It doesn’t matter if you have any reboot actions in the task sequence because, even though the workstation is locked, it will still reboot; just remember that you’ll need to execute the command again after reboot in order to lock the computer again.  Bear in mind though that you won’t be able to see the summary screen at the end of deployment so you won’t know when it has finished.


This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Comments (13)
  1. DeploymentGuys says:

    It’s very easy to make an executable to do this and not have to use rundll32.  I did this in Visual Basic 6.  Start a new “Standard EXE” project.  Delete the default Form.  Add a Module.  Change the Startup Object in the project properties to Sub Main.

    Paste the following code into the module and compile the EXE:

    Private Declare Function LockWorkstation Lib “user32.dll” Alias “LockWorkStation” () As Long

    Public Sub Main()


    End Sub

    You can then just run the EXE to lock the computer.

    Michael Murgolo

  2. doxley says:


    This also works with VB.Net.  I was just about to post the code 🙂

    Trouble with this is that it requires the install of the framework, depending on the OS being deployed.



  3. DeploymentGuys says:

    The Visual Basic 6 Virtual Machine runtime (msvbm60.dll) is in the operating system on Windows 2000 and higher.  So this particular VB6 program will work without installing any additional software.

    Michael Murgolo

  4. doxley says:


    Thanks for the comment.  I was aware of the article that Raymond wrote on this, but when I was researching the problem I can upon this page by the Scripting Guys:

    The best thing that I should do is to recommend that anyone reading this post should read both the link you posted and the one I have included in this comment.  Then they can make their own mind up as to whether the issue of a potential stack corruption is a priorityfor them, given that in the scenario I discuss, the deployment time is usually relatively short and that the system is always rebooted afterwards.



  5. Anonymous says:

    Thanks for the post on locking down the computer during the install I definitely need to do that. What I also need is a way to automatically logoff the local Administrator account after the task sequence is complete. I have tried adding a reboot but the workstation logs back in as the local Administrator after the reboot done.

  6. Sean Wheeler says:

    Also remember that LockWorkStation is not designed to be called from rundll32. This can cause stack corruption.

    See Raymond’s discussion of this:

    For this scenario that might not cause a problem but we shouldn’t reinforce the use of this technique.

  7. Erik says:

    We use a tool called  do block its an command line tool

    we start it with

    DIM objShell

    set objShell = wscript.createObject("")

    iReturn = objShell.Run("CMD /min /c z:ScriptsZ_doblock.exe block > c:log.txt", 0, FALSE)

    you can use Ctr alt delete to get pack in the computer

    and at the end we unblock with

    DIM objShell

    set objShell = wscript.createObject("")

    iReturn = objShell.Run("CMD /min /c z:ScriptsZ_doblock.exe unblock > c:log.txt", 0, FALSE)

    its free ware  but its not online any where any more.  i’ll try to put it online some where if there is intrest.

  8. Erik says:

    We use a tool called Do block.

    you can get your keyboard and mouse back and you can talk to it command line and no need for installing stuff, its free ware and only 100 kb or so

  9. Lukas says:

    We have written a BlatShield application (which in essence contains a mouse and keyboard hook that triggers a LockWorkstation call.

    Kevin please have a look at the following forum, i had simmilar prolem to yours and the solution provided there solved it.

    However is there a way to lock down winPE (LiteTouch) stage? During the first install stage two cmd shells are launched, where one of them is running winpeinit and the other sits idle. Im guessing the second one can be used for debugging purposes, but in wrong hands it can be used to view things like unattend.xml which contains sensitive information such as passwords.

    I dont think you can lock the workstation (i tried and WinKey + L does not responds). Any ideas?

  10. ryan says:

    Although it’s not a secure way as locking the computer, we stop the Explorer service as the first task to reduce anyone from working on the machine while it’s being built.

  11. Drewfus says:

    > rundll32 user32.dll,LockWorkStation

    Please see Raymond Chen’s comments on this command:

  12. Joe Hiltabidel says:

    You can lock the mouse and keyboard automatically during deployment using batch files, also.  The benefit to using this method, of course, is that you can actually see everything taking place on the machine.  You are locked from using the mouse / keyboard but you can still see everythinhg.  You can also unlock it automatically or manually using the second batch file.  Full information found here:

    I use MDT2010 for deployment and this method works perfectly.

  13. Eoin says:

    Joe's link above is dead – but it sounds like a smart solution.  Anyone happen to know how he did it?

Comments are closed.

Skip to main content