I’ve been working with vCAC 6.0 and wanted to blog about its power and some differences to its market counterparts. Citrix have a great product in Cloud Portal Business Manager, CPBM 2.x, and it has a nice look and feel. It is indeed very similar to vCAC 6.0 – they both have entitlements, you can easily manage access to resources via user and group assignments and you can add multiple endpoints, but there is one major difference between CPBM 2.x and vCAC 6.x – blueprints. Well, some might say blueprints are bundles, but there is functionality in vCAC 6.x that isn’t in CPBM 2.x. Blueprints are really just the beginning, for example you can create build profiles that get assigned to a blueprint that can, for example, run customisation scripts during the build process, i.e. use a company standard naming convention or run pre and post build scripts on the virtual machine you are provisioning. Here is a very good website that details the power of build scripts.
However, it doesn’t stop there. Using service blueprints and you begin to open up the power of vCAC. Service blueprints leverage vCO workflows. vCO, vCenter Orchestrator, provides a powerful Microsoft SSIS like workflow designer tool, which you can pretty much do anything with. VMware call this XaaS – anything as a service. From running a database backup, to connecting to a CMDB, running a multi VM provisioning workflow, creating objects in Active Directory or use one of many vCO plugins, for example configuring a f5 BIG IP device using the vCO f5 plugin.
Workflows can be quite complex, or you can use out of the box workflows. Once you have created your service blueprint, you can use entitlements which is a mechanism to allow end users to consume these blueprints.
Here is a quick look at how you can leverage vCO workflows using blue prints:
The above shows you a simple vCO workflow that creates an Active Directory organisational unit.
You can see here the the vCO workflow asks for 2 inputs – ouName and container. Now these would be user driven, but you could use a vCO workflow wrapper to get these values from an external source, i.e. a CMDB that determines the OU name using a site ID prefix.
Now you can get vCAC to provide this workflow as a catalogue item that a user can consume. You can see here that when you add a workflow in vCAC, you simply chose the vCO workflow that you want, in this case ‘Create an origanizational Unit’:
Once you have added the vCO workflow as a blueprint, you simply publish this for consumption:
Now the workflow is published, you just need to add the workflow to a catalogue and configure who can consume this by using entitlements:
Above you can see that you chose a service, in this case a pre-configured ‘generic’ service, and click on manage catalog items:
Then simply chose the new catalogue item, which is the vCO workflow that we discussed earlier. Once you have configured the catalogue item in a service, the users and groups that have been granted access to the services can then chose the new catalogue item from their service catalogues when they’re logged in to their vCAC portal, as shown below:
When the user requests the new catalogue item, they are prompted for the ouContainer and ouName:
Okay, I’ve skipped over a few of the more intricate configuration aspects, but you get the drift hopefully AND this is only a active directory container! (Yep, I too am thinking of a use case …). But, imagine the endless possibilities you can have, and I haven’t even mentioned vCloud Application Director! Wow… powerful stuff.
For information on vCO and vCAC, see these 2 great websites: