Use a Clean Blueprint When Importing Existing Infra into vCAC

A customer ran into this recently and suggested I post it on my blog.  He even let me use his screen shots! (Thanks Joseph).

The problem was that after importing some existing VMs it was noted that the Action Items available were limited to just a few selections.

Upon examining the screen shot, you may notice (if you look REALLY hard and use your imagination - sorry about the quality of the screen shot) that the machine's state is "Machine Provisioned" and there are only 3 actions available (Edit, Destroy, Expiration Reminder).

You may notice that the STATE of the machine dictates the available items in the Actions menu - obviously you can't RDP to a powered off server, for example.  Thus, the limited action items were correct, but what was not good was the hung "Machine Provisioned" state for an imported VM.

What had happened here is that the blueprint had a custom workflow stub set up for provisioning and since the existing VM didn't have the guest agent installed, so the workflow just waited.

To avoid any problems like this when importing unmanaged VMs into vCAC, VMware recommends creating a new, clean, simple blueprint - you can always customize the blueprint later if needed with lease times, archive times, workflow customizations (think about adding a disposing custom workflow to simplify decommissioning these existing VMs later).  But for the initial import, keep it clean!

Also, be aware of any custom properties which kick off provisioning workflows associated with build profiles, reservations, provisioning groups, etc as these can also impact your import.

Setting up LDAP with vFabric Application Director and a 2008 AD Domain Controller

Hopefully this will save you some time in setting up - the documentation provides pretty good overview of how to do this, but some details are left out.  This guide should get you up and running for a basic configuration.

First, you will need to run the darwin-cli either remotely or from the AppD appliance.  I decided to run it from my Windows 7 PC for convenience (you will need JRE 1.6 installed, although it did run fine on my PC with JRE 1.7).

I copied the /home/darwin/tools/darwin-cli.jar on the AppD appliance using WinSCP  and using the darwin_user credentials.

To run the client, simply open a command prompt, navigate to the directory where you copied the file and run java -jar darwin-cli.jar and you should be presented with the "roo" interface as in the screen shot below -

Now you can connect to your AppD instance by issuing the following command at the "roo" prompt:

login --serverUrl https://ip-or-fqdn-of-appd-appliance:8443/darwin --username admin

And you will be prompted for the admin password.

Once logged in you can now create an LDAP config.  I used the following command:

create-ldap-config

Then I answered the prompts as follows:

Server Attributes
Use SSL to communicate to LDAP server (ldaps)? [y/N]: n
* Server name/IP: 192.168.1.200
* Server port: 3268 (note, use port 3269 for SSL LDAP)
* Server base DN (eg: dc=example,dc=com): dc=mylab,dc=dias
Does your LDAP server support anonymous query? [Y/n]: n
* Username to use when querying for users: administrator@mylab
* Password to use when querying for users: ********
        Please re-enter the value: ********

User Attributes
  Base DN of user sub-tree (blank to search from root):
* Username attribute: sAMAccountName
* User UID attribute: objectGUID
* User's group membership attribute: memberOf
  User's first name attribute:
  User's last name/surname attribute:
  User's email address attribute:

Group Attributes
  Base DN of group sub-tree (blank to search from root):
* Group name attribute: cn
* Group UID attribute: objectGUID
* Group's member list attribute: member

LDAP Configuration Name
* Enter the name for this LDAP configuration:
A value is required, please try again.
* Enter the name for this LDAP configuration: mylab-ldap

NOTE that I used 3268 for the "Server port" - if you use the default of 389 the test will work, but you will not be able to login using those AD accounts.  As noted, 3269 can be used for an SSL LDAP connection (Thanks, Chris Lennon).

Also note that I did not use SSL for this configuration.  If you want/need to use a secure connection for LDAP, you will need to install the AD server certificate in the keystore on the AppDirector server.  Instructions can be found in the Application Director 5.2 documentation here.

BEFORE you make this active, you should test it as follows:

test-named-ldap-config --configname mylab-ldap --name gfreeman

Of course, replace "mylab-ldap" and "gfreeman" with the name of the configuration you just created and a valid AD login ID.  If all is good, you should see output similar to this:

Now you can activate your LDAP config as follows (THIS IS NOT REQUIRED if you are running AppD 6.0 and have created only one LDAP config):

activate-ldap-config --configname mylab-ldap

 Again, replacing "mylab-ldap" with your configuration name.

Now you are ready to add AD users and groups to your AppD instance.  I won't go into the roles and groups here, that is pretty well documented in the product guide I linked above.  However, here's an example of adding an AD group "Domain Admins" to the "Default" group so that I can log in with my AD user name instead of the local "admin" account (I'm going to assign all roles to the group):

import-ldap-group --name "Domain Admins" --group Default --roles ROLE_CATALOG_ADMIN,ROLE_DEPLOYER,ROLE_SYSTEM_INTEGRATOR,ROLE_APP_ARCHITECT,ROLE_CLOUD_ADMIN --configname mylab-ldap

Again, use your configuration name in place of "mylab-ldap" as before.