Request and manage vRealize Automation catalog items from ServiceNow

“We have ServiceNow and want to use its service management portal instead of vRA, is this possible?”  This question comes up a lot from our customers and often with a follow up questions “Can we wrap ServiceNow approval policies around it?” The answer is YES!

There are 2 ways to achieve this, the first is using VMware’s vRealize Automation plugin for ITSM which is available here.  The main premise of this plugin to expose the exact vRA services and catalog items directly within ServiceNow. This is good and all, but it does not provide a lot of flexibility and the application installation and configuration is complex.  Check out these blogs for additional information on v7.6.1 and v5.0.

The second solution, and what I will be using is SovLab’s ServiceNow connector module, which is very easy to implement and provides a lot of flexible by allowing ServiceNow administrators to customize the catalog and the request process directly within the ServiceNow platform.  It has the following highlighted features:

  • Multi-tenant & vRA instance support
  • Platform-native control for ServiceNow which means management and and customization is done directly within ServiceNow and also using ServiceNow constructs (catalog, workflow, etc.)
  • Day2 vRA operations support
  • Request as ServiceNow user automatically maps to corresponding vRA user, so also no requirement for SAML or ADFS!
  • SovLabs Template Engine support for metadata injection and custom logic, which is a huge plus
  • Can be coupled with the SovLabs CMDB Module, which is very useful and something everyone needs.

So lets start with the implementation prerequisites:

As a prerequisite you need a ServiceNow instance and a MID Server installed and configured. I assume this is already done so I will not provide steps here for this.

Some other SovLabs related prerequisites you need to take care of:

  • a ServiceNow instance with a MID Server installed and configured.
    • I assume this is already done so I will not provide steps here for this.
  • ServiceNow connector plugin software
    • SovLabs license key
  • For the ServiceNow tables: “question_choice”, “sc_cat_item” and “item_option_new” you have to set All Application Access for Can read, Can create, Can update, and Can delete
    • Go to System Definition > Tables > question_choice
    • Go to Application Access
    • For All application scopes, make sure Can read, Can create, Can update, and Can delete are checked
    • Repeat Step 2 and Step 3 for the other tables
  • The ServiceNow usernames needs to match their vRA username
    • Unless SovLabs ‘User Mapping’ is used, which you can read about here
    • I just setup the usernames in ServiceNow to match my domain username login for vRA.  “”
  • If you want to perform Day2 actions you have to install and configure the SovLabs ServiceNow CMDB module as well. Check out my blog on this.
  • Administrator credentials to vRO that also has entitlements to the Business Group/Catalog Items being Imported to ServiceNow

Continue reading

vRA & SovLabs: ServiceNow CMDB module

Having a centralize management database (CMDB) is crucial to provide insight into your environment especially with IT service management architectures becoming a lot more complex.  Some of the benefits of a CMDB are:

  • Increase control with asset management
  • Make systems more reliable by quickly identifying configuration drift like unplanned changes and improper configs that can cause performance issues
  • Maintain service levels through faster troubleshooting and identify key components, owners and dependencies

