cancel
Showing results for 
Search instead for 
Did you mean: 

Print Servers - Unable to publish in AD

ukDavidC
Level 4

We recently create a VCS Print Server and generally it works OK except for publishing in AD. The basic creation process was build VCS, create a cluster, use the print server wizard, add and share some printers, then in windows go to the printer and tick 'Publish in the directory'. This WORKS for the first node and in AD I can browse to the node and see the printers underneath. The problem comes when switching to any other nodes - the printers all come online OK but publishing doesnt work, reporting many events in the event log saying that the print queues couldn't be updated. Tech support suggested this might be a permissions issue in our AD environment so I created a test setup with a completely default AD domain controller plus two default VCS nodes and the issue still occurs.

The windows error is 'Failed to publish property xyz at LDAP://container-for-node-1/ Error 80070005

My thinking is that the printers should be published under the virtual print server name rather than the actual nodes but this doesn't seem to be the case. The first node always works (when it creates the published objects) but any subsequent nodes fail (when they try to update). Any ideas please?

Node 1:

Node 1 OK.png

AD:

AD.png

Node 2:

Node 2 Not OK.png

1 ACCEPTED SOLUTION

Accepted Solutions

D_White
Level 2
Hi ukDavidC,

I don't think an SP1 upgrade will resolve this.  Neither will changing LanMan attributes.

Your printQueue object is published under the physical node container in AD and therefore this is a permissions issue on the second node where the printshare was NOT created. The computer account for the "passive" node does not have permissions to the printQueue object which was created under the "active" node's container.

I assume you are using Windows 2003 as I believe the behaviour has changed in Windows 2008 to publish printQueue objects under the virtual name container in AD but for Windows 2003, print shares are published in AD under the container of the physical node where the share was created.

You could add both physical node computer accounts to the built-in "Print Operators" group to resolve this.  Otherwise, please work through support to request a change to the behaviour of the PrintShare wizard on Windows 2003.

Dave

View solution in original post

7 REPLIES 7

Wally_Heim
Level 6
Employee
HI UKDavidC,

What version of the product are you using? 

The print shares should be published under the virtual server name and not the physical server name.  I'm guessing that there is a problem with the virtual server object in AD.  By default the print share service groups do not create the AD object for the virtual server.  You should try enabling the ADUpdateRequired, ADUpdateCriticalForOnline, DNSUpdateRequired and DNSUpdateCrticalForOncline attributes of the Lanman resource.  Make these changes with the Lanman resource offline.  Online the service group and test again.

Thanks,
Wally

ukDavidC
Level 4
Hi Wally,

Thanks for your reply. I'm using VCS 5 RP1a. Tech support already mentioned about ADUpdateRequired and ADCriticalForOnline but not the two DNS properties. I've set them to on but the resource faults and says that DNS failed to updated - Lanman:PrintServer_SG-Lanman:online:Failed to update DNS entry (error_type:2, error_code:0x000005B4) 

Any thoughts on that one? 

David

Wally_Heim
Level 6
Employee
Hi ukDavidC,

The error 0x5b4 is a timeout error.  It means that the Lanman resource is timing out when trying to update DNS.

I'm working on testing the printshare group as it relates to published printers and will update when I'm done.

I do find suggestion to modify the print queue object in AD by assigning "Full Control" rights for the other physical node.

Thanks,
Wally

Wally_Heim
Level 6
Employee
Hi ukDaveC,

Sorry, I got your response after I had already started working on my test cluster for this issue.  As such, I setup SFW-HA 5.1 SP1.  I was able to reproduce the event id 26 errors in the system event log on failover with a standard/typical printshare configuration when specifying that the shared printers to "List in the directory" option (38 errors for the 1 that I enabled to be clear.)

I was still able to find and access the published printer in AD and it shows as belonging to the virtual print server.

I was able to resolve the event id 16 errors by enabling the ADUpdateRequired and ADCriticalForOnline attributes of the Lanman resource and restarting the service group.

Is it possible for you to upgrade to the 5.1 SP1 product? 

Thanks,
Wally

ukDavidC
Level 4
Hi Wally,
Thanks a lot for your efforts! I'm just sourcing the SP1 software so I'll give it a go as soon as possible and let you know..
David

D_White
Level 2
Hi ukDavidC,

I don't think an SP1 upgrade will resolve this.  Neither will changing LanMan attributes.

Your printQueue object is published under the physical node container in AD and therefore this is a permissions issue on the second node where the printshare was NOT created. The computer account for the "passive" node does not have permissions to the printQueue object which was created under the "active" node's container.

I assume you are using Windows 2003 as I believe the behaviour has changed in Windows 2008 to publish printQueue objects under the virtual name container in AD but for Windows 2003, print shares are published in AD under the container of the physical node where the share was created.

You could add both physical node computer accounts to the built-in "Print Operators" group to resolve this.  Otherwise, please work through support to request a change to the behaviour of the PrintShare wizard on Windows 2003.

Dave

ukDavidC
Level 4

Hi All,

OK to I've updated to the latest version on the test cluster and confirmed that the problem still occurs. Then taking your advice Dave, I added both physical nodes to the Printer Operators AD group and the errors no longer appear, so definate progress. I think there is still a problem though, just on the fact that a physical node holds the print queue object rather than the virtual - what happens if that node goes down and the queues dont work properly, or if the queues are on the "passive" node for an extended length of time might the queues go stale and get pruned? AD policy defaults to not do this but it seems less than ideal?

Appreciate you thoughts on that if you could spare a few mins. Thanks hugely for your help so far! I have a case active with support so I'll let you know any updates from that too.

David