Solution Guide
A certified, supported ServiceNow integration is now available for software deployment using Configuration Manager!
Learn more:
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 thebiggest 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:
- User browses to ServiceNow instance with web browser.
- User locates application to install and “orders” it, generating a request record and a related requested item record that defines the application.
- 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.
- 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.
- Orchestrator invokes a runbook to add the requesting user to the group which grants access to the application.
- Orchestrator invokes a runbook to watch for the new group membership change to be discovered by Configuration Manager.
- 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.
- 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.
- 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:
- From the Administration area list, navigate or search to System Definition > Tables
- Use the Label search to find the “Software Catalog” entry
- Click the Software Catalog label link to open table definition
- Scroll to the columns section and click New
- 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”.
- 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
\ . - 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.
Runbook Details
Add User to Application AD Group
Adds a specified user to an Active Directory group which defines access to a specified application. To determine the right group, the AD group description field must contain the exact name of the Configuration Manager application. The group itself can have any name desired. If the user is already a member of the group, runbook considers that successful and will not attempt to re-add. The runbook returns a success value and the Active Directory name for the matched group.
Inputs
| Parameter | Type |
|---|---|
| Active Directory Username | String |
| Application Name | String |
| Log Correlation ID | String |
Outputs
| Returned Data | Type | Description |
|---|---|---|
| Group Name | String | Name of AD group corresponding to specified application name |
| Succeeded | Boolean | True if successful |
Generate Log ID
Generates a unique log correlation ID based on timestamp and discriminator string if one is provided, otherwise a random GUID is used. This ID should be used whenever adding log records so that a trace log can be constructed for all log entries with a given correlation ID.
Inputs
| Parameter | Type |
|---|---|
| Discriminator | String |
Outputs
| Returned Data | Type | Description |
|---|---|---|
| ID | String | |
| Succeeded | Boolean | true if successful |
Get CM Group Membership Status
Given an Active Directory user and group, this runbook checks to see whether the user is reflected as a member of the group within System Center Configuration Manager. The membership is recorded only after the Configuration Manager discovery process runs and syncs the user and group properties from Active Directory. By running this runbook in a loop, it provides a way to watch for the discovery process to complete.
Inputs
| Parameter | Type |
|---|---|
| Active Directory Group Name | String |
| Active Directory Username | String |
| Log Correlation ID | String |
Outputs
| Returned Data | Type | Description |
|---|---|---|
| Is Member | Boolean | True if specified user is member of group in ConfigMgr |
| Succeeded | Boolean | True if successful |
Get Trace Log
Queries Orchestrator logs for all event records with a specified correlation ID. All matching entries are then returned as a single block of delimited text. This amounts to a trace log of a series of runbooks that all use the same correlation ID to create log entries.
Inputs
| Parameter | Type |
|---|---|
| Line Break Character | String |
| Log Correlation ID | String |
| Orchestrator Database Name | String |
| Orchestrator Database Server | String |
Outputs
| Returned Data | Type | Description |
|---|---|---|
| Log Trace Text | String | Combined event log entries matching supplied correlation ID |
| Succeeded | Boolean | True if successful |
Process ServiceNow Software Requests
Processes software catalog requests from ServiceNow. Should be run continuously, and monitors the "Requested Items" table in ServiceNow for new items. When a new item is discovered, will retrieve the associated Request and Software Catalog item, mark the request as "Work In Progress", and then orchestrate the fulfillment of the software. Fulfillment is done through an integration with System Center Configuration Manager, which is assumed to have collections for each application which derive their membership from a corresponding Active Directory group. This runbook calls child runbooks that add the requestor to the AD group, and then confirm that membership is reflected in Configuration Manager, such that the software will become available via the Configuration Manager Application Catalog for installation. Upon confirmation, marks the request and requested item as completed, so that the user can be notified to install the newly-available software. In the event of a failure, collects any errors in a trace log and records into the ServiceNow request for later troubleshooting, and then marks the request as incomplete to flag additional service desk support intervention.
Inputs
(No input parameters defined.)
Outputs
(This runbook does not return anything apart from common published data.)
Update Application Deployment Collection Membership
Triggers the collection membership update of a given Configuration Manager collection, and verifies that the specified user is found to be a member after the update completes.
Inputs
| Parameter | Type |
|---|---|
| Collection Name | String |
| Log Correlation ID | String |
| Member Active Directory Username | String |
Outputs
| Returned Data | Type | Description |
|---|---|---|
| Is Member | Boolean | True if specified user is member of updated collection |
| Succeeded | Boolean | True if successful |
Global Settings
Variables
The following global variables are referenced in one or more runbooks:
| Variable | Description | Example Value |
|---|---|---|
| Orchestrator Database Server | The name of the SQL server hosting the Orchestrator database. | SQL1 |
| Orchestrator Database Name | The name of the Orchestrator database. | Orchestrator |
(No counters were used.)
(No schedules were used.)
(No computer groups were used.)
Courtesy : https://automys.com/library/asset/self-service-software-deployment-servicenow-system-center
This information is really awesome thanks for sharing most valuable information.
ReplyDeleteServiceNow Training in Hyderabad
ServiceNow Training in Ameerpet
ServiceNow Training
ServiceNow Online Training
Thanks for sharing the awesome and most beautiful
ReplyDeleteFull Stack Training in Chennai | Certification | Online Training Course | Full Stack Training in Bangalore | Certification | Online Training Course | Full Stack Training in Hyderabad | Certification | Online Training Course | Full Stack Training in Pune | Certification | Online Training Course | Full Stack Training | Certification | Full Stack Online Training Course
Thanks for sharing valuable information and very well explained. Keep posting.
ReplyDeleteservicenow certification
learn servicenow online
ReplyDeleteIt is amazing to visit your site. Thanks for sharing this information, this is useful to me...
Servicenow Online Training
Servicenow Online Training in Hyderabad
Servicenow Developer Training
Servicenow Training in Ameerpet
Servicenow Course Online
Best Servicenow Online Training
Servicenow Developer Training Online
Servicenow Admin Training Online
Learn Servicenow Online
Servicenow Developer Online Training
Nice article,
ReplyDeleteThank syou for sharing this awesome blog with us.
Keep updating..
Servicenow course
Servicenow online training in india
Servicenow now learn