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

Prerequisites:

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

Configuration:

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. 
   3. Click Request on “Add ServiceNow Endpoint – SovLabs Modules”
   4. 
   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. 
   3. Click Request on “Add ServiceNow CMDB Endpoint – SovLabs Modules”
   4. 
   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

 

Links:

https://sovlabs.com/products/servicenow-cmdb/

http://docs.sovlabs.com/vRA7x/current.html#servicenow-cmdb

https://marketplace.vmware.com/vsx/solutions/vmware-vrealize-automation-plug-in-for-itsm-2-0-0