Migrating to vCAC 5.2…No its not a simple upgrade.
It’s been awhile since I have posted anything but I figured the new version of vCAC, 5.2, going GA was worthy of a post. As you all know, I have been knee-deep in implementing vCAC at my current employer and this new release is very exciting to me. There are several new features added, the ones I am most excited about are the Enhanced vCloud Director Integration and added support for vCNS. In the previous version of vCAC, 5.1, there was very limited support for vCD. You could clone vApps but there was no built-in functionality to customize VMs that were a part of the vApp during provisioning. The work around for this was, you could add vCenter Orchestrator instance as an Endpoint and call workflows to accomplish the customizations. In, 5.2, the concept of “vApp component blueprints”, is added. These allow you to customize the VMs within a vApp. This is a very welcome feature in my opinion. As far as vCNS goes a vCNS Manager can now be added as an Endpoint. This allows vCAC to discover network resources and now that the network resources are there they can tied to blueprints. Pay-as-You-Go- Allocation model and support for KVM were also added.
Ok, now that I have rambled on about the new features on to the meat of the post. I am going to cover the migration vCAC 4.5/5.1 to 5.2. Only these releases are supported in migrating to 5.2 so the first step is to verify your version. This can be done by browsing to the vCAC web portal at https://FQDN/DCAC . Once their click on the “About” in the upper right hand corner.
Next, make sure you have all the appropriate trusted SSL certs created and imported. vCAC uses SSL/443 for a lot of the communications between all the components by default. If you’re migrating, it’s almost a given you already have these in place, but if not you should. It uses IIS and there really isn’t anything special, but if you need some direction on this refer to the “vCloud Automation Center Installation Guide” SSL Configuration section for more details. You also need to make sure that there are no active machine provisioning /operations and that all data collections are completed.
Next you need to document the info on all the DEMs, Agents, and Endpoints. This is done because during the migration, all these components will need to be uninstalled. To gather info on your DEMs, from the web portal, click on vCAC Administrator==>Distributed Execution Status.
You will presented with a screen that lists all the DEMs. Document their Name, Host Name/Machine, Role, and Skills (if any).
Next document the agents. To do this RDP into the vCAC server and navigate to the agent installation location. This is usually %SystemDrive%\Program Files (x86)\DynamicOps\DCAC Agents. For each of the directory note the name. Then open a command prompt, navigate to the agent’s directory, and issue the following command: DynamicOps.Vrm.VRMencrypt.exe VRMAgent.exe.config get. Document the value of managmentEndPointName. Do this for all the agents listed in the directory.
Next record all service account user credentials. While on the Windows box go to Start -> Run -> Services.msc . Find the following services and notate the service account that is being used.
- Each VMware vCloud Automation Center Agent – agentname service (DynamicOps Cloud Automation Center Agent if upgrading from DCAC 4.5)
- Each VMware DEM-role – instancename service (DynamicOps Cloud Automation Center DEM if upgrading from DCAC 4.5)
- The VMware vCloud Automation Center service (DynamicOps Cloud Automation Center if upgrading from DCAC 4.5) — Manager Service host only
- Repeat these steps for any other host on which agents or DEMs may be installed.
You will need to also record the service accounts that are being used for the Application Pools in IIS. To do this go to Start–>Run–>inetmgr.exe. Click on the IIS Server name à then Application pools.
Off to the right hand side you will see Application Pools with an Identity associated with them. Document the Identity.
In my opinion, if you documented your install you should already have the info but it can’t hurt to verify. In my demo environment I have all the components on one box, if this were production these would be separated. For more info one were how to separate the services in a production environment reference the following doc: vCloud Automation Center Reference Architecture
If you used any customization via the vCAC extensibility toolkits, they will need to be uninstalled. For more details on this refer to the vCloud Automation Center Extensibility Guide.
Once all of the above is completed, RDP to the vCAC server and stop all the services. Again, in my demo environment I have all the components on one box, but in production you they would be separated. You should be able to look back at the info on the DEMs and see where they are installed and stop the services on those boxes.
Next it is suggested that you back up the following customization related files.
Application configuration files, including:
- ManagerService.exe.config, located in %SystemDrive%\Program Files (x86)\Dynami- cOps\DCAC Server
- DynamicOps.DEM.exe.config, located in %SystemDrive%\Program Files (x86)\Dynam- icOps\Distributed Execution Manager\instance_name
- VRMAgent.exe.config, located in %SystemDrive%\Program Files (x86)\Dynami- cOps\Agents\instance_name
Email templates located in %SystemDrive%\Program Files (x86)\DynamicOps\DCAC Server\Templates
Workflow configuration XML files located in %SystemDrive%\Program Files (x86)\Dynami- cOps\DCAC Server\ExternalWorkflow\xmldb
I just created a folder on another disk and copied them over. VMware also suggests that you take a backup or snapshot (if it’s virtual) of all the vCAC component hosts. In my case everything was on one host so I snapshotted the VM. They also recommend you backup the DB and AzMan store. To be honest with you at this point I was getting pretty concerned as they add you backing up so many things. Didn’t give me too much confidence in the migration to 5.2.
Ok, finally now on to actually updating vCAC to 5.2. The first part is to update the database. This is done through running DBUpgrade.exe. To get info on the arguments and switches that can be used with it, run it without any.
Since I was local to the box that had the DB on it and logged in with the vCAC service account I ran the following:
As you can see above, the first time I attempted to run the DBupgrade while specifying the I got an error message stating that:
There is no upgrade script to execute from release 184.108.40.206 to release 220.127.116.119
There is no upgrade script that has its starting version matches the installed database version 18.104.22.168
So next I tried did a change directory to the location that DBUpgrade is located and ran the same command without any issue:
DBUpgrade.exe must look in the current directory for the script and not the path that is specified to run it.
Uninstall the following components DEMs, Agents, vCAC Designer, vCAC Self Service Portal, and WinPEBuilder. Make sure not to uninstall the Manger Service, this will cause you to have to do a fresh install of vCAC. So basically everything but the Manager Service and the default portal. Obviously this is done through Start à Control Panel à Programs and Features. In my demo environment I had DEMS, a vCenter Agent, the Self Service portal, and designer.
Next order of business is to make sure you install .Net 4.5 because it is required. Once this is complete its best to good ahead and install the vCAC Prerequisite Checker, its part of the vCAC 5.2 installation zip and is in the tools folder. Truth is that if you’re doing a migration you must likely have everything you need installed, but when I first installed the product I missed some pieces. Can’t hurt to do a sanity check before proceeding. Once you have installed it, open it up. In my test environment I have all the components on one server, if there were production you would install the vCAC Prerequisite Checker on all servers. As you see you have the ability to scan based on the installed components. Once you have selected all the needed components click Run Checker.
Next you will run the vCAC-Server-Setup.exe install from the vCAC 5.2 installation zip, its in the Setups folder. Make sure all the options but the Database are selected. Since the install detects a pervious install this should be the default.
Click Next, Install, and then Finish.
The vCAC Configuration Wizard will auto launch.
Next you will be prompted for license keys. Add the required keys and click next.
Then you will be prompted for the DB instance and DB name. If the currently logged in user has the appropriate permissions to DB then leave the box checked to use the currently logged in user. If not uncheck the box and provide a user with the appropriate permissions.
Then click next. Next you will be asked to provide a Security Passphrase.
Click Next. You will next have you will be presented with a screen to verify your IIS settings. You can click the Test Binding to verify that the port is available. You should already have a certificate set. Click Next.
You will then be prompted to provide the username and password that you documented previously that is being used for IIS Application Pools.
The next screen will be already populated and will have authorization store selected, Click Next.
The Model Manager Service configuration screen will already populated verify the settings and click next.
The Manager Service Screen will be already populated. Verify the settings and click next. If this were a failover host you would select the Disaster Recovery cold standby node.
The vCAC Web Configuration screen will already be populated, verify your settings and click next,
On the Ready to Configure screen, click Configure. Then click next and finish.
Once you are done with the configuration wizard, you need to run vcacMigrationCleanUp.exe. The executable is part of the install zip. It’s located in Installation\Database\DBUpgrade\vcacMigrationCleanUp. You need edit the configuration file before you run it. Edit the following 2 lines:
<add name=”DB” connectionString=”Integrated Security=SSPI;Data Source=localhost;Initial Catalog=DCAC”/>
<add key=”repositoryAddress” value=”https://localhost/repository/”/>
Change local host to the FQDN of the Model Manager host. For Data Source use the SQL instance, and for Initial Catalog us the DB name. Next run vcacMigrationCleanUp.exe à Select Migration Clean Up–>vSphere Agent. Click Yes, Yes, and then OK. Exit the migration clean up tool.
Next it’s time to reinstall the DEMs. I am going to start with the DEM Orchestrator. First launch the vcac-Dem-Setup.exe and click next. Accept the End user agreement and click next. On the DEM instance Configuration screen, from the documentation you gathered, provide the DEM Instance Name, DEM Description and select Orchestrator Role.
On the Custom Setup screen take the defaults and click next.
On the Manager Service and Model Manager Web Service Host configuration screen provide the FQDN for the Model Manager Service, Model Manager Web Services, Model Manager Username/password, and click next.
Next provide a username and a password for the DEM service.
Repeat the above steps form and DEM Workers you might have. In a production environment their could be several. Obviously select the Worker Role. Next you will reinstall the agents, in my case this was a vSphere Agent. Launch the vCAC-Agent-Setup.exe which is part of the vCAC installation zip in the Setups folder and click next.
Accept the End-User Agreement:
Next you will need to look back in your documentation and provide the Agent Name, FDN for the vCAC Server:port, and Model Manager Web Service Host:port.
Next you will be prompted to select the agent type. As you can see people there are quite a few. In my case I selected the vSphere Agent.
Again look back at your documentation and provide the service account info for the vSphere Agent.
Next provide the Model Manager Username and password. You should have documented this before the upgrade.
You should have documented the name of your vSphere Endpoint, provide that in the screen below. Endpoints provide the credentials for the agents so this is pretty important.
If you have any other agents that need to be reinstalled go through the process again, select the appropriate agent type, provider the agent name, credentials, and endpoint.
If you were using the Self Service portal which is part of the extensibility pack, it’s time to reinstall it. Download and extract the install bundle. Then run the vCAC-SelfService-Setup.exe and click next
Accept the License Agreement.
If you’re installing in the default location click next. If not change the location.
Click Finish and the vCAC Software Configuration wizard will launch. Click Next.
You will then be asked to provide the DB instance and DB Name. Then click next.
The configuration will detect your setting, click next.
On the screen below you need to provide credentials for a service account, the Model Manager FQDN:port, and credentials for the Model Manager.
Click Configure. Then click next.
If you uninstalled vCAC Designer or have a need for it run the installer. It is also a part of the vCAC 5.2 extensibility pack. It’s a pretty basic install wizard and I am not going to go through all the details here. You will need the Model Manager Web Service FQDN:port, username, and password. vCAC Designer is only needed if you are modifying or creating workflows.