vRealize Automation Windows Blueprint Administrator password set (via gugent)

Here is a very simple way (i.e. non Orchestrator workflow route) for allowing your users to define their own passwords for a Windows VM when they request it via the catalogue.  This method uses the vRA Guest Agent.

An excellent walk through on vCAC 6.2 of how to do this for Linux VMs (and the main inspiration for this post) can be found here:-

http://www.virtualvcp.com/vmware-vrealize-automation-vcac/207-vrealize-automation-6-2-specifying-a-new-root-password-using-custom-properties

A good post on how to prepare your Linux and Windows Templates for the vRA Guest Agent (gugent) operations can be found here:-

vRA7 – Gugent on Linux

vRA7 – Gugent on Windows

So assuming you have all the pre-reqs in place you then need to create a small batch file on your Windows template in say c:\scripts.

My .bat file is:-

…. and the contents of the script (where %1 is the argument you pass from the Blueprint Request form):-

You now need to create the Property Group, in vRA 7 this is in Administration > Property Dictionary > Property Groups.

Create a new group with the following script actions:-

[table]
Name,Value,Encrypted,Overridable,Show in Request
VMware.VirtualCenter.OperatingSystem,windows7Server64Guest,No,Yes,No
VirtualMachine.Customize.WaitComplete,true,No,Yes,No
VirtualMachine.Software0.Name,Generate new root password,No,Yes,No
InitialRootPassword,,No,Yes,No
VirtualMachine.Admin.UseGuestAgent,true,No,Yes,No
VirtualMachine.Software0.ScriptPath,c:\scripts\vCACSetAdministratorPassword.bat {InitialRootPassword},No,Yes,No
[/table]

When you’re done it should look like this:-

vra7_windows_gugentNow add your new Property Group to the Blueprint:-

vra7_windows_gugent_1

Once you have saved the Blueprint, try a deploy and see if it works.  If you are having problems then the first place to look is the gugent log files which by default are in:-

post upgrade vRA 7 orchestrator endpoint won’t connect

I upgraded vCAC 6.2 to vRA 7 the other day. Everything looked good until I tested some blueprints which call custom workflows configured in the embedded Orchestrator.

I had my endpoint configured as per the documentation, listed here:-

http://pubs.vmware.com/vra-70/topic/com.vmware.vrealize.automation.doc/GUID-9E9E2393-A268-432C-B9EA-2CBEFA25361B.html#GUID-9E9E2393-A268-432C-B9EA-2CBEFA25361B

You can test if your Endpoint is working or not by either running a refresh or checking the logs. To force the endpoint to run a data collection login to vCAC as a Infrastructure Admin and go to Infrastructure > Endpoints > Endpoints, then select Data Collection and click Start to force a data collection run.vRA_7_Orchestrator_Problems_1

To check the logs go Infrastructure > Monitoring > Log and filter on Message for “endpoint”:-vRA_7_Orchestrator_Problems_2

As you can see I am getting the following error:-

Endpoint Data Collection failed for endpoint vCO-Embedded [Workflow Instance Id=588727]
Unable to connect to the remote server
Inner Exception: Unable to connect to the remote server

I checked the DEM log on my IaaS server. By default the logs can be found here:-

C:\Program Files (x86)\VMware\vCAC\Distributed Execution Manager\<DEM Worker>\Logs

And found the following errors:-

Endpoint Data Collection failed for endpoint vCO-Embedded [Workflow Instance Id=588727]
System.Net.WebException: Unable to connect to the remote server —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 172.22.4.61:8281

I tried a telnet from the IaaS machine and there is no connection available on port 8281.  So a quick check with the client via:-

https://<vcac app fqdn>/vco/client/client.jnlp

and you are presented with the auto filled java client session, which points at 443 rather than 8281:-

vRA_7_Orchestrator_Problems_4

So I edited the Endpoint, removed 8281 and ran the Data Collection again and it now works fine!

Conclusion

At the time of writing it looks like the VMware documentation is out of date but in short remove 8281 from your endpoint for the Embedded vCO and it should work fine.

I’ve left all the working out gumpf in this post on the off chance it helps others…..

vRA 7 Migration Tool

If you’re about to upgrade (or already have) to vRA 7.x and want to make sure your logins all work post upgrade then you will need to use the Migration Tool to shift your ID stores from the old SSO setup (whether this was a dedicated ID appliance or integrated with vCenter SSO etc) to the new vIDM system. If you don’t migrate the logins then you will have to create the SSO ID Stores manually which also requires creating a local vIDM user in the Tenant(s).

A good explanation of why VMware have moved from SSO to vIDM can be found here:-

vRealize Automation 7 – Part 5, Identity Management

How you perform the migration relies on which SSO method you were using for your 6.x system.  For example if you were running of a Windows based 5.5 vCenter SSO service you will need to run the migration tool on the Windows server that is hosting it.  Similarly if you were running a dedicated vCAC 6.x ID appliance you will need to run the linux version from the appliance.

In this example we will be running this migration from a dedicated appliance and as always make sure you have backups / snapshots etc before you go any further!!!

First off you will need to obtain the migration tool zip file URL:-

https://vra-app1.domain.local:5480 > vRA Settings > SSO and copy the migration tools URL.

SSH to your old SSO ID appliance (SSH can be enabled from https://<SSO ID Appliance IP>:5480 > Admin), cd /tmp, download and extract the zip:-

vRA_7_vIDM_Migration_1

Now cd to the new dir and set your environment:-

Now migrate your ID Stores (you will be prompted at various points for passwords and confirmations):-

vRA_7_vIDM_Migration_2

The script claimed to add everything but it wasn’t 100% clean. For some reasons it failed to sync my groups and when I got in to take a look it turns out the Group DN was missing.  I didn’t look too deep into this as the previous step gave me enough access to start putting my AD logins back in the right place!