During a recent Sunday downtime window doing Windows updates, I found that our Windows Server 2008 print server was missing service pack 2. Having had no difficulty in the past with the SP2 upgrade on our other boxes in the past, it didn’t even occur to me to make sure I had taken a VMWare snapshot of the server before performing the upgrade. It’s when your guard is down and you think there’s no way that anything could possibly go wrong that karma jumps up and bites you hard in the ass.
For a little back-story, we migrated from a FreeBSD based print server using LPD to a Windows print server running 2008 server approximately 2 years ago. The benefits of that switch were many and immediately apparent, with easier queue generation and ease of upgrading and installing drivers, giving us better control over our printers. Deploying those printers to our student use machines (which utilize roaming profiles) using group policy and scripts turned out to not work as well as we had hoped, but that’s another story for another time. Our old FreeBSD server had a name which fit with the server naming scheme of the time, and it also had a DNS cname alias. When we were doing the testing and migration to the new Windows box, we decided to give the server a regular name, and then just move the cname from the old box to the new. This seemed to be a marvelous idea, as we’d be able to test the new production box before migrating our users to using it, and then when we moved the cname, it meant all of our users wouldn’t need to delete and remap their printers. This all worked fairly well after finding that we had to create the DisableStrictNameChecking registry key in order for our server to respond to both it’s real name and it’s cname. This worked swimmingly well for us, at least until we installed SP2.
The SP install went fine, everything completed as normal. Before I left to go home, I decided to make a spot check that printing was still working, and I found that both of the network printers I had added to my machine using the alias were showing as offline. When I tried to get their properties or open the queues from my client machine, I received an error stating that I may have a network problem or the printer may have been deleted. The printers I had mapped to the same machine using the actual server name were working fine. If I browsed to \\servername, I could see all the shares, and then if I clicked the “view remote printers” button (this was a Windows 7 client), all of the printers would be shown. However, if I did the same thing using \\alias, I would see all the shares but after clicking to view the remote printers, none of the printers would appear. It was as though the actual queues on the server weren’t being mapped to the shares when using the alias.
I spent several hours Googling, and attempting fixes which ran the gamut from rebooting the server, creating host name entries on the server, checking the DNS records for the server and the cname, creating registry edits for setting lanman parameters, to setting SPN records. Finally, deep in the bowels of Google somewhere down around the 25th page of results, I found a tiny no name forum, which I can’t even find again now to give it the link love it so rightly deserves, was someone who had the exact same problem. That forum post claimed the resolution was to rejoin the server to the domain. I almost disregarded it entirely because I couldn’t come up with a single reason why this would work, and the connection to the domain seemed to be intact as I was able to login and authenticate to the server, and the domain doesn’t even know about the cname alias. Having tried everything else and having no other viable options on the table short of trying to migrate the printer queues to a new server with no guarantee that would solve the problem, I gave it a shot. Sure enough after the server rebooted, my print connections to the alias showed up as online, and started working again. Probably the most frustrating issue I have ever encountered during an upgrade was fixed by just about the easiest possible thing you could do, which just intensified the frustration and the celebratory drinking which soon followed.
So, the moral of the story is: If your cname alias for your Windows 2008 print server stops working after an SP2 upgrade, try rejoining the server to the domain.