Multiple Windows 10 Remote Server Administration Tools (RSAT) in ConfigMgr

When you do an in-place upgrade of Windows to Windows 10 Feature Release whatever it removes the RSAT tools and you have to re-install. Instead of our IT staff going to download it every time, I put it into SCCM as an available advertisement to our IT staff. I followed this post by Nicolas Pilon @ SystemCenterDudes over it and it has worked great until Feature Release 1709 (16299) came out.

Microsoft has a specific version of RSAT for 1709 and you use the previous (same link!) Windows Server 2016 release for older versions of Windows 10. This presented a small issue that was addressed with multiple Deplyoment Types for the Application.

First step is to create a Global Condition for the Windows 10 Build version for which Jörgen Nilsson @ CCMExec covers. This actually will be useful for other tasks around Windows 10 and technically will pull the build for any version but is only really relevant on Windows 10 platforms.

Then in the Application we have two Deployment Types (no 32-Bit here!). One for less then 1709 and one for 1709.

For each we use two requirements set appropriatly.

• Device | Operating System
• Custom | Windows 10 Build Number

For the 1709 deployment type, our requirements are Windows 10 and Build equals 16299. Note the detection version of ServerManager.exe 10.0.16299.2 as of this writing.

For the older versions, it is also Windows 10 but also Server 2016 and not equals Build 16299

To keep it simpler each MSU is in a seperate folder source so when 1803 (whatever the next one is called) its easy to add or change. Maybe Microsoft will make RSAT version agnostic.

-Kevin

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.

-Kevin

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