The CMDB contains valuable in-depth data about maintenance, repair histories, problems, changes, but this is all pretty much useless if the CMDB is not kept up to date and consistent.  There are many ways to achieve the necessary consistency, but the SovLabs ServiceNow CMDB modules for vRA provides a lot of additional benefits over something like auto-discovery with features which can viewed on the website here, but some of the highlights are:

  • Flexible mapping via JSON-based templates which can utilize dynamic or static values and vRA metadata, e.g. using vRA custom properties like business groups, catalog item owner, software installed,
  • Multiple operations permitted (insert/update/delete) on multiple related or independent tables using the direct to table method
  • CMDB configurations can be applied generically at the compute resource or business group level or more specifically at the blueprint level
  • Compatible with ServiceNow Discovery
  • Instantaneous CMDB inserts/updates occur during time of provisioning/de-provisioning/re-configure
  • Flexible de-provisioning/clean options
  • Supports import set or direct to table


  1. ServiceNow CMDB is properly configured
  2. ServiceNow CMDB service user account must have Web Service admin rights and rights to add/update/delete records
  3. If you are using VMware’s ITSM plug-in, set the “u_vra_uid” column to read/write from read only:
    1. In ServiceNow, navigate to System Definition
    2. Under Column name, search for u_vra_uid
    3. Click the cmdb_ci table from the results
    4. Uncheck Read only and Check Read/Write
    5. Click Update
  4. Login to the vRA tenant
    1. Add license for ServiceNow CMDB module
    2. Validate the following show up on the Catalog page:
      1. Add ServiceNow Endpoint
      2. Add ServiceNow CMDB


  1. Add DNS configuration
    • If you want the VIP host name to be automatically registered with DNS then you need to have the SovLabs DNS module installed and configured.  This was covered in my previous post which can be viewed here.
  2. Add ServiceNOW Endpoint

    1. Select Catalog -> SovLabs vRA Extensibility
    2. Screen Shot 2017-05-23 at 2.08.45 PM.png
    3. Click Request on “Add ServiceNow Endpoint – SovLabs Modules”
    4. Screen Shot 2017-05-23 at 2.10.00 PM.png
    5. ServiceNow Endpoint
    6. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
    7. Enter ServiceNow host URL
    8. Select Current ServiceNow version
    9. Credential Configuration
    10. Create credential = yes
    11. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
    12. Enter username and password
    13. Click Submit
  3.  Add ServiceNow CMDB Configuration
    1. Select Catalog -> SovLabs vRA Extensibility
    2. Screen Shot 2017-05-23 at 2.18.37 PM.png
    3. Click Request on “Add ServiceNow CMDB Endpoint – SovLabs Modules”
    4. Screen Shot 2017-05-23 at 2.18.46 PM.png
    5. ServiceNow CMDB Configuration
    6. Enter Configuration label
      • Only AlphaNumeric characters, no spaces or special characters except: - and _
    7. Select ServiceNow Endpoint previously created
    8. Use import set?
      • Selecting no will make of use import direct to table
    9. Select template name
      • I am using the default linux and windows templates provided by SovLabs so will be creating two separate CMDB configurations associated to each.
    10. Enter JSON template
      • This should be populate with the default template but additional information can be added within the template for instance the owner and the business group the owner belongs too.

Enable the module:

Now we need to enable the custom properties module on our blueprint

  1. Click on Design -> Blueprint
  2. Edit Blueprint
  3. Click on the blueprint vSphere machine on the Design Canvas.
  4. Click on properties tab
  5. In the properties group section click +Add
  6. Check the box for:
    • SovLabs-EnableLifecycleStubs
    • ServiceNow CMDB property group (starts with SovLabs-SnowCMDB-)
  7. Do not attach more than 1 ServiceNow CMDB property group to a blueprint
  8. Click OK
  9. Repeat these steps for all blueprints that should use this custom naming.


SovLabs ServiceNOW CMDB module     VS    VMware’s vRA plugin for ITSM:

VMware’s vRA plugin for ITSM provides a way to expose vRA’s Catalog items to ServiceNOW for machine provisioning with an approval process workflow that run in SNOW instead of vRA.

SovLabs CMDB module will automatically update the SNOW CMDB with the valuable information obtained from vRA after a Catalog Item request and successful deployment, either direct to table or through import sets.

Here are some limitations for each of the solutions that I think everyone needs to take into consideration.

VMware’s  vRA plugin for ITSM feature limitation: (base on my v1 experience)

  1. Only community supported!
  2. Only ADFS 2.0 is supported for authentication.
    Note: ADFS 2.0 comes with Windows 2008 R2 where as ADFS 3.0 comes with Windows 2012 R2. ADFS 2.0 is single point of failure.  ADFS 3.0 supports farms with primary and secondary servers.

    • Email address must match in both SNOW and the AD connection used by ADFS
  3. Custom properties of the following types are not supported- slider, spinner, yes/no, hyperlink, and SecureString as well as any properties using external values from vRealize Orchestrator.
    • Encrypted vRA custom properties not supported
  4. Only the vSphere.local tenant is supported (this might be fixed in v2 which I have not yet had a chance to test)
  5. Requesting XaaS blueprints or composite blueprints that contain dynamic form inputs from vRealize Orchestrator is not supported.
  6. Requesting machines from AWS or Azure or any other non-vCenter endpoint not supported.
  7. Resource mapping only on the vSphere virtual vRA inventory type which is limiting if you have OS-level CIs defined.
  8. Once configured, newly provisioned resources are imported into a new CMDB class while existing resources are available in the old CMDB class and would have to be imported into new.

SovLabs ServiceNOW CMDB module limitations:

  1. VM re-configure (should be available soon)
  2. Resource mappings for resources other than for machines except where they can be derived via machine properties