-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADDomain: ARM template deployment fails due to ActiveDirectoryDsc resource ADDomain throwing an error on first reboot after a DC Promo. #560
Comments
Hi @mitch-meade, thanks for raising this issue. I had a look at the old issues that you referenced and the retry code in the PR that resolved them is still present in the module. |
logs attached... Thanks for looking at this... before reboot 2-5-2020 358pm {B1AABD1D-4871-11EA-A80E-000D3A075975}-0.details.json.txt after reboot 2-5-2020 at 400pm {A44A8F4B-4873-11EA-A80F-000D3A075975}-0.details.json.txt |
The next LCM cycle was successful… Ignore the File resource, attempted to manually create the tracking file, this will be removed. Subsequent reboot 2-5-2020 at 409 pm {E6AFFA73-4874-11EA-A80F-000D3A075975}-0.details.json.txt |
Hi @mitch-meade, thanks for these logs. As you have figured out, the problem is the tracking file that is written at the end of the |
No policy to clear the system temp location on startup... I added a file resource to create this tracking file as a futile attempt at working around this problem but this resource never gets evaluated before the reboot as the ADDomain resource is rebooting the machine. As you can see, I have a Pending Reboot resource as well and this never triggers ether. I monitored the C:\Windows\Temp folder during the configuration run and the tracking file never gets created. What would prohibit this tracking file from being created? |
I watched this folder during this run and it never was created before the initial reboot by ADDomain. |
OK, can you check what the system Temp variable is set to on the machine :
|
OK, we need to know exactly where the function is trying to write the tracking file to and read the tracking file from. Can you edit your source of the ActiveDirectoryDsc module and modiify the In the
to
In the
to:
Then re-run the DSC and we should see from the log the path that the tracking file is written to and being read from. |
|
Did you want the configuration ran from a clean machine? |
Yes please, we need to see the |
Looks like the Temp path is pointing to the system profile (C:\windows\system32\config\systemprofile\AppData\Local\Temp) before the server becomes a Domain Controller. I create the Temp folder in the System profile because the absence of this folder breaks some other chocolatey processes.
Here is the ADDomain section prior to the reboot.
I bet me creating the temp folder in the system profile is having an effect on the resource. The Temp folder in the system profile fixes many processes so its kind of a standard add for any automated builds I do... |
OK, well its good to know what the problem is. My opinion is that the resource shouldn't write the file to |
Or another “natural” trigger, i.e. a file or registry value that exists after the domain controller was promoted. |
I’ll take a snapshot right before the promo and again after to find a good trigger. |
Need to make sure the trigger is consistent from Server 2012 to Server 2019. |
Might be able to pull that off... |
How about something like this? Validated on 2012R2, 2016 and 2019...
|
Both the registry value and file path are populated after the DC promotion and before the first reboot. |
Great find @mitch-meade! Definitely the way to go rather than the tracking file. I'm wondering whether we need to test the sysvol path though, or whether just the existence of the sysvol reg item is enough? Looking at the current |
I'm working on a PR that will refactor the |
So... I'd like to become more involved but I don't even know what a PR is,.. LOL Just too busy. Can you point me to documentation how I can contribute? |
A PR is a GitHub 'Pull Request'. Have a read of the DSC Community Getting Started as a Contributor. |
Attempted the Resource in 6.0.0-preview0001.
|
Hi @mitch-meade, can you raise a new issue for this error please? |
Details of the scenario you tried and the problem that is occurring
ARM template deployment fails due to ActiveDirectoryDsc resource ADDomain throwing an error on first reboot after a DC Promo. The DC promo completes but the error breaks the ARM template in progress. This is a reoccurrence of previously closed issues, #127 and #73.
Server is 2016 and ActiveDirectoryDsc module version is 5.0.0.0.
Verification of prerequisites for Domain Controller promotion failed. The specified argument \u0027NewDomain\u0027 was not recognized.
The promo completed file isn’t being created in C:\Windows\Temp<fqdn>.ADDomain.completed
Verbose logs showing the problem
The DSC configuration that is used to reproduce the issue (as detailed as possible)
The operating system the target node is running
Windows Server 2016 running in Azure
Version and build of PowerShell the target node is running
Version of the DSC module that was used
5.0.0 ActiveDirectoryDsc
The text was updated successfully, but these errors were encountered: