SCCM Side-By-Side Migration: A Real Life Issue – Resolved.


Good day IT folks, it's Trevor coming back at you with another real life scenario that sparked my interest today, that I thought would be valuable to share with the broader community (wish I stumbled across this previously!). Let me set the stage.


So I am onsite for a customer and the scope of work is quite simple. Migrate SCCM from on-premise infrastructure, to Azure IaaS instances. The networking and back-end Azure components have already been in place for quite a while, as this particular customer has a FY goal to move off of all on-premise ESXi hosts, to Azure. Sounds simple right? Network is there (through a marvelous ExpressRoute), security is in place, and surprisingly RBAC models have been adopted appropriately per our Azure Reference Architecture Recommendations. This sets us up perfectly for a standard SCCM side-by-side migration, we've done this hundreds of times in the past, yet interestingly it never ceases to amaze me that an issue I've never experienced in 12+ years with this tool set, of course I encounter during this engagement. Let's dive in.

We are nearing the completion of the migration as all desired objects have been migrated, source content has been flipped, a small test of clients have been re-assigned, and all things are flowing wonderfully. One of the last steps I perform with customers before going into further planning sessions, is showing how easy it is to "Share Distribution Points" as you're in a cut-over process.

For those of you who might not be aware of this nifty feature, this allows you to "Share" distribution points from your old source hierarchy, with clients assigned to your new destination hierarchy, then at a later date "Re-Assign" these distribution points, which will kick off a Stored Procedure that flips the management of the content libraries and the DP roles as a whole to your new site, ALL while not having a requirement to re-distribute that content. It's been around for a while, and certainly is a time and WAN saver.

Okay, ready? Let's go.


While running a discovery of the source hierarchy through Administration -> Migration -> Source Hierarchy, I had clicked the checkbox for "Enable Distribution Point Sharing" as one of my last tasks with this customer. During such discovery, I was monitoring the MIGMCTRL.LOG and noticed while it was able to discover the majority of the data, once it got to the point where it runs certain commands against the source hierarchy to get the NALPath (FQDN) of any site systems running the DP role, and performs a test connection through WMI to ensure proper permissions are set to share the DP's between hierarchies - failures were occurring. For reasons unannounced to me this team had an improper flattening of their hierarchy over a year ago, and have had this 'rogue' DP since then. What do I mean by 'rogue'? Well, this particular server USED to be a DP, but was no longer a DP on the source site, so why was SCCM / migration manager finding it as being a DP? This is where my investigation began:

Error in log: (migmctrl.log)


"Get the NALPath of active distribution points of current v5 site. SqlCommand = Select ServerName from DistributionPoints where DPFlags <> 1"

"Start syncing distribution points"

......"Couldn't find the specified instance SMS_SCI_SysResUse.FileType=2,NALPath='["Display=\\\\servernamehere"]'"

So what's happening? It's querying the DB in a few manners, and looking for certain true statements, of which it finds this server in particular.

Troubleshooting Time:

I decided to hop on the source hierarchy and login to the DB and run the following query:

select * from DistributionPoints

Oddly enough, the DP in question did not return... Strange. So where is migration manager getting this from then?

I looked deeper.

I noticed in the log it was looking in WMI:

Get-WmiObject -Namespace root\sms\site_<yoursitecode> -Class SMS_SCI_SysResUse -Filter "NALPath like '%servernamehere%"

This was found on the site - so I looked in the representative table in SQL:

select * from SC_SysResUse where NALPath like '%servernamehere%'

What do you know, there it is! At this point I knew this was the root issue, and confirming once again this is indeed NOT a true DP, I simply performed a delete command (With proper Support Engineering over my shoulder):


Delete from SC_SysResUse where NALPath = 'insertservernamehere'

Once this completed, I re-ran discover data now within the Migration node of the console, and it was successfully able to complete.

So how did this happen?:

Easy, an improper deletion of objects within SCCM, it appeared to me that someone was unable to properly decommission the DP at the time, and hacked the registry to delete it in an unsupported manner. Sadly this is why we deem things 'unsupported', but as I always say, "Logs never lie, neither does WMI." Which most definitely was proven true today!




SCCM Custom Report Request – PXE Enabled Distribution Points and Boundary Group Membership

The Request:

Good Day Everyone! I come to you this lovely afternoon with a post on a custom report request that came my way - that oddly enough was nowhere to be found as an offered solution within SCCM or on the wonderful World Wide Web! Last week a customer emailed me asking for a custom report that showed all PXE Enabled Distribution Points within their hierarchy, but also wanted to know the Boundary Group they were a reference in, and the Site Code in which that Boundary Group resided in. Sounded simple enough? Let's give it a go!

