VMware vRealize Automation Part 7 – Tenant Administrator & Basic Blueprints

Now that we’ve got all the system-wide roles (System / Infrastructure & Fabric Admin) fully configured and each user has done their configuration tasks, next in the to-do-list is the configuration items to be performed by the Tenant Administrator. We wont be looking at everything a Tenant Admin can do here, but only focus on key items relating to blueprints.

First of all, lets briefly look at the Tenant Administrator role (note that the System Administrator assigned the Tenant Administrator role during a previous stage mentioned here)

Tenant Administrator is a key user that is typically a business manager or an IT administrator who is responsible for a tenant who configure vRA according to the needs of the company. He / She is responsible for the followings primarily,

• Manages and configures the tenant
• Manages the users and groups (within the tenant)
• Manages catalog services
• Creates approval policies & entitlements
• Manage tenant brandings
• Manage business groups within the tenant
• Tracking resource usage by all tenant users
• Create & manage global (shared) blueprints

Key Tenant Admin tasks

1. Tenant Configuration Tasks
   1. Configure Identity Stores – This should have already been done at an earlier stage by the System Admin
   2. Configure custom groups
      1. Configure Custom groups (approval Administrator / Release Dashboard user / Release engineer / Release manager & Service architect roles
         and map them to AD users / groups  
   3. Configure Identity store users such as business group admins, business group users and support users and configure additional privileges to these users (Administration->Users&Groups->Identity Store Users & Groups)
   4. Configure Tenant branding if this is required (Administration->Branding)
   5. Configure notification providers such as email servers to be used within the Tenant for the approval notifications via Administration->Notification->Email servers (I’m not doing this here)
   6. Create Business groups (We’ve already created a business group earlier as Tenant Admin user)
2. Create & Publish IaaS blueprints
   1. Create an IaaS blueprint
      1. Notes:
         1. We’ll create a simple VM provisioning blueprint here using a CentOS 6.6 template & a customization specification (both need to have been pre-created and be registered in the compute / production cluster vCenter server)
         2. We will be using a basic cloning as the provisioning method (linked cloning and NetApp FlexClone options are also available)
      2. Go to Infrastructure->Blueprints and use new blueprint button to create a new virtual vSphere blueprint and fill out the basic Blueprint information
      3. Go to the build information tab and select the appropriate options (as below)
         1. You can use custom properties to achieve various functions. A full list of available all custom properties are available here and a list of specific custom properties applicable for a cloning blueprint (similar to what we are creating here) are available here.
         2. Some key, useful custom properties are as follows
            1.  Snapshot.Policy.Limit = <Depth of Snapshot limit. Default is 1, max is 31>
            2. Snapshot.Policy.AgeLimit = <Snapshot age limit in days. Default is no limit>
            3. VirtualMachine.Admin.ThinProvision = True/False (Applicable for VMware & Hyper-V using local or iSCSI storage)
            4. VMware.VirtualCenter.Folder = <Folder to place the VMs within vCenter>
            5. VirtualMachine.Admin.Owner=
            6. VirtualMachine.Admin.AddOwnerToAdmins=True
            7. VirtualMachine.Admin.AllowLogin=True
            8. VirtualMachine.Network0.Address=<IP address for Network 0>
            9. VirtualMachine.NetworkN.MacAddressType=generated/static
            10. VirtualMachine.NetworkN.MacAddress=<MAC Address>
            11. VirtualMachine.NetworkN.Name=<VMNetworkName>
            12. Machine.SSH=True
      4. We will cover the Build profiles and custom properties section separately
      5. Select the Actions that would be made available within the Blueprint definition (so they’d be available as entitlement actions to assigned users)  
      6. Now we have the first basic blueprint definition created successfully.
   2. Publish the IaaS blueprint
      1. Hover the mouse over the created blueprint and select publish & click Ok to confirm.
   3. Create a service
      1. In order for a published blueprint to be made available on a catalog to the users, a service need to be created and the blueprint must be associated with that service
      2. Go to Administration->Catalog management -> Services and add a new service, populate the information required and add.  
      3. Associate the blueprint with the service by selecting the service created and click on “manage catalog items”
      4. Add a catalog item and select the previously created blueprint
   4. You can create approval policies if required next(Administration->Approval Policies). I’m opting to not create approval policies and instead opt for no approvals.
   5. Create Entitlements
      1. Once a blueprint is created, and has been associated within a service, it (the service) need to be given entitlements. In other words, the service needs to be mapped to a user / group to be given access so that they can request a VM to be provisioned from this service / blueprint.
      2. Go to Administration->Catalog management->Entitlements and add a new entitlement. Provide a name for the entitlement (note: To avoid confusion, if the relationship between a blueprint:service:entilement is a 1:1:1, I keep the name identical for all 3 to keep thins simple and related) and select the AD groups / users that this blueprint / service is made available for within the online catalog. Click next
      3. Add the entitled services (created above), Catalog item (blueprint created above) and the appropriate entitled actions.
         1. Note: if the VM actions are not fully populated within the entitlements section, on the IaaS server host, navigate to “C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Café” folder from command line and run “Vcac-Config.exe” registercatalogtypes –v”
      4. Once added, the entitlements are complete
3. User request through the catalog
   1. All tasks required to make the blueprint listed on an IaaS catalog are now complete and the entitled users can now request a machine provisioning based on this blueprint through the portal
   2. Login to the vRA portal (URL “https://<FQDN of the vRA Appliance>/shell-ui-app” if using the default tenant) using the appropriate business group user (bg-user in our example based on the entitlements we set above) and you’ll see the CentOS 6.6 server is now available in the users catalog.    
   3. Request a VM to be provisioned off of this catalog item.   
   4. All submitted requests can be tracked within the requests tab.
   5. You can see the cloning task initiated by the vRA service account within vSphere client / web client. Note that there may be a slight delay before this is executed on the vCenter after being submitted via vRA. Note that the default custom properties set for the business group (explained in the previous post of this series) dictated where the VM is created within the vCenter folder hierarchy & the name of the VM is automatically based on the default machine prefix attached to the business group (also created earlier)
   6. Once successfully created, the item will appear under the “Items” tab within the vRA IaaS portal for the user to access based on the entitled actions previously defined.   

That’s basically it. This effectively now concludes the basic deployment tasks I’ve intended to cover as the typical deployment & configuration tasks you’d have to do in the field to deploy vRA 6.2.1 along with vRO 6.0.1 and NSX 6.1.x all fully integrated for extensibility. Hopefully this series of posts gave you a summarized view of all the initial tasks that you’d need to do, in the exact order they need to be done, including any undocumented little quarks I’ve come across that potentially could have cost you some troubleshooting time in the field. Hope this was of use to some. I know I will refer back to this in the future for my own benefit.

I would appreciate any feedback

Cheers

Chan

P.S. While this post concludes the series of posts formally, I will continue to provide additional vRA articles for further extensibility where we will look at more extensibility options to leverage vCO workflows during the provisioning stage to achieve various results and creating custom actions, advanced service blueprints, using vRA for publishing non IaaS functions such as AD password resets…etc. However they are not really mandatory for a typical vRA deployment and would only be required depending on the end user’s needs.

Next: (Optional Fix) Missing Catalog / Entitlement Actions on vRA 6.2.x –>