Wednesday, December 6, 2017

WSUS Additional Update Views for Windows 10

I was helping a friend with his WSUS and understanding all the Windows 10 upgrade options available within it once you select the Upgrade classification. I created a few Update views and he was amazed about it as he didn't know that could be done so I thought I would share how I did it.This works fine for WSUS upstream of a SUP in ConfigMgr also however it does not go downstream to the ConfigMgr console so is not really useful in that scenario.

In the WSUS console, just right click Updates and select New Update View and set it up.



In the above example I created the bottom three for specific scenarios in his environment. For Windows 10 elsewhere, I broke them out further based on Windows 10 feature updates or upgrades for Windows 7 and 8.1.


For the Windows 10 Feature Updates view configure as following:


And finally for the Windows 10 Upgrade view, configure as following. Note the legacy OS' products which you will need to have it pulling the meta data for. While the Upgrades classification is (currently) used to get TO Windows 10, it does not apply to the Windows 10 product only.



The above 7 and 8.1 upgrades get approved for a specific Computer group and GPO reflects that so the legacy versions of Windows do not get updated and potentially get out of license compliance. Seems to work well. Now if I can only figure out why there are always two Feature updates for each release. One will show under status that computers need it and the other do not. All my WSUS  servers show it, even the upstream for SUP.



Monday, December 4, 2017

Re-create ConfigMgr SSRS Stock Reports

After we updated to Current Branch 1706 we noticed some of the built-in reports were missing. Either from the SSRS site or in the console (\Monitoring\Overview\Reporting\Reports). Dont know if it was from the 1706 update itself or on of my techs accidently wacking them.

There is a really simple method to cause it to recreate them all as well as the bonus of  correcting the security settings on them. Open the registry on the server with the Reporting Services Role installed and navigate to  HKEY_Local_Machine\Software\Microsoft\SMS\SRSRP and change the SRSInitializeState REG_DWORD from 1 to 0. This will cause ConfigMgr to create all the default reports and permissions. This only touches the CONFIGMGR_SITECODE folder and does not touch any custom reports you made with report builder etc.

After a couple minutes, you can watch this activity in srsrp.log (located in the SCCM install path log folder on the Reporting Services Server) and ReportServerService_DATESTAMP.log (located in the install for SSRS such as <D:\Program Files\Microsoft SQL Server\MSRS12.SQL2014\Reporting Services\LogFiles>)

-Kevin

Monday, October 30, 2017

System Reserved Drive Letter Compliance Baseline


We have a scenario where the System Reserved Volume (S: usually) still retains its drive letter assignment after deployment. In trying to resolve we noticed several systems post deployment (months) that still have the Reserved Drive letter present. While we are still trying to find the root cause during a Task Sequence, its hard to track down. We can image a system and its present, clean it and do it again and it will not be there.

So as a resolution we are using a baseline to remove the letter assignment if found. I will not cover creating a baseline here but will show the relevant parts. To begin with we have to setup the detection using this PowerShell:

 $SysReservedDrive = Get-WmiObject win32_volume -filter "Label = 'System Reserved'" | select -property "DriveLetter"   
 $DriveLetter = $SysReservedDrive.DriveLetter  
 IF([string]::IsNullOrEmpty($DriveLetter)) {        
   Write-Host "Compliant"        
 } else {        
   Write-Host "Non-Compliant"        
 }  

Then for Remediation we use this PS1.

 $commands=@('List Volume')  
 $commands | diskpart  
 $results = $commands | diskpart  
 Foreach ($line in $results){  
 if ($line -match "System Rese"){  
 $POS = $line.IndexOf("System")  
 $line = $line.substring(0,$pos)  
 $Array = $line.split(" ",[System.StringSplitOptions]::RemoveEmptyEntries)  
 $NumElements = $Array.count  
 foreach ($element in $array){  
 $VolNum = $line.split(" ",[System.StringSplitOptions]::RemoveEmptyEntries)[-2]  
 $DriveLtr = $line.split(" ",[System.StringSplitOptions]::RemoveEmptyEntries)[-1]  
   }  
 }  
 }  
 $commands=@(  
   "Select Volume $VolNum",  
   "Remove Letter=$driveLtr"  
   )  
   $commands | diskpart  

Pretty easy, on the compliance condition just set it so the value = Compliant.


We advertise the baseline to a collection holding all workstations in it and set to Windows 7 and up to run daily. This way if there is a legit reason for IT staff to attach a drive letter assignment they can finish their task before the baseline remedies it.