Strange error in 2_CreateParentDisks.ps1, step "Creating DSC Configs for DC"

[berndbausch]

First, I need to disclose that I know very little about Powershell, and Windows in general. Also, I doubt that it counts but the server where I am running the MSLab scripts is a virtual server itself (running on KVM in Debian).

I attempt to create a two-node AzSHCI cluster (instructions) and consistently fail in the 2_createparentdisks.ps1 script. Not sure if I should create an issue, but I could use some help (thanks in advance!).

Error message from createparentdisks.log:

	 Creating DSC Configs for DC
Test-ConflictingResources : A conflict was detected between resources '[xADUser]Domain_Admin 
(C:\lab\mslab_v23.01.1\2_CreateParentDisks.ps1::1138::21::xADUser)' and '[xADUser]AdministratorNeverExpires 
(C:\lab\mslab_v23.01.1\2_CreateParentDisks.ps1::1187::21::xADUser)' in node 'DC'. Resources have identical key 
properties but there are differences in the following non-key properties: 
'Path;Password;Description;DomainAdministratorCredential'. Values 'OU=Workshop,DC=Corp,DC=contoso,DC=com;System.Manageme
nt.Automation.PSCredential;DomainAdmin;System.Management.Automation.PSCredential' don't match values 
'NULL;NULL;NULL;NULL'. Please update these property values so that they are identical in both cases.

The script then stops and seems to leave the environment in an intermediate state. I tried running the script a second time, which succeeds, but later in 3_deploys.ps1 the AD VM is not started because its VHDX file is being used by something else (probably a consequence of the error I am reporting here).

ZIP of createparentdisks.log and labconfig.ps1 is attached.
DSC config error.zip

[berndbausch]

The problem went away after reinstalling the MSLab host.

[machv]

Hello,
I am glad the problem is not occurring anymore.

Just to out of curiosity, before reinstalling whole Hyper-V host, have you tried to run MSLab scripts again e.g. in different folder? From the attached log it seem that DSC config that was generated during domain controller provisioning (2_createparentdisks.ps1), wasn't correct, but as it was already generated any consecutive executions were trying to reuse that config.

[berndbausch]

Thanks for looking into my logs. Indeed, I ran the scripts several times.

Also, I probably created incorrect configurations originally, perhaps by incorrect LabConfigs or accidentally running scripts that I should not run at that point. I naively thought that by removing the MSLabs folder, all config errors would go away, and didn't consider that some system-wide settings might have been changed.

To prevent poor souls like me from shooting themselves in the foot, you may want to state somewhere that erroneous installations should be wiped out entirely (preferably by reinstalling the host's OS).

I am a happy camper now, by the way. Impressive toolset. Thanks.

[berndbausch]

I found the source of the problem. The idea of a broken and not entirely cleaned up configuration was a red herring.

In my Labconfig script, I set DomainAdminName to Administrator. Because why not? Unfortunately, this causes a conflict between these two xADUser resource instances, defined in 2_CreateParentDisks.ps1:

                    xADUser Domain_Admin
                    {
                        DomainName = $Node.DomainName
                        DomainAdministratorCredential = $domainCred
                        UserName = $Node.DomainAdminName
(...)
                    }

and

                    xADUser AdministratorNeverExpires
                    {
                        DomainName = $Node.DomainName
                        UserName = "Administrator"
(...)
                    }

The instances end up having the same UserName "Administrator" and obviously the same DomainName. Since these two attributes are the resource keys, and the other attributes don't have identical values, the conflict arises. Setting the user name to anything else fixes the problem.

Now, it might be a best practice or common knowledge that one should not name an AD domain administrator "Administrator". I fell into this trap thanks to my non-existing Windows Server background.