Not able to set default printer in windows 2003 server

If you've chosen to use Kixtart as the language for your logon scripts, you can use its own native capabilities to connect to network printers. For example, the following Kixtart code checks to see whether the user is in the "PrinterGroup-Name" Windows group. Many Terminal Server administrators use code like this, adding this code segment for each printer in the environment. This can allow them to create an all-encompassing logon script that maps the proper printers based on users' group memberships.

Another option for ensuring that users can easily access their printers is to use roaming profiles. By doing so, your users will only have to connect to a printer once. After that, the printer connection will become part of their profile and will automatically be restored whenever they logon.

See Chapter 6 for full information about using roaming profiles. The last method of assigning printers is not exactly a "best practice," but it can work well in smaller LAN environments that don't have too many printers. To use this method, you install the printer "locally" onto a Terminal Server.

This does not mean that the printer must be physically attached to the Terminal Server. It just means that you add the printer to the Terminal Server as a local printer instead of a network printer. To do this:. Following this procedure creates a shared print queue on the Terminal Server. Even though this queue is for a remote printer, the server treats it as a locally installed printer. By default, all users that run sessions on a Terminal Server are able to print to local printers on a server, meaning that all users will "automatically" have access to this printer.

You can modify the permissions of one of these newly-installed local printers so that only certain users or groups can print to it. What's cool about this is that users won't see a printer that they don't have rights to print to, so you don't have to worry about any additional configuration. The major downside to this method is that since the print queue is local to the Terminal Server, the server's printing subsystem will spool the file locally and send it across the network in its raw data format instead of as an EMF file.

In some cases, such as when some types of JetDirect cards are used, this is always the case anyway. Instead of assigning printers to your users, you may have an environment in which users need to be able to choose their own printers.

This makes your job much easier. If security is important, you can still set the printing permissions on the printers that you don't want everyone to be able to print to. If you simply give a user permissions to print to a network printer, that printer will not be automatically set up for the user. However, the user will be able to browse the network and connect to the printer if he needs to print to it. If your users are able to configure their own printers via Windows Explorer or the "Printers" folder in the Start Menu when using a desktop session this may be fine.

However, in the real world, many people choose not to allow users to connect to the Windows desktop or Windows Explorer and instead only use single application connections, and thus users are not able connect to network printers since they have no interface to do so. With that problem in mind, many administrators will give the users a connection to the server that launches the Printers folder.

I have also gone into the Group Policy editor and checked that the [print] components do not specifically stop the user from using the printer. I am reluctant to just delete the user profile and recreate for 2 reasons. It is seems to be an inelegant solution because it circumvents the problem instead of solving it and 2. I need to understand the underlying mechanism that seem to have failed that brought this problem about.

I have reviewed many of the discussions related to this topic on the internet. Most seem to point to the policy-type of problem. There have been several references to a possibly corrupt registry key. One solution suggested that I log into the working profile and copy out the [device] section of the registry and then import it into the malfunctioning profile.

When I tried this, I found that the specific key was missing from the working profile and so could not export it. I'm not sure. Has anyone found a solution to this yet? Share Flag. All Answers. Collapse -. Did you find a solution? Cheers, Andreas 0 Votes. Possible spooler or driver issue. What I did is - remove the computer from the domain - delete the computer account in AD - wait for AD replication to occur - add the computer to the domain Why this helped I do not know, but now I'm happy : Andreas 0 Votes.

Didn't know it was solved already. I just let it set itself up as default but then i get a error saying 'cannot set default printer' The printer install dialogue box will not disappear as normal then and i have to choose cancel for it to go away. Its not stopping any printing but at the moment i cannot set a default printer. Similar Threads setting a default printer for all users By wellwillthisnamedothen in forum How do you do Cunning 'default printer' script By ajbritton in forum Scripts.

Windows Server R2 - No printer ports!! By pmassingham in forum Windows. Setting a permanent default printer. By ninjabeaver in forum Windows. The time now is AM.