Self-Service Software Deployment - ServiceNow and System Center

Solution Guide

 

What It Does

This example shows how to provide self-service, automated software deployment through an integration of ServiceNow and System Center Configuration Manager. Users can find software applications that are made available to them in their ServiceNow self-service software catalog and then quickly “order” them for automated fulfillment. Shortly after the request is submitted and optionally approved, the user receives an email notification with a link to install the application on their PC using the simplified installation experience provided by Configuration Manager’s Application Catalog.

This process can be completed in a matter of minutes with no requirement for human administration. Pretty awesome, right?

Why Do This?

In the old days (a.k.a today in many organizations), the standard way for a user to get new software was to open a file share containing the installers for the desired application, and then either install themselves or with IT assistance. But in the age of app stores, this is rightfully seen as awkward and inefficient. How and where to get software shouldn’t be a mystery or a bottleneck to getting work done. The rise of “shadow IT” has been partially in response to this legacy situation.

There are important business reasons to provide users in the enterprise with an equivalent “app store” experience:

• Speed: Allow users to quickly locate what they need

• Self-service, on-demand: Allow users to get the software installed when possible without the delay of requiring admin assistance

• Control license costs: You pay a lot for your software, and without a managed way to deliver it, license violations and waste is inevitable. A simple approval process to make sure licenses are intelligently deployed can result in big savings.

• Security: Failure to provide software in a timely fashion means users will figure out a workaround to get what they need, and this often means pressure on IT to allow privileges for arbitrary software installation on company devices, which means admin rights, which means opening the biggest vulnerability possible to malware. By limiting user privilege while simultaneously providing the software they need from your own vetted, secure library, you dramatically decrease risk of security breaches.

• Accurate historical records: Do you know what your most popular software is? Who uses it? How many copies are installed? How long it takes to deliver from the time requested? These and other questions can only be answered with data that is maintained through a managed service request process. ServiceNow and other service management platforms provide this advantage.

 It’s clear that an application catalog brings many benefits. The question remains: how best to implement it? This example reflects a couple assumptions:

• Leveraging your existing investments and best-in-class systems is better than trying to do everything with one system. For example, there is a basic request approval feature included in Configuration Manager – but it doesn’t integrate with the rest of your business processes. ServiceNow, on the other hand, is purpose-built for service management, and if it’s your business process platform, it makes sense to use it wherever possible. Configuration Manager is the premier platform for software delivery, while ServiceNow doesn’t do that. Integration gets us the strengths of both.

• Automation is key. Imagine if mobile app stores let you click a button to install an app, but then informed you to wait 1-2 business days for a callback from technical support? That’s not cool. And it shouldn’t happen at work either.

How it Works

Assuming you’re convinced such a thing is worthwhile, let’s look at how it works.

Note: this is one way to go about putting together this kind of solution. But it certainly isn’t the only way. You’d likely want to add some additional bells and whistles for a production-worthy implementation. This is offered as a starting point.

Architecture

This solution involves the following components:

• ServiceNow instance: the individual instance of ServiceNow in the cloud for a given organization, identified by a URL, e.g. “https://mycompany.service-now.com”

• System Center Configuration Manager: responsible for application delivery. Applications and Packages are deployed to a collection of users or devices, which can access and install them through the internal Application Catalog website.

• System Center Orchestrator: does the work of integrating ServiceNow with Configuration Manager. Executes runbooks that automate the process of turning a request into an available application for the end user.

• Active Directory: users and groups form the basis of managing access to applications.

We’ll look at each of these in more detail below. Here’s a diagram showing the relationships with some detail:

 

High-Level Process

What exactly happens for all this to produce our desired outcome? At a high level, it consists of the following:

1. User browses to ServiceNow instance with web browser.

2. User locates application to install and “orders” it, generating a request record and a related requested item record that defines the application.

3. System Center Orchestrator runbook executes continually, periodically accessing ServiceNow to query for new requested items that have been approved for fulfillment, and which have been marked as deployable from System Center Configuration Manager.

