I’m writing today about a fairly common use case – onboarding a customer. A new customer is always a good thing for a managed service provider, but setting everything up to give them access to their services can be a lengthy, error-prone process. The onboarding process is the first chance to prove to the customer that you can deliver, and it needs to be smooth and efficient. What’s the solution to a time-consuming, repetitive task? Automation, of course!
A managed service provider will generally represent each of their customers as a separate organization within vCommander. Many things must be tied to the customer – quotas, deployment destinations (i.e. infrastructure), ownership policies and IP pools, to name a few. Infrastructure changes are also often needed within vCenter Server. Wouldn’t it be great if you could do this by simply submitting a service request form?
We’re going to accomplish this by using custom component types. Custom components let you add non-VM components to entries in the service catalog – in this case, an “onboarding” component. You can specify what questions will be asked on the form when a request is made for this component and then feed the answers into a completion workflow that does the work. That work is going to be done by scripts that use vCommander’s REST API PowerShell library and vCenter Server’s PowerCLI. In this particular example, I’m going to show you how to set it up so that an onboarding request accomplishes the following tasks:
- The organization is created, users are added to it, and quota is assigned. This provides Service Portal access to the customer.
- A vCenter Server folder is created to store the customer’s VMs.
- A deployment destination is created to enable automated provisioning.
- An ownership policy is created, targeting the folder to ensure that vCommander tracks ownership even if a VM is created outside of vCommander.
You don’t need to stop there – you could create customer-specific port groups and assign IP pools to them, create resource pools, or make calls to other external systems. The sky’s the limit.
Setting up the service catalog
The first step is to set up a service catalog entry that can be submitted by the person responsible for onboarding. Create a new catalog entry, and on the component page, add a New Component Type. I called mine “Onboard Customer” and gave it a cost of $0, since cost isn’t relevant in this scenario. On the visibility page, make sure that you publish this catalog entry only to internal members of your organization – you don’t want this to show up in customer service catalogs.
Once the catalog entry is complete, head over to the Form Designer page. Under the component forms, you’ll see one for “OnboardCustomer”. Here, you can configure the fields the requester must fill out. I’ve set mine up to ask for the organization name, the manager’s AD username, and an optional user group, as well as questions about quotas and infrastructure. Most fields are simple input text fields, but the System drop down is a list-based custom attribute with friendly names that I can map to specific vCenter Servers in the scripts. If you need other fields with lists, or fields that need validation that data is formatted properly, you can use custom attributes instead. Here’s what the form looks like:
Setting up the completion workflow
The completion workflow is what will actually do the work of running the scripts to onboard the customer. Under the Completion Workflow tab, create a new workflow that is set to run after an Unmanaged Component is deployed. The steps of the workflow are shown in the image below – each of them in a script step. The command line uses variables to access the metadata from the request (see our online help for more details). On the assigned component page, select only the service/component we created earlier.
This could have been done using a single script step. I chose to split it apart to take advantage of vCommander’s workflow management capabilities. If a particular step fails, you’ll see it in the Workflows tab at the bottom of the console, and the step that failed will be highlighted. It’s much easier to troubleshoot these individual steps than a script combining all of them. Furthermore, once you’ve taken action to correct the failure, you can skip the step and have the rest of the onboarding process continue automatically.
Setting up the vCommander server
There’s not a lot to do on the vCommander server. Install the prerequisites: PowerShell v3, VMware PowerCLI and the vCommander REST API client. Copy the scripts attached to this knowledge base article to a directory on the vCommander server (you’ll need to customize the command lines to point to them).
Lastly, you’ll need to set up encrypted credential files. Hard-coding credentials in a plain-text script file is obviously bad, so the scripts are designed to use an encrypted credential key file. You can find instructions on creating the key file in the knowledge base article Encrypting Credentials for PowerShell Scripting. Create one key file for vCommander credentials and one for the vCenter Server credentials (for folder creation). Once you’ve created the key files, you’ll need to modify the script files to point to the correct location.
You’re ready to go
That’s all the setup that’s needed. You can now make a test request for a customer to be onboarded to ensure it works. I set up my approval workflow to automatically deploy, and this image of the Tasks list shows that the whole process took less than a minute once the form was filled out. Every customer you add through this process will have the standard set of steps followed. Nothing can be accidentally forgotten, and you’re not wasting time manually following a checklist.
Try it out for yourself
This is just one example of the power of custom components, scripting and the vCommander REST API. We’ve put detailed instructions and the scripts I used into a knowledge base article called Automating Customer Onboarding. Try it out in your own environment. I chose VMware for this demonstration, but there’s no reason you can’t do the same for any public or private cloud. If you’re working in a hybrid cloud environment, you could create both a private and public cloud destination for the user. Scripting takes some time, but if you target repetitious tasks you’ll get that time back soon enough.