ConfigMgr Upgrade Readiness Connector Setup

NOTE 07.27.2017 - I thought I posted this a while back so hopefully the steps and screenshots are still valid. I'll go validate when I have some time.

---

We are using Windows Upgrade Readiness to accelerate our transition from our legacy versions of Windows to 10 v1607. As we recently updated ConfigMgr to 1610 I wanted to make use of the connector available in SCCM for it.

To give a brief overview, we have the Readiness Scripts Deployment folder (with our info) in an SCCM package with the deployment set to run the BAT file. The deployment has a recurring assignment schedule to run once a month, the week before our monthly patch cycle. Its ran on all workstation OS' including Windows 10) as it is expected to be used well past our 7/8.1 migration to 10 but also from one build version to another in Windows 10 itself as Readiness lets you pick the destination version to work against. Quite handy. Definitely keep up on the teams blog if you use it and the team itself is great with communication and interaction with the world. I've had great conversations with them over this offering.

Here is a sample of the end result that you can see in the ConfigMgr console.I'll cover this more later.

So for the setup of the connector, the documentation was a bit more generic then I would have liked, especially around the OMS and Azure bits, so I did struggle a little on it so here is how I set it up. There are three basic steps to it:

1. Create an Application in Azure for SCCM to use, think of it as the username/password
2. Enable permissions to the OMS instance Upgrade Readiness is in
3. Setup the ConfigMgr to Windows Upgrade Readiness connector

This assumes you have Readiness already setup in OMS. I prefer the older manage web console to the newer portal one so thats where I perform the first step.

Step 1

Log in to the Manage portal and navigate to Active Directory on the left pane. Then click on your AD instance under name.

After that you select APPLICATIONS at the top

Then select Add at the bottom

Choose Add an Application my organization is developing

Give it a useful name such as ConfigMgrUpgradeReadiness and click on the right arrow.

Now you have to create two URLs, neither of which are used so enter whatever you want

Now you can create the Client ID and key that ConfigMgr uses to pull data. You can think of this as the username and password that ConfigMgr uses.

Select your newly created Application and click Configure at the top. This takes you to its customization.

Two parts here. First is  to copy the CLIENT ID somewhere as you will need it. Second is to select the duration of the key as 1 or 2 years. Once saved it will show you the key. you will want to copy the key as well. I would suggest you retain the client ID and key somewhere such as a password manager as you may need it long term. If not then you have to come back here and generate a new one.

Note that you only get ONE opportunity to copy the key. Once you leave this page the key will not be shown (as above) and you will have to generate a new one. You are now done with overall step 1.

Step 2

For step two you need to give this app the correct permissions. This was removed from the manage portal a while ago so over to the new portal. Select Resource Groups on the left pane.

As shown below you will select the Resource Group the Upgrade Readiness is located in (mms-eus in this example) then Access Control (IAM) on page 2 and finally +Add on page 3.

You will then select or search for the name of the Azure AD app you created earlier and grant it Contributor rights. This was my struggle. I originally thought you had to give rights to the domain SCCM service account thinking it was what ConfigMgr accessed OMS with. This is shown above highlighted in yellow.

Step 2 is complete and its onto Step 3, setting up the connector in ConfigMgr.

Step 3

For this you goto the SCCM Console and navigate to \Administration\Overview\Cloud Services\Upgrade Analytics Connector. Note it has not been updated to 'Readiness' yet.

Simply right click Upgrade Analytics Connector and choose Create Connection to Upgrade Analytics.

Enter the relevant information you saved from step 1 above which is the Client ID and secret key along with your Azure Tenant name, generally mycompany.onmicrosoft.com. Once done select Verify then Next.

Note this screenshot is AFTER I already entered it and you'll see the Client secret key: field is blank. If you ever go into here you will have to re-enter the key. You remembered to save it right?

If you setup the permissions correct you will be shown with the required information. This screenshot is post setup also.

Thats it., SCCM will now pull from Windows Upgrade Readiness. You can view information about it in the DMPDownloader.log located in your SCCMInstallFolder\Logs. While I suggest you save the key and Client ID somewhere, it is located in this log file but the logs may have rotated by the time you need either of them.

This is a sample of a normal run. The last line I do not like and wish it could be changed. Upgrade Readiness updates daily, however SCCM will download from it only once a week (10080 minutes) so your data is that old.

Final Thoughts

Once it has imported into SCCM you can act on it. Just goto \Monitoring\Overview\Upgrade Analytics. Per my initial screenshot, it shows readiness information for the All Workstations collection I've created. Just select any collections in your environment that are device based to work against.

