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
When running SqlAGDatabase with the MatchDatabaseOwner option Test-ImpersonatePermissions gets called. This dumps the fn_my_permissions for the user and checks for IMPERSONATE ANY LOGIN.
That permission does not exist on SQL 2012 and was only introduced in SQL 2014. This causes the test to fail even when equivalent permissions exist.
Verbose logs showing the problem
PowerShell DSC resource MSFT_SqlAGDatabase failed to execute Set-TargetResource functionality with error message: The
login 'LAB\LocalAdministrator' is missing impersonate permissions in the instances 'DAC1N1, SEC1N2, DAC1N2, SEC1N3'.
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : ProviderOperationExecutionFailure
+ PSComputerName : SEC1N1
Suggested solution to the issue
Check for CONTROL SERVER permission. This is given directly or through sysadmin, and grants an implicit IMPERSONATE ANY LOGIN permission.
Check for IMPERSONATE LOGIN permission for each database owner.
The DSC configuration that is used to reproduce the issue (as detailed as possible)
johlju
added
bug
The issue is a bug.
help wanted
The issue is up for grabs for anyone in the community.
in progress
The issue is being actively worked on by someone.
and removed
help wanted
The issue is up for grabs for anyone in the community.
labels
Oct 10, 2018
Details of the scenario you tried and the problem that is occurring
When running SqlAGDatabase with the MatchDatabaseOwner option Test-ImpersonatePermissions gets called. This dumps the fn_my_permissions for the user and checks for IMPERSONATE ANY LOGIN.
That permission does not exist on SQL 2012 and was only introduced in SQL 2014. This causes the test to fail even when equivalent permissions exist.
Verbose logs showing the problem
Suggested solution to the issue
The DSC configuration that is used to reproduce the issue (as detailed as possible)
SQL Server edition and version the target node is running
SQL 2012
SQL Server PowerShell modules present on the target node
SqlServer, SQLPS
The operating system the target node is running
Windows Server 2012
Version and build of PowerShell the target node is running
5.1
Version of the DSC module that was used ('dev' if using current dev branch)
dev
The text was updated successfully, but these errors were encountered: