Wednesday, May 14, 2014

A Couple of Gotchas Using Out of the Box Content in Application Director

I thought I would share these - not major issues if you know about them. During a recent POC these came to light and hopefully will save others some time and frustration if you are using any of the OOTB (out of the box) content (services, application blueprints, scripts, etc). As I find other gotchas I may add them to this list.

Service - Microsoft .Net Framework 4.0

THE PROBLEM - Service exits with a non-zero errorlevel causing deployment to fail.

DESCRIPTION - I attempted to use this OOTB service to install .Net 4.5, thinking I could just substitute the content property "DOTNETFX40_EXE" and the DOTNET_VERSION property with the newer version (which WILL work - that's not the bug).  However, what I discovered was that .Net installer returns a non-zero error level (for reboot required) and the INSTALL script is a somewhat elaborate cmd file that traps this error and attempts to exit with an errorlevel 0.

The reason for this is that you really want AppD to handle the reboots so that the deployment workflow is resumed properly when the system comes back up.

But, as good intended as this install cmd script is, it fails to exit with an errorlevel 0.  This is because of the way batch/cmd scripts handle vars.  Basically, the manipulation of the errorlevel works but once the conditional loop is closed the original errorlevel is reset, the script exits with a "non-zero" and the AppD workflow fails.

MY FIX - I basically removed the script's conditional loop for trapping the non-zero errorlevel and added "set errorLevel=0" as the last line in the script.  My script looks like this -

@echo off
if exist %WINDIR%\Microsoft.NET\Framework\%DOTNET_VERSION% (
  echo Found %WINDIR%\Microsoft.NET\Framework\%DOTNET_VERSION%, the .NET framework of interest appears to have already been installed.
   echo Skip .NET 4.0 installation. 
) else (
    echo Installing .Net Framework.
    start "Install .NET Framework" /wait "%DOTNETFX40_EXE%" /q /norestart
echo Installation Completed.    
echo This lifecycle always reboots. Rebooting now...
REM log the error level returned by the .Net installer for troubleshooting
echo Errorlevel NOW set to %errorLevel%
REM always exit with a zero
set errorLevel=0

Service - vFabric tc Server v2.7.1

THE PROBLEM - tcServer does not install and deployment fails.

DESCRIPTION - The required properties of the service were provided (or catalog values used where appropriate).  However, the install would fail with the error that the EXTERNAL_TEMPLATE could not be found - and that property is NOT shown as required.  This property is referenced in the CONFIGURE script and you can see on line 36 of that script there's a conditional check for the property and if it's populated then it is used - otherwise, nothing is done.  I believe the problem is with the script itself in that a NULL value for that property isn't evaluated as intended.

MY FIX - Really just put in any value there.  I noticed that the OOTB jPetStore Blueprint sets the value to the darwin_global.conf path (as used in the global_conf property) and that seems to work just fine.  Of course, if you actually HAVE an external template that path should be used.  Ideally, you could modify the service and set the property there so you could just use the catalog value each time.

Monday, May 5, 2014

Use vCAC Static IP Without vCenter Customization Spec

You are probably aware that vCAC has a nice little IP Address Management (IPAM)  capability built in (referred to as "Static IP" in the documentation) that allows you to create IP pools and settings with Network Profiles that can be associated to Network Paths in your reservations.  If so, you're also aware that using this out of the box for VMware virtual machines requires you to use VM templates and vCenter Customization Specifications*.

However, deploying a Windows VM with a customization spec adds time and if all you really want is the IP address assignment it can be annoying to have to use a customization spec.  In fact, the reason I'm posting this information is because I had a request from a customer to speed up the provisioning time while still using the Static IP feature.  The use case was they simply needed to spin up a Windows server for quick QA and then destroy it.  Now, there are some other ways to accomplish this (snapshot/revert comes to mind) but it did get me to thinking of ways to avoid running vCenter customizations on Windows clones to speed up deployment.

One way to accomplish this is with vCenter Orchestrator (vCO).  This post assumes some knowledge of and experience with vCO, but you may be able to put this together without that background.  

In general, a VM deployed with Static IP will have the following machine properties set with the values from the Network Profile:

... and optionally ...

There are other properties for networking, but for our use case we will leverage these specific property values via the vCAC Extensibility Workflows.  These are included with the embedded vCO instance and you will want to go ahead and set that up if you haven't already.  See this presentation for an overview and setup walk-through.

In addition, I will use the Guest Script Manager Package for vCO to run the configurations directly on the new VM's guest OS - note that this requires VMtools to be installed on the guest.

*Static IP is also supported for AutoYAST/kickstart using the guest agent.