VMware Horizon Community
Russ0lson
Contributor
Contributor
Jump to solution

App Volumes Manager Silent Install

Has anyone gotten App Volumes Manger to do a Silent Install?  I've tried several variations with external and with SQL Express databases and nothing seems to work.  The logs tell me that it looks like it cannot connect to the database.  Manual install with the GUI works, but I need to script the process.

Reply
0 Kudos
1 Solution

Accepted Solutions
da2125
Enthusiast
Enthusiast
Jump to solution

Adding ENABLESTRONGENCRYPTION=0 worked for me.

$Argument = @("/i `"App Volumes Manager.msi`" /l* `"c:\path_to\logfile.txt`" /passive INSTALLDIR=`"C:\Program Files (x86)\CloudVolumes`" IS_SQLSERVER_SERVER=(local)\SQLEXPRESS IS_SQLSERVER_DATABASE=svmanager_production ENABLESTRONGENCRYPTION=0 RESET_DB=0 ALLOW_HTTP=1")

Start-Process "msiexec.exe" -ArgumentList $Argument -Wait -PassThru

View solution in original post

5 Replies
da2125
Enthusiast
Enthusiast
Jump to solution

$Argument = @("/i `"App Volumes Manager.msi`" /l* `"c:\path_to\logfile.txt`" /passive INSTALLDIR=`"C:\Program Files (x86)\CloudVolumes`" IS_SQLSERVER_SERVER=(local)\SQLEXPRESS IS_SQLSERVER_DATABASE=svmanager_production RESET_DB=0 ALLOW_HTTP=1")
Start-Process "msiexec.exe" -ArgumentList $Argument -Wait -PassThru

I have used the above script to install AV Manager remotely many times, but on a brand new install, or SQLExpress I have occasionally run into a certificate issue.
A LASTEXIST CODE of 1603 implies a trust issue with a self-signed certificate. You can search the install log for error messages.

Per VMWare...
ALLOW_HTTP=1 switch is intended to skip the certificate verification for the SQL connection, but it may not be working as intended.
AVM does not trust the self-signed certificate that was generated by the SQLExpress instance.
In the mean time to work around this I believe we will need to use a certificate that is trusted by the OS. I do not know of a way to extract the
current certificate from SQL but a new internally signed or self-signed (generated in Windows and imported to SQL) certificate should work for
this situation. Once the new certificate is generated, configured in SQL, and added to the trusted root (unless the signing CA is already trusted)
it should prevent this failure. Alternatively, if you have a 3rd party signed cert that is already available it should also work.

Reply
0 Kudos
Russ0lson
Contributor
Contributor
Jump to solution

I pretty much came to the same conclusion looking through the various logs.  How to fix it is the thing.  I have a CA in this domain and can issue certificates, but how do I get the SQL Express install to use it.  It seems the Ruby generated certificate is the only thing it can use,  If I run the install and add the certificate to the certificate store, it gets written over when trying to run the install again.

Looks like I will have to take another look at the SQL Server and see if I can get it to use a certificate from the CA.  This is what I tried in the first place.  Back to square one... 🙂

Tags (1)
Reply
0 Kudos
Russ0lson
Contributor
Contributor
Jump to solution

I pretty much gave up trying to use SQL Express as the database since there was no way to modify it to use an SSL cert.  I went back to my original plan of using SQL Server (Need it for Connection Server Event DB anyway) and setting the communication protocol to use the cert issued by my CA.  Still have some minor issues to iron out, but I think it will work.  I wonder if there is anyway to see if there is a bug report on this...?

Reply
0 Kudos
da2125
Enthusiast
Enthusiast
Jump to solution

Adding ENABLESTRONGENCRYPTION=0 worked for me.

$Argument = @("/i `"App Volumes Manager.msi`" /l* `"c:\path_to\logfile.txt`" /passive INSTALLDIR=`"C:\Program Files (x86)\CloudVolumes`" IS_SQLSERVER_SERVER=(local)\SQLEXPRESS IS_SQLSERVER_DATABASE=svmanager_production ENABLESTRONGENCRYPTION=0 RESET_DB=0 ALLOW_HTTP=1")

Start-Process "msiexec.exe" -ArgumentList $Argument -Wait -PassThru

Russ0lson
Contributor
Contributor
Jump to solution

Thank you! That is probably the right answer!  I hope someone will add this to the documentation.  At this point I am going to stick with the SQL Server option since I have that figured out already.  This was my original preference, since I needed it for the Connection Server Event database any way.

Reply
0 Kudos