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
|Total Number of Sessions
|Total Number of Sites
|Total Number of Pods
This is yet another great update to VMware’s Horizon and Cloud Pod Architecture.
Earlier this Month VMware released the latest update to the Horizon Client for the iPad. Version 4.2 can be downloaded here
This brought a number of great updates but my favorite is the ability to use a Mouse with my iPad, yes that’s right when connected to a Horizon desktop or application I can now use a Bluetooth connected mouse.
The mouse that is supported is the SwiftPoint GT mouse, this is a great mouse and fantastic from people that travel with an iPad Pro
This mouse is extremely small but works really well, I have been using the iPad for travel for a few months now and it has been working well but when connected to a virtual desktop there is definitely something missing and that’s the mouse. I have tried to use the Apple Pencil and that works OK but it’s not as good as a mouse. The SwiftPoint GT fixes that problem and now I feel that when traveling with my iPad I have everything I need to do my job as if I was at my desk.
If you would like more details on the SwiftPoint GT mouse you can find it here.
Recently VMware released Identity Manager 2.7 and with it there is a new requirement when clustering the Identity Manager behind a load balancer.
It is now required that you have a minimum of 3 Identity Manager Appliances with in the cluster.
The diagram below shows this minimum requirement.
This will also help when upgrading to future version. If there is a minimum of 3 appliances then it will be possible to upgrade these appliances one at a time with out any downtime.
To upgrade with a minimum of 3 in the cluster you and simply take a single appliance out of the load balanced pool upgrade the server and then add it back to the load balanced pool. Simply do this for each appliance in the load balanced pool and not down time will be required.
With the release of VMware Horizon® 7 and VMware Identity Manager™ 2.6, it is now possible to configure VMware Identity Manager to work with Horizon Cloud Pod Architecture when deploying your desktop and application pools over multiple data centers or locations.
Using VMware Identity Manager in front of your VMware Horizon deployments that are using Cloud Pod Architecture makes it much easier for users to get access to their desktops and applications. The user has just one place to connect to, and they will be able to see all of their available desktops and applications. Identity Manager will direct the user to the application hosted in the best datacenter for their location. This can also include SaaS applications as well as the applications that are available through VMware Horizon 7.
For the full blog please see my blog on VMware.com
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
This was a useful step by step guide for deploying SQL Always On
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.
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
- Open SQL Management Studio and log in with sysadmin privileges (This should be done on the primary server)
- Click File – New – Query with current connection
- In the editor window paste the following SQL Commands
CREATE DATABASE saas
ALTER DATABASE saas SET READ_COMMITTED_SNAPSHOT ON;
CREATE LOGIN horizon WITH PASSWORD = N'H0rizon!';
IF EXISTS (SELECT * FROM sys.database_principals WHERE name = N'horizon')
DROP USER [horizon]
CREATE USER horizon FOR LOGIN horizon
with default_schema = saas;
CREATE SCHEMA saas AUTHORIZATION horizon
GRANT ALL ON DATABASE::saas TO horizon;
- Click Execute
- The saas Database will now be created
- 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
- 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
- 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
- Jdbc:sqlserver://SQLAGListener;DatabaseName=saas; multiSubnetFailover=true
This week I deployed VMware Identity Manager in my lab to do some testing with SQL Always-On and F5.
When I configured VMware Identity Manager to work with F5, something I have done many times in the past, I came across and issue. After I logged out I couldn’t log in to VMware Identity Manager with a domain account but could login with a local account. The issue is below
After testing a few things and trying to figure out the issue I found that when changing the FQDN of VMware Identity Manager there is a new step that need to be done.
Basically after changing the FQDN go back to the Admin UI.
Click Catalog and then settings.
From there select New End User Portal UI and click Enable New Portal UI
After this log out and you should now be able to log back in with a domain account.
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.
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.
App Volumes Back Fling
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.