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
VMworld in San Francisco is approaching very quickly. It’s a must-attend event for VMware customers, but there is a lot to take in, so I thought I would take a few minutes to highlight some key activities led by my team of End User Computing (EUC) consultants and architects that you won’t want to miss.
Our organization is called Professional Services Engineering (PSE) and is part of the Global Technical and Professional Services Organization. As VMware’s EUC subject matter experts, our team works with some of our largest EUC customers worldwide.
You can read the rest of my post and find out what I will be doing on VMware.com. Click Here
Recently I was asked by a customer if it was possible to add an untrusted Domain to their current VMware Workspace deployment to easily manage access to applications that are currently being managed by Workspace.
Workspace does give you the option to add a non trusted Active Directory Domain by adding a second connector to that domain as an Identity Provider.
The following figure shows the high level architecture of both a Multi-Forest Domain and separate Active Directory Domain utilizing VMware Workspace.
The following steps document how to add a second connector to your VMware Workspace environment.
Before Installing a Second Connector
The following is required before you configure a second connector for Workspace
- Workspace is currently up and running in your environment
- Create a IP address in DNS for the second connector and make sure its using reverse lookup.
Procedure for Adding a Second Connector
- Within vCenter Deploy a new OVF Template
- Browse to the OVF file and click Next
- Confirm the OVF Details and click Next
- Accept the License Agreement and click Next
- Enter the Name of the connector and select the correct location with in vCenter and click Next
- Select the Cluster and click Next
- Select the Resource Pool and click Next
- Select the Storage and click Next
- Select the Disk Format and click Next
- Select the Network and click Next
- On this screen it is important to select Connector Only Install, enter the Network Properties and click Next
- Confirm everything is correct, select Power on after deployment and click Finish
- While the OVF is installing connect to the Admin portal of the original Workspace deployment
- Click on Settings, Identity Providers and Add Identity Provider
- Add the fully qualified domain name of the second connector and click Save
- Copy the Activation Code as you will need this during the configuration of the second connector
- In a second web browser connect to the second connector
- On the Getting Started Page click Continue
- Configure the passwords and click Continue
- Paste the Activation Code and click Continue
NOTE: If you are using self signed certificates then you will need to copy the root certificate from the first Workspace Appliance and paste it in the Root Certificate box that will show up
- Configure the new Active Directory and click Continue
- Configure the User Attributes and click Continue
- Select the users and click Continue
- Select the AD groups and click Continue
- Confirm everything is correct and click Push to Workspace
- Click Finish