We purchased some licenses, and I am trying to deploy our first server.
Here is what we have done.
Created a new Windows Server 2019 VM.
Created a new database on our SQL Always On Cluster.
Attempted the installation of PSU 3.3.5 with the SQL option selected.
We tried a few different connection string options.
Searched the Documentation and forum for a solution.
At no point do we get an error. The installation works. However, the appsettings.json is pointing to the local DB as if I hadn’t selected SQL and the SQL DB is empty. I can log in to the UI using Admin.
Any guidance would be appreciated.
** Edit to add additional information **
We are running the service as an AD service account. That service account does have full access to the new PowerShell Universal SQL DB.
I also noticed that changing the repository path during the installation doesn’t update the appsettings.json either.
What I would suggest would be in your appsettings.json in %ProgramData%\PowerShellUniversal, edit the settings you want. Since the service is installed and running, you won’t need to actually run the installer again. The installer collects those settings and then creates that file and uses it going forward.
The appsettings.json file won’t be updated or replaced on upgrades or uninstalls. You’ll likely end up with an appsettings.json file that is something like this.
I would like to get the installation to work correctly. However, in the interest of getting this working I went ahead and manually configured the connection string in appsettings. The service won’t start and the log isn’t updating.
I noticed this error in the Application Event Log.
CoreCLR Version: 6.0.922.41905
.NET Version: 6.0.9
Description: The process was terminated due to an unhandled exception.
Exception Info: Microsoft.Data.SqlClient.SqlException (0x80131904): A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)
I resolved that problem by adding TrustServerCertificate=True to the connection string.
That resolved the error, but the service still wouldn’t start. Then I remembered that I needed to add MultiSubnetFailover=True due to our always-on configuration.