Acknowledgement: I should thank Adam Bohle and Kim Ranyard who have been unofficially supporting me, and helping me. Without Adam and Kim’s assistance over the last couple of days this blog post wouldn’t have been possible. Thanks guys!

Previously, I spent an entire post just talking about meeting the pre-requisites for an installation of vCAC. By the end of the process I now have two setups – one that’s fully-distributed and product like with multiple Windows instances for the different vCAC roles – and another I’m calling “Uber-vCAC” which is one big Windows instance that will do the whole shooting match. I wanted to try both types of install – because I know the 1st one would be done in production and the second one would be done in a homelab. I must admit creating the Uber-vCAC was very easy. I guess it just shows that in IT once you have done a task more than two or three times it becomes second nature to you, and feels qualitative easier.

Now that I happy that all those pre-requisities have been met I think I’m ready to proceed to the installation part. As ever you need permissions and rights in order to install anything into Windows. That means what ever account you use it must have “Local Administrator” rights. I guess this is why so much software gettings installed using the credentials of the Domain Admin in our world. To be bit more specific the user rights that stuck out for me in reading the install guide were:

• Manager Service Install – needs at least DBO privileges to the vCAC Database.
• Manager Service Install – if you need to authorise users to Active Directory, the Manager Service user must have rights to the “Windows Authorisation Access” group on the Domain

For this reason I created an “vCAC-Admin” account with the appropriate rights including membership of the groups. It was this account I used for the local login for the installation.

Requesting Certificates for vCAC:

At this point I’m folking the blogpost to initially cover the installation the whole of vCAC to single Windows instance. It’s probably easier to install vCAC using HTTP rather than HTTPs communications. However, I have my own Root Certificate Authority Server running my labs, so I thought I would cover this. I haven’t touch IIS in anger since Windows 2000 so the process was actually different from what I was expecting. Remember IIS 7.0 does have the option to create a self-signed certificate which you could use, and add into your computer store to make it trusted.

1. To make a certificate request from IIS 7.0 you need to select the server (not the website), and select “Create a Certificate Request

2. Complete the request form as befits your location and FQDN.

3. Accept the default cryptographic provider used to secure the request process itself:

4. Save the request to text file

5. Copy the contents of the file – to be submitted to a Certificate Root CA

6. Next I logged into the webpage front-end of my Microsoft Root CA, to request a certificate

Navigating to > Request a Certificate >Advanced certificate request >Submit a request by using a file

Pasting the contents of the request to the edit box, and selecting “Web Server” from the template list

I was then able to download the certificate file:

Double-clicking at the certificate on my desktop I could see it name matched the server, and that it was trusted. The next step was importing the certificate into IIS 7.0 and making sure SSL support was in place

7. That can be done, by going back to IIS 7.0 and clicking the “Complete Certificate Request“

8. Normally, at this stage you would need to enable “Bindings” into IIS to use HTTPs. There’s NO NEED to do this in our case as the installer engine will do that for us. In fact if you do enable manually it will confuse the vCAC installer. If your paranoid you might like to enable just to confirm your certificate is valid and works properly. Then opening a web-browser to the FQDN of the web-server – and confirming https:<FQDN> responds correctly with a valid certificate.

Granting the Installer Account DB Rights:

You can create the database in SQL completely by hand or create a pre-pared database which you then later select during the installation. I guess much depends if you have “rights” over the Microsoft SQL or if you have to ask the “Database Administrator” (do these still exist?) to handle the DB side of things yourself. In a homelab I assume your the admin-for-everything so using the installer to create the DB make sense. In a simple deployment you can copy the domain\administrator account – and then grant that user rights the SysAdmin role.

That means adding the account into Microsoft SQL first:

and add it into the SysAdmin role:

Installing vCAC:

1. Navigate into the /setup directory and run DCAC-Manager-Setup

Note: You will see referrence to DCAC in file names and some documentation. Remember vCloud Automation Center (vCAC), was originally DynamicOPs Cloud Automation Center (DCAC)

2. Next browse for the license file which contains your license.

3. Next you will be presented with options of which components you wish to install – enable the option for “Database”

