ADGroup: generates an error that a group already exists when run from a different domain

[davnport]

When the xADGroup resource is executed from our TEST domain to create AD groups in the PRODUCTION domain a group is created on the first execution. Subsequent executions generate an error that the AD group already exists.

When the xADGroup resource is executed from our PRODUCTION domain to create AD groups in the PRODUCTION domain a group is created on the first execution. Subsequent executions do not generate an error; the resource works correctly.

This is an example of the code being run from TEST to create a group in PRODUCTION

PS C:\Windows\system32> $credential = Get-Credential

$invokeParams = @{
  Name          = 'xADGroup'
  Method        = 'set'
  Property      = @{
    groupname = 'LSA-DSC-TESTING'
    groupscope = 'Global'
    category = 'Security'
    path = '<removed>'
    ensure = 'present'
    description = '<puppet managed> Users'
    credential = $credential
    domaincontroller = '<removed>'
  }
  ModuleName = @{
    ModuleName      = "C:\Program Files\WindowsPowerShell\Modules\xActiveDirectory\2.11.0.0/xActiveDirectory.psd1"
    RequiredVersion = "2.11.0.0"
  }
}

Invoke-DscResource @invokeParams
cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:

RebootRequired 
-------------- 
False          



PS C:\Windows\system32> $invokeParams = @{
  Name          = 'xADGroup'
  Method        = 'set'
  Property      = @{
    groupname = 'LSA-DSC-TESTING'
    groupscope = 'Global'
    category = 'Security'
    path = '<removed>'
    ensure = 'present'
    description = '<puppet managed> Users'
    credential = $credential
    domaincontroller = '<removed>'
  }
  ModuleName = @{
    ModuleName      = "C:\Program Files\WindowsPowerShell\Modules\xActiveDirectory\2.11.0.0/xActiveDirectory.psd1"
    RequiredVersion = "2.11.0.0"
  }
}

Invoke-DscResource @invokeParams
Invoke-DscResource : The specified group already exists
At line:20 char:1
+ Invoke-DscResource @invokeParams
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (CN=LSA-DSC-TEST...DC=stjoe,DC=org:) [Invoke-DscResource], CimException
    + FullyQualifiedErrorId : ActiveDirectoryServer:1318,Microsoft.ActiveDirectory.Management.Commands.NewADGroup,Microsoft.Pow 
   erShell.DesiredStateConfiguration.Commands.InvokeDscResourceMethodCommand

Invoke-DscResource : The PowerShell DSC resource '[xADGroup]DirectResourceAccess' with SourceInfo '' threw one or more 
non-terminating errors while running the Set-TargetResource functionality. These errors are logged to the ETW channel called 
Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
At line:20 char:1
+ Invoke-DscResource @invokeParams
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (root/Microsoft/...gurationManager:String) [Invoke-DscResource], CimException
    + FullyQualifiedErrorId : NonTerminatingErrorFromProvider,Microsoft.PowerShell.DesiredStateConfiguration.Commands.InvokeDsc 
   ResourceMethodCommand

PS C:\Windows\system32> 

First warning logged to event viewer

Error Message = Cannot find an object with identity: 'CN=LSA-DSC-TESTING12345,OU=Server Admin groups,OU=<removed for privacy>'.
Fully Qualified Error ID = ActiveDirectoryCmdlet:Microsoft.ActiveDirectory.Management.ADIdentityNotFoundException,Microsoft.ActiveDirectory.Management.Commands.SetADGroup


Context:
        Severity = Warning
        Host Name = Default Host
        Host Version = 5.0.10586.117
        Host ID = 5878f754-4aca-4548-b4bf-33e8d884a946
        Host Application = C:\Windows\system32\wbem\wmiprvse.exe
        Engine Version = 5.0.10586.117
        Runspace ID = 798de977-d131-49ec-977b-50d469f50aa5
        Pipeline ID = 8
        Command Name = Set-ADGroup
        Command Type = Cmdlet
        Script Name = C:\Program Files\WindowsPowerShell\Modules\xActiveDirectory\2.11.0.0\DscResources\MSFT_xADGroup\MSFT_xADGroup.psm1
        Command Path = 
        Sequence Number = 17
        User = TST\SYSTEM
        Connected User = 
        Shell ID = Microsoft.PowerShell


User Data:

second warning logged to event viewer

Error Message = The specified group already exists
Fully Qualified Error ID = ActiveDirectoryServer:1318,Microsoft.ActiveDirectory.Management.Commands.NewADGroup


Context:
        Severity = Warning
        Host Name = Default Host
        Host Version = 5.0.10586.117
        Host ID = 5878f754-4aca-4548-b4bf-33e8d884a946
        Host Application = C:\Windows\system32\wbem\wmiprvse.exe
        Engine Version = 5.0.10586.117
        Runspace ID = 798de977-d131-49ec-977b-50d469f50aa5
        Pipeline ID = 8
        Command Name = New-ADGroup
        Command Type = Cmdlet
        Script Name = C:\Program Files\WindowsPowerShell\Modules\xActiveDirectory\2.11.0.0\DscResources\MSFT_xADGroup\MSFT_xADGroup.psm1
        Command Path = 
        Sequence Number = 18
        User = TST\SYSTEM
        Connected User = 
        Shell ID = Microsoft.PowerShell


User Data:

[iainbrighton]

@davnport I'm not entirely sure, but I think PR #107 might resolve this issue for you. Would you mind testing and letting me know?

[davnport]

@iainbrighton PR #107 corrected the issue I reported. I encountered a new issue while testing:

I setup the scenario from the initial report and generated the expected error. I replaced "C:\Program Files\WindowsPowerShell\Modules\xActiveDirectory\2.11.0.0\xActiveDirectory.psd1" with the code in the pull request. An error was not generated for groups that already exist. Awesome; thank you.

When a new AD group is created it takes ~20 seconds to propagate to all the domain controllers. I have circumvented this delay by using the same DC for all transactions. Is it possible for the code that checks if the group exists to reference the domain controller that is specified in the xADGroup script?

[iainbrighton]

@davnport Do you mean the following?:

• You don't specify the DomainController parameter
• The AD group may be created on one server, for example SERVERA
• The AD group updates may then be invocate on another server, for example SERVERB
• If the AD group hasn't replicated from SERVERA to SERVERB and therefore, the update fails

I don't think there's any way to determine on what server an update was performed on (or not that I'm aware of). A solution to this might be:

• If DomainController is not specified, query the domain for a/the nearest domain controller
• Use this DC for all AD cmdlets

This should make the resource dynamic enough that there isn't a hard-coded, single point of failure.
Thoughts? /cc @TravisEz13 @PlagueHO

[johlju]

If no value is set for DomainControiller the the default value for the cmdlets parameter Server is used, which will be the domain of the computer. Reads more here for the parameter Server https://docs.microsoft.com/en-us/powershell/module/addsadministration/get-adgroup. The default value will probably return/choose the fastest domain controller to respond (the closest), this can change from time to time (moment to moment) and not seeing we could rely on a logic to always get the same specific domain controller when non is specified. Probably is a logic criteria for what domain controller responds, like what site the computer belongs to, if the site changes, so will the domain controller the computer should connect to. There could also be new domain controller added, or domain controllers removed. 🤔
The only why to make sure to avoid the potential sync lag is to choose a specific domain controller in the parameter DomainController.

If there are another way, please comment on this issue and we can continue the discussion.

Closing this issue at this time.