Share via

System Center 2012 Configuration Application Request / Approval – Deep Dive and Automation

  • Article

Introduction -

Approaching my ten-year of systems management using SMS / Configuration Manager I can reflect back on many scripts, applications, and in some circumstances full systems I’ve implemented in order to facilitate a ‘self-service / approval friendly’ software delivery mechanism. SMS/Configuration Manager has always worked great as the delivery mechanism, however has historically lacked an ‘in box’ method to facilitated application approval. With the release of Configuration Manager 2012 we now have true user targeted, self-serving capabilities using the Application Catalog. We also have the ability to flag an application as requiring approval, which can then be completed in in the Approval Requests node of the Configuration Manager console.

While this solution is slick, and provides a good amount of the sub surface plumbing, there is still room for custom engineering that in in my opinion brings the Application Approval process full circle. For instance, included with Configuration Manager we do not have an application request notification engine (deliver an email to the specified approver each time a new request is entered). Additionally, all approval activities need to be performed directly inside of the Configuration Manager console. Fortunately, we have an existing solution to help fill in these potential gaps. The Application Approval Workflow Solutions Accelerator does a fantastic job at providing both a notification engine and an ‘out of console’ approval experience. However this solution does require the use of Systems Center 2012 Service Manager. If your organization is not currently using System Center 2012 Service Manager and thus cannot benefit from the use of the AAW Solution, fret not.

In this blog post I will be exploring the internal components of application approval and will also provide some sample PowerShell that you can use to develop you own automation around the application approval process. Stay tuned for part two of this Application Approval Blog series in which I will share a simple yet complete end to end notification and ‘out of console’ approval solution. If you would like to be alerted of when the second post of this series in completed, subscribe to my Twitter feed using the button found on this page.

Blog Overview -

  • Quickly cover the basics of Application Approval (what is the out of box experience).
  • Dig into the Configuration Manager Database providing reporting examples and data points that may be valuable for custom Application Approval solutions.
  • Explore the Application approval WMI class and information that can be derived from it.
  • Finally detail how to pragmatically approve or deny an application request using PowerShell code.

The Basics –

I am going to quickly lay down some of the basics concepts of the application approval system. The assumption here is that you are familiar with the core components of configuration Manager 2012 such as Application Deployment, user targeted deployment, and the Application Catalog.

  • Deploy an application or applications to a user or group of users.
  • While doing so configure the deployment settings with the ‘Require administrator approval if users request this application’ - see figure 1.
  • While logged in as a user whom the application has been deployed to, open up the application catalog and observe all available applications. Notice the 'Requires Approval' column – see figure 2.
  • Request an application, enter some request comments, and finally observe the ‘My Application Requests’ tab for the current request status – see figure 3.
  • In the Configuration Manage console, browse to the Software Library – Approval Requests node and observe each request. Here you can approve / deny each request – see figure 4 and figure 5.

Figure 1: Marking a deployment as requiring approval.

Figure 2: Application Catalog with all applicable user targeted applications.

Figure 3: View of all requested application.

Figure 4: View from the console of all application requests – Click Image for better view.

Figure 5: Application Approval form used to approve application requests.

Once the application has been approved or denied, this can be observed in the Configuration Manager Console and then also back at the client in the application catalog. Finally as should be expected, once/if the application has been approved, the installation will complete client side.

So far very awesome – we have seen how the self-service / approval system works. As seen here, without modification, this experience requires an administrator to monitor the Configuration Manager console for new requests and then act upon each one within the console at that time.

Going Deeper: Observing the Requests -

So what is really going on here; what is under the covers, and what interfaces do we have with this system? When an application has been requested what data can be used to alert on the request? Here I will detail how to observe application requests using data stored in the CM Database and also how to observe the same application requests as stored in WMI.

Database –

It should go without saying that making any direct modification to the Configuration Manager database is not a good idea and not supported unless doing so through appropriate channels. The purpose of exploring the database here is only to read or report on application request activities. With that said here are the goods.

V_UserAppRequests – this view can be used to view all application requests. In this view we can find the application name, which user has requested the application, and also the current state of the request (among other data). So for instance if I wanted to see all open (non-approved/denied) request I could use this view and the following query –

 

Select

DisplayName,

Unique_User_Name0,

NetBios_Name0,

Comments,

RequestGuid

From v_UserAppRequests

Where CurrentState = 1

Which will return the following results -

 Query Results – Click Image for better view.

 

There are a few items here worth examination. First in the SQL query, the where statement specifies CurrentState = 1. Ok cool – but what does CurrentState = 1 equate to and what additional states can an application request contain?

Fortunately for us, there is a dictionary or sorts defining each application state. This can be found by examining the contents of the UserApplicationRequestsStates table in the Configuration Manager database. The contents of this table are found below, and will come in handy as we progress through this blog series. 

Potential States of an Application Request.

Secondly notice that in our SQL query we are returning the RequestGuid for each request. This will prove important when moving onto programmatically approving or denying requests. Basically each requests gets assigned a unique ID, we will reference this value when making the approval.

WMI –

In addition to the information accessible through the Configuration Manager database, we have most of the same information available to us through WMI on the site server. As we will see later in this article it is here (in WMI) where the approval process takes palce. To view this data in WMI, use your favorite WMI inspection application and navigate to the following location.

  • NameSpace: ROOT\SMS\Site_XYX where XYZ is your site code.
  • Class: SMS_USERAplicationRequest

As you will see, for each instance of the SMS_USERApplicationRequest class, we will see data similar to what is observable in the V_UserAppRequest database view.

Click Image for better view.

Running the following PowerShell will make available the same data as the SQL query previously examined in this article.

 $app = Get-WmiObject -Class SMS_UserApplicationRequest -Namespace root/SMS/site_<Site Code> -ComputerName <site server>

foreach ($appr in $app) {Write-Host $appr.Application; Write-Host $appr.User; Write-Host $appr.Comments; Write-Host $appr.User; Write-Host $appr.RequestGuid; Write-Host `r`n}

This script returns -

And if you wanted to filter this down to only the application requests that have been requested but are waiting an approval, we would just add the following -

$app = Get-WmiObject -Class SMS_UserApplicationRequest -Namespace root/SMS/site_<Site Code> -ComputerName <site server> | where-object -FilterScript {$_.CurrentState -eq 1}

foreach ($appr in $app) {Write-Host $appr.Application; Write-Host $appr.User; Write-Host $appr.Comments; Write-Host $appr.User; Write-Host $appr.RequestGuid; Write-Host `r`n}

Resulting in the following –


Through both the Database and WMI examples given here, you should now have an idea about the ways in which you can retrieve data about all current application requests. In the following section we will use this data to programmatically approve or deny an application requests.

Taking Action – Programmatically Approving or Denying Application Requests

Once we have gathered data about pending application requests, or those with a state of 1, the hard work has been completed. Included with the SMS_UserApplicationRequest WMI class are two WMI methods (Approve and Deny). To use these WMI methods we need the following items

  • Request ID of the application request
  • The value Approve or Deny (depending on which way the approval will swing)
  • Any comments we want to attach to the approval

With this data we can simple execute the WMI method completing the application approval.

Let’s take the following example - you will see in this WMI data a pending request (Current State = 1) for Visio Viewer, with a Request ID of CC60EEB9-1C0E-4F31-850E-722EED690D20. I would like to Approve this request and thus will note down the RequestGuid.

Click Image for better view.

PowerShell -

The following PowerShell code will approve the request and add a description to the approval.

$APPAPR = Get-WmiObject -Class sms_userapplicationrequest -Filter 'requestguid = "CC60EEB9-1C0E-4F31-850E-722EED690D20"' -ComputerName "<Site Server>" -Namespace "root\sms\site_<site Code>"

if ($APPAPR)

{

     $rtn = $APPAPR.Approve('System Center PFE Approval through PowerShell');

}

You will see that we are loading an instance of the class, filtered on the RequestGuid, into the $APPAPR variable and then triggering the .Approve method. Provided to the method is the comments to be attached to the approval. After execution as we can see in the following screen shot, the state has changed to 4 or Approved (remember the state dictionary from above), and the Comments have changed to reflect the approval.

Click Image for better view.

On the client end if we open up the Application Catalog – My Application Requests, we can see again that the application has been approved. Additionally the application at this point should soon start the installation process.

If the intention was to deny the application the only change would be which method is called as seen below.

$APPAPR = Get-WmiObject -Class sms_userapplicationrequest -Filter 'requestguid = "CC60EEB9-1C0E-4F31-850E-722EED690D20"' -ComputerName "<Site Server>" -Namespace "root\sms\site_<site Code>"

if ($APPAPR)

{

     $rtn = $APPAPR.Deny('System Center PFE Approval through PowerShell');

}

Closing –

System Center 2012 Configuration Manager provides a robust targeting, self-service, and approval system. As seen in this post, we have the ability to programmatically interface with the approval system which establishes the foundation for a tailored/custom notification and approval experience. In this blog we have seen how to pull data about application requests from both SQL and WMI, and also how to differentiate between the different states of requests. We have then taken it step further and examined programmatically taking action against a request.

Stay tuned for the next post in this series in which I will show an example that includes everything discussed today while folding in some System Center Orchestrator Runbooks and a bit of ASP.NET. The blog will provide example of a full end to end automated notification and ‘out of console’ approval mechanism. I will include in this post more code examples and an export of the Runbooks. As stated earlier please click the Twitter follow button on this blog posting to subscribe to my Twitter feed which I keep updated with all System Center PFE blog activity.

Comments

  • Anonymous
    January 01, 2003
    thanks
  • Anonymous
    September 10, 2014
    Update: I have released an installed, configuration instruction, as well as source code for an application
  • Anonymous
    September 17, 2014
    Finally detail how to pragmatically approve - shouldn't it be programmatically?
  • Anonymous
    December 18, 2014
    if i was to automate the check for new requests and approve/deny process using Orchestrator, were a runbook will run the PS script every 5 min, how do i stop it from picking up old requests still in requested state without adding a new state to the CM DB table?
  • Anonymous
    June 05, 2015
    Hello, this is a nice post, however, is there an option to allow users to install an application in one computer after it is approved by the SCCM administrator?
  • Anonymous
    June 05, 2015
    To complete my post, I want user to be able to install an application in one computer after it is approved. My issue is that I want to deploy Visio and Project and I want user to be able to install them in their primary computer only one time. Now what happens is that they install the approved application to as many computers as they want. In the lab and can login to their colleagues computer and help them as well.
  • Anonymous
    July 06, 2015
    Sameer,
    what you could to that perform operation is to change your deployment type requirements and specify that the application can only be installed on the user primary device.
  • Anonymous
    August 17, 2015
    Thanks a lot for the wonderful post.