ow that the IaaS server is installed and vRA is up and running you can go and do STUFF with it! But what if you don’t really know what ‘stuff’ is supposed to look like? Well, at the end of part 3b of this series we pressed the button marked Create Initial Content. This creates a nice catalogue item you can click on in vRA.
So, what we’re going to do in this stage is log in to vRA as the user configurationadmin (created by the install wizard in part 3b), run the initial content creation catalog item and then watch how this creates some ready made blueprints based on your vSphere environment for you to use and modify.
I should point out here that there are two types of catalog item in vRA. Either a published Blueprint (allowing the creation of a VM) or an Advanced Services item which is a way of instantiating vRO workflows with parameters from vRA (and yes, that is as powerful as you would think).
Before Step 0: Before You Start
You should ensure that you have at least one (preferably 2 or more)VMware machine templates ready and waiting in vCenter as this step will use them to create vRA Blueprints. If there’s no templates, the process will run but do nothing interesting!
Step 1: Log on to vRA
To start, we need to log on to the default vRA tenant as the specially created user configurationadmin. This was created at the end of the installer wizard.
You’ll see the logon page. Log in as configurationadmin with the password you specified in the installer wizard.
After a few moments the vRA default tenant portal should appear. If you click on the Catalog tab at the top to see the current Service Catalog. You should see the vSphere Initial Setup item ready to be requested.
click on the Sphere Initial Setup item.
Once you click, a multi stage form will appear asking many questions. This is part of the power of vRA you can create single click items or complex workflows that appear simple to the end user.
The first window is all abut Tenant Settings. Tenants in vRA are like organisations. Logically distinct entities that have their own Service Catalog with their own set of actions and Blueprints published for them. Generally they are aligned to a specific vCenter or compute resource. The form give you these options:
Do you want to use current tenant (y/n): This is simply asking if you want the blueprints to be created in the default tenant. You could do this but in this exampleI want to create a tenant as if it were a real life business unit/organisation. Select No.
Do you want to create a new tenant (y/n): If you click yes (we we will) the process will create a new tenant for you.
System tenant administrator password: This is the admin password for the default tenant (i.e. the one we’re logged in to) that you created in the installation wizard. Type this here. NOTE: this is NOT the ‘configurationadmin‘ users password.
Tenant name: What would you like to call the tenant? Enter this here. NOTE: make it easy to type and simple. vRA tenants are accessed by appending the tenant name to a url e.g. https://vra7.lab.local/vcac/org/<tenant name>
First Name: Type in your (or a friendly) first name.
Last Name: Type in your (or a friendly) last name.
Email address: Type in an email address for approval and status mails to be sent to. NOTE: this doesn’t have to be right but you’ll have to manually remember to check for pending approvals if you don’t use a real address (I don’t in the lab).
Username: Type a sensible username. This will be created and then used by you to log on to this new tenant.
Password: Type a sensible password for the above username.
Click next and continue with the process.
Now we’re at the vSphere setting section. The screen below doesn’t show it but you need to add this information in manually (my first screenshot was messed, this is a summary shot with the correct information). You’ll need to enter:
Endpoint name: This is the name you gave to the Proxy Agent back in step 3b. This MUST match EXACTLY what you typed before or it wont work. Fi you check back (or remember) this is the part where I said you should name the agent and the endpoint the same thing. NOTE: This is case sensitive.
Endpoint host: Enter here the FQDN of your vCenter.
Endpoint compute resource: The name of the resource you wnat to coneect to. e.g. the cluster name of your lab. In my case, ‘HomeLab’.
Username: The username of the account hat has admin rights on the vCenter server you used in the previous step.
Password: The password for the above.
Now you’re ready to run the action. So click next / ok to continue.
You’ll now get a standard vRA “Request Submitted Successfully” message as shown below. This means the action is being processed and you should be able to track it progress.
For me, the initial part of this took a good 10-15 mins. You can check on the status of a request by selecting the Requests tab. This lists all vRA requests chronologically in the order requested. It’s a good idea to check here now as, although the process can take a while to complete, if you’ve typed a setting incorrectly it will fail FAST and the status of your request will change to Failed.
NOTE: This screen does not auto update. You have to click the refresh icon at the bottom.
After about 10 mins, refresh and check that the request is still in progress. If it is, check for notifications in your inbox. This is done by clicking the Inbox tab or going back to the home screen as there is an inbox widget on that to.
You should see an item asking for approval. Open it, read it and approve it. The next bit is very fast and, by the time you’ve clicked on the requests page again, should now be complete
Now you’ll want to see what the process has created so log out of the default tenant and in to the one you had created using the above process with the system admin password you specified. In our case that means navigating to: https://vra7.lab.local/vcac/org/pepsicac7
Now click on the Catalog tab and you should see a shiny set of blueprints, one for each template you have available in your vCenter.
Now it’s time to play around. Try to provision a few VMs via the blueprints and see if you can edit the settings.
NOTE: when I initially tried out my blueprints they all failed with an error message “cannot find the template xxxx” simply editing, changing nothing and then saving the blueprint caused everything to work. Seems vRA7 still isn’t without it’s oddities.
Next up in part 5 of this series I’ll do a quick tour of the interface and manual configurations screens for vRA. However, the install is essentially complete now so go forth an play around.
I’ll be adding in a how to series also in the near future for common operations.
This post, right here, is one of the reasons why vRA 7 is leagues ahead of vRA /vCAC 6.x. In vRA 6 you had to manually ensure that each of the many, MANY pre-requisites for installing the IaaS server on a Windows machine were exactly right before trying. If even the slightest detail was incorrect you had to start over again (and I mean from the vRA appliance forward. It broke everything). vRA 7 has a nice pre-req checker that tells you if your out of compliance with any of the requirements and wont let you continue until you’re done. Crucially, it has a button labelled “Fix” that I didn’t know about that will sort EVERYTHING for you automatically. I didn’t know about this the first time so spend a good few hours manually sorting all the pre reqs before starting. This was a waste of time…
So, if you want to get going quickly and easily keep reading. If you wan to see what is required first hand in getting a server ready for an IaaS install (and it is interesting to see how it all fits together) I would like to direct you to the alternative version of this bog “Part 3 a”<<<COMING SOON>>>
Stage 1: Getting Your Server Ready
NOTE: I’m assuming that you have provisioned a vanilla Windows 2012 R2 server ready to be used as the IaaS server. It must be:
Part of the same domain as the vRA appliance
Be registered in DNS
Have no ports blocked between it and the vRA VA (personally I just turn the FW off in the lab).
Meet the minimum system requirements of 2 x vCPU, 8GB RAM, 30GB HDD space (in addition to Windows)
For a lab environment you CAN drop the RAM after install but not before completion.
Stage 2: Install IaaS Management Agent
Before starting the main install of the IaaS server you need to install the IaaS Management Agent on the IaaS server (It looks for it in the initial setup). You can get this by navigating to the URL https://<VRA Appliance FQDN>:5480/installer on the iaas server.
This brings up a page with various packages available for download from the vRA7 appliance server. We’re interested in the top one at this time. Click the link to download the Management Agent Installer.
Save this file somewhere easy on your IaaS server and then run the installer to start the wizard. Continue through until you reach the Management Site Service window.
At this stage you’ll be asked to fill out a few important fields. The main thing to note here is that if you get the vRA appliance address incorrect (or the UN/pwd) you will be unable to load the SHA1 fingerprint and continue.
You also have to tick the box confirming that you know the fingerprint is correct. I’m not checking this in this guide but you should do in a production environment (steps on how to do this will be in the “enterprise” deployment blog).
Once you’ve got the URL, Username and Password correct you’ll be able to load the fingerprint and continue.
Next you’ll be asked to ender the active directory account created earlier that will be used to run the Management Agent Service. This must have local admin rights as well as Logon as a service and logon as batch job rights.
NOTE: If you need to enable the logon as a service right for the account but dont know how to Follow this link to the Microsoft TechNet article describing how to achieve this.
Stage 4: Starting the IaaS Install Automation Wizard
Now we’re finally ready to start the main IaaS install and configuration using the new Wizard process. To start, navigate to the following URL in a browser from the IaaS server:
This will bring you to a logon screen where you need to log on as root with the password specified in Part 1 of this blog series.
Once you successfully logon for the first time the Wizard should automatically start.
IMPORTANT: The Wizard will only start ONCE. if you get part way through the process and quit you will not be able to initiate setup via this method again. If this happen you’ll have to use the old fashioned method of install and configuration.
After the EULA you get to select your instillation type. For this exercise we are installing vRA 7 in the Minimal Deployment type so ensure this is selected. You also get the option to deselect the Infrastructure as a Service option to not install the IaaS server portion of vRA (and thus rely on Advanced services and Orchestrator). We want to be able to use the ‘easy’ Blueprints in the test environment so we’re going to install it (i.e. ensure it’s checked as an option).
Now there is the first of two prerequisite check screens. This is checking for the pre-reqs for the install to begin. the screen below shows you how the screen looks if you have NOT deployed the IaaS Management agent on this server already (or if it’s not contactable).
You’ll be unable to proceed unless the agent shows up and can contact the vRA 7 appliance. As we have already installed and configured the agent you should see something like this…
Note: In the above screenshot time sync was out as my windows box wasn’t using the same time sync as the ESXi host. The install fixes this which is why the NTP configuration option is important. It must be set to the same as the source for the appliance.
Next up is the important bit. The prerequisite checker screen. vRA 7 IaaS is still very specific in what you need to be able to successfully install the componant on the Windows server. There’s a LONG list of things that have to be ‘just so’ listed in the manual. If you want to know how everything hangs together and what needs to be changed check out “Part 3a” of my guide where i do everything manual because I thought I had to. If not… Click the Run button and the wizard will go off and start checking the system for you.
Once you’ve click to start the process the screen will show the status. First off you’ll see something like that shown below. The name of the IaaS server is displayed and a “waiting….” style message appears. On my lab this took 3-5 mins.
Soon after you’ll probably be greeted with something like this telling you that your server isn’t configured right…
Now, in vCAC / vRA 6.x this would mean checking every setting it said was wrong (or guessing) or reinstalling if everything looked ok (but wasn’t). In vRA 7, however, VMware have made this bit far, far better that before.
You can simply click the “Fix” button on the pre-req checker screen and the wizard will go off and fix pretty much everything for you (A restart will be required). It looks like this:
I tried this twice and it worked perfectly both times. Your mileage may vary but i gave it a vanilla Windows 2012 R2 server and it behaved brilliantly. Anyone coming from vCAC / vRA 6.x will understand how big of a deal this is!
If y0ur server requires a reboot let it come back up and re navigate to: https://<vr_server>:5480 and log back in as root. The Wizard will (should) restart where it left off. You should find that the wizard restarts at the pre-req checker stage. Re run, ensure things are ok and continue on…
Once you’re done you can continue on to the vRealize Automation Host specification page. you can enter the host manually if you want or, as I prefer, click the Resolve Automatically option and the wizard should resolve the FQDN itself. NOTE: The screenshot below has the Enter Host option selected the one we’re talking about appears beloe.
I actually think this is a good test that everything is working correctly before going any further as the management service SHOULD be able to see the appliance at this point. If you can’t then you might want to fix that first! (Remember NOT to cancel the wizard).
It will look something like this if it’s working:
Once the appliance information has been entered it’s on to specifying the administrator password for the default tenant account. The default tenant account is the part of vRA when you can log in and configure everything important vRA related INCLUDING creating other tenants and setting up permissions for others to use them.
This is the only tenant that can do this so be sure not to lose this password or set it to something completely esoteric for no reason.
We now need to specify the configuration parameters for the IaaS server (the one you’re on).
The IaaS web address should be the same as the DNS entry you’ve set up (i.e. the servers FQDN if you get windows do it when you joined the domain).
The Install IaaS Components on drop down should only have one entry (this server).
The Username field should be set to the domain account you set up right at the beginning that has local admin rights on this server. The password is, obviously, the one you set.
Security Passphrase is very important. Communication to the SQL database will require the use of an encryption key (that you’re setting here). This must be remembered at al costs. Recovery in the event of a failure without this phrase is not possible. I personally like to go with something long but memorable such as “thephantommenacewascompletegarbageandyouknowit” just ensure you remember it!
Next is the SQL server configuration. You don’t have to have pre created a database as the wizard will do this for you. In the lab we’re using default settings and Windows Authentication. Just ensure that the account you’re logged on as / Running the Management agent as is also a dbcreator / sysadmin on your SQL server before continuing.
Next up is the Distributed Execution Managers setup. DEMs are actually two separate processed. The DEM-Orchestrator that takes care of scheduling asks within vRA and the DEM-Worker which handles the actual execution of vRA tasks (up to 15 per DEM-W).
These are installed to an IaaS server (in our case THIS IaaS server) they need a name and a description (I’ve not been very creative in the example below). These processes run as Windows services so the username and password must be from an account that has Logon As A Service Rights in the IaaS system. This is the account we set up earlier.
On to the next step… Agents. This is where you enter the infomration used to set up the communication between the vRA install and you vCenter & vSphere endpoints. vRA will then install and agent that allows communication between the two systems. Remember, vCenter doesn’t know about vRA, it’s vRA that gathers information on vCenter and then send requests. The agent is the go-between / proxy for this two way communication.
IMPORTANT: The Endpoint name and Agent Name fields should be descriptive and the SAME. This is because the explicit name of these two inputs are used in the configuration of vRA down the line and it’s something you have to manually type in and GET RIGHT. Specifically, there’s no way I know of getting the correct Endpoint name if you can’t remember it or didn’t call it the same as the Agent (which shows up in Windows services). So, if you forget and want to configure an endpoint manually for an agent you can’t remember the name of you’re left with a free form text box and not a hope in heck! This is one of the parts of vCAC that seems to have carried over…. It needs to go!
So, enter sensible information and the details of the relevant username and password (that has vCenter Admin rights in this case) and continue. As before, in a production environment this would probably be a separate account.
Now it comes to Certificates. These are tricky in vRA under an enterprise install. BUT, in a minimal install you are allowed to use Self-Signed Certificates. And we are most certainly going to do this! First up is the certificate for the virtual appliance.
The screen below shows the result of the following procedure.
Select the Generate Certificate option.
Type in a relevant Organisation, Organizational unit and country code (the first two can be whatever, the country code needs to be right).
Click Save Generated Certificate and wait a sec.
The screen will refresh to that shown below.
Now on to the creation of the Web certificate for the IaaS server. Same procedure as before using the same values and you should be left looking at a screen as shown below. This is a time saving of about 3 hours and two servers over the enterprise way of doing this section.
Finally… the Manager service certificate. It should pick up that it’s on the same box as the IaaS Web server and use the cert you just generated. It will look something like this.
The wizard is now almost done. It’s time to validate the install. Click the Validate button and you’re away. Progress will be shown like the screenshot below.
Take note of this line. It really does take this long. Go make another cuppa…
After the wait you should be greeted with this. We’re finally ready to install.
The next screen gives very important advice. vCAC 6.x was notorious for failing the install and leaving everything in such a state that you had to rebuild from scratch (yes, seriously) and try again with fingers crossed. Guard against this possibility by snapshotting the vRA appliance, this IaaS server and the SQL server before attempting the install. It’s worth the wait!
Once you’ve done this it’s time to ignore this next screen and press Install.
Now all you need to do is wait while everything gets installed and configured. a pretty helpful status is shown.
NOTE: I ended up with a screen showing “success” and “100%” install but with the final item on the list still showing as in progress. This is, I think, a bug. everything had completed fine and the system functions as expected.
Once the install is complete vRA will ask you for the licence key.
NOTE: You don’t HAVE to enter a key at this time. However, you can’t do anything if you don’t as there’s no free trial period with vRA 7. If you go on without the key you can display the logon page and sign in. However, it just sits there with a spinning wheel and wont load the mains creen
Next to the option to turn on telemetry which sends info to VMware. IMO this product needs all the help it can get (despite being awesome). Turn it on.
Finally there is the option to create a vRA catalog items that will go off and create a suite of blueprints for you to get you started. This is quite a cool idea and takes the guess work out of navigating the interface the first time. it’s basic but its useful.
You simply need to choose a password for a user that will be created called configurationadmin. In the next stage you’ll log in as this user and run the process to create initial blueprints.
Click the Create Initial Content button and you should see:
That’s it! Now it’s time to log in and create some blueprints. This will be covered in part 4 of this series!
Finally, after pretty much a full year of waiting VMware released version 7 of the vRealize Automation suite. Rumour is that it’s far easier to install, more stable and bug free than before. Given the difference between the hell that was 6.0.1 and the, much better but still poor, 6.2.2 releases I’ve had the pleasure of deploying I’m hopeful of significant progress. Obviously I want to check it out as son as possible so this series of Blogs will be about getting it deployed in my home lab.
Installing In A Home Lab
vRA is a beast when it comes to system requirements 6.x was massive but 7 is much improved. Gone are the requirements for a separate Identity appliance (SSO) and pSQL DB to talk to the vRA host. Both of these as now included in the basic appliance. It’s still beefy though so, for a 1st time I’m going to deploy the “minimal” version of vRA
So, What Does It Look Like?
The minimal install looks like this:
This is nice and simple for the lab. We only NEED two boxes. One vRA appliance and one Windows Box for the IaaS components, agents and SQL.
In this series of blog posts I’m going to be using a SQL server I already have as part of the lab (the same one that houses my Virtual Center DB). Therefore I’ll be interacting with three boxes that make up the install.
So, What’s Being Provisioned?
The vRA7 lab install will be made up of:
1 x vRealize Automation appliance, which deploys the management console, manages Single Sign-On and houses the internal PSQL DB and Orchestrator server.
1 x Windows Server box (2012 R2) for the Infrastructure as a Service (IaaS) components. This includes the Web Server, Model Manager Data, Manager Service (agent), Distributed Execution Managers (worker and orchestrator) as well as the agents for vSphere / vCenter etc.
What Have I already Provisioned?
An MS SQL Server for the IaaS Database (Server 2012). This is already set up in my lab.
An Active Directory Domain with a domain already set up. This is fr creating users and groups with relevant permissions.
What We Need To Proceed
To complete the install you’ll need:
1 x vRA7 OVF file from VMware to deploy the appliance.
Download from the MY VMware site.
1 x Vanilla Windows 2012 R2 server for the IaaS components
2 x vCPUs
60GB HDD (30GB Windows, 30GB Free for IaaS Components)
1 x Licence Key for vRA.
It doesn’t work without one so don’t try (installs, wont log in)
Accounts And Logins Required
Before you start it’s best to create any users and groups you may require now. vRA has some specific requirements such has insisting that the IaaS server is installed as the account that has local admin rights on the Windows Server. I have created the following users and groups that are used in my Active Directory.
User: svc-vra-admin This is my generic service account that I create for anything vRA related. In this case it’s used to log on and install the IaaS components as well as run the vRA services (i.e. the service runs AS THIS USER). It’s also the account I give permissions in vCenter to have admin access for data collection later in the process. In a real world environment you probably shouldn’t just use the one account. However, as this is a lab PoC test I have.
Member Of Groups:
vRA Administrators – For defining an account as having vRA admin permissions. vRA Users – For defining an account as a standard user. VC Admins – Group giving members admin rights to my Virtual Center. vRO Admins – Group giving members admin rights in vRO.
Additional Standard Groups This User Is A Member Of:
NOTE: This isn’t close to best practice. In a shared environment, anything facing the internet or a real deployment Create seperate users as appropriate. After this simple guide I will be doing an “Enterprise” install with the correct segregation of duties. This solution is, obviously, not production ready!
Once you’ve got all this downloaded and provisioned You’ll be ready for the Next Stage. Deploying the vRA Appliance
Continuing from the previous posts. Here we shall generate the certificates used for the vCAC appliances.
Step 5: Install Open SSL
VMware requires that a very specific version of Open SSL is installed for use with vCAC 220.127.116.11 appliances and components. In this instance we have to use Open SSL v0.9.8zb as anything from the 1.x stack is not supported in this version. This version of 0.9.8 is a patched version that is NOT vulnerable to the security flaws that prompted the 1.x version release.
Prior to installing Open SSL on your issuing CA (again, in my lab this is the DC running MS Certificate Services). you need to ensure the per-requisites for Installing OpenSSL have been met. In this case it is the downloading and instillation of Visual C++ 2008 Redistributable. This is available from Microsoft (vcredist_x86.exe).
So, first off install that pre-req and then download and install Win32OpenSSL-0_9_8zb.exe
The instillation of Open SSL is mostly a ‘Keep Clicking Next affair’ However, as outlined below you should ensure that the Open SSL binaries are stored in the /bin directory and NOT the Windows system directory. It makes things MUCH easier later and allows things to happen automatically.
Step 6: Issue SSL Certificates for the vCAC and SSO Appliances
Open a PowerShell windows and make a new directory as shown and then launch the certificates Manager console. Or do it via Windows Explorer if you like.
Expand the Trusted Root Certification Authority and then select Certificates. You should be able to see the Root certificate for the Authority. Now, in the details pane, right click on your created Root Certificate (In my case LabDC01-EntRootCA) and select All Tasks > Export
The Export wizard will open up. Follow the process ensuring that the certificate is exported in Base-64 encoded X-509(.CER) format (shown below).
Then save the file in the C:\Certificates\vCAC folder as Root64-1.cer and complete the wizard. Note that the names of the folders and files here refers to commands we will soon be executing. If this was in an offline root CA with an online issuing CA there would be a second root certificate in the chain of trust and this would also have to be exported (hence the ‘-1’ at the end of the certificates file name).
Below is the user variable area of the script with my values plugged in. Ensure you have the $CertOutputPath and $OpenSslInstallDir are correct before running the script. Also note that there are NO SPACES in the Certificate Template name as the template name is created without spaces regardless of the friendly name given.
# Path to directory to store created certificates
$CertOutputPath = "C:\Certificates\vCAC"
# OpenSSL location
$OpenSslInstallDir = "C:\OpenSSL"
# CA Name
$CAName = "LabDC01\LabDC01-EntRootCA"
# Certificate Template Name
$CertificateTemplateName = "VMwareSSLCertificate"
$CertificateCountryName = "GB"
$CertificateStateOrProvinceName = "London"
$CertificateLocalityName = "London"
$CertificateOrganizationName = "Lab"
$CertificateOrganizationalUnitName = "Dev"
When the script is run it simply asks a few questions (shown below) all revolve around Subject Alternate Names (SAN) values for the certificates. vCAC gets really, REALLY sniffy about these values existing so it is best to put in all names you can think of here. NOTE: The common Name must be FQDN, the SANs are DNS names and entries. Normally I wouldn’t put the IP address as an entry here but this is a lab environment so I want a fail back if I mes my DNS up!The script will do some OpenSSL goodness and then ask you if the Root CA certificate is in the correct location. Check that the Root64-1.cer is there and then select Yes.
Again, Magic will happen and the following confirmation should appear:
The same steps are required now for the vCAC Virtual Appliances. As before, ensure the SANs are entered correctly and thoroughly. Remember that, in a distributed environment the main address for the vCAC VA will be the load balancer address / DNS entry.
Again, a confirmation will appear (shown below) if everything has gone right.To check everything has run correctly you can take a look in c:\Certificates\vCAC and you should see two new folders created (vCAC-SSO and vCAC-vAPP). These folders will contain numerous files within making up the certificates in the right formats for importing in to the vCAC appliances.
That’s it. We are now done with certificates and can get on with Installing the vCAC appliances.
When installing vCAC in a distributed / load balanced way it is not possible to use self-signed certificates to get everything working correctly (wildcard certs are not supported either). Therefore, correct certificates have to be generated for your environment and then issued for the various vCAC components. In a production environment the Public Key Infrastructure (PKI) would ideally be an Offline Root CA server with a second server provisioned as an Online Issuing Certificate Authority. In my lab environment I don’t have the capacity for this so my online Domain controller will be an Enterprise Root CA. There wont be a secondary issuing server. I will also assume that you are setting up a PKI for the first time and it’s not already installed
Step 1: Create A CAPolicy.inf File
Before installing Active Directory Certificate Services you can create a CAPolicy.inf file that defines certain default values you want the PKI to adhere to. In my case i was strong encryption with long validity so I don’t ever have to worry about replacing anything later.
The file should be created as %windir%\CAPolicy.inf and contain the values you require. In my case it looks like:
This specifies a key length of 4096 bit (strong) with a 40 year validity period and a 20 year period for Certificate Revocation Lists. Delta CRLs are disabled for simplicity!
NOTE: I believe this file is only used if the GUI configuration of the CA is followed. If using PS as below these settings need to be configured manually.
Step 2: Install Active Directory Certificate Services
I prefer to add features to Windows using PowerShell as it means I don’t have to keep clicking Next every few seconds. The commands I use going forward only work on Windows Server 2012 upwards (sorry). If you are running 2008R2 or older you’ll have to install the roles and features the old way. Also note that the method below requires the server I am installing on be a Domain Controller.
To install AD-CS Open up a PowerShell Window (ensure it’s running as an administrator) and run the command:
Remember, you can use the –whatif switch to check that the command is valid and to see what it will do.
There will be a confirmation dialogue (as show above), confirm the action and wait for the process to complete(almost instant). The confirmation is odd (shown below). It looks like an error but isn’t
Successful configuration at this point can be confirmed by opening Certificate Services:
Right clicking on the root server (should have a green tick by it) and selecting Properties and then View Certificate.
If all is well you should notice that, in the details tab, the Public Key field is set at 4096 and the validity period is indeed 40 years.There is a little more configuration required to set up the publication URLs, CRLs and disable Delta CRLs. The commands below need to be entered (modify for your use
As an example you should get output similar to the screenshot below if the commands complete successfully.Now, if you check: C:\Windows\System32\CertSrv\CertEnroll You should see your root certificate all present and correct.
Step 3: Creating A vCAC Specific Web Enrollment Template
Now, to be able to issue the correct type of certificates for vCAC (it has very specific requirements according to the docs) we need to create an new Certificate Template. This done by launching the Certificate Authority utility on your issuing CA (In my case this is the Enterprise Root CA installed above).
Expand the Certification Authority tree and right click on Certificate Templates. Now select Manage from the context menu. This will open up the Certificate Templates Console. Scroll down the list and select Web Server. Right click and select Duplicate Template. (Shown Below).
The properties window will be displayed. Leave the compatibility level at Windows Server 2003 level and then select the General tab.
In the general tab change the information to that shown below. Specifically, make sure the Publish certificate in Active Directory check box is selected and that the validity periods are right for your environment (I don’t want to bother replacing them so have set it long).
Now select the Extensions tab, select Key Usage and ensure the options shown below are checked.Click OK and then, still in the Extensions tab, select Application Policies and then Edit. Click add and then select Client Authentication and then OK.
Click OK and close the Certificates Template Console. The certificate is now available in AD and available to publish.
Step 4: Publish The New Web Enrollment Template
Still logged on to your Issuing CA with an account that has Domain Admin privileges open the Certification Authority utility and expand the tree as before. Right click on the Certificate Templates folder and select New > Certificate Template to Issue from the menu.The Enable Certificate Templates window will appear. Scroll down and select VMware SSL Certificate as created above and click OK.
The VMware SSL Certificate should then appear in the Certificate Templates folder.
Next up is installing Open SSL. This will be continued in Part 3
This series of posts will guide you through a full distributed install of VMware vCloud Automation Center (vCAC 18.104.22.168). This is something I’ve done in a live environment but I’m going to try to re-create a small setup in my lab environment to enable me to test upgrading between vCAC versions. Why? Because I’m interested.
A Note on System Requirements
I don’t have a super powerful lab. Storage is fast but not that plentiful. As this is a test install that won’t really do much some of the Components will be t minimum spec or below if I know I can get away with it. This will show mostly on the second side of the stack. This will be set up to prove clustering and load balancing but will be logically turned OFF and left undersized once running.
Part One – Windows Pre-Requisites
For ease of administration, and to replicate what I would do in a Live environment, I have created the following security groups in Active Directory using the Users and Computers utility. These will hold relevant accounts that are needed in the install process.
The following accounts were also created in Active Directory Users and Computers utility as they will be needed later.
When creating these accounts you will need to specify a password. This should, obviously, be strong but be aware that some special characters will cause issues with the vCAC install later on because of the way the installer uses SOAP to pass through certain password. For this reason it’s a good idea to avoid ‘#‘, ‘&‘, ‘@‘ for sure (other characters may also be bad).
I’ve added my personal account and the domain admins group to the VC Admins group, the svc_vcac_admin user is a member of vCAC Administrators and svc_sql to the SQL Administrators group.
Set Up a DNS Entry for PKI
vCAC uses Certificates a LOT and we will need to set up a Public Key Infrastructure (PKI) to be able to do this in the lab. I will be installing PKI on my Lab DC so, for later use, I’m also creating a DNS A record looking like: pki.lab.local 192.168.1.151
Whilst testing vCAC (22.214.171.124) we have recently run into a strange little issue when trying to tear down and evacuate everything from a test tenant. In order to remove a tenant you must strip back everything first by removing machines, blueprint, reservations, business and fabric groups. We got as far as removing the blueprints before running in to the error below. “Error Deleting Blueprint <blueprint name>/ it is still being referenced by 1 machines.”
This should not be the case as we had destroyed all test machines assigned by this blueprint in the correct manor before. Indeed, selecting the blueprint and choosing “view machines” yields the information shown below. i.e. there are no machines managed from this blueprint.
We also have another blueprint within this tenant and attempting to delete this gives the same result. However, this time, clicking “view machines” shows that one VM is seemingly stuck in the “Disposing” state. This is a permanent issue as no amount of refreshing, data collection or restarting clears this status. Clearly, this is blocking this blueprint from being removed.
It is possible to try to force a destroy of this machine but, despite claiming success, and eventually removing the machhine from the “disposing” state nothing actually changes. Deleting the blueprint still gives the error that is it still being ‘referenced by 1 machines’.
Please note: The following solution involves hacking about in the vcac SQL database. this is almost certainly not a supported action and could cause things to go badly wrong if you do something silly. Only do the following at your own risk and after backing up the SQl and PSQL databased associated with your vCAC install.
This issue was traced down to an incorrct entry in the vcac SQL database. within the vCAC database there is a table called ‘dbo.VirtualMachine’ Running the query below will return all VMs that the vcac databse considers being currently managed or assigned to a blueprint.
SELECT * FROM Virtualmachine WHERE IsManaged=1
This returns a list of VMs. take a look through the VMs and see if any of them co relate to the name of the blueprint you are trying to remove.
<Insert Picture here>
For each of the VMs that relate tot he affected blueprint copy and paste out the ‘VirtualMachineID’ to a text file for later use.
<Insert Picture here>
Now, for each of the VirtualmachineIDs you have run the query below. Again, ensure you have a backup and the ID is correct and only referencing the blueprint you are wishing to delete.
UPDATE dbo.VirtualMachine SET IsManaged=0 WHERE VirtualMachineID=’<Insert VM ID Here>’
Now restart the IaaS Web services and log back on to the vCAC web interface and try to remove the blueprints again. In the case above the steps performed allowed the removal of the second Blueprint but NOT the first. Further steps were required to enable this to be removed.