Exploring Configuration Manager Automation Fundamentals– SMS Provider
Published Jun 23 2023 12:00 AM 7,523 Views
Microsoft

Hello!

 

My name is Herbert Fuchs, and in this blog series, I want to take you on a journey exploring automation and API capabilities within Microsoft Configuration Manager. We will cover the fundamentals, share tips and tricks, and delve into advanced content.

 

Over the next few weeks, we will cover the following topics:

 

  1. SMS Provider
  2. Windows Management Instrumentation (WMI)
  3. PowerShell Cmdlets
  4. Administration Service (REST API)

 

Before we dive into coding examples and details, it's essential to cover some essentials. Our first stop is the SMS Provider (System Management Server). This concept is crucial because whenever you interact with the Configuration Manager Console, ConfigMgr PowerShell Cmdlets, Windows Management Instrumentation (WMI), or Administration Service (REST API), you are working with the SMS Provider.

 

So, what is the SMS Provider?

 

SMS Provider in General:

 

To manage Microsoft Configuration Manager, you use a Configuration Manager console that connects to an instance of the SMS Provider.

The SMS Provider is a Windows Management Instrumentation (WMI) provider that grants read and write access to the Configuration Manager database at a site.

By default, an SMS Provider is installed on the site server when you install a central administration site (CAS) or primary site.

You can have multiple SMS Provider instances for each site.

The SMS Provider does not interact with Configuration Manager clients.

 

SMS Provider Prerequisites:

 

The role must be in the same domain as the site server and the site database site systems.

It can't have a site system role from a different site.

It can't already have an SMS Provider from any site.

It requires a supported OS version.

At least 650 MB of free disk space is needed to support the Windows ADK components.

For the Administration Service REST API, .Net 4.6 is recommended (but .Net 4.8 is recommended).

 

Always refer to the Microsoft documentation for a list of supported operating systems for site system servers.

https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/configs/supported-operating-systems-...

 

Now that we know there is a role that is automatically installed and some prerequisites to consider, let's discuss authentication and authorization:

 

SMS Provider Authentication:

 

You can specify the minimum authentication level for administrators to access Configuration Manager sites. This feature enforces administrators to sign into Windows with the required level before accessing Configuration Manager. It applies to all components that access the SMS Provider, including the Configuration Manager console, SDK methods, and Windows PowerShell cmdlets.

 

In the hierarchy settings, you can configure three authentication level options:

 

  1. Windows authentication
  2. Certificate authentication
  3. Windows Hello for Business authentication

 

msfoxworks_1-1686592634375.png

 

 

For more details on each option, refer to the "Plan for security - Configuration Manager" documentation on Microsoft Learn.

Plan for security - Configuration Manager | Microsoft Learn

SMS Provider Authorization:

 

Once you configure or allow a user/group to access the Configuration Manager Console, they become a member of the local group SMS Admins.

 

msfoxworks_2-1686592634381.png

 

msfoxworks_3-1686592634386.png

 

Don't worry; this doesn't mean they are Configuration Manager administrators. Members of this group are allowed to access the SMS Provider instances in the WMI control.

 

msfoxworks_4-1686592634396.png

 

This is why you need WMI-Inbound (RPC-Dynamic) on your site server in case you are using a Configuration Manager Console on a remote system. We access this WMI namespace to perform read and write activities in Configuration Manager.

 

Let's summarize: When the SMS Provider is installed and registered, the WMI namespaces are based on the schema of a compilation file called SMSPROV.MOF, which reflects the SQL Database as well.

 

The following diagram illustrates what happens:

 

msfoxworks_5-1686592634399.png

 

We have three different administrative users, each performing a different activity. One is using the Configuration Manager Console, another is using the ConfigMgr PowerShell Cmdlets, and the third is making a native WMI call. In all these cases, we interact with the SMS Provider through WMI. The SMS Provider serves as our interface, mapping these read or write operations against SQL. Additionally, the SMS Provider handles authentication and authorization, checking if correct Authentication Level is used and if the user has the necessary permissions to read/write to the object/instance.

 

SMS Provider Logging:

 

Activities and actions performed through the Microsoft Configuration Manager Console are tracked in the logfile SMSProv.log. If you want to automate activities but don't know where to start, this logfile is your first point of reference.

 

msfoxworks_6-1686592634407.png

 

In this logfile, you can find WMI queries, SQL queries, called methods, and other information. It can serve as your starting point to track the activity you want to automate and identify which WMI class is used or where the information is stored in a view or table. You can also determine if a static method can be used to accomplish your task. Keep in mind that this logfile is quickly overwritten in a production environment, depending on how busy your Configuration Manager admins are. It might be helpful to have a lab environment in place.

 

Conclusion

 

As mentioned, this part is essential, and you should be aware of it because whenever we talk about automation or API calls, the SMS Provider is involved.

 

In the next blog post, we will dive into WMI, which has been mentioned several times in this blog.

 

 

Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

2 Comments
Co-Authors
Version history
Last update:
‎Jun 12 2023 11:10 AM
Updated by: