When you’ve done a fresh MDT 2010/2012 installation you will notice that by default only you can authenticate past the login screen in the Deployment Wizard. That’s because when the deployment share (DeploymentShare$) is initially created when installing MDT only the user who’s installing it is given security permissions to access the share.
In a working environment with an Active Directory domain, however, you will typically want to allow a group of your IT support staff (IT Technicians, maybe?) to carry out deployment duties and refresh Windows computers as and when required.
This can be accomplished by making the relevant IT support staff user accounts members of an Active Directory group (which we’ll call DeploymentAdmins) and giving the group read and write security permissions to the deployment share. That way any user who is a member of the DeploymentAdmins group can successfully authenticate themselves in the Deployment Wizard log in screen.
Here are some instructions:
Create a security group object in Active Directory (I called my group “DeploymentAdmins”)
Make all the relevant IT users members of the DeploymentAdmins group
Give the DeploymentAdmins group access to the DeploymentShare$ share with full read and write security permissions
It’s as easy as that.
Bear in mind if you’re doing this AFTER installing a MDT database you will need to give the DeploymentAdmins group access to the MDT database as well. There’s an excellent post over at WindowsNetworking.net with instructions on how to give a Windows domain user access to the MDT database using the SQL Server Management Studio. When following the instructions simply replace the user account in the post with the name of your security group object.
I was already working with the MDT database when I started thinking about how deployment would/should work in a domain environment. After having given the DeploymentAdmins group access to the deployment share I found none of my database settings where being applied when deployment was initiated by a member of the DeploymentAdmins group. It was then I had to use the SQL Server Management Studio to solve this as explained above.