Desktop Networked Printer Management on Active Directory Environment

Question

Right now all of our network printers are funneled thru a single Windows server. The printers are then deployed to the desktops via Group Policy.

However, should this server fail then the networked printers all go "poof" and no one can print. Obviously, some sort of AD-based replication would be fantastic -- having a "warm standby" is OK but there's no easy way to re-direct the print jobs: unless we add BOTH printers to the clients, but then that's annoying "Which printer should I use, 'Main Printer on Server1' or 'Main Printer on Server2'?". For that reason I'd like to avoid end-user workarounds and hopefully handle it somewhere upstream.

Thoughts?

Answer 1

I've been thinking about this, and contemplating the following:

• Set up a dedicated VM for print serving only
• Clone this VM and suspend (do not shut down)
• Copy the clone to a backup VM server

This covers me in the event of VM OS failure as well as hardware failure on the VM server (since we don't yet have anything more sophisticated to deal with failover). Recovery will take less than 15 seconds as the suspended VM is brought online, and could likely be scripted in the event that I finally get Nagios or something similar put in place...

"Warm" standby, without the client-side duplication. I can't think of any big snags, but this gives me a chance to throw the theory out there and see if anyone can find em.

Answer 2

Clustered print-server.

Total and utter overkill, but this is best-practices solution to your question!

Answer 3

From here:

"There are three approaches I can think of. The first (clustering), we can discount for all but the bigest of networks on the grounds of cost.

The second is to use the network load balancing (NLB) feature of Windows Server 2003. Microsoft doesn't recommend using this for print serving due to the fact that you won't have shared storage, and the print queues will be lost if a server fails. However, I would think that for a lot of people, if the worst thing that happened when a print server failed was that some users had to click "File | Print" again, that's not too much of a trauma. I have tested this in a lab environment and it seemed to work OK for me.

The third approach is to have a second print server as a standby machine. Disable strict name cheching, as described in the following article.

Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name http://support.microsoft.com/default.aspx?scid=kb;en-us;281308

Then, point all your machines at a DNS alias name that you create. Initially, this alias points to the main print server. Periodically use the PrintMig utility from Microsoft to back up the main print server and to restore to the standby server. When the main print server fails, repoint the alias to the standby server.

At worst, users may have to reboot (or otherwise clear their DNS caches), but it's a whole lot better than having a print server fail with no backup and no plan."

Answer 4

Sounds pretty easy.

• Create queues for the printers on a second server. (Use PrintMig or whatever to replicate the configuration. Perhaps consider doing it on a recurring schedule.)

• Create a second set of GPOs to deploy the printers queued on the secondary server. Disable the links on these GPOs (or disable the user portion of the GPOs).

• In the event of a failure, enable the links on the "secondary" printer deployment GPOs.

Depending on the tool you're using to deploy the printers you may need to "un-deploy" the printers on the failed server computer, too.

If you have a large number of GPOs consider using a script to do the enable / disable function en masse.

Answer 5

Here's a more sensible option than my last two suggestions.

This is a script we've used to migrate users from print-server to print-server. It'll also retain their Default Printer choice.

If the worst happened, you could call this script from the existing login-script, and just ask your users to reboot their machines/log out and in.

You would of course need to have the backup print-server up and running first, and you'll need to ensure all the print queues are ready on the new server with the same print queue names.

Here it is:

Option Explicit
'On Error Resume Next'

MigratePrint "\\svr-print-01.yourdomain.loc", "\\svr-print-02.yourdomain.loc"

Function MigratePrint(strOldServer, strNewServer)
    Dim strComputer
    Dim strShareName
    Dim objWMIService
    Dim objPrinter
    Dim objItem
    Dim colItems
    Dim WshNetwork
    Dim objshell

    strComputer = "."

    Set WshNetwork = WScript.CreateObject("WScript.Network")
    Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
    Set colItems = objWMIService.ExecQuery("Select * from Win32_Printer",,48)

    For Each objItem in colItems
        If objItem.ServerName = strOldServer Then   
            If objItem.Default = "True" Then
                strShareName = objItem.ShareName
            End If
            WshNetwork.RemovePrinterConnection objItem.ServerName & "\" & objItem.ShareName, True, True
            WshNetwork.AddWindowsPrinterConnection strNewServer & "\" &  objItem.Sharename
        End If
    Next

    Set objPrinter = CreateObject("WScript.Network") 
    objPrinter.SetDefaultPrinter (strNewServer & "\" & strShareName)
End Function