ConfigMgr AdminService and WMI Methods – A match made in the cloud (1910)

This post applies to Microsoft Endpoint Configuration Manager 1910 Current Branch

At Microsoft Ignite 2019 Brad Anderson demoed a few things in his sessions, later covered more in depth in other sessions, that highlighted some new features to allow you to leverage the cloud console to manage ConfigMgr-only devices. As I watched these sessions, I realized that they were using the ConfigMgr Administration Service to do integrate into the cloud.

Watch these sessions for more background on what’s coming
BRK008 – Modern management: How/why you do it now
BRK2082 – What’s new in Microsoft Endpoint Manager, including Microsoft Intune and Configuration Manager (Part 1 of 2)
BRK3220 – What’s new in Microsoft Endpoint Manager, including Microsoft Intune and Configuration Manager (Part 2 of 2)

Paul Mayfield showed how to sync ConfigMgr client policies on ConfigMgr-only, non co-managed, non Intune registered device (BRK2082 11:50 timestamp)

Brad Anderson shows a real-time application install on a ConfigMgr-only, non co-managed, non Intune registered device (BRK008 11:00 – timestamp)

Both of these demos use the ConfigMgr AdminService on the backend. I know I’ve been trying to sell the AdminService as a replacement for WMI, but it’s so much more. The AdminService will leverage your Cloud Management Gateway as a web proxy and allow you to take actions on Any Device from Anywhere (within reason). With Co-Managed and Intune-only devices, you already had much of this functionality; now with the Microsoft Endpoint Admin Center, you can leverage a centralized cloud console to manage devices, regardless of how they are managed.

In this post, I’d like to highlight some of the new features that have been enabled in in the AdminService in Microsoft Endpoint Configuration Manager 1910 Current Branch. *If you were at MMSJazz, you may have heard me talk about this in the 1911 Technical Preview.

WMI Methods!

Up until now, the AdminService has been largely read-only – you could only read WMI classes, but none of the WMI methods were available until now. In 1910, the WMI methods are all here! You can see them by listing the WMI route metadata and looking for ActionImport in the XML output.

https://<SERVERNAME>/AdminService/wmi/$metadata

If you visit the reference for the WMI class in question, you will be able to find the methods and method syntax. From there, you should be able to work out how to execute any WMI method.

SMS_ClientOperation

The Inside the ConfigMgr console, the right-click menu has several options which leverage the BGB (Big Green Button) or Fast Channel to communicate with the client. These include:

  • Run Script
  • Install Application
  • Client Notification
    • Download Computer Policy
    • Download User Policy
    • Collect Discovery Data
    • Collect Software Inventory
    • Collect Hardware Inventory
    • Evaluate Application Deployments
    • Evaluate Software Update Deployments
    • Switch To Next Software Update Point
    • Evaluate Device Health Attestation
    • Check Conditional Access Compliance
    • Wake Up
    • Restart
  • Client Diagnostics
    • Enable Verbose Logging
    • Disable Verbose Logging
  • Endpoint Protection
    • Full Scan
    • Quick Scan
    • Download Definition

If you watch SMSProv.log when you click these, you will see that they each call methods on the SMS_ClientOperation WMI class on the SMS Provider server.

Each device with the ConfigMgr client installed has a WMI class called ROOT\ccm\ClientSDK. Generally, whenever you want to do things on the client, you would need to remotely connect to the device, attach to the ClientSDK class and trigger a WMI method on the client. Essentially, everything is happening client-side. This is no good when you want to take actions from something like a web API or web console. When you trigger these fast channel methods, all of the logic is in the WMI method on the server side, not the client side. I’m sure I’m doing a terrible job of describing what actually happens here…

If we look up the class in the WMI reference https://docs.microsoft.com/en-us/configmgr/develop/reference/protect/sms_clientoperation-server-wmi-class we can see that there are several methods available to take actions on clients from the server. Here’s the PowerShell to trigger a reboot using the SMS_ClientOperation class using Type 17:

Now that we’ve got a handle on BGB and the SMS_ClientOperation class, let’s see how that translates over to the AdminService.

Triggering Client Operations with AdminService

The big win here is that the client Fast Channel will allow the AdminService to trigger client actions FROM ANYWHERE. Up until now, the AdminService was limited to server-side only methods and had none of the existing WMI methods. With ConfigMgr 1910 Current Branch, we will be able to start triggering client actions from any platform that can call a web API.