4. Orchestrator updates the request to a “work in progress” state, and takes note of the user who created the request, and the name of the application he/she has requested.

5. Orchestrator invokes a runbook to add the requesting user to the group which grants access to the application.

6. Orchestrator invokes a runbook to watch for the new group membership change to be discovered by Configuration Manager.

7. When discovery is confirmed, Orchestrator invokes a runbook to trigger a membership update on the collection that controls access to the requested application, and then confirms update is successful.

8. If everything worked, Orchestrator marks the request and requested item in ServiceNow as complete, which triggers the notification to the user to install the app.

9. If something went wrong, Orchestrator marks the request as incomplete in ServiceNow with any available trace log and error information it has, which can trigger notification to an administrator to intervene.

If you think about it, the only substantive action performed by Orchestrator here is adding the user to a group in Active Directory. The rest of the functionality is really handled by native capabilities of Configuration Manager and ServiceNow, with Orchestrator doing some hand-holding to make sure everything gets set up correctly for the user. People like to say “it’s the small things that count”, and this is certainly true of automation, where a lot of the work is in making things work together smoothly and reliably.

Configuration Manager

Applications

We’ll start with the software, which is in the form of applications or packages defined in Configuration Manager. We’re using applications in the normal way, nothing unusual or unique about their creation or management. What we are doing differently is orchestrating their availability to users based on external requests.

We start with the application, for instance, Adobe Reader. This is what we want to make available in the self-service catalog. To do this, the application must have a deployment targeting a user collection, which determines the users allowed to install it. In this case, we have a collection called “Adobe Reader Users”, and a deployment to this collection for the application “Adobe Reader XI”.

 

 

The names are important, because we use these for some references that help link each of the components together so they all understand how to talk about the same application.

Collections

The collection in this case should be a user collection that derives its membership from an Active Directory group. This way, whichever Active Directory users are added to the AD group will become members of the collection. Why do this? You could add users to a collection directly, but using AD group membership is good for transparency and manageability: anyone in the organization can easily look to see what users have access to Adobe Reader simply by viewing the group membership. You could also get fancy and use this as a distribution group to email these users in particular, for example when a security exploit is found that requires an immediate update to this specific app – better than blasting the entire company.

Here’s our example user collection configured with membership based on an Active Directory group membership query:

 

 

 

For simplicity, we adopt the convention here that the collection name matches the group name. Orchestrator then uses this assumption when working with the collection. Note also the enabled option to “Use incremental updates for this collection”, which allows membership changes to be picked up quickly by Configuration Manager.

Discovery

Collection queries like this require that both Active Directory User/Group discovery be enabled. For group discovery, the following configuration allows group membership changes to be synched as soon as possible after they occur:

 

 

Application Catalog

Finally, we’re assuming that the Application Catalog website is enabled and configured for the Configuration Manager site server. This is what we provide a link to for the user to get immediate access to the application once approved and access is granted.

 

 

Active Directory

As mentioned above, we’re using Active Directory here to manage access to applications via group membership. There’s nothing at all complicated for this to work in our example, as long as these are true:

• The AD group name matches the Configuration Manager collection name

• The AD group description contains exactly the Configuration Manager application name

• The ServiceNow user ID matches the AD username

ServiceNow is typically integrated with AD to sync the user accounts, so the third is normally true and only needs to be considered for dev environments with manually-created accounts.

The second is done as a way to use a friendly name for the group not tied to version. So “Adobe Reader Users” can grant access to “Adobe Reader XI” today, and “Adobe Acrobat Reader DC 2015.007.20033” in the future without changing the group or collection names. An example:

 

 

ServiceNow

