Knowledge Base

A user who is logged on to a Windows Server 2003-based Terminal Server cannot configure a printer as the default printer

Article ID: 933996

Article Last Modified on 10/11/2007

APPLIES TO

Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
Microsoft Windows Server 2003, Enterprise Edition
Microsoft Windows Server 2003, Standard Edition (32-bit x86)
Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
Microsoft Windows Server 2003, Datacenter x64 Edition
Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems
Microsoft Windows Server 2003, Enterprise x64 Edition
Microsoft Windows Server 2003, Standard x64 Edition

Important This article contains information about how to modify the registry. Make sure that you back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows registry

SYMPTOMS

When a user logs on to a Microsoft Windows Server 2003-based Terminal Server, that user cannot configure a printer as the default printer. Also, the user experiences the following symptoms:

If the user right-clicks a printer, and then clicks Set as Default Printer, nothing happens. The user does not receive an error message, and the printer is not set as the default printer.
If the user clicks Yes under Do you want to use this printer as the default printer when the user installs a new printer, the user receives the following error message:

Default printer cannot be set

CAUSE

This problem may occur if the following registry subkey is missing from the affected user's profile:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows

This problem may occur if either of the following conditions is true:

The NTUser.dat file is damaged for the affected user.
The user does not have sufficient permissions to access the NTUser.dat file

RESOLUTION

To resolve this problem, remove the affected user's profile, and then re-create the affected user's profile.

WORKAROUND

To work around this problem, use one of the following methods, as appropriate for your situation.

Method 1: Use a logon script to create the registry subkey

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

Configure a logon script to create the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows

To do this, follow these steps.

Step 1: Create a .reg file to create the Windows registry subkey

Start a text editor such as Notepad, and then type or paste registry information that resembles the following into a new text file:
```
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows]
"Device"=""
```
Save the text file as a .reg file. For example, save the file as WindowsKey.reg.
Copy the WindowsKey.reg file to a shared network location. For example, save the file to the Netlogon share on a domain controller.

Note If you copy the WindowsKey.reg file to the Netlogon share of a domain controller, you must copy this file to the Netlogon share of the domain controller that holds the PDC Emulator operations master role.

Step 2: Create a script to update the Windows registry

Start a text editor such as Notepad, and then type or paste script information that resembles the following into a new text file:
```
@echo off 
regedit /s \\example.com\NETLOGON\WindowsKey.reg
```
Note In this script, the location of the registry file is the Netlogon share of a domain controller. However, you can modify this location, as appropriate for your situation.
Save the file as a .cmd file. For example, save the file as UpdateWindowsKey.cmd.
Copy the UpdateWindowsKey.cmd file to the same shared network location to which you copied the WindowsKey.reg file. For example, copy the UpdateWindowsKey.cmd file to the Netlogon share of a domain controller.

Step 3: Create a Group Policy object to run the script at startup

Log on to a domain controller, and then start the Active Directory Users and Computers tool. To do this, click Start, click Run, type dsa.msc, and then click OK.
Right-click the container in which you want to configure the Group Policy object, and then click Properties. For example, right-click an organizational unit container.
Click the Group Policy tab, and then click New.
Type a descriptive name for the policy, and then press ENTER.
Click Properties, and then click the Security tab.
To prevent this policy from being applied to certain users or to certain groups, add the particular user or the particular group, and then click to clear the following check boxes in the Allow column:
- Read
- Apply Group Policy
After you modify the permissions, click OK.
Click Edit to start the Group Policy Object Editor tool.
Expand Computer Configuration, expand Windows Settings, and then click Scripts (Startup/Shutdown).
In the details pane, double-click Startup.
Click Add, and then type the UNC path of the .cmd file in the Script Name box. For example, type \\ domainControllerName \NETLOGON\UpdateWindowsKey.cmd.
Click OK two times, and then exit the Group Policy Object Editor tool.
Click Close to exit the ObjectName Properties dialog box.

When a user applies Group Policy, the .cmd file updates the user's profile to create the Windows registry subkey. Therefore, you must make sure that the policy is only applied to the users for whom you want to modify the profile.

Method 2: Add the Domain Users group to the Default User folder on the Terminal Server

Add the Domain Users group to the Default User folder on the Terminal Server, and then grant this group the following permissions:

Read & Execute
Read

To do this, follow these steps:

On the Terminal Server, start Windows Explorer, and then locate the Default User folder.
Right-click Default User, and then click Properties.
Click the Security tab.
Add the Domain Users group to the Group or user names list.
Click the Domain Users group, and then click to select both of the following check boxes in the Allow column:
- Read & Execute
- Read
Click OK.
Log off the affected user from the Terminal Server, and then have the user log on to the Terminal Server.

Note If the steps in the "Method 2: Add the Domain Users group to the Default User folder on the Terminal Server" section do not work, you may have to delete the affected user's profile. Then, the user must log on to the Terminal Server again to create a new profile. You may also be able to work around this problem by following these steps:

Rename the NTUser.dat file, or remove the NTUser.dat file from the Default User folder on the Terminal Server.
Copy the NTUser.dat file from the Default User folder on a Terminal Server with which you do not experience this problem to the Terminal Server with which you experience this problem. Make sure that you use a default NTUser.dat file from a Terminal Server on which the users have the same roles and on which the users use the same operating system.

MORE INFORMATION

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

843259 A limited user can no longer print to a shared printer from a terminal server session after you restart the Spooler service in Windows 2000

833746 You cannot print from a Terminal Server session that is hosted by Windows Server 2003

831754 You receive an error message when you try to print to a shared network printer in a terminal server session

319939 Description of the Point and Print Restrictions policy setting in Windows Server 2003 and Windows XP

Additional query words: Terminal Services, TS

Keywords: kberrmsg kbtshoot kbprb KB933996

Microsoft KB Archive/933996

Contents