address a winrm error at deploy time by chaning when the ps scripts u…

[dpcybuck]

Change 2 of 3
After forcing standard public ipaddress SKU. I was met with an error when running the ps script for:
"name": "DC01-CreateADForest2-DCPromo" and its call out to Add-DC2-Domain.ps1

Error message: 'DSC Configuration 'Add-DC2-Domain' 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:

My debugging and research seemed to indicate it was something to do with either the timing of when the permissions to do the WinRM call was made, or the permissions themselves.

So I changed

Deploy-AD/DesiredSateConfig/src/Add-DC2-Domain.ps1
NetBIOSName -DomainFQDN $DomainFQDN)
[System.Management.Automation.PSCredential]$DomainCreds = New-Object System.Management.Automation.PSCredential ("${DomainNetbiosName}$($Admincreds.UserName)", $Admincreds.Password)

To

[System.Management.Automation.PSCredential]$DomainCreds = $AdminCreds

By doing it local, it seemed to avoid the issue that the domain name didn't exist yet, and the script was able to run.

Change 3 of 3
In the process of trouble shooting the issue with add-dc2-domain.ps1, I came across something I thought was the fix. But it seems like a small change for the better any way in:

Deploy-AD/DesiredSateConfig/src/Deploy-ADCS.ps1
certutil -config "DC01.doazlab.com\doazlab-DC01-CA" -setreg policy\Editflags +EDITF_ATTRIBUTESUBJECTALTNAME2

I thought the issue with the running of add-dc2-domain.ps1 and the error running the remote WinRM call might be the hardcoded domain name here, doazlab.com\doazlab-dc01-ca
So i changed that to be more dynamically set:

$localCA = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration' -Name 'Active' -ErrorAction Stop).Active
$caConfig = "$env:COMPUTERNAME.$using:DomainFQDN$localCA"
certutil -config $caConfig -setreg policy\Editflags +EDITF_ATTRIBUTESUBJECTALTNAME2

If you go look at my main branch of the fork, over at: https://github.com/dpcybuck/DO-LAB
Your going to see a lot of search replace changes.

To test this I needed to change all the references to this DefensiveOrigions/DO-LAB /main and /raw/main to point to my repo so that as the arm's and scripts were running they pointed to the modified "azuredeploy-ad.json" and other things.
To test I had to change the encoded URL in readme.md and readme.html to also, point to dpcybuck/DO-LAB fork

Because of permissions I can't create a branch here. But with 3 changes. I was able to execute the DO-LAB deploy from my fork.

[Relkci]

Some nuance here -- I'm pretty sure you may have experienced a race condition as you suggested. However, a change to the PS1 file in DesiredStateConfig src folders don't do anything during build time. The actual PS1s used at build time are in the DSC ZIP files in the parent directory. No changes to the files in the src folder will have an impact at build time unless the zip files in the parent folder are updated. (And you'll have to change the ZIP URL parameters to your repo if you change them).

Add-DC2-Domains.ps1 is a component of Create-AD.zip
Deploy-ADCS.ps1 is a component of Deploy-ADCS.zip.

This is unnecessarily confusing, but how DSC works to deploy multiple configs via PowerShell.

• The ZIP URL is specified in azuredeploy-ad.json parent template and passed when calling createADForest.json along with the script name for each DSC.
• createADForest.json passes the DSC ZIP URL to the PowerShellDSC extension which downloads the ZIP and invokes the DSC.

createADforest.json:

   {
     "name": "[concat(parameters('vmName'), '/PowerShellDSC')]",
     "type": "Microsoft.Compute/virtualMachines/extensions",
     "apiVersion": "2019-12-01",
     "location": "[parameters('location')]",
     "properties": {
       "publisher": "Microsoft.Powershell",
       "type": "DSC",
       "typeHandlerVersion": "2.77",
       "autoUpgradeMinorVersion": true,
       "settings": {
         "wmfVersion": "latest",
         "configuration": {
           "url": "[parameters('createADForestScript')]", <-------------DSC Zip File URL (Create-AD.zip)
           "script": "[parameters('script')]",  <---------- Script PS1 Filename
           "function": "[parameters('function')]" <------- Function inside DSC PS1 script

The Zip file is called from:

azuredploy-ad.json :

// (Line 272...ish)
    "createADForestZip": "https://github.com/DefensiveOrigins/DO-LAB/raw/main/Deploy-AD/DesiredSateConfig/Create-AD.zip",

// (Line 537...ish)
{
  "name": "DC01-CreateADForest1-Services",
  "type": "Microsoft.Resources/deployments",
  "apiVersion": "2019-10-01",
  "dependsOn": [
    "[resourceId('Microsoft.Compute/virtualMachines/extensions', variables('domainController')[0].vmName, variables('domainController')[0].extensionName)]"
  ],
  "properties": {
    "mode": "Incremental",
    "templateLink": {
      "uri": "[variables('createADTemplateUri')]",  <--------PATH TO URL createADforest.json
      "contentVersion": "1.0.0.0"
    },
    "parameters": {
      "vmName": {
        "value": "[variables('domainController')[0].vmName]"
      },
      "createADForestScript": {
        "value": "[variables('createADForestZip')]" <-------DSC Zip File URL (Create-AD.zip)
          },
          "script": {
            "value": "Add-DC1-Services.ps1"   <---------- Script PS1 Filename
          },
          "function": {
            "value": "ADD-DC1-Services"  <------- Function inside DSC PS1 script
.....

(other DSC extensions use the other PS1 filenames and function names respectively)

[Relkci]

While this probably is a race condition that's difficult to narrow down, I tested three deployments today and are all successful. Closing for now.