This is the reopened Pull Request #401, which was reverted.
I investigated the build failures and it doesn't look like they are caused by the changes in this PR.
The logs show that both Set-RsDatabase and Set-RsDatabaseCredentials scripts were executed successfully.
The build fails after a number of attempts to make a POST request to the server resulting in the response with 503 status code each time.
The error message says: “Failed to update the AllowedResourceExtensionsForUpload”.
As I understand, the server fails to get initialized correctly before appveyor script starts to send the requests to it.
Here are some obvious examples of other merged PRs having the build failing with the same error:
Considering all this, I expect that the checks for this PR may fail with the same error again and will require several restarts until successful completion.
Motivation:
Set-RsDatabase script started to result in failure with the following error:
Executing database creation script... Failed!
Invoke-Sqlcmd : 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.)
After investigation, I discovered that this behavior is a result of the recent update of SQL Strict Connection Encryption, which introduced some changes to the defaults of SQL connection encryption.
Since v22, Invoke-Sqlcmd cmdlet from PowerShell SqlServer module has three new parameters:
-Encrypt;
-TrustServerCertificate;
-HostNameInCertificate.
According to the documentation on Invoke-Sqlcmd cmdlet, the default value for -Encrypt parameter is now Mandatory, which seems to be the reason of the connection failure, since currently no value for -Encrypt parameter is specified for Invoke-Sqlcmd invocation in Set-RsDatabase script.
Previously the encryption of the connection depended on -EncryptConnection switch of Invoke-Sqlcmd cmdlet, which was not specified in the script and is considered deprecated since v22 of SqlServer module.
So, basically, if the user has the SqlServer module v22 or higher installed, the Set-RsDatabase/Set-RsDatabaseCredentials script uses the recently updated version of Invoke-Sqlcmd cmdlet, which makes the connection Mandatory encrypted by default.
I consider the ability to specify the newly introduced parameters a required improvment for Set-RsDatabase and Set-RsDatabaseCredentials scripts functionality.
Changes proposed in this pull request:
Added new parameters to Set-RsDatabase and Set-RsDatabaseCredentials scripts according to updated Invoke-Sqlcmd parameters:
-Encrypt;
-TrustServerCertificate;
-HostNameInCertificate.
Refactored parameters specification for Invoke-Sqlcmd invocation.
I also tried to ensure compatibility of the modified scripts with different versions of Invoke-Sqlcmd cmdlet, since it is present in SqlServer , PsSqlLegacy and SQLPS modules:
If user doesn't have SqlServer module v22 or higher installed and no recently introduced parameters were specified, the behavior of the scripts will not be affected by these changes and the connection will not be encrypted (as before);
If the user has SqlServer module v22 or higher installed, PowerShell will most likely use the latest version of Invoke-Sqlcmd cmdlet from this module, and user will have to specify the recently introduced parameters to prevent the default encryption of the connection (-Encrypt=Optional and -TrustServerCertificate is advised);
If no installed SqlServer module v22 or higher was found, but the recently introduced parameters were specified, the user will receive an error, suggesting them to install the SqlServer module v22 or higher required for these parameters support.
How to test this code:
Import the updated module, as described in ReadMe ("Local testing and development");
Manually execute Set-RsDatabase/Set-RsDatabaseCredentials script in different environments (various versions of SqlServer and other modules installed/removed);
Ensure that scripts and parameters work as described.
Note:
This is the reopened Pull Request #401, which was reverted.
I investigated the build failures and it doesn't look like they are caused by the changes in this PR. The logs show that both
Set-RsDatabaseandSet-RsDatabaseCredentialsscripts were executed successfully. The build fails after a number of attempts to make a POST request to the server resulting in the response with 503 status code each time. The error message says: “Failed to update the AllowedResourceExtensionsForUpload”.As I understand, the server fails to get initialized correctly before appveyor script starts to send the requests to it.
Here are some obvious examples of other merged PRs having the build failing with the same error:
385 (comment, build);
393 (comment, build).
Considering all this, I expect that the checks for this PR may fail with the same error again and will require several restarts until successful completion.