KB5004948 (PrintNightmare patch for Server 2016) Breaks Sharing?

[HCHTech]

I have a client that reported today that none of their network shares are working. Their application server, running Server 2016 just had the PrintNightmare patch loaded last night at midnight, and that appears to have been the only change. The symptom is that the Server service will not start/run - which of course, means that sharing doesn't work. The first failure message on the server service is at 12:29am, so it seems pretty clear the update is the culprit here. I've rebooted, but the error persists, ID 7023, The Server service terminated with the following error: The system cannot find the file specified."

I'm in the middle of uninstalling the patch now (it is a ssssllllloooowwww uninstall), and I'm hoping that restores sharing, but I'm not keen to live without the patch.

Has anyone else run into this?

 

[Sky-Knight]

None of my servers have reflected this. But given the change, my suspicion would be an incompatible printer is installed.

There is a whole swath of old label printers UPS was using for decades that are simply no longer an option thanks to that patch. So this seems like a reasonable side effect.

 

[HCHTech]

They are using Papercut on that server, it has the print server role, and there are only 2 printers shared on their network; an HP Pagewide XL 3900 and a Xerox C60 MFP Copier. Both are fairly new machines.

40 minutes and counting on the "Working on updates, 100% complete" screen after queuing the uninstall of the patch.... I'll wait it out a bit longer, but will probably end up forcing a reboot. Crap.

 

[HCHTech]

Well - this has been a frustrating undertaking. Forcing a reboot just resulted in the 'working on updates' hang on restart again. I let it go an hour, then killed the trusted installer task, which let me log in, but I had the same result as before, the server service won't start - cannot find the file specified, which did clearly exist.

Some googling around found this thread from 2010, but grinding through the suggestions didn't help. Since everything was working fine on Friday before the update installation, AND since this VM is setup so none of the data is on the vhdx containing the OS, I just restored the backup from Friday evening (which completed only 60 minutes prior to the installation of the problem update).

Sadly, as soon as I started up the VM with the restored OS drive, it started installing the update - it had actually been loaded on Wednesday evening - out of band - but the server doesn't reboot until Friday at midnight for the update window). The install just hung, so I killed it and restored the OS vhdx from Tuesday evening. Unfortunately, when I started the VM (which did start successfully without trying to install the update), I still had the same problem - *bangs head on desk*. The server service won't start - cannot find the file specified. I ground through the suggestions from that old MS tread again, but no joy.

Now, I think I might have to uninstall the PrintNightmare update from the DC. If taking the appserver back to a point when it was working didn't solve the problem, there must be more than the appserver in play for this issue. Since the update installed successfully on the DC, I have more hope it will uninstall successfully as well. So much for my Sunday. Ugh.

 

[Sky-Knight]

I wouldn't mess with the DC... That's just making more work for yourself.

Does the event log indicate what file isn't found?

 

[HCHTech]

I decided to stop for 20 minutes and then revisit. I pulled up a Server 2016 appserver from another client and compared things. The dependencies for the server service on the problem server had the srv service instead of the srv2 service as it should. In fact, my own thread here was a similar issue.

After checking that SMB2 was enabled and SMB1 was disabled, I corrected the dependency, restarted the server, and what do you know it works.

Now, I know this server has had SMB1 disabled since it was built in 2018. I also know this had to be working as late as Friday evening, so those two facts make me wonder:

• How did the installation of the PrintNightmare patch cause this change - resetting the dependencies on a service to include SMB1 instead of SMB2?
• WHY didn't restoring the ENTIRE drive from a time when the server was working perfectly well unwind this mistaken change? Could this have been changed on the running system at sometime in the past without breaking things until a reboot? That is the only thing I can think of that would cause the fact pattern I have before me.

We have been having on and off problems with their HP Pagewide printer (architects) for a couple of months now. The printer vendor is pointing to the network as the problem and after exhausting all possible issues, I have been blaming the printer (and by association, the vendor). If my second bullet supposition is possible, I suspect that the printer vendor may have made this change without realizing the time bomb they left for when the server was next rebooted. I think I'm going to change the password for the server again and not give it to anyone!!

 

[Sky-Knight]

Yeah someone certainly mucked with it, that's one of those it shouldn't have ever worked things and the only thing the patch did was reboot it...

So someone must have broken the server before this patch was deployed, but AFTER last month's update rollup.