Starting Points:

As with any custom report request, I start in the views where I know my information lives. In this case it's within the below snipped views:

What's provided in these views? Let's talk about that.

  1. View: vSMS_BoundaryGroupSiteSystems - this view provides information on all of the Site Systems within each Boundary Group from your hierarchy. Keep in mind this will include any site system specified in the "References" tab of your boundary group. Naturally this will include more than just a DP in most cases. Keep this thought!
  2. View: v_DistributionPointInfo - this view provides information on all properites and information about your distribution points. This would be the UI equivalent of Administration -> Distribution Points -> (Choose DP) Properties.
  3. View: vSMS_BoundaryGroup - this view provides detailed information on boundary group information, such as Name, how many boundaries (members), under-the-hood GroupID, GUID, and more!

I knew with the above 3 views that I had all the information right in front of me, now it was time to start choosing specific information from each. For this I leveraged GroupIDs from vSMS_BoundaryGroupSiteSystems and vSMS_BoundaryGroup. If these two were the same, I knew I could join it as a where statement (which they were). Next I needed the Server/DP Name, and the Primary Site Code. SiteCode came from vSMS_BoundaryGroup, and Server/DP Name (in a readable form) came from v_DistributionPointInfo.

Finally - it's time to join it all together! 

Select vSMS_BoundaryGroup.Name [Boundary Group Name], vSMS_BoundaryGroupSiteSystems.SiteCode [Primary Site Code], v_DistributionPointInfo.ServerName [Distribution Point Server Name], v_DistributionPointInfo.IsPXE [PXE Enabled] from vSMS_BoundaryGroup, vSMS_BoundaryGroupSiteSystems, v_DistributionPointInfo

Where v_DistributionPointInfo.NALPath = vSMS_BoundaryGroupSiteSystems.ServerNALPath and vSMS_BoundaryGroup.GroupID = vSMS_BoundaryGroupSiteSystems.GroupID and v_DistributionPointInfo.IsPXE = 1

Order By vSMS_BoundaryGroup.Name asc

There you have it! The results will output the Site Code, Boundary Group Name, Distribution Point Server Name, and PXE information, like below:

Take the above query, move it around, make it look pretty in Report Builder and you now have a satisfied customer and a completed request!

Told you it'd be an easy one!

  • Until Later!!!

ConfigMgr Cloud Management Gateway!

Good day everyone! Recently I spoke at Microsoft Tech Talk - Dallas on this topic, and I wanted to put together a quick informative post on some of the prerequisite steps along with implementation steps necessary to deploy the SCCM Cloud Management Gateway! This is an amazing feature that is truly a new way to manage your internet clients in your enterprise.