At the bottom you can select the pull down and create collections based on the "buckets" that are in Upgrade Readiness. I have created several that in turn have the in-place TS advertised to them as available. It does create these with 'All Systems' as the limiting collection so I have changed that to use more appropriate ones to coordinate with any implementation schedules.

My firm has a small team that spends time every few days in the Upgrade Readiness OMS website so as systems are marked as ready in the Readiness tool then flows via the connector into ConfigMgr Collections to get Windows 10 in-place advertised to that endpoint as being available. Awesome right?

I created a UserVoice to request the 10800 min interval (week) be changed to a day or allowed to be configured. This makes more sense as the Analytics updates daily.

-Kevin

ESXi Windows Server Backup Tool Bare Metal Restore

I have a small single host ESXi on a Dell PowerEdge R710 (popular for homelab) that I support for family. It has all the normal stuff on it:

• Windows Domain Controller with DHCP
• Windows Domain Controller
• General Purpose server for WSUS, MDT and what not. 
• Multiple MDT Build and Capture 
• Multiple Windows 10 Insider Preview
• ???

All normal homelab stuff. Recently there was a power loss event, that while it lasted only a few minutes; and should not have been noticed, hadcaused the battery in the UPS that protects this host to blow up, literally, so all the VMs and the host went down hard.

There is an physical Ubuntu Linux server and network equipment that is on a different (matching) UPS and it controls both UPS' so if a power loss happens it will SSH into the ESXi host and pause the VMs and shut it down gracefully if needed. Sooooooo did not plan for batteries exploding.

While we recently bought VMWare vSphere Essentials, which gives us the backup API, its not in use just yet. When both the host and the VMs were setup it used the free license so everything else used free options. Therefore to protect the "critical" Windows Server VMs, we used the built in Windows Server backup tool and did a daily Full Server backup. These are sent to a UNC path on the above Linux server as it has lots of space and is external. Due to limitations in the built in backup software only a single full backup is done so no incremental.

So upon bypassing the UPS and bringing the host and VMs back up, one of the Domain Controllers was not happy and kept blue screening and in a restart loop.

Solutions on this error were to go through Directory Services Repair Mode. Thankfully this was the DC that is only a DC, no FSMO roles or duties so was pretty disposable. Since the backup is ran daily it was less then 24 hours old I decided to do a bare metal restore instead since its been a while since I did a restore exorcise.

First step was to shut it down and take a snapshop so I can revert and go the Repair Mode route if I chose to. Then boot the VM from the 2012R2 Install ISO.

Select Next on the initial dialog

Then Repair your computer at the bottom

then Troubleshoot

and then finally System Image Recovery

Since my backup is not local and on a Linux server it will error out so we need to get connected to Samba on the Linux box.

Choose Cancel to close this dialog then select Next to proceed

Then you click on Advanced... so you can enter a UNC path.

Here you would locate a backup on the network, however the second option reminded me that I used VMXNET3 for the NIC on this VM and the driver is not in the 2012 R2 install media since its installed by the VMWare Tools. 

If you try to attach to the UNC path you will just get an error since there is no NIC present in this PE instance. You can verify further by going to a Command Prompt in Advanced Options and using ipconfig etc.

I previously wrote on where to source the drivers but that meant getting a source (floppy or CD) mounted on this broken VM. There is a simpler solution for ESXi. I edited the VM and added a second NIC that is supported by the media, which in this case is an E1000e.

After giving a few seconds for DHCP to kick in I selected Back until I could select Advanced... again then select Search for a system image on the network which then asks if you want to bring the network up.

Select yes and enter the UNC to your backups

and of course credentials to get at the backups

Now we have all our Server Backups so we can select the one we want and then Next 

It then asks us which volumes to restore. Since its a DC and only has the one so we select it and Next again.

Since it is bare-metal and going to the same "hardware" you just need to select Next here as we have nothing to change.

And now we are at the confirmation dialog. Finally! Just have to select Finish and let it restore.

Nope, still one more dialog to be sure we are REALLY ready to restore. Select Yes.

Away it goes.

This is weird. Got an error on the restore. I would get this error again each time I tried but in different spots so the backup seemed good to me still.

This is such a generic error I thought it may be NIC related so I went back to ESXi and created a small drive on the multipurpose Server VM

and then copied the backup to it. Note you need to create a folder in the root called WindowsImageBackup then place the systems backup folder in it. Once completed, I unmounted it from that VM and mounted to this broken VM

and ran through the wizard again. All live, the PE instance was seeing all the hardware changes I was making. This time the wizard found it at the beginning since it was local to the VM so I did not have to go through Advanced like before.

After selecting Next you are taken to the Choose additional restore options dialog and its the same from there on out like above, just no errors this time!

