Tag Archives: Horizon

VMware Series 2013 – EUC and vDC Ready and Waiting

Over the last couple of weeks I’ve been fortunate to represent ZettaGrid, as a Platinum Sponsor of the VMware Series 2013 road shows in Melbourne and Sydney. The event has also been held in Brisbane and Canberra, and finishes up in Perth this week.

The road shows main theme is showing off VMware’s End User Computing pillar and how it’s finally ready for serious adoption. After almost two years of hype and missed release schedules, Horizon Workspace and View 5.2 has arrived and delivers on its promise of streamlining the day to day tasks of todays mobile worker…View has been around for a while, and there are plenty of other solutions that can deliver SaaS/Remote/Thin Apps…but with the addition of Data (Project Octopus) and Blast (AppBlast) into the stack, the suite delivers significant enhancements over other options in the market.

The video above may seem a little unrealistic (certainly a Mirage Laptop re-image can’t happen that fast with current internet speeds) and over the top, but the reality is that it’s a scenario that is true to life and possible with Horizon. The keynotes of the road shows have focused on EUC and it’s with a great sense of pride that what’s been demoed on stage, and in the presentation videos is something that ZettaGrid can deliver to it’s clients today. The reality is that what I blogged about last year just after VMWorld 2012 on the EUC Revolution is finally happening and is available.

I’ve even become a convert to VDI! That is personally a huge realization that the technology that View 5.2 uses to deliver remote desktop instances over PCoIP or HTML Blast is mature enough for adoption. Seamless device hopping while maintaining a desktop state is possible on iPads/iPhones, MAC and Windows end points…or any compatible HTML5 capable browser.

ZettaGrid is also showing off the power of it’s automation technologies to provision VMware Backed vCloud Powered Virtual Datacenters…this is being shown in real time during a 15 minute presentation at the road shows…and (minus any presenter related ID10T issues), shows that a scalable, flexible vDC based upon an initial set of defined compute, network and storage options can be delivered just minutes after clicking confirm.

Again, something that used to take a day or so in provisioning, now takes minutes and the value proposition for any business thinking of moving their on premise servers to a VMware vCloud vDC platform over other Public Clouds like AWS, Azure or Rackspace is the fact that it’s VMware end to end…and for most people that equates to a smoother migration/setup and a sense of familiarity in the hyper-visor technology. It’s an exciting time to be in a position to help deliver these technologies to companies…they are ready and waiting for consumption!

Quick Fix: Horizon Workspace : Error creating admin user “ hostname in certificate didnt match: !=”

I came across this issue yesterday while trying to deploy a new instance on Horizon Workspace 1.0 in a POC environment. Having installed the vAPP a couple times previously, I made sure that DNS (forward and reverse entries) was setup correctly as per my first blog post on Horizon Workspace setup.

The vAPP deployment went through without any issue and appeared to complete successfully. When it came time to go through the Workspace Setup Wizard and configure the database (internal in this case for the POC) I received the following error:

Error creating admin user “ hostname in certificate didnt match: !=

A pretty self explanatory error, but what caused it? A little digging around various blog posts I came across a few similar examples. In my case (as listed in that post) logging into the configurator-va cli as root and running the following commands fixed my issue.

So this command is run during initial setup via the configurator-va during the deploying SSL part of the install. For some reason when I checked my gateway-va before re-running the command the SSL cert was mismatched to the internal DNS name of the server and not the FQDN initially chosen during the setup.

At this stage, I don’t know why that happened (suspect reverse DNS issues), but after I ran the commands above the gateway-va SSL cert was relative to the FQDN and the internal database creation was successful.


How-To: VMware Horizon Workspace 1.0 vApp Install – Part 1

I’ve been waiting to deploy Project Octopus for the best part of 18 months… I’m still actively running the Octopus Beta and for my personal use/internal testing and it’s lived up to expectation for the most. There have been a number of bugs identified and general limitations with the Beta release builds, but all in all it does the job. I was a little frustrated with the time to market for the initial GA of the product, and even more so when it was incorporated into the Horizon Suite of products. Feel VMware has missed getting to a key part of the market with DropBox like clones popping up everywhere of late.

Having just gone through my first deployment of the Horizon Workspace vApp (…and failed) …put together with the fact there isn’t much on the internet in terms of walkthroughs, I thought a blog post would be handy. This won’t be a HA scaled out deployment as I only need to support 100-500 internal users for the moment, but the on-line docs do touch on Advanced Configuration tasks.

There is quiet a bit to the deployment, so this post will only touch on the key points and any additional items the docs don’t cover clearly. While starting to write out this post it became clear this would need to be a multi-parter…in this part I’ll go through initial DNS configuration requirements, deploying the Horizon Workspace vApp and going through the initial configuration wizard.

Initial Design Action Items:

Reading through the online docs the key takeaway is that you need to get your DNS right…that is, allocate the vApp VM IP addresses and ensure the reverse IP’s match up. You also need to think about the FQDN for internal and external access.

FQDN: xx.horizon.domain.com -> (split DNS employed relative to the vCenter/ESX environment to ensure internal and external access is achieved without the VM’s having to route publicly)

 Caution: After you deploy, you cannot change the Horizon Workspace FQDN.

This was the mistake I made which meant I had to redeploy the vApp and get the FQDN right. When it came time for me to publish the gateway-va externally the external host name redirected the the FQDN specified during setup which I configured as an internal address.

Deploy The vApp:

Once you download and acquire the OFV from the VMware Download page, deploying the vApp is straight forward, however one thing to point out is that you need to ensure you have a vCenter Datacenter IP Pool configured so that the vAPP can correctly allocate IP/DNS settings to the VM’s. The OVF deployment screen below, warns you about that.

I had a previous IP Pool setup for my vCOP’s install, but there wasn’t a requirement to populate the DNS settings. That part is critical for this setup to be successful as the vApp will use these settings to configure DNS on the VM’s…without it, the initial configuration will fail due to a DNS lookup error when the configurator VA tries it’s first lookup against the VA IPs. You will need to restart the VA if any errors are detected.

Initial Configuration:

Once the vApp has been deployed you should only have the configurator-va powered on. (do not power on the other VA’s). Log into the vCenter console for the configurator-va and go through the initial Configuration Wizard.

Once enter is pressed the wizard kicks off the the DNS checks mentioned above are executed. You are then prompted to enter in the root password to all VA’s in the vApp (this also becomes you default login password). From there you enter in your SMTP relay, Workspace FQDN and vCenter credentials.

From this point the wizard goes through and configures the remains VA’s, allocates the root password throughout the different systems and creates the SSL certificate services. This process can take up to 30-40 minutes depending on the your underlying storage. Viewing the process through vCenter you can see a summary of what’s taking place…interestingly (similar to vCloud Director managed VM’s) the VA’s management is taken over by the configurator-va and through that all the wizard actions take place.

Once complete you are presented with the message below and you are ready to continue configuring Horizon Workspace from the configurator-va web console.

Part 2 will follow and run through setting up initial Horizon Workspaces users, groups, services and policies.