Building a slide deck, pitch, or presentation? Here are the big takeaways:
- A pair of Windows Server 2008 R2 patches released on March 13 have caused vNICs on VMs to reset, leading to disconnects.
- There is currently no fix for the issue aside from rolling back to previous installations—a good reminder to always test new patches before rolling them out to a production environment.
Microsoft's latest Tuesday patches contained a pair of updates that have caused issues for some Server 2008 R2 administrators.
KB4088875 contained fixes for Internet Explorer, Spectre and Meltdown, and Hyper-V security updates, while KB4088878 was purely a security update. Both patches target Windows 7 SP1 and Windows Server 2008 R2 SP1, but issues have only been reported on Server 2008 R2.
More specifically, the problem is isolated to Server 2008 R2 installations running VMWare containing virtual machines with static IP addresses. The vNICs on those VMs have been found to be resetting to DHCP after the update, leading to disconnects and a lot of frustrated administrators.
No fix, yet
Microsoft told The Register that it's aware of the issue and working to fix it, but there's no fix in sight yet, aside from rolling back to a point prior to installing the update.
Also pointed out by The Register, the issue of resetting vNICs is nearly identical to a previous update released in early December 2017 that caused static IP vNICs to be replaced by new DHCP ones. In that instance, the static IP information was stored in the registry, so those affected by the latest patch snafu may be able to find their vNIC tucked away there.
SEE: Configuration management policy (Tech Pro Research)
Microsoft released a VBS script to fix the issue in December, but don't try using it—there's no way to know if it's safe to run, will fix the issue, or could lead to more issues.
How to patch safely
Reddit users in the Sysadmin subreddit's Patch Tuesday Megathread have been discussing the Server 2008 R2 vNIC bug in detail, and the thread's original post contains a few good tips for how to be sure your systems don't fall prey to this, or other future, patch bugs.
- Always deploy a new patch to a test environment before rolling it out to production. If a test machine suddenly loses its network connection and its vNIC is reset you'll know there's an issue.
- Once you've approved the patch in the test environment, deploy it to a select test group of live servers before releasing it to the entire organization. Seeing several different machines react to it in a live environment may lead to discoveries the test didn't reveal.
- Make backups, and be prepared to roll back—that's the only solution for this latest issue, so don't forget to make backups and keep them on hand for when things go wrong.
- IT pro's guide to effective patch management (free PDF) (TechRepublic)
- Windows 10 update: Microsoft's latest bug fixes include AMD reboot patches (ZDNet)
- Windows 10: Microsoft lifts block on security updates after sorting out AV clash (TechRepublic)
- Microsoft is about to kill off its weirdest Windows 10 experiment (ZDNet)
- Microsoft forces Windows 10 update on PCs that were set up to block it (TechRepublic)
Brandon Vigliarolo has nothing to disclose. He does not hold investments in the technology companies he covers.
Brandon writes about apps and software for TechRepublic. He's an award-winning feature writer who previously worked as an IT professional and served as an MP in the US Army.