Using the same URL listed earlier https://<SERVERNAME>/AdminService/wmi/$metadata to list the metadata for the WMI route, if we search for SMS_ClientOperation, we will find all of the WMI Methods from the docs listed as ActionImport lines in XML.

Here’s a listing of the actions available for the SMS_ClientOperation WMI class in the AdminService metadata.

Now that we have the class and methods, we just need to trigger the WMI method using an OData Action. For OData, we will be using a HTTP POST method and sending a json formatted BODY as parameters to the method. The URL syntax for OData Actions used by AdminService is:

https://<ServerName>/AdminService/wmi/<WMIClassName>.<WMIMethodName>

For this example it would be:
https://<ServerName>/AdminService/wmi/SMS_ClientOperation.InitiateClientOperation

Since this is a POST method, you have to upload a body. As far as I know, you can’t do this natively in a browser and need to use a separate tool. I’m using PowerShell, but you can also use Telerik Fiddler or various other tools to do the same thing.

Here’s a sample bit of PowerShell that I put together to test out the Client Notification actions.

The script will prompt for your server name and the ResourceID of the device you want to target (you can actually provide multiple ResourceIDs). The last 3 lines will query SMS_ClientOperationStatus and you will see a new entry for the ResourceID(s) that you targeted. This is all done using the newly added WMI methods in the AdminService.

To verify that the action is actually working, you can check the AdminService.Log and BGBServer.log on the SMS Provider server or the client log that corresponds to the action that you triggered.

AdminService.log
BgbServer.log

The best part about WMI methods being available in AdminService now is that we can call them from anywhere. No need to use PowerShell remoting to connect to the server to call the WMI method. Any authorized user can call these methods. You can even use them in Task Sequences.

As if this wasn’t enough, the next part is even better. You may have seen my previous post where I showed how to trigger CMPivot through the Cloud Management Gateway – now you can do real-time client actions over the CMG. Sync client policies, Restart, or even Install Applications in real-time.

Triggering Client Operations Over the Internet

Next I’m going to step up the game and I’m going to trigger client actions on a Co-Managed device that isn’t on the company network from a non-company device on the internet. This will simulate being able to take actions on clients through the Microsoft Endpoint Manager Admin Center.

I’ve taken the same machine that I was testing on and moved it to a non-business network with internet only. Then I run a script to use the internet-facing URL of the AdminService on a personal device and I’m able to trigger a device restart on the internet-only device. It’s not even registered in Intune.

You will need your external URL and need to generate an authentication token. I followed Sandy’s guide here https://www.scconfigmgr.com/2019/07/16/use-configmgr-administration-service-adminservice-over-internet/. I took her script and rebuilt it a bit then took the sample script from above and integrated it into a new script. Here’s the result.

If you did it right, you should have just triggered a client action on a co-managed device. I haven’t been able to test a non-co-managed device, but I expect that the functionality we saw demoed at Ignite will bring that functionality along once it is released.

Summary

The purpose of this post was to show you that you can trigger WMI methods with the ConfigMgr AdminService in the 1910 CB release of ConfigMgr. Hopefully it has inspired new ideas for how you may use this moving forward. I’ve already spoken with a few folks who are looking at making standalone admin web frontends or leveraging the Power Platform apps to interact directly with ConfigMgr using AdminService. The possibilities are truly limitless! One last note – the AdminService is still very much a work-in-progress. If you plan to mess with it, I wouldn’t start building business processes around it just yet – I think it will get better and easier to interact with moving forward. But if you want to just start getting your hands dirty, get in and give it a test drive.

4 Comments

  • Reply
    Madan
    November 1, 2020 at 8:43 am

    Hi Adam,
    Could you please provide an example of how a resource can be added to a collection via REST. Thanks.

  • Reply
    Joel
    November 2, 2020 at 1:09 pm

    What is the type [int] value if you want to run a script?

  • Reply
    Michael
    February 5, 2021 at 1:13 am

    Hey Adam. My yesterday’s tests indicate that you can’t use TargetCollectionID at the same time with TargetResourdeIDs on 2006. It’s one way or another, which makes sense to me.

    • Reply
      Adam Gross
      February 5, 2021 at 7:31 am

      It doesn’t surprise me. This stuff has been a moving target. Thanks for the info.

    Comment

    This site uses Akismet to reduce spam. Learn how your comment data is processed.

    2,343

    Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: `POST https://dc.services.visualstudio.com/v2/track` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): Guzzle in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113