This is quite interesting and is fixed in the RTM release but whilst your testing your RC releases of App-V its worth whiling knowing about this gotcha that can occur! as it has caught a couple of my customers out. So lets consider that we want multiple Management servers connecting to a remote SQL server.
The first management server installs correctly and creates the database 100% fine and dandy! All the services start fine and life is good!
However, when adding a second management server after completion of the install and the restart or the server, the application virtualization services fails to start. In the sft-server.txt the server cannot connect to the database
Also in the event viewer we see the following;
Log Name: Application
Source: Application Virtualization Server
Date: 11/08/2008 15:56:27
Event ID: 41494
Task Category: (1)
Failed to establish a connection to the data source: (Server: SoftgridServer, Database: Softgriddatabase).
Also on the remote SQL server for the same time a failure audit will appear;
Event Type: Failure Audit
Event Source: MSSQLSERVER
Event Category: (4)
Event ID: 18456
Login failed for user ‘DOMAIN\x.y.z$’. [CLIENT: 192.168.1.2]
The subsequent management server logon was not automatically added to the Softgrid Database. This can be confirmed by looking at the permissions to the App-V database and confirming if the management servers computer account has access.
To resolve this a machine account must be added for the Management Server.
In SQL Managament Studio for that server Instance where the database is installed, create a new login for the SERVER$. To Do this go to Database Server> Security > Logins right click on the Logins node and Click New Login. In the “Login – New” Dialogue box add the login name NO2MANAGESERVER$ where NO2MANAGESERVER is the name of the subsequent management server.
Once Completed select User Mapping on the left hand side, on the right hand side find the App-V database that was created. In the users mapped to this login, Confirm the MAP tick box is ticked for the database, and that under user and default schema the DOMAIN\LOGINNAME$ is selected (Where LOGINNAME is the Login Name in General).
In the Database role membership for : DATABASENAME confirm that public, SFTeveryone, SFTuser is enabled.
Once completed select OK.
Restart the 2nd management Servers service and confirm that the service can start and no errors occur in the sftserver.txt
Hey Presto that 2nd or additional Management Server should be running and your NLB solutions or other solutions will be up up and away!