Adding Network Printers as a Standard User in Windows 7

If your environment consists of users that are local admins on the machine, this is something you should really try to get away from. Running in full administrative mode in a Windows environment is probably one of the most dangerous things that can be done from an security standpoint. One of the luxury’s of User Account Control is that it allows you to elevate privileges when needed. One of the many advantages of deploying Windows 7 is that standard users can do more then what they could do previously with Windows XP. A very common computing task for the everyday worker is installing a Network Printers. I don’t know about you, but, the last thing I want to have to do is call the IT Service Desk to assist me with this effort. Ugh! 🙂

In Windows 7, as a standard user, you’re not able to do this without making a few changes to the supporting infrastructure first. There is a computer policy you can deploy to Win7 clients in your environment.

Step by Step

  1. In the GPMC, right-click the OU on which you want to apply the Windows 7 Printer Policy, and choose “Create a GPO in this domain, and link it here.”
  2. Name the GPO something appropriate, “Windows 7 Printers”
  3. Right-click on the new GPO, and choose Edit from the shortcut menu to open the Group Policy Management Editor.
  4. Drill down to Printers by choosing Computer Configuration_Policies_Administrative Templates: Policy definition. Click Printers and double click on Point and Print Restrictions.
  5. Enable the Policy
  6. Disable the “Users can only point and print to these servers”
  7. Enable the “Users can only point and print to machines in their forest”
  8. Do not show warning or elevation prompt for both “When installing drivers for a new connection” and “When updating drivers for an existing connection.”

Here is a snippet of the Computer Configuration Policy:

Note: If you want to restrict this policy specifically for Windows 7 machines, use the following WMI filter:

Query looks like this: “Select * from WIN32_OperatingSystem where Version=’6.1.7600″ and ProductType=1”

Getting caught by your own permissions!

I have a confession to make. This is pretty embarrassing,and a terrible mistake. Something I’m not too proud to admit even. 🙂  Raise your hand if you have ever tried to replicate content out to a linked deployment share and get continuous failures. It might look something like the following:

The problem is the share is read-only. You might want to confirm that your account has change/full control access to the deploymentshare. This will likely fix this problem, but keep reading…

I’ve even seen errors like “DISM was unable to set the system root (target path) for the Windows PE Image, so the update process cannot continue.” The DISM error is on the computer running MDT, so it doesn’t have anything to do with the remote server. Look for a message that indicates that the image was mounted successfully. Often then “system root” error is caused by antivirus software prventing access to the just-mounted registry files.

If you have confirmed the proper permissions are setup in this scenarios and you’re still having issues, please save yourself some time and reboot the server. This will likely correct the issues described above.

No Task Sequences are available in MDT 2010

