dsccommunity/SqlServerDsc

Problem description I am installing SQL Server 2025 with AS feature. But currently encountering an error when connecting to AS There we're also a line on the logs that says it detected the AS feature and then fail the deployment when connecting. I am already using lates versions of SqlServerDsc and SqlServer modules. Also tried leveraging the property: FeatureFlag: "AnalysisServicesConnection" This particular error didn't occur on SQL Server 2022 and lower. Verbose logs Failed to invoke DSC Set method: PowerShell DSC resource DSC_SqlSetup failed to execute Set-TargetResource functionality with error message: System.InvalidOperationException: Failed to connect to Analysis Services instance 'mrfmrp-dsql00'. (SQLCOMMON0021) ---> System.Management.Automation.PSArgumentException: Cannot find type [Microsoft.AnalysisServices.Server]: verify that the assembly containing this type is loaded.\r\n at System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)

Context In PR #2453, the Sid parameter was added to the SqlLogin resource to allow setting the security identifier (SID) for newly created SQL logins. However, the SID validation logic for existing logins is being removed from Test-TargetResource to avoid infinite drift loops, since SQL Server does not support changing a login's SID after creation. This issue tracks the work to re-add SID validation and implement login recreation functionality in a future PR. References: PR: #2453 Comment: #2453 (comment) Original issue: #1470 Requested by: @johlju Requirements 1. Re-add SID validation to Test-TargetResource Check if the Sid parameter is bound Compare the current login's SID with the desired SID Return $false if they don't match (when AllowRecreate is $true) If AllowRecreate is not set and SIDs mismatch, emit a warning but don't fail the test 2. Add login recreation logic to Set-TargetResource When Sid is bound and the login exists with a different SID Check if AllowRecreate para

Problem description I try to execute some SQL Command on an different Server (MSX). With DSCv3 I get always permission denied error. Also if I use Credential parameter i get the same result. The Resource looks like: If I use the same with DSCv1 and a fresh generated MOF file and the same credentials I get success and the job was added. The MOF file was also executed with DSCv3. /* @TargetNode='MSSQL176' @GeneratedBy=xxx @GenerationDate=02/16/2026 17:56:54 @GenerationHost=MSSQL176 */ instance of MSFT_Credential as $MSFT_Credential1ref { Password = "1234567890"; UserName = "domain/installuser"; }; instance of DSC_SqlScriptQuery as $DSC_SqlScriptQuery1ref { Id = "Unit_Test"; ServerName = "MSSQL002"; QueryTimeout = 300; PsDscRunAsCredential = $MSFT_Credential1ref; ResourceID = "[SqlScriptQuery]MSXTest"; SourceInfo = "C:\\Temp\\set-mofmsx.ps1::22::9::SqlScriptQuery"; TestQuery = "IF(NOT EXISTS(SELECT 1 FROM msdb.dbo.sysjobservers JOIN msdb.dbo.sysjobs ON sysjobs.job_id = sysjobser

Problem description After a SQL Server 2025 instance restarts during SecureConnection integration tests, connections cannot be established to the database instance, causing test failures. This problem seems specific to service restarts during the test lifecycle when running against SQL Server 2025. We have temporarily disable the integration tests for SecureConnection targeting SQL Server 2025 to avoid CI breakage until this is fixed. Longer term, once #2304 and support for SQL Server 2025 are resolved, tests should be refactored and re-enabled. See attached logs for detailed error output. Verbose logs 2026-01-27T13:08:52.9676388Z �[95mRunning tests from 'D:\a\1\s\tests\Integration\Resources\DSC_SqlSecureConnection.Integration.Tests.ps1'�[0m 2026-01-27T13:08:52.9676860Z WARNING: This will change your machine environment variable PSModulePath but can be restored by running the command 2026-01-27T13:08:52.9677242Z Restore-TestEnvironment. 2026-01-27T13:08:52.9677581Z WARNING: There

Problem description Connect-Sql should support finer control for EncryptConnection and optionally for TrustServerCertificate properties on the ServerConnection object when connecting to SQL Server. Currently, if the Encrypt parameter is not specified, EncryptConnection is not explicitly disabled, and there is no way to opt in or out of TrustServerCertificate unless the property is set after object creation. Improvements should: Explicitly disable EncryptConnection when -Encrypt is not present, to clarify intent. Add an opt-in parameter to control TrustServerCertificate, defaulting to disabled if property exists and not explicitly set. Switch logic depending on SQL Server defaults, e.g., SQL Server 2025 has TrustServerCertificate enabled by default (secure-first). This should align with defaults based on the target SQL Server version. Reference/example code to improve: # localization string IgnoreServerCertificateTrust = Ignoring server certificate trust; server certificate trust