The ConfigMgr OData Web Service – V2

I went to Microsoft Ignite 2018 for the first time this year. During the week, I got to chat with lots of folks, including some of the SCCM/ConfigMgr product group. Mark Silvey was kind enough to chat with me about plans for the OData connector that was first introduced in  ConfigMgr 1612 Technical Preview. When it was first released it was called CMRestProvider and it had to be enabled in the console (you can read more about this initial implementation here ). I never tested the 1612 TP or the service so I was anxious to see how it worked. Mark mentioned that the new service was enabled by default as in the 1810 TP and included an option to enable it to work through a Cloud Management Gateway, meaning, you can access ConfigMgr from internet based clients! Additionally, he mentioned that they are making strides towards to replace ConfigMgr’s WMI implementation with this new connector called AdminService. I just started playing with it, so this is not a complete write up, but it should get you started if you want to poke around with the 1810 Technical Preview.

The service is installed under <InstallDir>\bin\X64\CMRestProvider where you will find a sccmprovidergraph.exe and sccmprovidergraph.exe.config as well as all of the related components. If you check TaskMgr, you will see that sccmprovidergraph.exe is running and the command line that it launches is <InstallDir>\bin\X64\CMRestProvider\sccmprovidergraph.exe -Namespace root\sms\site_<SITECODE> . Additionally you will find new log files – 1 for the installation and 2 for services.

• <InstallDir>\Logs\RESTPROVIDERSetup.log – Install Log
• <InstallDir>\CMProviderLog\SMS_REST_PROVIDER.log – Monitors the Graph service.
• <InstallDir>\CMProviderLog\AdminService.log – Logs execution of web service calls.

AdminServiceis configured to use HTTPS on port 443 by default. I don’t know if it’s supported, but for testing, I changed the setting to use HTTP and port 80 in the  sccmprovidergraph.exe.config file since I was having issues authenticating with SSL in PowerShell. I’m sure when they fully document the service, the HTTPS stuff will get easier.

The new URL for the service is https://<ServerName>:443/AdminService/v2
or if you switch to http  http://<ServerName>:80/AdminService/v2

To test, I used a simple PowerShell script, but you can use your web browser or something like PostMan – an API testing tool. The script is pretty self-explanatory. You can download it from GitHub .

$Credential = Get-Credential
$SCCMServerName = "localhost"
$Function = "Collection" #Change this to whatever you want to query.
$URL = "http://$($SCCMServerName):80/AdminService/v2/$($Function)"
$Result = Invoke-RestMethod -Method Get -Uri "$($URL)" -Credential $Credential
$Result
$Result.value.Name #Returns collection Names

Based on the original documentation, you can get more advanced an pass in ResourceIDs, CollectionIDs, etc. Basically, anything you can do in WMI today, you should be able to do in the AdminService.

I mentioned the Cloud Management Gateway ( CMG ) option. I haven’t tested it yet in my TP lab because it requires a CMG and other stuff that I don’t have set up yet. However, I did check the box to see what happens. It breaks stuff! If you check the AdminService.log you will see that it changes to use Azure Active Directory ( AAD ) credentials and if you aren’t using AAD, it can’t authenticate you to use the service.

Additionally, I found a blog post by René Kierstein that talked about the 1612 CMRestProvider and he has a Word document with all of the available functions at the time ( 590 ). I set up my PowerShell to loop through each function and attempt the call and check for failures. I ended up with a list of 565 that worked with no extra parameters. I’ve uploaded my list to GitHub .

One last thing. This only worked once and now I can’t seem to reproduce it. I used TaskMgr and stop sccmprovidergraph.exe and relaunch it using psexec.exe -i -s cmd to open a new cmd prompt window as System then launch sccmprovidergraph.exe -Namespace root\sms\site_<SITECODE> and it left a command window open and I was able to watch the Graph service in action. It will log all of the AdminService actions live.

That’s it for now. I have only spent a few hours testing it today but it looks encouraging. It will go a long way to helping reduce our dependency on as many amazing community/third party tools that are currently bridging the gap. I can’t wait to plug it into Power BI and see how it works!