You may have run into the issue where you boot into WinPE and get the very common “No Task Sequences are available (TaskSEquences.XML does not exist, is empy or inaccessible.” I ran into this for the very first time after upgrading from MDT 2008 Update 1 to MDT 2010.

You then go and validate that the TaskSequences.XML in the control folder of your deploymentshare has data in it and is not corrupt. I noticed that when I canceled out of the deployment wizard, deleted the MININT directory with the following command: rd C:\MININT /q/s – and restart the litetouch.wsf, I do not get the same error. I can then select my Task Sequences as expected.

A tip to debug this issue is to add the /debugcapture when you start the litetouch.wsf script.You can edit the Windows PE Unattend.XML and add the /debugcapture after the litetouch.wsf in the RunSynchronous section. The value on the right side states to run wscript.exe x:\deploy\scripts\litetouch.wsf, just add /debugcapture to the end of it. After making this change you will need to regenerate your boot image with MDT 2010. Then start the process by booting and view the log file when you are done. This might give you some additional information in the BDD.log

Often the issue involves the DeployRoot value isn’t quite correct. Tim Minter does an excellent job discussing this on his blog:

BitLocker Deployment and Window 7 SKUs

I, like many others, build my reference image with a virtual machine. Building your reference image with a VM is the way to go and will give you fewer problems when you go to re-deploy your newly captured WIM. However, at times it can also be extremely frustrating going through the process of running your build and capture Task Sequence and then having it bomb on you when the client reboots into WinPE to capture the image. The most common cause is with network latency and resource issues. You might then find yourself in the scenario where you manually capture your WIM.

The problem you might run into is when you go to deploy your image. Despite the fact that you have the configuration setup in the CustomSettings.ini appropriately, you notice the BitLocker screen was skipped in the deployment wizard.

If you analyze the BDD.log you might  realize that when you captured the Image manually with ImageX, you did not append flags onto it with the SKU of the image (Enterprise). If you’re capturing the image manually you can do that after the fact like this:

imagex /flags “EDITIONID” /info Install.wim 1 “NEW_IMAGE_NAME” “NEW_IMAGE_DESCRIPTION”

Where “EDITIONID” is the appropriate SKU ID as defined in the original factory image (or listed in the WAIK)

The reason why the screen was skipped was because MDT checks the flags value in the wizard to make sure we are only showing the bitlocker screen if you are running Enterprise or Ultimate since Bitlocker is only available on those SKUS.

“Multiple Connections to a server or shared resource by the same user, using more than one user name, are not allowed” with MDT 2010

After upgrading to MDT 2010 from MDT 2008 Update 1, I noticed a common theme at some of my remote offices. The UserDataLocation variable specifies the location of where data is to be stored during the migration process of the deployment. This variable is processed with the ZTIGather.wsf script tha queries the deployment rules and the MDT DB. Even though the technician might not restore user data – they’re going to get errors like what you see below:

Example: UserDataLocation=\\servername\usmt4\migdata\

So during the deployment wizard it would auto-complete the above location. Then all the tech would have to do is type %computername%.  In this scenario if the tech chooses not to restore user data, he gets the error seen in this screen shot:

I discussed this with one of the Lead MDT Developers in October and have posted the details of the error and the fix below.

The error encountered in the ZTIUserState.log and BDD.log, “Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again..”

A change has been made in MDT 2010 to deal with mappings to lower-level directories, which has caused some issues when the lowest level part of the path doesn’t exist. MDT attempts to map it, but that fails because the folder doesn’t exist, and is not able to create the folder because were not mapped. While this doesn’t cause the deployment to fail, it leaves you with some nasty errors in the logs and you might see this in the Summary Screen:

To fix the problem the ZTIUtility.vbs file needs to be edited in the scripts folder. Open the file and replace the following code in the MapNetworkDriveEX function:

Case Else

‘ Case &h800704C3 ‘ Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.

‘ Case &h8007052E ‘ Logon failure: unknown user name or bad password.

‘ There was a some kind of fatal error.

If ErrDesc <> “” then

MapNetworkDriveEx = ErrDesc


MapNetworkDriveEx = “Unable to map UNC Path ” & sShare & ” :” & “( 0x” & hex(HasError) & ” ) ”

End if

oLogging.CreateEntry MapNetworkDriveEx & “”, iLogType

Exit function

End select

With this code:

Case Else


On Error Resume Next

oNetwork.MapNetworkDrive  chr(sDrive)&”:”, sShare, False

HasError = err.number

ErrDesc = err.Description

On Error Goto 0

If Err.Number <> 0 Then

‘ There was a some kind of fatal error.

If ErrDesc <> “” then

MapNetworkDriveEx = ErrDesc


MapNetworkDriveEx = “Unable to map UNC Path ” & sShare & ” :” & “( 0x” & hex(HasError) & ” ) ”

End if

oLogging.CreateEntry MapNetworkDriveEx & “”, iLogType

Exit function


Exit Function

End If

End select

Johan Arwidmark’s Deployment CD

In Oct. 2008 I had the pleasure of meeting Johan Arwidmark. I highly recommend his training course for even the most seasoned OS deployment guru.

Johan’s “Deployment CD” is freely available and you can download the ISO from

Here is a breakdown of the contents:

MDT 2010 Lite Touch Deployments (just the free tools)
– Installing the server for MDT 2010 Lite Touch
– Creating a Windows 7 reference image using Lite Touch
– Deploying a Windows 7 image using Lite Touch
– Dynamic Settings, creating and using the deployment database

MDT 2010 Zero Touch Deployments (deployment with ConfigMgr 2007 SP2 R2)
– Installing the server for MDT 2010 Zero Touch and ConfigMgr 2007 SP2
– Creating a Windows 7 reference image using ConfigMgr 2007 SP2
– Deploying a Windows 7 image using ConfigMgr 2007 SP2
– Dynamic Settings, creating and using the deployment database

Additional Presentations
– New features in MDT 2010
– Upgrading MDT 2008 to MDT 2010
– Migrating Windows XP to Windows 7