Once complete it restarted and the restored server booted back up in its earlier state.

I did however interrupt the restart and unmounted the restore volume and deleted the e1000e NIC I attached. I looked at the event logs to make sure AD replication was happy and then after a couple days I removed the snapshot I took in the beginning. 

Without the ESXi parts at play, Windows Server backup can be a free yet powerful tool to backup servers and restore them. On physical hardware you could copy the backup to a USB if you had the same NIC issues.

Now to work a process around exploding UPS batteries. As a preventative measure, I did copy out the same day backups of the other two servers in case they had this happen but am happy to say they have been running great since this incident happened several weeks ago. Until I have time to research free ESXi backup options that work with my VMWare Essentials license I have added these backups to my rsnapshot.conf on the Linux box to get quasi incremental backups.

-Kevin

Windows 10 ConfigMgr Collections

I've been creating alot of Windows 10 focused collections in SCCM so thought I would gather what I have here. Mostly for me, but also to share with the world. I'll update as I add other ones and tweak these queries. If you have any share them with me!

The main one is to look for Windows 10 specifically. It should be pretty commonly known. I'm not one to use the 'All Systems' built-in collection so I have a parent called 'All Workstations' which contains all endpoints that are not Servers. I set the initial Windows 10 collection below to limit from that collection.

All Windows 10 Systems

 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 OperatingSystemNameandVersion like '%Workstation 10.0%'  

Individual Versions. These all reference the above as the limiting collection. They are the same exception the version at the end.

All Windows 10 v1507 Workstations (10.0.10240)

 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.Build like '10.0.10240%'  

All Windows 10 v1511 Workstations (10.0.10586)

 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.Build like '10.0.10586%'  

All Windows 10 v1607 Workstations (10.0.14393)

 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.Build like '10.0.14393%'  

All Windows 10 v1703 Workstations (10.0.15063)

 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.Build like '10.0.15063%'  

These show the branches. These are the same except for SMS_R_System.OSBranch difference.

All Windows 10 Current Branch (CB)

 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.OperatingSystemNameandVersion like '%Workstation 10.0%' and SMS_R_System.OSBranch = '0'  

All Windows 10 Current Branch for Business (CBB)

 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.OperatingSystemNameandVersion like '%Workstation 10.0%' and SMS_R_System.OSBranch = '1'  

All Windows 10 Long Term Service Branch (LTSB)

 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.OperatingSystemNameandVersion like '%Workstation 10.0%' and SMS_R_System.OSBranch = '2'  

These are neat ones. They show which ones that have expiring info around Servicing. They are all the same except SMS_WindowsServicingStates.State.

All Windows 10 Servicing Current

 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 LEFT OUTER JOIN SMS_WindowsServicingStates ON SMS_WindowsServicingStates.Build = SMS_R_System.build01 AND SMS_WindowsServicingStates.branch = SMS_R_System.osbranch01 where SMS_WindowsServicingStates.State = '2'  

All Windows 10 Servicing Expiring Soon

 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 LEFT OUTER JOIN SMS_WindowsServicingStates ON SMS_WindowsServicingStates.Build = SMS_R_System.build01 AND SMS_WindowsServicingStates.branch = SMS_R_System.osbranch01 where SMS_WindowsServicingStates.State = '3'  

All Windows 10 Servicing Expired

 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 LEFT OUTER JOIN SMS_WindowsServicingStates ON SMS_WindowsServicingStates.Build = SMS_R_System.build01 AND SMS_WindowsServicingStates.branch = SMS_R_System.osbranch01 where SMS_WindowsServicingStates.State = '4'  

For Editions you can use these to capture Pro vs Enterprise etc. I dont use Education but it should be easy to adapt also.

All Windows 10 Enterprise Edition

 select distinct 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_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption = "Microsoft Windows 10 Enterprise"  

All Windows 10 Pro Edition

 select distinct 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_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption = "Microsoft Windows 10 Pro"  

For the Insider Preview versions I'm still figuring out a nice query for it. In the mean time. I just created a collection that is limited to the initial Windows 10 collection. It in turn has an include for the same Windows 10 collection and excludes for the versions above. (1507, 1511, and 1607 currently). When the Creators Update is released its version would need to be added as an exclusion.

Everything above uses the initial Windows 10 collection as limiting. Once any useful ones are created , you can have all sorts of fun by taking the initial query above and using other limiting collections such as bit-level (64-bit vs 32-bit), or platforms like mobile vs desktop or Dell, Lenovo, and what not to isolate further.

Then of course there is Windows 2016

 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 OperatingSystemNameandVersion like '%Server 10%'