The self-service portal that holds our software catalog in this example is provided by ServiceNow. As alluded to above, the idea behind using a platform like ServiceNow as a front-end for an application catalog is that this approach makes application delivery an integrated part of the overall service delivery and business management environment. It allows users to get software in the natural place they would look for it: where they request everything else. And the built-in workflows, business rules, and other service automation features of ServiceNow provide an excellent complement to the other components of the infrastructure. It’s especially useful to look at this example as a way “the cloud” can be seamlessly connected to on-premises infrastructure in a way that is transparent and unifying from a user’s perspective. This is in contrast to the possible perception that mixing cloud and on-premises infrastructure means more fragmentation, stovepipes, and confusion.

As with Configuration Manager, there’s not much customization required to light up this scenario. You could, of course, do a lot more, but getting started is pretty straightforward. Out of the box, ServiceNow provides a service catalog with various categories including software. A catalog is made up of items – for software, each application would be a catalog item. When “ordered” through the self-service catalog from a user’s homepage in their portal view, a new request is generated with their chosen application as a linked “requested item”. This application is what we deliver through Configuration Manager.

You might next ask: if Configuration Manager has an application catalog, and ServiceNow has an application catalog, doesn’t this mean we now have two catalogs? A valid question, and the answer is yes, this could be slightly confusing, but is done only for demo purposes. You could orchestrate the application deployment directly to the user’s PC without their needing to open the Configuration Manager application catalog to click “Install”. But this would require more work to make happen quickly, whereas it is relatively simple for the app to appear immediately in the application catalog website and give the user a simple URL for access.

How then does ServiceNow know about the applications that Configuration Manager can deploy? This is also something done manually for simplicity of the example, but in a production scenario you’d certainly want to implement a runbook or other process that performed a discovery to automate the population of ServiceNow applications from Configuration Manager. (Perhaps a future example?). For our purposes, we just create matching software items in ServiceNow for the Configuration Manager applications we want to make available by request.

To differentiate these deployable applications from other types of software items in the catalog, we extend the software catalog table with a simple true/false property, “Deploy From System Center Configuration Manager”. Checking this box indicates this software should be processed in our runbooks, while leaving unchecked means it should be ignored for automated fulfillment. Finally, we use the convention that the “Product ID” field matches the corresponding Configuration Manager application name. Everything else about the ServiceNow item can be used as normal.

 

 

Role Breakout

We’re also leveraging ServiceNow to provide other features, including the approval and notification engines. It might get confusing about who does what, since there is some potential overlap. Here’s a breakout of responsibilities that might help:

Task	Component	Description
Software Catalog UI	ServiceNow	Self-service software catalog allows finding and requesting new applications through web portal
Application Installation UI	Configuration Manager	Application Catalog website provides installable item once request is processed
Approvals	ServiceNow	Based on internal workflow/policy definitions, approvals will be facilitated or automatically granted, and recorded
Notifications	ServiceNow	Email notifications based on request state changes automatically sent using predefined templates
Request fulfillment workflow	Orchestrator	Takes a request from approval until closed, performs backend tasks to make app available
Application Access Control	Configuration Manager	Collections determine access, with membership derived from AD groups
Application Access Changes	Orchestrator	Runbook makes group membership changes that form basis of application access

 

System Center Orchestrator

Finally, the glue that holds the other components together: Orchestrator. The Orchestrator runbooks perform the tasks that translate a requested software item in ServiceNow into an installable item on the user’s desktop. It does this by manipulating each of the other components through integration packs: ServiceNow, Configuration Manager and Active Directory.

There are several runbooks that work together, coordinated by a primary runbook, “Process ServiceNow Software Requests”. This runbook watches for new requested items, and when it sees them, proceeds to process each by reading and updating the ServiceNow records involved, updating Active Directory, and validating the automatic discovery done by Configuration Manager to update its collection accordingly. Finally it updates the ServiceNow records with the result, which triggers any further workflows, including notifications like the one that provides the user with directions and an installation link. More information about each runbook is provided later. You can also explore each of the runbooks and activities using the runbook viewer above.

ServiceNow Integration

