VMWare support notified us that there were issues with two Microsoft patches released this month. Sure others were notified as well. We would have found this out following our Patch Testing Group process which I loosely cover here. These updates can cause Server 2008 R2 and Windows 7 Virtual Machines to loose their IP configuration. The two KBs in question are:
with this item specifically causing the problem
A new Ethernet virtual Network Interface Card (vNIC) may be created with default settings in place of the previously existing vNIC, causing network issues after applying this update. Any custom settings on the previous vNIC are still persisted in the registry but unused.
Both Twitter and Reddit are lighting up over this. My understanding is this issue requires 3 conditions to apply:
- OS is Server 2008 R2 or Windows 7
- NIC is vmxnet3 (therefore on VMWare)
- IP is statically assigned.
Microsoft has a workaround which is to basically set up the new vNIC with the IP info of the old one. While most of our systems are newer versions of Windows we have enough of these impacted systems that touching each one manually is not all that appealing. VMWare suggests you not apply either of these. We choose this route to see if Microsoft more directly addresses. As we have taken a "Virtualize Only' stratagy we have alot of systems that would be affected, mostly on the server side. Per policy we have chosen to exclude these systems from the cumulatives for now until we decide on a more eleqouent resolution. Since we use ConfigMgr to patch I put together some collections to captured impacted systems.
First up is we have a 'All Virtual Systems' Collection that sources from 'All Systems' that we will pivot off.
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.IsVirtualMachine = "True"
as well as an 'All Physical Systems' Collection to break these out. As I am always thinking of the future vs focusing on this one issue I then collected all the Virtual Systems with a VMWare vmxnet3 NIC that had a static IP called 'All Virtual Systems with VMXNet3 NIC and Static IP':
Additionally those with DHCP.
Counts didnt seem quite right so looking at some systems which we learned that instead of doing an 'equal vmxnet3 Ethernet Adapter' in the query to change it to 'like vmxnet3 Ethernet Adapter%' as some had multiple NICs or "vmxnet3 Ethernet Adapter #8" (!!) in one case. I am assuming several did not get legacy devices cleaned up after a P2V operatoin. This put counts more in line with what vCenter showed but identified the vmxnet3 vs e1000 and other NICs in use.
We then took it further by narrowing on the impacted OS versions and created a collection that limits from the above 'All Virtual Systems with VMXNet3 NIC and Static IP' collection. We create collections for each OS version, and feature release for Windows 10, so we just had to include the Server 2008 R2 and Windows 7 collections and now we have the impacted systems to exclude. Called it 'All 2008R2 and 7 Virtual Systems with VMXNet3 NIC and Static IP'.
For further detail we created two more collections, one for each OS and sourced the above collection and included just the 2008R2 or 7 OS collection.
For the SUGs (Software Update Group) We follow the monthly/yearly method. So we put these two KBs into their own SUG and targeted the 2008 R2 and 7 systems but excluded the above impacted systems. With how we structured Software Update collections and Maintenence Window Collections we then had to create a collection that included all systems but excluded the impacted systems.
Took me longer to write this post then to do the actualy work! I would expect this to be resolved next month so the special SUG goes away however the initial collections seem pretty useful for the future.
-Kevin
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_NETWORK_ADAPTER on SMS_G_System_NETWORK_ADAPTER.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER_CONFIGURATION on SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.ResourceID = SMS_R_System.ResourceId where SMS_G_System_NETWORK_ADAPTER.DeviceID = SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.Index and SMS_G_System_NETWORK_ADAPTER.Manufacturer like "VMWare%" and SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.IPEnabled = 1 and SMS_G_System_NETWORK_ADAPTER.Name like "vmxnet3 Ethernet Adapter%" and SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.DHCPEnabled = 0 and SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.IPAddress is not NULL
Additionally those with DHCP.
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_NETWORK_ADAPTER on SMS_G_System_NETWORK_ADAPTER.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER_CONFIGURATION on SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.ResourceID = SMS_R_System.ResourceId where SMS_G_System_NETWORK_ADAPTER.DeviceID = SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.Index and SMS_G_System_NETWORK_ADAPTER.Manufacturer like "VMWare%" and SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.IPEnabled = 1 and SMS_G_System_NETWORK_ADAPTER.Name like "vmxnet3 Ethernet Adapter%"
Counts didnt seem quite right so looking at some systems which we learned that instead of doing an 'equal vmxnet3 Ethernet Adapter' in the query to change it to 'like vmxnet3 Ethernet Adapter%' as some had multiple NICs or "vmxnet3 Ethernet Adapter #8" (!!) in one case. I am assuming several did not get legacy devices cleaned up after a P2V operatoin. This put counts more in line with what vCenter showed but identified the vmxnet3 vs e1000 and other NICs in use.
We then took it further by narrowing on the impacted OS versions and created a collection that limits from the above 'All Virtual Systems with VMXNet3 NIC and Static IP' collection. We create collections for each OS version, and feature release for Windows 10, so we just had to include the Server 2008 R2 and Windows 7 collections and now we have the impacted systems to exclude. Called it 'All 2008R2 and 7 Virtual Systems with VMXNet3 NIC and Static IP'.
For further detail we created two more collections, one for each OS and sourced the above collection and included just the 2008R2 or 7 OS collection.
For the SUGs (Software Update Group) We follow the monthly/yearly method. So we put these two KBs into their own SUG and targeted the 2008 R2 and 7 systems but excluded the above impacted systems. With how we structured Software Update collections and Maintenence Window Collections we then had to create a collection that included all systems but excluded the impacted systems.
Took me longer to write this post then to do the actualy work! I would expect this to be resolved next month so the special SUG goes away however the initial collections seem pretty useful for the future.
-Kevin
No comments:
Post a Comment