Update 12/04/2018: Check out the latest info on the SMS Provider API.
I posted last week about the OData connector that is included in ConfigMgr Technical Preview 1810. I did some more digging this past weekend and made a few more discoveries. Additionally, I ran into some issues during testing and was able to get in touch with some of the team working on the new AdminService and they gave me some great insight on my findings. Here’s what I’ve got so far:
RESTful API’s use Routes and Controllers to build a framework for requests based on parts of the URL, the type of request (Get, Put, Post, Delete), headers and request body. The OData standard is a for RESTful API’s and it is what the AdminService is built around. In the previous post, I mentioned that the service was v2. After working with it, I found that it was the WMI Route for AdminService and can be accessed by https://localhost/AdminService/v2/
which will become https://localhost/AdminService/wmi/
in the production release. This is the base URL for the WMI route and will produce a listing of all of the available entities. In this case, the entities WMI class names.
In addition the WMI route, there’s another route on https://localhost/AdminService/v1/
which lists 4 categories. From what I can tell, this route is used for a limited set of admin tasks as the moment. I have been able to run scripts on specific collections as well as Approve and Deny user application requests using this route and the correct controller/action/function combination. Additionally, this route has been configured to output OData metadata information which is critical for enabling Power BI (or other OData consumer) to properly render the data.
The product team confirmed the that v2 route isn’t fully built out at the moment, so the OData metadata can’t be rendered with the current iteration of AdminService. Additionally, you will need to add your account to ConfigMgr as an admin directly (not in a group) since the RBAC functionality is still being developed so permissions won’t process correctly yet.
Sample Queries
Here are some of the query options I’ve played with. I’m using Postman for my testing, but you can use PowerShell or any browser plug-in that handles API testing. EVERYTHING IS CASE SENSITIVE and Trailing / matter!
Also Note, I’m using http in my lab, but the default is https. Double check what you are using if you have issues getting this working. See my first post for more info.
|
|
|
|
|
|
|
|
|
|
Run Scripts and Approve/Deny App Requests
Here’s where I think it gets fun. I found a few actions/functions. The RunScript action requires changing to POST and creating a body object using Key:Value format. The script GUID can be found in the ConfigMgr console by adding the Scripts GUID column or running https://localhost/AdminService/Scripts/
to list all of your scripts.
|
|
In the ConfigMgr console, look under Monitoring>Script Status and you can see that the script ran by comparing the Client Operation ID with the value from the results.
You can also approve or deny User Application requests, though you have to lookup the Email GUID from the ApplicationRequests table in SQL.
|
|
Power BI
If you have made it this far, way to go! This is taking forever to write, so thanks for sticking with me. So, here’s how you add the OData connector to Power BI.
- Open Power BI and Sign In (or don’t, I don’t care!)
- Click Get Data to create a new report.
- Select OData Feed from the list and Click Connect
- Enter the v1 URL in the OData feed box
http://localhost/AdminService/v1
and click OK - The initial load will fail.
- Change to authentication to Windows then click Connect]
- In the Navigator you should see a list of tables. Select the tables to show data previews. **If you don’t see data, ensure that your account is in the ConfigMgr console as an Admin.
- Click Load.
Summary
As you can see, there is already a ton of cool stuff in the new AdminService and it can only keep getting better. Build up a ConfigMgr 1810 Technical Preview box and give it a spin!