To connect to ServiceNow from Orchestrator we use the excellent Integration Pack for ServiceNow from Kelverion. This integration pack makes it very quick and simple to connect to our ServiceNow instance over a secure web connection and then to monitor, read, and update the records related to software requests (or any record in general). It allows working with all tables and their standard properties, and also custom properties like the one we added to mark software as deployable from Configuration Manager.

Configuration Manager Integration

Orchestrator works with Configuration Manager through the SC 2012 Configuration Manager integration pack from Microsoft. This involves issuing queries to the Configuration Manager database through the “Query ConfigMgr” activity, and working with collections.

Active Directory Integration

The standard Active Directory integration pack is used to read and update group membership to provide a user access to their requested application.

Implementing In Your Environment

To get this working in your environment, start by download the solution files using the button at the top of the page. Then, proceed.

Prerequisites

Make sure you’ve got the following ready in a lab environment before jumping in:

• System Center Configuration Manager 2012

  • 2012 R2 release with latest update rollup recommended

  • Application Catalog website and web service roles enabled and configured

  • A test application created and ready for deployment

• System Center Orchestrator 2012 R2, with following integration packs installed

  • Active Directory (download link)

  • SC 2012 Configuration Manager (download link)

  • Integration Pack for ServiceNow from Kelverion (free trial available)

• ServiceNow dev/test instance

  • Dev instances can be obtained at no cost through the ServiceNow Developer program

Configure ServiceNow

We need to add a few things in ServiceNow to get it ready for use.

Orchestrator User Account

Within ServiceNow, set up a user account for Orchestrator to use when connecting. This is done under the Users administration area. For testing purposes I gave my user the admin role, although this would be limited in a production scenario.

• The User ID will be used in the Orchestrator configuration

• Set the time zone to match that of the runbook server

 

 

 

Kelverion Integration Setup

Follow the User Guide provided with the Integration Pack for ServiceNow to configure ServiceNow as documented. In particular, this involves modifying a setting the System Properties > Web Services area. See the User Guide document included with the Kelverion download for details.

Customizing the Software Catalog Table

To add our fancy “Deploy from System Center Configuration Manager” checkbox:

1. From the Administration area list, navigate or search to System Definition > Tables

2. Use the Label search to find the “Software Catalog” entry

3. Click the Software Catalog label link to open table definition

4. Scroll to the columns section and click New

5. Create a new True/False entry with the exact label “Deploy From System Center Configuration Manager”. The automatically generated name should be “u_deploy_from_system_center_configuration_manager”.

6. Click Submit to save

 

 

 

 

Create a Software Catalog Item

Still in the Software Catalog table definition, scroll down and find a link for “Show List” under Related Links. Opening this, we’re able to create a new software item to represent our application in ServiceNow. When creating, note the following:

• Name can be any display value

• Product ID must match the application name in Configuration Manager

• Check the box for “Deploy from System Center Configuration Manager”

• Set the Catalogs, Category, and Workflow as shown

• Set a price as desired to test approval triggering, depending on workflows in your ServiceNow instance. By default, requests above $1000 are routed for approval, while those below are automatically approved.

• When finished, Submit the new record

 

 

 

The new item should now appear as available for ordering through the self-service software catalog.

Notifications

Finally, we want to email instructions with a link to the user to open the Configuration Manager application catalog when the request is completed. This can be done using the email templates and notifications in ServiceNow.

First, create a new email template within System Policy > Email > Templates. In the Message HTML field, include whatever content you like, including dynamic content from the software catalog item or request, and a link with the URL to the Configuration Manager application catalog website. We reference the “Requested Item” table to get data from the requested item record that triggers the notification.

 

 

Next, we’ll need an Email Notification configured to send this template when a software request is completed. You can create a new notification from the “Related Links” section at the bottom of the new template view page.

Create as follows:

• Table: same as that selected for the template (“Requested Item”)

• When to send: “State” is “Closed Complete”, or whatever criteria defines a completion for you

• Who will receive: under Users/Groups in fields, add “Request.Requested for”. This sends to whichever user opened the parent request.

