This post is dedicated to the System Center Configuration Manger (SCCM/ConfigMgr) Administration Service (AdminService for short). Please check back here for helpful links and to blog posts, documentation and examples for using the AdminService. Please note, I wasn’t sure what the name was officially when I first started, and I didn’t expect to keep posting new info about it, so sorry if it’s disjointed.
Update: 11/3/2109 - I am updating this post to show information for the the latest ConfigMgr Current Branch release. Trying to keep track of changes between releases is not all that useful except for in Technical Previews.
Original Posts
- 1810 TP -The ConfigMgr OData Web Service – V2
- 1810 TP - The ConfigMgr AdminService
- 1810 CB - Updated Information about the AdminService/SMS Provider API in SCCM/ConfigMgr 1810
- 1906 TP - ConfigMgr 1906 Technical Preview – Testing CMPivot over CMG using AdminService
Latest AdminService News
- 1810 CB - added Email Approvals which leverages AdminService.
- 1810 CB - the SMS Provider API role was added.
- 1901 TP - added Create and Edit functionality to the WMI Controller.
- 1901 TP - added Connected Consoles in the Administration\Security node which leverages AdminService
- 1902 TP - changed WMI Class names to align with WMI SMS_ class names.
- 1902 CB - the changes from 1901 TP and 1902 TP have been included.
- 1906 TP - enabled AdminService on multiple nodes in the console
Community Blogs
- Sandy Yinghua - Use ConfigMgr administration service (AdminService) over internet
- Nathan Niehnert
The Basics
The AdminService is a REST API that runs as a service, independent of the other web components in IIS on your site servers.
Service
You can check the status of the service in the console under \Monitoring\Overview\System Status\Component Status - SMS_REST_PROVIDER
Files and Registry Keys
There are several files to be aware of. Below are the key files of interest.
- Service components
- \bin\X64\CMRestProvider\sccmprovidergraph.exe
- \bin\X64\CMRestProvider\sccmprovidergraph.exe.config
- Logs
- Locations
- \Logs
- Application Event Log - Source - CMRestProviderService
- Files
- SMS_REST_PROVIDER.log - Logs the status of the provider service
- AdminService.log - logs commands run against the AdminService
- Locations
- Registry
- HKLM\SOFTWARE\Microsoft\SMS\Tracing\SMS_REST_PROVIDER
- HKLM\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_REST_PROVIDER
- HKLM\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_SITE_COMPONENT_MANAGER\Component Servers<SERVERNAME>\Components\SMS_REST_PROVIDER
Setup
Beginning in 1810 CB, you will see the SMS Provider API as an option during setup. This feature enables the AdminService REST API. You also have the option to install the SMS Provider role on additional site servers. When you do this, the AdminService will also be included on this new server. See info here: https://docs.microsoft.com/sccm/core/plan-design/hierarchy/plan-for-the-sms-provider
Additionally, you can configure the AdminService to communicate through the Cloud Management Gateway CMG by configuring the SMS Provider role.
Usage
My earlier posts linked above show the progression of testing that I performed with the AdminService. Below is a summary and key changes between releases. You can test using PostMan or another REST API testing tool.
Routes/URLs
There are 2 main Routes in the AdminService - v1.0 and wmi. v1.0 is for items newer items that have been transitioned from WMI to OData/SQL. These are already in use for several item including parts of the SCCM console and Application Approvals. The wmi routes should match the WMI class names that you should already be familiar with - most beginning with SMS_.
Versioned Route Controllershttps://<ServerName/AdminService/v1.0
https://<ServerName/AdminService/v1.0/$metadata
WMI Route Controllerhttps://<ServerName/AdminService/wmi
https://<ServerName/AdminService/wmi/$metadata
Read-Only Query Basics
Note: All queries in this section use a HTTP GET method. Also, everything is CASE SenSiTiVe.
- Get all Devices
https://<ServerName>/AdminService/wmi/SMS_R_System
- Get All Users
https://<ServerName/AdminService/wmi/SMS_R_User
- Get Device By ResourceID (same syntax for users)
https://<ServerName>/AdminService/wmi/SMS_R_System(12345678)
- Get User By ResourceID
https://<ServerName>/AdminService/wmi/SMS_R_User(12345678)
- Retrieve related class information. This example gets Operating System information for a specific device.
https://<ServerName>/AdminService/wmi/SMS_R_System(12345678)/SMS_G_System_OPERATING_SYSTEM
You can find more query examples in my previous posts.
Create and Edit Methods using wmi Controller
In my recent testing, this doesn’t seem to work with 1906 CB but does work with 1910 TP. Will update if this changes with the next release. The general concept should apply moving forward - you can use POST and a body to create new objects.
Create a new Package
POST - https://<ServerName>/AdminService/wmi/SMS_Package
BODY - {"Name": "Test Package", "Manufacturer": "ASD"}
You should be able to see your new package in the console or you can use the AdminService to query SMS_Package to find it.
GET - https://<ServerName>/AdminService/wmi/SMS_Package?$filter=Name eq 'Test Package'
Editing A Package
Using the methods above, we can edit the package that we just created. First we have to get the ResourceID for the package.
GET - https://<ServerName>/AdminService/wmi/SMS_Package?$filter=Name eq 'Test Package'
|
|
Edit the Package object
POST - https://<SERVERNAME>/AdminService/wmi/SMS_Package
Body - {"PackageID": "TP100009", "Name": "Test Package #1", "Manufacturer": "A Square Dozen"}
You can also return just the properties that you want, however in 1906 the $select operator doesn’t work - but it does on 1910 TP and previous builds.
GET - https://<SERVERNAME>/AdminService/wmi/SMS_Package?$filter=Name eq 'Test Package %231'&$select=PackageID,Name,Manufacturer
|
|
Console Connections
Navigate to \Administration\Overview\Security\Console Connections in the Admin Console to see a list of all Admin Consoles that are connected and their versions. Check the AdminService.log to see the query that gets executed.
https://<SERVERNAME>/AdminService/v1.0/ConsoleAdminsData
Look for the Console Heartbeat feature coming soon.
Application Approvals
Depending on whether you’ve enabled the AdminService to communicate through the CMG or not, the email approvals will include a URL to approve an application request. The URL can only be used once since the email GUID is removed from the database once the URL is clicked.
Internal URLhttps://<SERVERNAME>/v1.0/UserApplicationRequest/AdminService.ApproveRequest(Guid=%27<GUID>%27)
CMG URLhttps://<InternetFacingURL>/CCM_Proxy_ServerAuth/ImplicitAuth?AADTenantID=<TENANTGUID>&RoleID=<ROLEID>&EndpointName=AdminService&Path=v1.0/UserApplicationRequest/AdminService.ApproveRequest(Guid=%27<GUID>%27)
PowerShell Usage
You can use the above queries in PowerShell as well. I have several sample scripts on my GitHub Repo here. It’s just for demo purposes and isn’t complete but it should give you a good starting point. Feel free to reach out if you have questions.
Cloud Management Gateway (CMG)
Check my GitHub Repo for a sample script to query the AdminService from the internet through the CMG.
OData
I’m having trouble getting this to work in 1906 and 1910 TP at the moment. Since the AdminService uses OData, it can be integrated directly into PowerBI with no need to understand the database or SQL queries.
Summary
I plan to update this page as new AdminService features are released. Please check back for more info. Also, I’d love to hear what things you’ve tested out. Check out my ConfigMgrAdminService GitHub Repo for more sample files in the future.