xDFSReplicationGroup - test-targetresource always returns PrimaryMember as true

[meh485]

Details of the scenario you tried and the problem that is occurring:
I am trying to configure an existing DFS Replication group using xDFS. I have the PrimaryMember flag set to $false in the DSC configuration and I can confirm when running Get-DFSRMembership, primarymember is set to false as well. But when I run Start-DscConfiguration, Test-TargetResource returns $false because:
Test-TargetResource: DFS Replication Group "" folder "" on "****" has incorrect PrimaryMember. Change required.

Verbose Output when running start-dscconfiguration
VERBOSE: [hostname]: LCM: [ Start Test ] [[xDFSReplicationGroupMembership]Admin-Membership]
VERBOSE: [hostname]: [[xDFSReplicationGroupMembership]Admin-Membership] Test-TargetResource: Testing DFS Replication Group "replicationgroup" folder "replicatedfolder" on "hostname".
VERBOSE: [hostname]: [[xDFSReplicationGroupMembership]Admin-Membership] Test-TargetResource: DFS Replication Group "replicationgroup" folder "replicatedfolder" on "hostname" exists.
VERBOSE: [hostname]: [[xDFSReplicationGroupMembership]Admin-Membership] Test-TargetResource: DFS Replication Group "replicationgroup" folder "replicatedfolder" on "hostname" has incorrect PrimaryMember. Change required.
VERBOSE: [hostname]: LCM: [ End Test ] [[xDFSReplicationGroupMembership]Admin-Membership] in 0.2500 seconds.

Verbose Output when Manually running test-targetresource
Test-TargetResource -GroupName "replicationgroup" -FolderName "replicatedfolder" -ComputerName "hostname"
VERBOSE: Test-TargetResource: Testing DFS Replication Group "replicationgroup" folder "replicatedfolder" on "hostname".
VERBOSE: Test-TargetResource: DFS Replication Group "replicationgroup" folder "folder" on "hostname" exists.
True

The DSC configuration that is using the resource (as detailed as possible):
xDFSReplicationGroupMembership "$($DFSRConfig.ShareName)-Membership" {
GroupName = $DFSRConfig.ReplicationGroupName
FolderName = $DFSRConfig.ReplicatedFolder
ComputerName = $hostname
ContentPath = $DFSRConfig.ShareDestinationPath
PrimaryMember = $false
StagingPath = $DFSRConfig.StagingPath
StagingPathQuotaInMB = $DFSRConfig.StagingPathQuotaInMB
PSDSCRunAsCredential = $Credential
DomainName = $DFSRConfig.DomainName
DependsOn = @("[File]$($DFSRConfig.ShareName)-StagingPath", "[xDFSReplicationGroupFolder]$($DFSRConfig.ShareName)-ReplicatedFolder")
}

Version of the Operating System and PowerShell the DSC Target Node is running:
OS: Windows Server 2016 Datacenter
PowerShell:
Name Value

---

PSVersion 5.1.14393.1944
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.1944
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Version of the DSC module you're using, or 'dev' if you're using current dev branch:
3.2.0.0

[PlagueHO]

Thanks for raising this @meh485 - I've been a bit snowed under lately so a bit behind on this stuff. But I'm hoping to make some time for DSC stuff this weekend. Again, sorry for the delay!

[Borgquite]

Just a quick note - in my testing, the PrimaryMember attribute does not behave the 'usual' way in Get-DfsrMembership and Set-DfsrMembership. It can only be set temporarily during the initial replication process - once that initial replication has taken place, the system automatically sets it back to $false, so a 'working' DFS replication group normally has PrimaryMember set to 'false'. However, it is necessary to set it when a DFS replication group is first created, otherwise replication never takes place.

This doesn't really fit with the way that DSC works - not sure the best way to proceed. For myself, I have set it up outside of DSC once the replication group is created. One could also use a Script resource to do so inside DSC, I guess.

[PlagueHO]

@Borgquite - ah right. So, PrimaryMember always returns $false when calling Get-DfsrMembership. So, the resource will never go into state?

That is a difficult one to solve as this is essentially a "write-only" property. The only way to deal with it is to not evaluate its state in the Test-TargetResource - or probably better: evaluate it and write verbose information about it's state, but indicate that it is not used to evaluate the resource state.

[Borgquite]

Almost - it will return $true during initial sync, but be set back to $false once that is complete. Just found these articles which describe the behaviour I've observed:

https://techcommunity.microsoft.com/t5/storage-at-microsoft/determining-which-member-was-set-as-the-primary-member-for-dfs/ba-p/423220
https://techcommunity.microsoft.com/t5/storage-at-microsoft/the-primary-member-in-dfs-replication/ba-p/423127

I agree that 'ignoring' it (with logging) for the purposes of evaluation of Test-TargetResource is probably the best way ahead.