• What it will contain: select the email template just created. Can leave remaining fields empty, since they will be filled in from the template during send.

 

 

This should be everything we need on the ServiceNow setup.

Import Orchestrator Runbooks

After the required integration packs are installed, import the runbooks from the provided export file.

Once the runbooks are imported, you’ll need to configure the integrations through the global configurations in Runbook Designer. Configure each of the integration packs listed above from the Options menu, which will enable Orchestrator to access ServiceNow, Configuration Manager, and Active Directory. Also update the variables in the example folder under Global Settings > Variables.

When configuring the ServiceNow connection, provide the User ID for the ServiceNow account you created, and the URL to the instance.

 

 

Active Directory

As previously discussed, we need an Active Directory group to define access to each application.  Create one for your test application:

• Name is any display value

• Description contains the exact name of the Configuration Manager application

Configuration Manager

Now we need a matching User Collection in Configuration Manager for targeting application deployment to users. Configure as follows:

• Collection name should match Active Directory group name

• In the Membership Rules tab, add a query rule based on AD group membership. The query should have a criteria entry to match users where the “User Group Name” is equal to the name of the group you created, in the format <DOMAIN>\<AD Group Name>.

• Enable incremental updates for the collection to ensure membership changes are discovered quickly

 

 

With the collection in place, we can deploy our application to it. You can use standard settings, e.g. with action “Install” and purpose “Available”. No need to check the box for “require administrator approval” here – that’s what ServiceNow is for. As always, make sure the application is distributed to one or more distribution points.

 

 

Finally, you may want to adjust the discovery interval to get the fastest possible AD change updates. This is configured under Administration > Hierarchy Configuration > Discovery Methods, in the Active Directory User Discovery and Active Directory Group Discovery items. You can enable and configure the “Delta discovery interval” to as few as 5 minutes here.

That should wrap up all the setup steps. Now on to the fun stuff: testing.

Testing the Example

Before doing a full end-to-end test run, start by making sure everything is ready in ServiceNow and Configuration Manager.

Configuration Manager

Start by testing the group discovery. Select a test user and add as a member to the AD group for the target application. Then wait for the incremental update to happen, by default every 15 minutes. When complete, the user’s “User Group Name” property should include the application group name. If so, you should be able to trigger an update of the application collection membership and see the user appear in the collection.

Once this test works, you can remove the user from the AD group and repeat to revert for the actual test.

 

 

ServiceNow

Within ServiceNow, make sure the request can be created and that notifications work.

• As the test user (which has a user ID matching the AD username and email address configured), go to the self-service software page in ServiceNow and order the test application. This should trigger the initial notifications.

• Approve the request if needed and check the resulting notification

• Open the Requested Item record for the request and set the state to “Closed Complete”. Verify the “your software is ready” notification is sent.

• Delete the test request

Orchestrator

In Runbook Designer, start the runbook “Process ServiceNow Software Requests”. This will run continually. After a few moments, check the Orchestrator event log to see if any errors are logged indicating a login problem. If successfully connected, you should also see your Orchestrator ServiceNow account listed in the “Logged in Users” administration view in ServiceNow.

 

 

 

Full Test

If all is working so far, you’re ready to try a full test. With the Orchestrator runbook “Process ServiceNow Software Requests” running, submit a new order from the ServiceNow software catalog as the test user. After optionally completing the approval, you should soon see Orchestrator begin a new runbook execution to process the request (as second running entry in the Logs tab). When complete, review the log history of the runbook. Opening the last execution provides details of the result of each activity. A successful execution looks like this:

 

 

In the Configuration Manager console, we should see the user now appear as a member in the correct user collection for the application.

 

 

Back in ServiceNow, review the state and work notes of the Requested Item and request to verify success.

 

 

At this point, the user should have received an email notification and be able to open the Configuration Manager application catalog website to install their application.

 

 

That’s it. Easy, right?

Getting Help

If you get a chance to work with this example, feel free to get in touch with questions, problems or feedback, either in the comments below or directly.

Discuss