You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Details of the scenario you tried and the problem that is occurring:
Enable AlwaysOn fails to configure SQL Server 2016 when both SQL Server 2014 and SQL Server 2016 is installed and having SQLPS module installed for both major version.
The reason is that sometimes the wrong SQLPS module is loaded (because it is the first in the $env:PATH list).
Could not obtain information about SQL Server Service 'MSSQL$DSCSQL2016'.
+ CategoryInfo : ResourceUnavailable: (MSSQL$DSCSQL2016:) [], CimException
+ FullyQualifiedErrorId : ServiceError,Microsoft.SqlServer.Management.PowerShell.Hadr.EnableSqlHADRServiceCommand
+ PSComputerName : localhost
The DSC configuration that is using the resource (as detailed as possible):
The integration tests might need a workaround for this as well. I added this code to the integration tests I am working on. But I revert back to make sure only on SQLPS module is available for the time being.
<# This must be done before SQLPS modules are restored. Otherwise this could complain that the same cmdlets already exist. This is also a workaround for having multiple SQLPS modules installed on the AppVeyor build worker (see issue #806).#>Write-Verbose-Message 'Installing SqlServer PowerShell module.'-Verbose
Install-Module-Name SqlServer -Force
- Changes to xSQLServer
- Moved the code block, that contains workarounds in appveyor.yml, so it is run
during the install phase instead of the test phase.
- Changes to xSQLServerSetup
- Changes to integration tests.
- Moved the configuration block from the MSFT\_xSQLServerSetup.Integration.Tests.ps1
to the MSFT\_xSQLServerSetup.config.ps1 to align with the other integration
test. And also get most of the configuration in one place.
- Changed the tests so that the local SqlInstall account is added as a member
of the local administrators group.
- Changed the tests so that the local SqlInstall account is added as a member
of the system administrators in SQL Server (Database Engine) - needed for the
xSQLServerAlwaysOnService integration tests.
- Changed so that only one of the Modules-folder for the SQLPS PowerShell module
for SQL Server 2016 is renamed back so it can be used with the integration
tests. There was an issue when more than one SQLPS module was present (see
more information in issue #806).
- Changes to xSQLServerAlwaysOnService
- Added integration test (issue #736).
johlju
changed the title
xSQLServerAlwaysOnService: Loading wrong SQLPS when both SQL Server 2014 and SQL Server 2016 exists
SqlAlwaysOnService: Loading wrong SQLPS when both SQL Server 2014 and SQL Server 2016 exists
Dec 23, 2017
Details of the scenario you tried and the problem that is occurring:
Enable AlwaysOn fails to configure SQL Server 2016 when both SQL Server 2014 and SQL Server 2016 is installed and having SQLPS module installed for both major version.
The reason is that sometimes the wrong SQLPS module is loaded (because it is the first in the
$env:PATH
list).The DSC configuration that is using the resource (as detailed as possible):
Version of the Operating System, SQL Server and PowerShell the DSC Target Node is running:
Windows Server 2016, SQL Server 2014 and 2016, WMF 5.1
What module (SqlServer or SQLPS) and which version of the module the DSC Target Node is running:
SQLPS
Version of the DSC module you're using, or 'dev' if you're using current dev branch:
Dev
The text was updated successfully, but these errors were encountered: