Saturday, April 14, 2018

ConfigMgr WSUS Server Assignments Report

With all the cool changes in Current Branch 1702 and later around Software update Points and boundary groups it made me think about our current topology and what endpoints are using which SUP. Numbers were changed to protect the innocent.


Looking at basic machine metrics such as memory and CPU I knew one of our primary site SUPs was busier then the others. Sure enough this report shows its is about 70% of the load (top two above). We have three WSUS servers in the primary site with two internal and one for Internet facing. Rest are on Secondary sites. It also showed a couple WSUS servers that have been gone for years and one I have no idea about so some service tickets were placed to address these anomalies.

We did not spend too much time on the report to make it fancy so it shows the counts at the top and breaks down each machine below it so you can export to CSV, XLSX or whatever to manipulate. In the case of the strange ones above, identify those systems so we can put in ticket to fix them.


We could not find anything already collected so we created a MOF to collect the data from the endpoints registry.

 //=======================================================  
 // WSUS Machine Location  
 //=======================================================  
 #pragma namespace ("\\\\.\\root\\cimv2")  
 #pragma deleteclass("WSUSLocation", NOFAIL)  
 [DYNPROPS]  
 Class WSUSLocation  
 {  
 [key] string KeyName;  
 String WUServer;  
 String WUStatusServer;  
 };  
 [DYNPROPS]  
 Instance of WSUSLocation  
 {  
 KeyName="RegKeyToMOF_32";  
 [PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate|WUServer"),Dynamic,Provider("RegPropProv")] WUServer;  
 [PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate|WUStatusServer"),Dynamic,Provider("RegPropProv")] WUStatusServer;  
 };  
 #pragma namespace ("\\\\.\\root\\cimv2")  
 #pragma deleteclass("WSUSLocation_64", NOFAIL)  
 [DYNPROPS]  
 Class WSUSLocation_64  
 {  
 [key] string KeyName;  
 String WUServer;  
 String WUStatusServer;  
 };  
 [DYNPROPS]  
 Instance of WSUSLocation_64  
 {  
 KeyName="RegKeyToMOF_64";  
 [PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate|WUServer"),Dynamic,Provider("RegPropProv")] WUServer;  
 [PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate|WUStatusServer"),Dynamic,Provider("RegPropProv")] WUStatusServer;  
 };  
 //=======================================================  
 // WSUS Machine Location END  
 //=======================================================  

The report needed some tweaking as our Internet facing WSUS would be returned as several DNS names based on how the endpoint reported it. You'll see that in the report and can modify to your IBCM WSUS or comment it out but it should work fine unless you have a system called 'IBCM_WSUS'.

 when wuserver00 like '%IBCM_WSUS%:80' then 'IBCM_WSUS:80'  
       when wuserver00 like '%IBCM_WSUS%:8530' then 'IBCM_WSUS:8530'  
       when wuserver00 like 'http://%.internal.mydomain.com%' then SUBSTRING(wuserver00, 8, CHARINDEX('.internal.mydomain.com',wuserver00) -8 )  
       when wuserver00 like 'http://%.external.mydomain.com%' then SUBSTRING(wuserver00, 8, CHARINDEX('.external.mydomain.com',wuserver00) -8 )  
       when wuserver00 like 'https://ibcm.mydomain.com:8531' then SUBSTRING(wuserver00, 9, CHARINDEX(':8531',wuserver00) -9 )  
       when wuserver00 like '%IBCM_WSUS%:80' then 'IBCM_WSUS:80'  
       when wuserver00 like '%IBCM_WSUS%:8530' then 'IBCM_WSUS:8530'  

Download



This Report is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this Script.  Always test, test, test before rolling anything into a production environment.

You can find the report here.

Thursday, April 12, 2018

ConfigMgr Count Windows 10 Versions Report

Wish there was a built in report and am glad to hear one is coming soon. Until then I have this report we made to show the breakdown of Windows 10 Feature releases.


As we did this a while ago it is a manual process to update when each release comes out (such as the pending 1803 Feature release).Towards the bottom just add a couple likes to add new version and mostly add the friendly name.

           Select Case sBuild  
                Case "14393"  
                     sBuild = sB & " (1607)"  
                Case "10586"  
                     sBuild = sB & " (1511)"  
                Case "10240"  
                     sBuild = sB & " (1507)"  
                Case "15063"  
                     sBuild = sB & " (1703)"  
                Case "16299"  
                     sBuild = sB & " (1709)"  
           End Select  

Download



This Script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this Script.  Always test, test, test before rolling anything into a production environment.

You can find the report here.

-Kevin

Sunday, March 25, 2018

2008R2/7 March 2018 Cumulative and vmxnet3 NIC

Hmm. I thought I posted this last week. whoops!

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':

 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