Application requests are a new feature in SCCM 2012. This allows administrators to deploy applications to a wider group of users, while still maintaining the correct number installs versus license amount. A user must go through the application catalog and request an application before it is available for install. When a user requests an application, the request shows up in the “Approval Request” section under the “Application Management” node. This article will focus on these requests, and how to generate an email alert when one is sent.
What do I need to know about Application Requests?
First, application requests can only be generated from user-deployed applications. They cannot be generated for packages or computer-deployed applications. This means that if you have packages in your current SCCM environment, they will all have to be converted into applications before using this feature.
Second, requesting approval for applications can only be done from the application catalog website, not from Software Center. You must have the roles for the application catalog website point and the application catalog web service point deployed and functional.
Third, there is no built in SCCM alert for application requests. This means that by default, you cannot set up an alert to notify you when an application has been requested – this where System Center Orchestrator (SCORCH) comes into the picture.
What do I need to know about System Center Orchestrator?
SCORCH is a datacenter automation tool. It can be used with the rest of the System Center suite to tie all of the System Center products together and make them function as one. It can also be used with other datacenter products, such as VMware or IBM, to make them work together and with System Center.
SCORCH requires some setup. It is completely scalable, and can run on one server or 100. Just like all System Center products, it uses a Microsoft SQL Server instance for its database. This database can put on the same server as your other System Center databases. It requires a server to run the runbook services, but the designer can be installed on a workstation.
SCORCH uses the concept of a “runbook” to perform its tasks. The administrator builds a runbook to perform the needed task. In the case of this article, we will be building a runbook that alerts the SCCM administrator when an application request has been made.
Requesting and approving the application
To request an application, log into the application catalog, find the application that you are requesting, and hit the request button; on an application that does not require approval, this button will say, “Install”. Once approval has been granted, the button will change from “Request” to “Install”.
Once the request is made, it will immediately show up in the SCCM console under the Software Library node, Application Management folder, then Approval Requests.
From here, the request can be approved by either right clicking the application request and selecting Approve, or select Approve from the ribbon. After the application is approved, it will begin automatically installing on the user’s computer after a few minutes. The user can elect to postpone this install if he/she chooses.
Creating the email alert
Now we need to use Orchestrator to set up the email alert. This is required because SCCM does not have a built-in method of generating an application request alert. Here is how this simple runbook looks. This is only one method for accomplishing this task. If you do a Google search for this topic, there are countless blog posts that have much more complex versions of this alert. This is just a simple method to get it going in under 30 minutes.
We first need to set up two global variables. These will be your SCCM site code, and primary site server FQDN. We do this by expanding the “Global Settings” node, and then Variables node of the left pane in Runbook Designer. I elected to store them in an “SCCM” folder, but you can store them however you want. Setting this global variables here can help you in the future when creating other runbooks associated with your SCCM environment.
The first thing in our runbook is the “Monitor Date/Time” step. This step allows you to set the runbook up to execute every X number of seconds, minutes, hours, or days. This activity is found under the “Scheduling” group.
Select “Monitor Date/Time” and drag it into your runbook. Double-click it to open it. Set it to whatever you think is an appropriate amount of time. I have mine set to 10 minutes. When it is set, click finish.
The next step is “Find App Requests”. This step uses PowerShell and performs a WMI query against your primary site server and pulls out any pending requests. If there are any requests, it stores the relevant information in variables, and then passes those variables to the next step. To add the script activity, go to the “System” group, select “Run .NET Script”, and drag it into your runbook.
Double-click it, select the General node, and give it a name. I elected to call mine “Find App Requests”. Select the “Details” node, change the script type to Powershell, and input the following code:
$a=@()
$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)
{
$a += $appr.RequestGuid
}
Delete {Site Code} and {Site Server}. Right click where they just where, and select “Subscribe”, then “Variable”. This is where we put in the variables that we established earlier.
The next thing we need to do is set up what data gets published to the next step. When this PowerShell command executes, it stores all of the data about the application request in the $app variable. We can use that stored data to populate variables for the next step. We will be creating 4 variables – the GUID of the request, the comment the user submitted with the request, the user who made the request, and the application name.
To store the variables, select the “Published Data” node. Here is a screen shot of what mine looks like:
To add a variable, press the “Add” button. You are presented with this screen:
Fill in the boxes according to these screenshots, pressing OK to say your changes.
Add another “Run .NET Script”, double-click it, select the “General” node, and give it a name. I elected to call mine “Process Each Request”. Select the “Details” node, change the type to PowerShell, and copy this code:
$app = Get-WmiObject -Class SMS_UserApplicationRequest -Namespace root/SMS/site_{Site Code} -ComputerName {Site Server} | where-object -FilterScript {$_.RequestGuid -eq “{Request GUID from “Find App Requests”}”}
foreach ($appr in $app) {$comment = $appr.Comments; $user = $appr.User; $appName = $appr.Application; $date = $appr.ConvertToDateTime($appr.LastModifiedDate)}
$today = get-date
$diffd = ($today – $date).days
$diffh = ($today – $date).hours
$diffm = ($today – $date).minutes
if ($diffd -lt 1 -and $diffh -lt 1 -and $diffm -lt 2)
{
$action = “Email”
}
Follow the same process listed above and replace {Site Code} and {Site Server} with their respective variables. Delete the {Request GUID from “Find App Requests”} text. Right click where it was, select “Subscribe” and then “Published Data”. Make sure the activity is set to “Find App Requests”. Select the “Request GUID” option, and then press OK.
This will correctly set up the variable.
The rest of the code for this step ensures that the runbook has not sent out an email for this request already.
Lastly for this activity, we must set up the published data. This step processes the comments, user, and application requested from the previous step. We will publish all of this data to the email step. Set up the “Published Data” node according to these screenshots:
The final variable (action) is used in the link between “Process Each Request” and “Send Email”. This is what triggers the email when there is a new request. After you draw the link, double-click the arrow to bring up the following window:
Click on “Process Each Request” change it to “action”, and press OK.
This changes the link to “action Process Each Request equals value”. Click on “value”, and set it to “Email”. This is the $a variable from the “Process Each Request” activity.
Finally, add the “Send Email” activity from the Email activity node. Double-click it to open. Most items here are pretty self-explanatory. In the message body, we can use the variables that we captured from the “Process Each Request” activity. Here is what I put in my message body:
DO NOT REPLY! Email from this account is not monitored.
For assistance, please submit a support request at: <website of support ticket system> .
An application has been requested.
Requestor: {User from “Process Each Request”}
Application: {Application from “Process Each Request”}
Requestor Comments: {Comment from “Process Each Request”}
As with before, replace the text in blue with variables using the same process as above. Other settings in the “Send Email” activity that need to be set are the “Connect” node and “Security” node. These are settings to connect to your mail servers to send the email.
Summary
This is only one way to do this. You can get as complicated or as simple as you want with a process like this. This is meant to be a starting point from which to expand on this service. This is also a good intro to Orchestrator, as you cover most of the basics in this guide.
