One of the most advanced portals on the market is the one from VMware, VMware Workspace One. Workspace One if you would dissect it is Identity Manager and AirWatch combined. Identity Manager is the one taking care of offering secure single-sign-on connections for provisioned applications. AirWatch offers the compliance and device management capabilities. Working on a project that involves the whole solution we started out with Identity Manager. This short blog will show you which of the variables needed to deploy are mandatory and which you can play around with.
Story behind the blog
As mentioned before we’re doing a project that involves the whole solution but there is more. In the past, VMware Identity Manager was rather picky with parameters one could use. In the recent documentation, the idea was given that the parameters were not as mandatory as before. Many consultants and customers would be pleased with that as in Enterprises they don’t like predefined names. Enterprises have naming standards for databases and accounts and the lab namings of VMware just don’t fit there. So that’s the story behind the blog, ran into issues and decided we need a proper test to know what is possible.
The version used at the project and during the tests is version 3.1.
As I mentioned before the documentation has changed, in the past with version 2.x there was a strict mention that the database had to be called saas. The login, when you used SQL login, had to be called horizon. These were carved in stone and could not be changed. With the release of version 3.x, a change was noted in the documentation and the script. If you look at the script you notice the first line saying “values within angle brackets are example values” Examples values can be changed or so one would think.
Values within angle brackets (< >) are example values. When replacing the example value,
remove the angle brackets.
CREATE DATABASE <saasdb>
ALTER DATABASE <saasdb> SET READ_COMMITTED_SNAPSHOT ON;
CREATE LOGIN <loginusername> WITH PASSWORD = N'<password>’;
If only life was this simple, it isn’t so the text you see in the script is rather misleading. I will show you what tests I have done and what is still mandatory and what is not.
If we look at the deployment of the appliance there are three of them actually. Of course, there are more variables like the IP details but those are not important and can be changed at will. The parameters that are important to take a look at are;
- SQL Login user
- SQL database name
- SQL schema name (added after new information).
- SQL Port number
As mentioned before the first two were mandatory in the past, horizon for the login and saas for the database name.
I thought it would be a good idea to set up tests to determine the changes if there were any. The first test was the setup like I was running at the customer site. The only difference is that I can’t set up an Always-on SQL cluster. I worked with a SQL Express edition for this. The outcome is the same and so the test I executed were;
- Database name = WorkspaceOne, Schema name = WorkspaceOne, Login = svcWorkspace, Port = 16888
- Database name= saas, Schema anme = saas, Login = serviceuser, Port = 16888
- Database name = saasdb, Schema name = saasdb, Login = horizon, Port = 16888
- Database name = saas, Schema name = saas, Login = horizon, Port = 16888
- Database name = saasdb, Schema name = saas, Login = serviceuser, Port = 16888
So I had four tests and in theory, at least number four would work fine as that one has the values VMware had in the documentation. After posting the blog I got information and noticed that I forgot to test the schema name apart from the database name. I always had them aligned. I know now there is a difference, tomorrow I will do a few extra tests.
Test 1 – Everything is different
The first test is like the one at the customer site, every variable is changed from what is documented by default. I changed the names a bit as it is of no use to use the variables used there.
After deploying the appliance I connected to the web-page and set the connection string for the external database. Mind you when working with a clustered environment you need more parameters in the string. For this test, those parameters are not important. So I used saasdb instead of saas, horizonuser instead of horizon and 16837 instead of 1433.
The database setup goes wrong with this setup. If we look at the database tables you see that there are only a few tables created. This is the customer setup and at least I now have reproduced it in a lab.
Test 2 – Login and port number are different
During the second test, I changed the database to saas. The other parameters are left unchanged.
With the database name named saas I completed the setup. The naming of the database seems to be a very important part of the setup.
Test 3 – The database and the port is different
With the previous test I changed the database name and it finished without an error. To see if the database name is the only parameter that is important I deleted everything and started over.
I set up the environment with the username horizon, as VMware documents, and I changed the database name to something foreign together with the port number. As you can see below the database setup goes wrong with this test. The idea that the database name is the one doing this is growing.
The database tables that have been created are similar to the one you saw in test 1. Only a handfull are created.
Test 4 – only the port is different
The fourth test is the one with all the VMware settings but with the port changed. This is one that I knew would work as the port was the least of my concerns.
So if we look at the database afterwards we see all the tables are created as expected and the database setup finishes fine.
Test 5 – schema name is saas, the rest is changed
After receiving some information I did another test where I keep the schema name to saas, the default value and change all the other settings. The connection check went fine.
The setup also works with this setup, so the database schema name is the one that is still mandatory.
After conducting all the test I can conclude that still with version 3.x there is a mandatory parameter. The database schema name parameter is not one you can choose, you are forced to use “saas” as the database schema name. All the other parameters are to be changed at will, including the database name. I think that the fact we still have a mandatory parameter is rather shocking, not something we can have in Enterprise environments.
After some information from development, I need to state that the schema name is important, it has to be saas, the database name, however, is allowed to be changed. I will test this tomorrow to see if the claims are true.. This should be documented more clearly.