Incorrect time zone on vCloud Director 5.5 sysprepped VMs

In our vCloud Director 5.5 instances I’ve noticed that all of our Windows VMs that are sysprepped by vCloud Director have their time zones set to GMT Standard Time.

VMs in vCloud Director will be sysprepped if “Changed SID” is enabled.  “Enable guest customization” must be selected as well for any guest customization to occur.

2014-06-23_20-22-40

After the guest are customized the time zone resets from the original time zone to the following:

2014-06-20_12-19-07

vCloud Director syspreps the VMs by injecting an unattend.xml file into the guest and passes this file to sysprep.   Here is the time zone section of this unattend.xml file in VM that was sysprepped by vCloud Director:

2014-06-20_8-50-35

Prior to vCloud Director 5.5, the unattend.xml file was on the vCloud Director cells, but I was unable to find it on vCloud Director 5.5 cells.  I was thinking that I could perhaps edit the unattend.xml file on cell and correct the problem.

I imagine this issue could be solved several different ways, but for now I decided to edit the customization script and have it set the time zone correctly.  We use vCenter Orchestrator to build the customization script, but here is a simple example that sets the time zone to “Mountain Standard Time”.

2014-06-20_12-22-41

if "%1%" == "precustomization" (
  goto end
) else if "%1%" == "postcustomization" (
  tzutil /s "Mountain Standard Time" 
)
:end

This is a temporary fix until VMware can resolve the issue.  I’ve submitted a service request to them and will update this post when I receive an answer.

 


Using Powershell to create Veeam Backup jobs of vCloud vApps

When creating Veeam vCloud backup jobs you have a lot of options.  You can specify the entire vCloud environment, an organization, an org vDC, etc.  Usually we create backup jobs that point to a vCloud organization.  This is nice because the next time the Veeam backup job runs, it will pick up any new vApps that have been created in vCloud since the last backup job  run.  Unfortunately, we have one organization that always has failures (all other backup jobs are fine), and it seems like each time the backup job is ran, it’s different vApps that fails.  If I create a backup job with a single vApp from this same org, it always succeeds.  As a test I wanted to create a single backup job for each vApp in the org, but obviously doing this by hand would be a pain so I decided to look at Veeam’s Powershell providers.  Basically the idea is to see if there is any difference between running one Veeam job with all vApps in the org or running many Veeam jobs at once with each job containing a single vApp.

This was a quick script that I tried to create as fast as possible.  I did no research and read no documentation (beyond Powershell’s built-in documentation) so it’s probably not optimal.  It’s as bare-bones as possible as there is no error handling, etc.

# Set environment variables
$vcloudServerName = "cloud.vmware.local"
$backupRepoName = "repo.vmware.local"
$proxyName = "VMware Backup Proxy"
$orgVdcName = "Test Org vDC*"

# Set Veeam “Backup Infrastructure” items
$vcdServer = get-vbrserver -name $vcloudServerName
$backupRepo = Get-VBRBackupRepository -name $backupRepoName
$proxy = get-vbrviproxy -name $proxyName

# Get all vCloud vApps. Doesn’t seem like you can provide more than one filter so need to filter out the org/org vDC vApps with another command.
$vcdVapps = Find-VBRvCloudEntity -Server $vcdServer -vApp

# Get all of the vApps in the org vDC
$vcdVapps = $vcdVapps | ? { $_.Type -eq 'vApp' -and $_.Path -match $orgVdcName }

# Create a Veeam job for each DCO vApp, and store each job into $vbrJobs
$vbrJobs = $vcdVapps | % { Add-VBRvCloudJob -name "Test Org vDC - $($_.name)" -description "Created automatically by Powershell - $([environment]::username)" -entity $_ -BackupRepository $backupRepo }

# Set the proxy for each job.  This is only if you don't want automatic proxy selection to take place. Veeam always selects a proxy halfway across the world so we need to manually select a local proxy.
$vbrJobs | % { set-vbrjobproxy -job $_ -proxy $proxy }

# Create a new job schedule
$jobScheduleOptions = New-VBRJobScheduleOptions

# Set the daily run time to run at 11 PM.
$jobScheduleOptions.OptionsDaily.time = "$(get-date -format d) 11:00 PM"

# Apply the schedule to all the jobs
$vbrJobs | % { Set-VBRJobScheduleOptions $_ -options $jobScheduleOptions }

# Enable the schedule
$vbrJobs | % { Enable-VBRJobSchedule -job $_ }

# Set the jobs to disabled (This was just done so I could verify that the jobs looked good before than ran)
$vbrJobs | % { Disable-VBRJob -job $_ }

# You can enable the jobs with
$vbrJobs | % { Enable-VBRJob -job $_ }