Self-Service Software Deployment - ServiceNow and System Center



Automate your self-service application catalog by integrating ServiceNow, System Center Configuration Manager, and System Center Orchestrator.

Videos



Runbook Viewer



Solution Guide


A certified, supported ServiceNow integration is now available for software deployment using Configuration Manager!

Learn more:

ServiceNow App: Software Deployment - ConfigMgr

 

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:

 

Solution architecture - Integrating ServiceNow and System Center
Solution architecture - Integrating ServiceNow and System Center

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”.

 

Configuration Manager application to be deployed through ServiceNow
Configuration Manager application to be deployed through ServiceNow

 

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:

 

Application access controlled by user collection based on AD group membership
Application access controlled by user collection based on AD group membership

 

User Collection group membership query rule
User Collection group membership query rule

 

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:

 

Configuration Manager automatically discovers group membership updates
Configuration Manager automatically discovers group membership updates

 

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.

 

Leveraging existing Configuration Manager application catalog feaure
Leveraging existing Configuration Manager application catalog feaure

 

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:

 

Active Directory group description matches ConfigMgr application name
Active Directory group description matches ConfigMgr application name

 

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.

 

Software Catalog item in ServiceNow for Configuration Manager application
Software Catalog item in ServiceNow for Configuration Manager application

 

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:

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

 

Creating ServiceNow account for Orchestrator access
Creating ServiceNow account for Orchestrator access

 

Granting Orchestrator account ServiceNow permissions
Granting Orchestrator account ServiceNow permissions

 

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

 

Find the Software Catalog table to customize
Find the Software Catalog table to customize

 

Create a new column in the table
Create a new column in the table

 

Configure the new column
Configure the new column

 

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

 

Show list to view the Software Catalog table items
Show list to view the Software Catalog table items

 

Create a new catalog item

 

Configure software item to match name of Configuration Manager application, and enable deployment checkbox
Configure software item to match name of Configuration Manager application, and enable deployment checkbox


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.

 

Create ServiceNow email template
Create ServiceNow email template

 

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.

 

Configure ServiceNow email notification for completed software requests
Configure ServiceNow email notification for completed software requests

 

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.

 

Configure Kelverion ServiceNow integration pack to connect to your instance
Configure Kelverion ServiceNow integration pack to connect to your 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

 

Configure collection membership rule to use group membership
Configure collection membership rule to use group membership

 

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.

 

Configuration Manager application deployed to corresponding user collection
Configuration Manager application deployed to corresponding user collection

 

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.

 

User's AD group memberships reflected in Configuration Manager object properties
User's AD group memberships reflected in Configuration Manager object properties

 

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.

 

Event is logged when ServiceNow connection fails from Orchestrator
Event is logged when ServiceNow connection fails from Orchestrator

 

Successful connection indicated by login record in ServiceNow
Successful connection indicated by login record 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:

 

Succesful Orchestrator runbook execution
Succesful Orchestrator runbook execution

 

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

 

Requestor has successfully been added to collection
Requestor has successfully been added to collection

 

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

 

Orchestrator has added execution details to request records
Orchestrator has added execution details to request records

 

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.

 

Application appears for installation, like magic.
Application appears for installation, like magic.

 

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.

ServiceNow + System Center = Easy


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.)


Join our growing list of automation-savvy IT Pros for regular brain upgrades:

Noah Stahl | About the Author

Noah specializes in IT automation, infrastructure and integration at Automys, where he has declared himself Prinicpal Architect and Founder.

Noah Stahl

Discuss