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
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
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.
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.
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
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://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.