0

I am getting below error while triggering a dsc configuration in a AD VM.

VMExtensionProvisioningError","message":"VM has reported a failure when processing extension 'ConfigureActiveDirectory'. Error message: "DSC Configuration 'AD' completed with error(s). Following are the first few: WinRM cannot process the request. The following error with errorcode 0x80090350 occurred while using Negotiate authentication: An unknown security error occurred. \r\n Possible causes are:\r\n -The user name or password specified are invalid.\r\n -Kerberos is used when no authentication method and no user name are specified.\r\n -Kerberos accepts domain user names, but not local user names.\r\n -The Service Principal Name (SPN) for the remote computer name and port does not exist.\r\n -The client and remote computers are in different domains and there is no trust between the two domains.\r\n After checking for the above issues, try the following:\r\n -Check the Event Viewer for events related to authentication.\r\n -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.\r\n Note that computers in the TrustedHosts list might not be authenticated.\

Below is the authentication method used.

[System.Management.Automation.PSCredential]$DomainCreds = New-Object System.Management.Automation.PSCredential ("${DomainNetBiosName}\$($AdminCredentials.UserName)", $AdminCredentials.Password)

Whenever I try to rerun the same dsc config on VM, the issue is not repeating.

Tried adding below PS command in script, however it doesn't help in resolving

winrm set winrm/config/client '@{TrustedHosts="localhost"}'

Hariprasath
  • 3
  • 3

3 Answers3

0

What VM SKU and which region are you deploying? I have the exact same problem with West Europe with Standard_D4_V4. However it works just fine with Standard_D2_V4.

Check out this thread where noone figured out what is the root cause ARM template with DSC extension fails with security error after reboot during create new AD forest and domain

pnowaktty
  • 1
  • This is more appropriately posted as a comment not an answer. See https://stackoverflow.com/help/how-to-answer – CoderBlue Sep 24 '22 at 17:44
  • Great that works for you, we are also using Standard_D4_V4 VM, let me try it out. However, as temporary fix I have added Guestagent to check for DNS after reboot to make sure DNS is up and running. That fixed my issue – Hariprasath Oct 10 '22 at 13:44
0
      SetScript = {

                 Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\WindowsAzureGuestAgent' -Name DependOnService -Type MultiString -Value DNS

            Write-Verbose -Verbose "GuestAgent depends on DNS"
        }

As per MS suggestion, adding this lines to the code fixed our issue.

Hariprasath
  • 3
  • 3
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Oct 15 '22 at 15:18
0

I ran in to the exact same issue. I was trying to deploy a new Windows Active Directory domain via Bicep. The PowerShell DSC configuration failed with that error. The above Set-ItemProperty CMDlet fixed the issue. I added the following to my Bicep file:

resource setScript 'Microsoft.Compute/virtualMachines/runCommands@2021-07-01' = {
  name: 'RunCommand'
  location: location
  parent: vm
  properties: {
    asyncExecution: false
    source: {
      script: 'Set-ItemProperty -Path "HKLM:\\SYSTEM\\CurrentControlSet\\Services\\WindowsAzureGuestAgent" -Name DependOnService -Type MultiString -Value DNS'
    }
  timeoutInSeconds: 30
  }
}

The parent is the 'Microsoft.Compute/virtualMachines@2021-03-01' resource. There is a subsequent PowerShellDSC VM extension resource with depends on this "runCommand" resource. So the VM is created, the Set-ItemProperty command runs, then the PowerShell DSC configuration runs.

The CMDlet sets the Windows Azure Guest Agent service to wait for the DNS Server service before starting. Presumably without this setting the Windows Azure Guest Agent service would start before DNS and name resolution would fail, which screwed up WinRM.

airfrog7
  • 1
  • 1