Time to Upgrade your Horizon Environment

Is it time to upgrade your Horizon Environment? Is your infrastructure team getting ready to upgrade the vSphere servers? Both questions that you should probably be saying yes to.

If you have read any number of blogs that have been released recently, vSphere 5.5 will be going End of General Support in less that 6 months’ time. Read more here: https://kb.vmware.com/s/article/51491

Upgrade to Horizon 7

So why am I talking about vSphere upgrades in a blog about Horizon upgrades. Well now is the time you need to ask what version of Horizon you are currently running, because if you haven’t updated to Horizon 7 yet then now would be a great time to start planning your upgrade.

You can read the rest of my post on VMware.com. Click Here

Horizon Cloud Pod Architecture 7.1 Update

Last year with the release of Horizon 7 I wrote a blog on the new features of Cloud Pod Architecture (CPA) this included the new scale numbers. You can find that blog here.

This week VMware released Horizon 7.1 and with this release VMware has increased the scale numbers yet again for Cloud Pod Architecture.

Now with Horizon 7.1 Cloud Pod Architecture can support a maximum of 75k sessions across 5 sites.

The table below shows the new update compared with Horizon 7.0

Horizon 7 Horizon 7.1
Total Number of Sessions 50,000 75,000
Total Number of Sites 5 5
Total Number of Pods 25 25

This is yet another great update to VMware’s Horizon and Cloud Pod Architecture.

Configuring VMware Identity Manager with SQL Always On

For the last few weeks I have been testing VMware Identity Manager with SQL Always On database for multi-site deployments. This has been an interesting learning curve as its been some time since I last did anything substantial with Microsoft SQL. Before I start with the VMware Identity Manager I think it is worth calling out these 2 resources that I found really useful for setting up SQL Always On in my Lab.

This is a quick intro in to SQL Always On and how to configure it

https://www.youtube.com/watch?v=VKCqRgqLAuo

This was a useful step by step guide for deploying SQL Always On

http://www.careexchange.in/installingconfiguring-sql-2014-always-on-cluster-on-windows-2012-r2-recommended-way/

Now before configuring VMware Identity Manager with an SQL Always On Database you should be aware that even though there is a database in each of the datacenter’s all Read and Writes operations will take place on the Primary database with in the Availability Group.

Screen Shot 2016-05-18 at 8.41.02 AM

From my testing I found that setting the database to automatic failover worked as expected and the database was only unavailable for a very short time less than a couple of seconds. However, I did find that when I failed the database back after an outage this took a bit more time and I would recommend that any failback is done in a much more controlled manner. In my testing fail back took about 40 seconds so a noticeable difference.

Creating the VMware Identity Manager SQL Always On Database

 

  1. Open SQL Management Studio and log in with sysadmin privileges (This should be done on the primary server)
  2. Click File – New – Query with current connection
  3. In the editor window paste the following SQL Commands
CREATE DATABASE saas

COLLATE Latin1_General_CS_AS;

ALTER DATABASE saas SET READ_COMMITTED_SNAPSHOT ON;

GO

BEGIN

CREATE LOGIN horizon WITH PASSWORD = N'H0rizon!';

END

GO

USE saas;

IF EXISTS (SELECT * FROM sys.database_principals WHERE name = N'horizon')

DROP USER [horizon]

GO

CREATE USER horizon FOR LOGIN horizon

with default_schema = saas;

GO

CREATE SCHEMA saas AUTHORIZATION horizon

GRANT ALL ON DATABASE::saas TO horizon;

GO
  1. Click Execute

Picture2

  1. The saas Database will now be created
  2. Make a Full backup of the database (This must be done before adding the database to an Always On High Availability Group)
    • Right click the database – Tasks – Back Up
  3. Add the database to the Always On High Availability Group

 

NOTE: It is also recommended to make the following changes to SQL

  • Change ‘HostRecordTTL to a lower value than the default in multi-site deployments. 120 seconds is a good value
  • Change ‘RegisterAllProvidersIP’ to false in multi-site deployments

Connect VMware Identity Manager to the SQL Database

During the install of VMware Identity Manager connect to the SQL Database using the following settings

Jdbc:sqlserver://SQLAGListener;DatabaseName=saas

  • SQLAGListener = the SQL Availability Group Listener, in the example below that is SQLProdServer
  • If the secondary SQL server is on a different subnet add the following to the jdbc string
    • multiSubnetFailover=true
      • Jdbc:sqlserver://SQLAGListener;DatabaseName=saas; multiSubnetFailover=true

Picture3

 

Announcing the App Volumes Backup Fling

It gives me great pleasure to announce the first Fling that I have worked on.

Over the last couple months Chris Halstead, Stephane Asselin and I have been working on the new App Volumes Backup Fling.

Picture1

This tool will help customers to backup their AppStacks and Writable Volumes VMDK files using their standard backup tools, normally backup tools do not see these files as they are not seen with in the vCenter inventory unless they are connected to a users virtual desktop.

Below you will find a number of links where you can find more information about the App Volumes Backup Fling.

Fling Download

App Volumes Back Fling

Video Demo

You can also see the full announcement on VMware.com here

For instructions on how to use the Fling see the blog here

Please feel free to leave any feedback for Chris, Stephane and I and any features you would like to see added.

VMware App Volumes Storage Group Improvements with 2.10

Several months ago I wrote a blog post on how VMware App Volumes can be deployed in a multi-site deployment. You can find the blog here.

With the release of App Volumes 2.10, for more information on the release see the information here, there has been a great improvement of the way App Volumes handles Storage replication. In this Blog I will explain how the new storage replication works and how to configure your storage groups to take advantage of this improved feature.

The main change that has happened when when looking at configuring storage groups and datastore’s is the ability to make datastore’s non-attaching. What does this mean, well basically a non-attaching datastore would be a place to create AppStacks but those AppStacks would never be attached to a desktop from this datastore.

The non-attached datastore would then be a member of a storage group or a number of storage groups. These storage groups would then replicate the AppStacks from the non-attached storage to all the other datastore’s with in the storage group.

Picture8

Now how will this look when deploying App Volumes to multiple sites here is a high level architecture of how this could be deployed. As you can see from this diagram at least 1 vCenter from each site will need access to the non-attached datastore.

Picture9

How to create the New Storage Group

First create the non attachable storage

With in the App Volumes Manager click on Infrastructure, Storage then select the storage to be non-attachable then click Make As Non Attachable.

Picture3

Now create a Storage group

With in the App Volumes Manager click on Infrastructure, Storage Groups then click Create Storage Group

Picture4

Give the storage Group a Name. Then select the required options. When choosing the datastore’s make sure to include the datastore’s that will be used to attach the AppStacks from as well as the non-attachable datastore. Click Create.

Picture5

 

As you can see from the image below I have created 2 Storage Groups one for each site and the Non-Attached storage, NFS2, is included in each Storage Group.

Picture10

 

Now all you need to do is create AppStacks on the non-attachable storage and they will automatically be copied to all the other datastores in the storage groups.