Solved

domain level printing server 2008 r2

Posted on 2011-09-09
1
343 Views
Last Modified: 2012-05-12
we have setup a new server 2008 r2 environment with some terminal servers and are having an issue adding printers to users sessions. The printers have been added to both dc's so they show up at the domain level but when users try to add printers they get a warning message that states the printer name or address has changed.  When they try to add from the dc it works fine.  In the old environment [server 2003] this has worked fine.  All I have done is add the printers to one server and then export the printers to the 2nd dc.  Once that was done they showed up at the domain level but they can not be added.  Am I doing something wrong of will it not work like this?
0
Comment
Question by:hamel01
1 Comment
 
LVL 7

Accepted Solution

by:
BobintheNoc earned 500 total points
ID: 36515227
Printers, when shared under the ROLE of Print Server, can be published into Active Directory, and be applied via GPO in 2008.  Alternatively, if you are trying to connect a SHARE based printer from the TS server directly, you may find that the printer only shows up within the profile of the user account that was used to add the printer, since SHARE level access is dependant upon the user profile and the user's security, not the SERVER's security.

In order to add a printer to the TS server directly, so that it shows up in all users who login to that server, you'd want to create a direct print via TCP/IP port so that the printer acts as a local printer to the server.  This'd bypass your management ability and Queueing ability from a centralized print server.

The confusing/odd part of your problem is the response of the printer changing it's name or address.  When publishing to Active Directory, off the Print Server Role, be sure that you're not creating TWO printers named identically for the sharename.  Since DCs (which you appear to be using as print servers) don't have a local accounts database, they probably are representing their shared printers as belonging to DOMAIN instead of a printerserver name.  Example, if you had a member print server (non-DC) name PSERVER, and shared a printer object as PRINTER1, the resulting share would be \\pserver\printer1 .   Published to AD, this object would connect to the pserver's exclusive share.  When done from a DOMAIN controller, named DC1 on an AD domain called mycompany.local (DNS) and mycompany(netbios), with a share of a printer called PRINTER1, the resulting share path may be getting listed as \\mycompany\printer1   .   If BOTH DCs share the same printer object and publish them BOTH to AD, and they have the same PRINTER1 name, both DCs would be potentially publishing an object with a sharename that's identical, \\mycompany\printer1   instead of \\dc1\printer1  and \\dc2\printer1.

Bottom line, if you are going to share from BOTH DCs/print servers, you need to share them with different names.  Example, instead of PRINTER1, perhaps DC1PRINTER1 and DC2PRINTER1, resulting in two different shared path objects.

All DCs should respond when you reference a domain name as the server name, since ALL DCs w/DNS services will have DNS records named SAME AS PARENT, with the IP address of each DC.  Example:  query your ad dns name with NSLOOKUP:    nslookup mycompany.local  and you SHOULD get a result containing each DC's IP address.  The default behavior of ROUND ROBINing DNS, when you query one time, you'll get a response of DC1's IP address and then DC2's address.   Next time you query, you should get DC2's address first, followed by DC1.

When you are attempting to connect to a share that's representative of a domain, it could be that the initial object reference (which will be unique and specific to one of the two shared objects) doesn't match the succeeding attempt to validate the object--starts with the object from DC1's share, but then when validated, due to round robin, may be resolving to the share off DC2--a midstream shift.

In the end, you should likely share the printer object on ONLY one server, especially if they're DCs.  
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

We recently had an issue where out of nowhere, end users started indicating that their logins to our terminal server were just showing a "blank screen." After checking the usual suspects -- profiles, shell=explorer.exe in the registry, userinit.exe,…
Scenario:  You do full backups to a internal hard drive in either product (SBS or Server 2008).  All goes well for a very long time.  One day, backups begin to fail with a message that the disk is full.  Your disk contains many, many more backups th…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now