In the previous Unattended Installation Citrix Provisioning Services articles I explained how PVS can be installed automated via scripts. In this part I’m going to describe some of the peculiarities I have encountered with the unattended installation of Citrix Provisioning Services.
SQL Server with an specific Instance: Creating the database while an empty database already exists
This one was the first I encountered and logically by accident, because the change you have an existing empty database on your SQL server is pretty rare. However the case is that strange that I would like to inform you about this fact. As described in part one you have two options to set-up a PVS database. The first is using a SQL script created with dbscript.exe, the second is using the PVS Configuration Wizard to create the database. When you use the second method using the unattended methodology something strange is happening. In the unattended methodology (see all the information is part one) one the required settings you need to specify is the database name. I created this for one of my customers in my own test/demo environment and it was working fine. However when the scripts were moved to the customer infrastructure, I got same strange errors and behavior during the configuration phase. When I checked that the database was there, but was completely empty. In the same time a colleague asked me if he know who filled his database. In some way using the unattended the wrong database was filled with the PVS content.
Logically I tried to reproduce and we found out that PVS uses another database if that one is empty and created earlier than the PVS database. I retested this scenario in my environment and the behavior was not there, so there was a need to find out which difference in this environment was causing this behavior. Between the environments there two differences, another SQL version (SQL 2008 v SQL 2012) and the instance usage (a specific instance versus a default instance). As the script should run on the customer infrastructure I also build a SQL 2008 with a specific instance and I got the same behavior. It looks like the behavior is caused by using a specific instance; the behavior is investigation by Citrix during the moment of writing. If new information is available I will update the article according.
SQL Server with an specific Instance: Joining the farm while more PVS databases are available
This scenario could happen in more infrastructures and is a difficult one. I noticed this behavior during testing of the installation scripts, while running some tests on the earlier installed PVS infrastructure. I tested the farm creation based on the configuration wizard database creation and that was successful, next was joining a second farm to this PVS farm using the unattended join script. While this script was already run successfully in earlier test I was expecting a successful run and the installation feedback was also indeed reporting successful. However the server did not show up in the PVS farm (checking the PVS Console on the first server of this other farm). When I started the console on the just installed server, it connected without any problem to a farm, however it was the already existing farm, while the answerfile was really pointing to the second database.
Again this is only happening with a SQL Server with a specific instance, so it looks likes the same bug as with the creation of the database. If the installation finds another database on the server that was there earlier that one is used.
DBSCRIPT: Adding the GUID to .SQL script
Till know those above are most likely bugs in the product, this one is not a real bug. However it has again some strong behavior our PVS acts with the available information. This one showed up when using the SQL script and the tasks to make him useable for more environments using variables. As already described in part three <<LINK>> of this article series I made an sample SQL script with dbscript.exe and thought I found all the parts that should be variable. The replacement of the variables worked fine in my environment, but as soon we used the script in the customer infrastructure the installation/configuration of the first server connecting to the already set-up database failed with issues. First I saw they forgot to add the installer account they used to the AD group they had specified in the configuration as the Farm Administrators. At a first glance this looked like the issue has the wizard continued and services were configured. However at this stage we got an error in the log about Site Creation Failed and again some error messages about unknown user name or password. Actually as site should not be created as the answer file were using the parameter ExistingSite. When we run the wizard manually the already available site in the database did not show up.
Actually we dived pretty deeply into it and thought about different security rights on the SQL server, but could not found anything that was related. As manual actions were working as expected, even creating a database via the configuration wizard manually, we tried as a kind of last resort creating a SQL script using dbscript.exe and tried to connect to that one. When that was working fine, we do this was not a SQL security issue. Comparing the scripts we found out that the only difference was a kind of GUID, in the AuthGroup table. We checked our suspect, the AD guid and we were on the right path. PVS also adds the AD GUID of the group to check if the rights are correctly. This sounds logical, but we were misled by the fact that it was stopped earlier because the installer account was not member of the configured AD group (with that different GUID). So PVS is using for some parts the actual group name, while for other parts the AD GUID (stored in the database) is being used.
As described in article three we changed the script to determine the actual GUID of the provided group and add this using variables in the actual .SQL we are executing and the issue was solved.
No License Server filled in with DB created with the .SQL script
When you created the database using the .SQL script based on the PVS dbscript.exe, followed by using an answer file the license server is not added to the database although the license server is specified within the answer file. I did not have any clue why this is happening. I thought the parameter is not taken into account; however when I removed it from the answer file the installation stalled so it’s taken into account but someway not set. I have added a PowerShell SnapIn PVS command on the Farm setting the License Server (again) at the end of the script, which is working fine.
Re-installation without emptying the database / removing login accounts
When you are building scripts for the unattended installation, logically you roll-out several times for troubleshooting the scripts and add error handling for example. During this process some of my rollouts failed with strange error messages about not specifying a PVS store name, while the store name was available in the answer file. After some troubleshooting I found out what was going wrote, which was pretty obvious. Unfortunate the error message does not reflect what the actually issue is. I was running the first server script (where the database was created using the .SQL script), where you specify to set-up the PVS store for the PVS farm. I did not remove the database, however the initial farm set-up was already done with the same name for the PVS store. So logically the PVS store cannot be created again as this was already mentioned in the database. It is a pity that the error message is not directly stating you in that direction and it looked that sometimes this part is ignored. The solutions is easy, just re-create the database when you are testing the first server script.
Conclusion
With the last article I close the article series about the unattended installation of Citrix Provisioning Services. In the first two articles I showed how you can install PVS unattended. In the third article I explained how you can add the possibility to re-use the scripts for different environment based on PowerShell variables. This last article summarized some not expected behavior I encountered during the creation and testing of the unattended scripts.