4. Next we enable the IIS Site Bindings Configuration – from the pull-down list select the “Default Web Site“. In my case I kept “HTTPs” as the Site Binding Protocol. In a lab environment you might wish to use HTTP, or instead generate a self-signed certificate. Finally, select certificate from the available certificates in the IIS Store:

Note: The “Enable Web Farm Support” would use in distributed model designed for production – where you would have mulitple web-servers for load-balancing and redundancy. If you enable this option you will need either commercial load-balancer like a VMware vCNS Edge Gateway or F5 BIG-IP – or alternatively more cheap and cheerful an ASPState Database which basically tracks the session state of inbound connections to the web-server farm.

5.  Next type in the name of your Microsoft SQL Server

6. You can if so wish change the SQL Database Name – I changed mine to Uber-vCAC – because my more “production” like setup will have its database on the same Microsoft SQL server. The “Test Connection” option allows you to verify the connection to Microsoft SQL is good.

7. Next you need to configure your AzMan Authorisation Store. You have 3 choices – File/SQL/AD Store. Remember an AD Store requires the use of the AzManUtil to pre-prepare the OU for this type. In lab environment you might want to opt for a File level store – its the simplest – but it doesn’t support a distributed vCAC implementation. The SQL and Active Director models both support a high-availability model for vCAC.

8. Next configure the Email options for vCAC

9. Next configure the vCAC Service Options – The “Diaster Recovery cold standby node” merely installs the product, but the core services are marked to be started manually, rather than automatically. Here I’m using my vCAC-Admin account as the service account, which is perhaps best practise in a production location.

10. Next we must handle the “Model Manager” configuration. The only field that was blank here was the FQDN for the website itself – note if you using HTTPs you type in the raw FQDN (in my case ubervcac.corp.com), you don’t have to type https://ubervcac.corp.com

11. Next we need to configure vCAC Web Portal. The only fields here that need to be completed is the username/password fields. In this dialog box you will see a reference to a “Session State Database Name”.  This is optional feature, and is perhaps best explained from the  official install guide:

You can use a SQL Server database to store ASP.NET session state across the web servers in the cluster throughout a user’s visit. This database should be created in the SQL Server instance containing the vCAC database before the web components of a web farm configuration are installed. For performance reasons, VMware recommends that you use a load balancer with session affinity to track user sessions instead of a session state database.

By leaving the field blank you can bypass the check for the ASPState database. It’s also possible to remove the X next to user “Default Log Location” to relocate log files to partition other than C:

Note: After this dialog box the main copy process begins…!

Installing the DEM Worker & Orchestrator

As you might recall from the previous post about pre-requisites – we also need a DEM (Distributed Execution Manager) Worker and Orchestrator instance as well. One runs the process such as deploying a collection of VMs, whilst the other invokes and monitors its progress. These are installed using a separate setup.exe package called “DCAC-Dem-Setup”. The installer can be run twice – once to install the worker role, and then again to install the Orchestrator role. In my case I began with the “Worker” role first.

1. Specify an “Instance Name” together with a description, selecting “Worker Role” as the type.

2. The DEM Worker needs to be told the FQDN of both the Manager Service and Model Manager Web Service. In our case this is the same Windows Instance. Note that you must specify the port number used to communicate. If you have secured comms this will 443.

WARNING: Watch out for these sorts of dialog boxes during the installation. Some require just an FQDN, whereas others require a FQDN:PortNumber.

3. Finally, we can register the DEM Worker service with the system

The Orchestrator install is precisely the same install routine just move the radio button!

Conclusions:

With this being Windows and with some many bits of software being installed to the same instance, I decided to err on the side of caution, and trigger a reboot. After which I was able to open my web-browser (FireFox) to https://ubervcac.corp.com/dcac to gain access to the welcome page. As I was logged at the time as corp\administrator the web-page took my credentials and passed them through to IIS using Windows Authentication:

There’s still plenty more steps to go through before you can start provisioning VMs – such as adding in credentials for vCenter and other provisioning sources, adding the provisioning systems them selves – creating and defining provisioning groups and so on. More about those in the next thrilling instalment of “Mike’s vCloud Journey Journal”.