Certificate verification


  1. SCCM IIS Certificate
  2. SCCM Client Certificate
  3. SCCM CMG Certificate (same as IIS cert, but private key is exportable)
  4. SCCM OSD Certificate (same as client auth, but exportable)


  1. On Primary Site Request Client, IIS, OSD, and CMG certificates.
    1. SCCM IIS Cert Request (common name in request) short and FQDN
    2. SCCM OSD Cert Request (common name in request) short and FQDN
    3. SCCM CMG Cert request Unique (common name) must be specified when requesting SCCM CMG Certificate (example:
  2. GPO for autoenrollment for client certificates


  1. Root Cert to file
  2. Intermediate Cert to file (if present)
  3. SCCM CMG Certificate with password
  4. SCCM OSD Certificate with password

Azure Subscription & Permissions

  1. Login to – identify subscription, verify permissions. We prefer this is done via a service account, however that service account needs to have temporary subscription ownership for us to continue.

PKI SCCM Changes and log verification process

  1. MP – IIS and console (mpsetup.log, mpcontrol.log)
  2. SUP – IIS and console (wcm.log) please refer to SSL in WSUS and SUP
  3. DP (workstation cert (SCCM OSD Certificate) in console)
  4. Site and Hierarchy Settings (HTTP or HTTPS, deselect CRL, use PKI when available)

Azure services wizard in console

Detailed steps:

As with most configurations for SCCM, we are going to start in the ConfigMan console.

  • In the ConfigMgr Console, go to Administration > Cloud Services > Azure Services.
  • Click Configure Azure Services on the ribbon menu.
  • Select Cloud Management in the Wizard.
  • Provide a Name and click Next to proceed.
  • Click on Browse to either Import an existing App or click Create to start with a fresh App.
  • You need to Sign in with a Subscription Admin/Owner.

Follow the steps for both Web and Client App to proceed with the wizard.

Click Next, Enable Azure AD User discovery is not required for CMG and is optional if you'd like to check it and finish the wizard.

Azure app registration modifications

Within the Azure Portal, we need to navigate to App Registrations:

We will hopefully find both our Server and Client API Apps that we created in the previous SCCM Console Wizards like below:

Click each of the app registrations, and navigate to the settings option like below:

We need to then modify permissions so that we can continue on with the actual creation of the Cloud Management Gateway with no issues. Please modify like below (we will need to do this on both Client app and the Server app):

Cloud management gateway creation

  • On the ConfigMgr Console, go to Administration > Cloud Services > Cloud Management Gateway
  • Click Create Cloud Management Gateway on the ribbon menu and Sign In with Azure Subscription Admin account
  • The subscription info and the Web App created in Section 3 will auto populate. Click Next to proceed.


  • Click Browse to specify the SCCM CMG Certificate (same as IIS but with the exportable private key and password) This will auto populate the Service name.
  • Choose your Azure Region
  • Choose Create new under Resource Group.
  • Add the Client Trusted Root Certificate from section 1.1
    • If you have an intermediate CA, please complete the chain of trust, by “Add” again.
  • Verify Client Certificate Revocation checkbox [Clear this only if you haven't published the CRL on internet.]
  • Click Next to finish the Wizard.

The deployment in Azure begins -

CloudMgr.log will show the details of the CMG deployment. Below are a few key points of the process that we are looking for log-wise.

Resource Manager - Creating resource group cmgarm with location South Central US        SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:02:27 PM        3140 (0x0C44)


Resource Manager - Resource group cmgarm created        SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:02:28 PM        3140 (0x0C44)


Resource Manager - Creating cloud service cmgarm with deployment CreateCloudServiceba0f51cf-SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:02:28 PM        3140 (0x0C44)


Resource Manager - Creating storage service cmgarm with deployment CreateStorageService7cabb6ec-SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:02:45 PM        3140 (0x0C44)


Uploading file C:\Program Files\Microsoft Configuration Manager\inboxes\\CloudProxyService.cspkg to container deploymentcontainer with blob name cmgarm.cspkg in storage account cmgarm        SMS_CLOUD_SERVICES_MANAGER        3/27/2018 6:08:44 PM        3140 (0x0C44)

Log in to the Azure Console to view the resources

Validate the status Ready from ConfigMgr console.

Cloud management gateway connector point creation

We must now go ahead and configure the Cloud Management Gateway Connector Point. You can think of this as a secure tunnel that’s connecting authenticated requests through your CMG, down to your on-premise hierarchy, specifically your management point and software update point(s)..


  • Add new site system role and choose Cloud Management Gateway connection point
  • Validate the Gateway name we just created and the Region to finish the wizard.

The Connection Point server will show as associated in the console. For troubleshooting this component, you can check SMS_Cloud_ProxyConnector.log.

SUP and MP changes to accept CMG traffic

Within the console we must modify properties of the designated MP’s and SUP’s that your business organization has chosen to accept Cloud Management Gateway Traffic for your internet clients.

  • On the Management Point Properties, check the box Allow Configuration Manager cloud management gateway traffic
  • Follow the same steps for Software Update Point.

Ensure and enable content hosting on CMG (this is new to 1806+)

Starting with 1806, the product group modified the behavior and administration of cloud content. Historically you had to provision a Cloud Distribution Point for content, now all of that can be hosted on your CMG (go to properties of CMG):

Test functionality

We must modify our Default Client Settings, or the Client Settings deployed to our test collection of machines to ensure that we have CMG options enabled. Upon confirmation, we can either initiate a machine policy download, or simply restart the SMS Agent Host for quicker results.

The client machines will receive CMG connection info which can be verified by the following registry key – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Internet Facing


On a test client outside corporate network, check CCMMessaging.log to validate a successful communication with CMG

Additional testing methods

You can force the client to always use the CMG regardless of whether it’s on the intranet or internet. This configuration is useful for testing purposes, or for clients at remote offices that you want to force to use the CMG. Set the following registry key on the client:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Security, ClientAlwaysOnInternet = 1

Verify that the client is on Internet through the Configuration Manager applet in the control panel:

And run following PowerShell line to verify that the CMG is available as Internet management point:


Get-WmiObject -Namespace Root\Ccm\LocationServices -Class SMS_ActiveMPCandidate | Where-Object {$_.Type -eq "Internet"}

Custom Reports 101 – An Example from the Real World – Report on Software Updates in a Software Update Group

Custom Reports 101 – An Example from the Real World – Report on Software Updates in a Software Update Group.

Good day everyone, my name is Trevor Stuart. I am one of the authors and operational leads of Today I wanted to share a post on a real-world client request that came my way. To shed a little background, I am a typical Tech Guy– specializing in SCCM (12+ years), Windows 10 (RTM +), Azure (5+ years), and Cyber Security (learning and loving it). I work alongside Joe Anich (the original author and operational lead of daily for this customer.


Whilst I was on my way out for the evening, the manager I report to for this particular customer asked if I was able to create a custom report that quickly showed all software updates that were in a particular software update group – group it, and highlight the ones that have been modified/added since the last time the software update group had been deployed. Sounds simple right? Let’s dive right in to see if that’s true or not!

Technical Deep Dive:

First thing that must be accomplished is to identify where in the SCCM DB the data for this request is stored. Now I am not going to sit here and assume everyone reading this understands the SCCM DB Schema to an expert level, so I want to share a common trick I teach customers during training on custom report creation. There is a component in all hierarchies called SMS Provider, the provider essentially takes what you do in the SCCM admin console, which is normally executed in WQL, translates that to SQL and executes it against the DB. So, how does this help? Big time!

Go to: Software Library – Software Updates – Software Update Groups – Double click your SUG to show the members of it.

This is the content you’re looking to identify, now quickly go to your log directory on you site server <installation directory>\Program Files\Microsoft Configuration Manager\Logs – within that directory you will see SMSProv.log – open it.

You can see from the highlighted line the precise SQL command that SMS Provider is executing against your DB to bring you what you visually see in the console. Here we are seeing all the columns it’s selecting and most importantly where it’s selecting this information from within the DB. Keep this log up on that line – we will need it later.

Moving on, you will need to open up SQL Server Management Studio and make a connection to your Site DB. Once connected go ahead and open up a new query window. I normally start off by doing a few “Select *” statements from the views I see within the SMSProv.log execution like below:


select * from vSMS_SoftwareUpdatesPackage_List

select * from vSMS_CIRelation

select * from v_AuthListInfo

select * from v_CIToContent

Returned Results:

As you can see here most of our information comes from these four views. Now what we must do is start pruning out what we do not need vs what we are trying to obtain in order to start forming this custom query to then build a report from. What you can learn from these select statements is your Name, CI_ID, etc. all of which will be crucial to the success of this report. I was quickly able to identify the CI_ID that I wanted to target along with sorting by date released to meet the other requirement from the customer.


select distinct











from vSMS_CIRelation as cr

inner join fn_listupdatecis(1033) upd on upd.ci_id = cr.tociid and cr.relationtype =1

inner join v_CIToContent cc on cc.CI_ID=upd.CI_ID

inner join v_AuthListInfo al on al.ci_id=cr.FromCIID

where al.CI_ID = 1473

order by upd.DateCreated desc

Results (461 Rows Returned which match what we visually saw in the SCCM Console):

The above results provided me with everything I needed from a requirement perspective. So, at this point I know that I’m clear to move onto Report Builder, merely copying the query and taking it with me.

Next up we will open Report Builder (don’t worry, Report Builder isn’t all that difficult after all you’ll shortly see!), and follow the Wizard below:

1. Within “New Report” – Click “Table or Matrix Wizard”, that will bring up the following window:

2. Allow “Create a dataset” to remain selected and click Next. This will bring the following window:

3. It should automatically identify the data source that’s mapped to your report server, at this point click “Next” and that will bring you to the following window:

4. Now we are getting somewhere! At this point you will select “Edit as Text” which will bring you to the following window:

5. Remember that query we created in SQL? Let’s go ahead and copy and paste that into this window like the following:

6. After successfully pasting, please click “Next” and you’ll be presented with the following window:

7. You will see numerous available fields in which you will be able to drag and drop into Columns, Rows, or Values. For basic configurations I normally just drag the appropriate fields into the “Values” box like below:

8. Once the desired fields are in “Values”, click Next and you’ll see the following screen:

This will provide you a high-level look at what you’re table will look like once completed – go ahead and click “Next”, then “Finish” on the following screen.

9. You’ll now be brought into the Report Designer window where you will see the beginnings of your report!

10. From this point on you can customize the look and feel of the report as you deem fit. I normally expand the size so that all of the information is presented in a readable manner, I change the fonts, alignment, and add custom branding per each customer. At the end – the results look like the following (Customer Scrubbed Out):

11. Finally, go ahead and save the report where you’d like within your report server and you’re officially complete!

I was able to provide the URL where this report can be run to the manager of this customer, with all requirements met, and accepted! I have various other custom SQL queries that I will be posting at a later date, but feel free to request custom SCCM reports here: Custom SCCM Report Requests & Discussion – and we will do our best to provide the SQL statements for the data you’re trying to obtain.

Thanks for your time! Like, and share! See you all soon.

  • Trevor