WaitforADDomain: Get-Domain in WaitforADDomain

[oradcliffe]

$domain = Get-Domain -DomainName $DomainName -DomainUserCredential $DomainUserCredential

Should this be Get-ADDomain?

Get-ADDomain -Identity?

I am trying to figure out why deploying DSC configured AD with Azure template keeps failing on the wait for AD domain when it's there, but it says "MSFT_xWaitForADDomain failed to execute Set-TargetResource functionality with error message: Domain NOT found..."

[iainbrighton]

@oradcliffe As per #73 - can you ensure you're using the whatever the local 'Administrator' password was (before the domain promotion) for the DomainUserCredential in xWaitForADDomain.

[iainbrighton]

@oradcliffe Get-Domain is an internal function used to query for the domain.

[oradcliffe]

@iainbrighton Oh thanks for that; I kind of thought that was the case but didn't see that.

I have the following in my template:

"resources": [ { "name": "Microsoft.Powershell.DSC", "type": "extensions", "location": "[resourceGroup().location]", "apiVersion": "2016-03-30", "dependsOn": [ "[resourceId('Microsoft.Compute/virtualMachines', parameters('GTM-DC01Name'))]" ], "tags": { "displayName": "DC01DSC" }, "properties": { "publisher": "Microsoft.Powershell", "type": "DSC", "typeHandlerVersion": "2.9", "autoUpgradeMinorVersion": true, "settings": { "wmfVersion": "latest", "configuration": { "url": "[variables('DC01DSCURL')]", "script": "[variables('DC01DSCscript')]", "function": "[variables('DC01DSCfunction')]" }, "configurationArguments": { "DomainName": "[parameters('domainName')]", "Admincreds": { "Username": "[parameters('GTM-DC01AdminUserName')]", "Password": "PrivateSettingsRef:AdminPassword" } } }, "protectedSettings": { "Items": { "AdminPassword": "[parameters('GTM-DC01AdminPassword')"

GTM-DC01 is the same parameter that I use for the local admin credentials on this particular machine, so they should be the same.

Here's where they are referenced in my DSC script:

xWaitForADDomain DscForestWait { DomainName = $DomainName DomainUserCredential = $DomainCreds RetryCount = $RetryCount RetryIntervalSec = $RetryIntervalSec DependsOn = "[xADDomain]FirstDS" }

And $DomainCreds is being created after importing resources in my DSC script like this:

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

[oradcliffe]

@iainbrighton Rather than using the xWaitForADDomain maybe I can just use a custom script section in DSC that checks for the domain and the rest depends on that? Would there be any issues with that approach?

[oradcliffe]

@iainbrighton - I dug around a bit to see what xWaitForADDomain required and noticed that the domain credential was optional - after removing that it seems to have worked, but I'm going to nuke that resource group and try again to see. Is there any reason to keep that parameter in there?

[iainbrighton]

@oradcliffe I'm not sure that you need the xWaitForDomain on a domain controller? The xADDomain (or xADDomainController) resource should wait until the domain is created/joined.

There may well be an issue using the xWaitForDomain resource on a domain controller itself (I'm not sure anyone has tried that!)?

[oradcliffe]

Oh, OK, that makes life easier then. I was just following some of the active directory quickstart templates and noticed that they were using xADDomainController to wait for the domain on domain controllers prior to the xPendingReboot module.

[oradcliffe]

Do you happen to know if there's a problem passing credentials into DSC if the password is stored in a key vault and referenced in the parameters JSON file? Or does that require some access to the key vault other than just whoever is running the template's @outlook or whatever account?

[oradcliffe]

I am seeing similar issues when trying to create a second DC using xADDomainController - could this be an issue with credentials?

I have one DC that comes up, domain is there, hooray. I have a server that successfully joins the domain using a JSON domain join extension, so I know the domain is up and available.

The second DC I am trying to create with another DSC extension - I have it depending on that first server joining the domain, so at that point I am sure the domain is available, yet I get an error saying that the domain can't be found.

I am using the same credentials throughout, with the password being stored in a keyvault in Azure so as not to have it in plain text on github. So the first DC machine is created - local admin1, pass1. After the domain is created, it uses these same credentials, correct? domain\admin1, pass1. Now, if I use those same credentials to make the second DC, those should theoretically work right? Unless it is trying to create another domain user with those same credentials, in which case I would expect that to fail. Regardless, whether or not I specify new credentials or reuse the same ones from the first DC (by literally calling the same parameter for both), it fails saying it can't find the domain.

It seems like there's a good few threads open with some similar issue; should we try to consolidate them?

[kwirkykat]

@oradcliffe Are you running on Server 2016? Have you tried the newest version of xActiveDirectory (2.16.0.0)? There were some issues fixed with waiting for domain controller promotion to complete specifically with the Azure DSC extension.

[oradcliffe]

@kwirkykat Hey, I haven't had a chance to try yet - I'll branch and try it ASAP. I just got a lot of new equipment at home so I've been setting up a little homelab so I haven't had a ton of free time.

[oradcliffe]

@kwirkykat do you think that could solve the issue of not being able to pass in real credentials using the protected settings? Right now I have it working, but I had to do it like this:

`"properties": {
            "publisher": "Microsoft.Powershell",
            "type": "DSC",
            "typeHandlerVersion": "2.21",
            "autoUpgradeMinorVersion": true,
            "settings": {
              "wmfVersion": "latest",
              "configuration": {
                "url": "[variables('DSCURL')]",
                "script": "[variables('FS01DSCscript')]",
                "function": "[variables('FS01DSCfunction')]"
              },
              "configurationdata": {
                "url": "[concat(parameters('assetLocation'), variables('adPopulationData'))]"
              },
              "configurationArguments": {
                "domainName": "[parameters('domainName')]",
                "adminCreds": {
                  "userName": "[parameters('GTM-DC01AdminUserName')]",
                  "password": "[parameters('GTM-DC01AdminPassword')]"
                }
              }
            },
"protectedSettings": {}`

Ugh that formatting is atrocious, sorry about that.

[kwirkykat]

@oradcliffe From the schema you provided in a previous comment, I think you may have combined the old extension schema with the newer schema. Specifically I see both public settings --> configurationArguments (new schema) along with protected settings --> Items (old schema).

You can see the old schema vs. the new schema in this blog: https://blogs.msdn.microsoft.com/powershell/2016/02/26/arm-dsc-extension-settings/

[oradcliffe]

@kwirkykat This was very much a work in progress for a long time while I learned how all of this worked - I see what you're saying though, and thank you for that link. I'm going to update the DSC extension settings tonight; maybe that was my issue all along. Thank you for pointing that out - I actually used as many samples as I could find to learn this stuff and there were quite a few like that back around December so I thought that was correct.

[oradcliffe]

@kwirkykat within the new schema, do we still reference the private settings with privatesettingsref? So it would look like:

"properties": {
"publisher": "Microsoft.Powershell",
"type": "DSC",
"typeHandlerVersion": "2.21",
"autoUpgradeMinorVersion": true,
"settings": {
"wmfVersion": "latest",
"configuration": {
"url": "[variables('DSCURL')]",
"script": "[variables('DC01DSCscript')]",
"function": "[variables('DC01DSCfunction')]"
},
"configurationArguments": {
"domainName": "[parameters('domainName')]",
"adminCreds": {
"userName": "[parameters('GTM-DC01AdminUserName')]",
"Password": "PrivateSettingsRef:AdminPassword"
}
}
},
"protectedSettings": {
"configurationArguments": {
"parameterOfTypePSCredential1": {
"adminPassword": "[parameters('GTM-DC01AdminPassword')"
}
}
}
}

[oradcliffe]

@kwirkykat Also, just as an FYI, I do have this working in 2012R2 with whatever version of xAD I have - the issue I think I was having was with credentials on the domain join, which is why in my master branch I kind of just have them hardcoded in there. If you care to take a look, it's all here in the master branch:

https://github.com/oradcliffe/AzureRm-Windows-Domain

[oradcliffe]

@kwirkykat so I just reran with the new settings in the DSC extension and it did in fact fail with "A parameter cannot be found that matches parameter name 'parameterOfTypePSCredential1'.\n\nAnother common error is to specify parameters of type PSCredential without an explicit type. Please be sure to use a typed parameter in DSC Configuration, for example:\n\n configuration Example {\n param([PSCredential] $UserAccount)"

[oradcliffe]

OK, I have updated the secure arguments to look like:

"configurationdata": {
"url": "[concat(parameters('assetLocation'), variables('adPopulationData'))]"
},
"configurationArguments": {
"domainName": "[parameters('domainName')]"
}
},
"protectedSettings": {
"configurationArguments": {
"adminCreds": {
"userName": "[parameters('GTM-DC01AdminUserName')]",
"Password": "[parameters('GTM-DC01AdminPassword')"
}
}
}

That seeeems to make more sense to me; I'm running it now.

[kwirkykat]

@oradcliffe There is no more PrivateSetttingsRef because the whole credential object now goes into the protected settings. So using the new schema your config arguments should look like this:

"properties": {
"publisher": "Microsoft.Powershell",
"type": "DSC",
"typeHandlerVersion": "2.21",
"autoUpgradeMinorVersion": true,
"settings": {
"wmfVersion": "latest",
"configuration": {
"url": "[variables('DSCURL')]",
"script": "[variables('DC01DSCscript')]",
"function": "[variables('DC01DSCfunction')]"
},
"configurationArguments": {
"domainName": "[parameters('domainName')]",
}
},
"protectedSettings": {
"configurationArguments": {
    "adminCreds": {
        "userName": "[parameters('GTM-DC01AdminUserName')]",
        "Password": "[parameters('GTM-DC01AdminPassword')]"
    }
}
}
}

[oradcliffe]

@kwirkykat OK, so what I just posted is the correct way to do it, right? That would be awesome if this worked; it was the only part of my template that I really hated because the credentials would never be encrypted that way.

[oradcliffe]

@kwirkykat Ah, well this time it failed with:
" "message": "VM has reported a failure when processing extension 'CreateSecondDC'. Error message: "DSC
Configuration 'CreateSecondDC' completed with error(s). Following are the first few: PowerShell DSC resource
MSFT_xADDomainController failed to execute Set-TargetResource functionality with error message: Domain
'gametimeor.priv' could not be found. Unable to find a default server with Active Directory Web Services running."

Which sort of makes sense because I branched from master, which is working, and just made changes to the protected settings like we were talking about. I bet it can't find the DC because the credentials it's getting aren't valid, which is the problem I was having before when I had to put the password in the non-protected settings.

[oradcliffe]

@kwirkykat would the way I'm defining my parameters be an issue?

"GTM-DC01AdminUserName": {
"type": "string",
"minLength": 1
},
"GTM-DC01AdminPassword": {
"type": "securestring"
},

If I'm including adminusername in the protected settings, does that need to have type securestring?

[kwirkykat]

@oradcliffe I don't think the admin user name needs to be a secure string but maybe try it with the password as a 'string' rather than 'securestring'? I know it's not as secure but it could be that the extension is re-encrypting the secure string and then only decrypting it once rather than twice.

The example in the blog seems to have just a string:
"configurationArguments": {
"parameterOfTypePSCredential1": {
"userName": "UsernameValue1",
"password": "PasswordValue1"
}
}

[oradcliffe]

@kwirkykat Ok, I'll give that a shot and report back. I just started a deployment with kind of the opposite, with both set to secure string in the parameters section so I want to test that quick and then I'll try it the other way.

[alexaymonier]

I also ran into this problem with a brand new Server 2016 Core box and removing the domain credential did the trick. Thanks @oradcliffe

[oradcliffe]

@alexaymonier What do you mean remove the domain credential? Like removed it from protected settings or?

[oradcliffe]

I'm refactoring this thing so it can be deployable with an Azure button and it's making me rethink this again haha.

[andyrdavidson]

I think I'm having the same issue. I'm use Lability to build a lab environment and when a member server tries to domain join using DSC it just sits there forever. If i stop the server manually and log into the server the Lability bootstrap log states: Could not find domain.

Looking into the error I tried pasting in the commands from the Get-Domain function into a PowerShell window (with appropriate variable values). When I pass in the commands without domain credentials it finds the domain OK. However when I pass in valid domain credentials the error message is returned "current security context is not associated with an active directory domain" from the command $domain = ([System.DirectoryServices.ActiveDirectory.DomainController]::FindOne($context)).domain.ToString() and so it never finds a domain and therefore it can never join it.

Like the others in this thread I'm trying without domain credentials now to see if that cures domain join.
I just thought I'd add in the error message I found to the thread just in case that was helpful.

[iainbrighton]

@andyrdavidson In what format are you passing in the username part of the DomainUserCredential parameter? We do use the xWaitForDomain resource with with the DomainUserCredential in most of our internal configurations.

PS - Thanks for trying out Lability 😉.

[andyrdavidson]

@iainbrighton I tried passing in PSCredential object if I remember right (I've slept since then ;-)).

The function works just fine if the virtual machine is already a domain member, it seems to fail only when the virtual machine isn't joined to a domain. In which case I guess you shouldn't be passing in the domain credentials anyway! Removing the credentials works just fine. So that's what I'm now doing - I learnt something! :-)

I mention it so that you can see the error message - maybe it could quit the function? if it receives that error code because no matter how many times it retries it won't ever find a domain in those circumstances.

P.S. You're welcome - fabulous system. Although I'm still getting my head round all of it. :-)

[gmatusko]

OK, so been using this resource for ages in our dsc scripts to deploy Server 2012R2 DCs. We're testing moving our DC deployments over to Server 2016 and now the WaitforADDomain resource fails on the second DC. I read through this entire thread trying the various suggestions to get this to work but still no luck. Not sure why simply changing the deployment image to 2016 breaks this but probably something to do with added security in Server 2016. I tried running the commands manually as @andyrdavidson did on the second machine that is attempting to become a DC and with and without credentials fails. I'm going to try joining the machine to the domain first using the domain join extension as that seems it should work but if anyone could explain why this works without issue on 2012R2 but not on 2016 I would appreciate it.

[GoateePFE]

Hi folks, What's the latest on this one. I ran into this today with a fresh build of a DC on 2016. We were on 2.16.0.0. Thanks.

[andikrueger]

I'm facing this issue too. During the setup of a DC the following message appears:

 "Exception":  {
                      "Message":  "PowerShell DSC resource MSFT_xWaitForADDomain  failed to execute Set-TargetResource functionality with error message: Domain \u0027dev.local\u0027 NOT found after 20 attempts. ",

The Domain was provisioned successfully.
I tested the PowerShell commands used in the xWaitForADDomain manually and everything worked as expected.

WIN2016, xActiveDirectory 2.16.0.0 via AzureAutomation

[kwirkykat]

@RichardSiddaway @raandree

[nebffa]

Yeah, adding my 'plus one' to this issue. xWaitForADDomain fails when using a domain credential on a computer that is outside the domain.

[andyKalman]

+1 here. Exact same behavior here with 2016 core. First DC no problem, second DC has the same Set-target resource error as above.

[andyKalman]

It looks like there may be a DNS requirement for Get-Domain and Set-TargetResource. I set the DNS server for the second DC to be the IP of my first DC but still no joy. To be clear I am in Azure and have not changed my vnet over from Azure Global DNS just yet. Is my OS override going to conflict with that and further, is the DNS bit just a red herring in all of this?

[gesandovalr]

has anyone be able to make this work? I have the same issue with a template in Windows Server 2016.

{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.","details":[{"code":"Conflict","message":"{\r\n "status": "Failed",\r\n "error": {\r\n "code": "ResourceDeploymentFailure",\r\n "message": "The resource operation completed with terminal provisioning state 'Failed'.",\r\n "details": [\r\n {\r\n "code": "VMExtensionProvisioningError",\r\n "message": "VM has reported a failure when processing extension 'configureController'. Error message: "DSC Configuration 'VDIServerIndependent' completed with error(s). Following are the first few: PowerShell DSC resource MSFT_xWaitForADDomain failed to execute Set-TargetResource functionality with error message: Domain mydomain.local not found after 0 attempts with 0 sec interval The SendConfigurationApply function did not succeed."."\r\n }\r\n ]\r\n }\r\n}"}]}

[andyKalman]

@gesandovalr I did get this to work. I wish I could say what the silver bullett was because I addressed a number of things but I will list them here. Also, full disclosure, I am using this in Azure so I may have faced some different issues compared to others:

1. My first issue was Azure networking. I had some offending routes in routetables that needed corrected ; i.e. I had bad routes with next hop of none. Also, adjusting NSG rules were done to make sure routes were reinforced and ensuring the pull server could be contacted. The AzureCloud service tag was helpful in that regard.

2. I created credentials within my Automation Account. These were not in the correct format nor syncing up with my VM deployment. I changed them to the format domain\user as shown in the image below. It is critical that the username and password match exactly what you specify in your initial VM deployment with the addition of the domain prefix of course.

3. The last issue for me was with Azure CLI itself when the VM template was executed. I realize the below is a bit sloppy password wise but it is where I'm at at the moment 😃 The below does work and I am not prompted to enter the adminPassword for my VM.
   --parameters @CRM_Sand/sand-vm-pmods-parameters.json
--parameters adminPassword='password_here'
   The issue was that password was not getting passed in correctly. I have yet to dig into that one some more but I did change the complexity of the password and it passed in successfully after that. An additional test was for me to remove that --parameter line and type the password on the command line interactively.

After I addressed these items xWaitForADDomain, xADDomain and xADDomainController worked without issue. Hopefully this helps some......

[gesandovalr]

I'll give it try tomorrow, I'm trying to deploy something very simple https://github.com/citrix/Citrix-Cloud-VDI-ARM-Template I read the readme.md that this guy had and I didn't saw the part of an automation account was required.

Thanks.

[andyKalman]

Looks like he is building the automation credential object himself. If you're deploying to Azure it becomes fairly simple in your script to get the credential if you have it stored in an automation account already vs building the object yourself by using Get-AutomationPSCredential. Surely the other way works too but this is how I am achieving the result. It may be more overhead than you want to have an automation account. Give Azure Automation Credentials a read.

$domainCredential = Get-AutomationPSCredential 'azrDev Domain Admin'

[gesandovalr]

I'm creating the credentials first with the Automation Account if doesn't work, I'll proceed to change the code.

[darkedges]

I am using xWaitForADDomain to wait for services to become available, but although it reports it is available when I use xADUser it reports

virtualbox-ovf: VERBOSE: [WINDOWS2016STD]: LCM:  [ Start  Resource ]  [[xWaitForADDomain]DscForestWait]
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]: LCM:  [ Start  Test     ]  [[xWaitForADDomain]DscForestWait]
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]:                            [[xWaitForADDomain]DscForestWait] Checking for domain darkedges.local
    virtualbox-ovf:  ...
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]:                            [[xWaitForADDomain]DscForestWait] Found domain darkedges.local
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]: LCM:  [ End    Test     ]  [[xWaitForADDomain]DscForestWait]  in 0.0150 seconds.
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]: LCM:  [ Skip   Set      ]  [[xWaitForADDomain]DscForestWait]
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]: LCM:  [ End    Resource ]  [[xWaitForADDomain]DscForestWait]
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]: LCM:  [ Start  Resource ]  [[xADUser]MSSQLSERVER]
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]: LCM:  [ Start  Test     ]  [[xADUser]MSSQLSERVER]
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]:                            [[xADUser]MSSQLSERVER] Retrieving Active Directory user
    virtualbox-ovf: 'MSSQLSERVER' ([email protected]) ...
    virtualbox-ovf: Error looking up Active Directory user 'MSSQLSERVER' ([email protected]).
    virtualbox-ovf:     + CategoryInfo          : NotSpecified: (:) [], CimException
    virtualbox-ovf:     + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-TargetResource

    virtualbox-ovf:     + PSComputerName        : localhost
    virtualbox-ovf:
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]: LCM:  [ End    Test     ]  [[xADUser]MSSQLSERVER]  in 1.2160 seconds.
    virtualbox-ovf: PowerShell DSC resource MSFT_xADUser  failed to execute Test-TargetResource functionality with error message: Server
    virtualbox-ovf: instance not found on the given port.
    virtualbox-ovf:     + CategoryInfo          : InvalidOperation: (:) [], CimException
    virtualbox-ovf:     + FullyQualifiedErrorId : ProviderOperationExecutionFailure
    virtualbox-ovf:     + PSComputerName        : localhost
    virtualbox-ovf:
    virtualbox-ovf: VERBOSE: [WINDOWS2016STD]: LCM:  [ End    Set      ]

I have found adding

while ($true) {
    try {
        Get-ADDomain | Out-Null
        break
    } catch {
        Start-Sleep -Seconds 10
    }
}

to my powershell some makes this work.

[johlju]

This resource has been refactored in PR #455 which will be merged shortly and available in the next release in a week or so.

If there are still issues using the refactored resource in the module ActiveDirectoryDsc, then please submit a new issue so the community can get the configuration used and the verbose logs together with the error that is occurring.

I'm closing this issue at this time.