The Deployment Guys

Helping to deploy your world automagically...

Back to basics #1 – Locking the computer during deployment

Back to basics #1 – Locking the computer during deployment

  • Comments 13
  • Likes

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

 

image

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

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

    See Raymond's discussion of this:

    http://blogs.msdn.com/oldnewthing/archive/2004/01/15/58973.aspx

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

  • Sean,

    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:

    http://www.microsoft.com/technet/scriptcenter/resources/qanda/nov04/hey1115.mspx

    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.

    Thanks,

    Daniel

  • 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()

       LockWorkstation

    End Sub

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

    Michael Murgolo

  • Michael,

    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.

    Thanks,

    Daniel

  • 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

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

    we start it with

    DIM objShell

    set objShell = wscript.createObject("wscript.shell")

    iReturn = objShell.Run("CMD /min /c z:\Scripts\Z_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("wscript.shell")

    iReturn = objShell.Run("CMD /min /c z:\Scripts\Z_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.

  • 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

  • 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.

  • 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. http://blogs.technet.com/deploymentguys/archive/2008/01/29/bdd-2007-litetouch-rebooting-at-the-end-of-the-task-sequence.aspx

    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?

  • 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.

  • > rundll32 user32.dll,LockWorkStation

    Please see Raymond Chen's comments on this command:

    http://blogs.msdn.com/oldnewthing/archive/2004/01/15/58973.aspx

    http://weblogs.asp.net/bdesmond/archive/2003/12/11/43016.aspx

  • 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:

    hiltabidel.com/techblog

    I use MDT2010 for deployment and this method works perfectly.

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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment