FQDN for NameSpace roots

[bk147]

It would be very nice if the Resource supported using FQDNs as servernames in DFSN Root Targets :-)

[PlagueHO]

@bk147 - thanks for your feedback! I'm sure it could be made to do this. I'll take a look and see what I can do (unless someone gets to it first). I'll try and get to this this weekend but possibly the next week.

[PlagueHO]

@bk147 - I've started work on this one. But I now recall why FQDN doesn't work - it is a limitation (possibly an intentional one) in the PowerShell DFSN cmdlets:

The PowerShell Cmdlets for DFS Namespaces do not return the FQDN of any targets added to the Namespace - even if an FQDN was used to set it.

Unfortunately this will cause a looping scenario on the current DFSN resources. This is probably what you've run into - is that correct - the resource trying to add the FQDN root targets to the root every 5 minutes but failing (because they actually have already been added).

There is hope however - I could probably work around this limitation by simply stripping everything but the flatname from the FQDN when looking up the existing target. The only issue with doing that is that if you try and change the Domain of one of the target nodes that already exists then it will not change because the resource will think it is already in the correct state. There is no way around it that I can see because I can't find to pull the FQDN used to create the target.

But before I proceed with this change, could I get you to drop a copy of the config in here that'd you like to use. I just want to confirm I am actually going to implement something that will solve this problem. I also want to confirm you're talking about putting FQDN's int the TargetPath parameter of the resource - the Path should already accept FQDN paths.

Cheers!

[PlagueHO]

Also, can you confirm what sort of Namespaces you're using here (DomainV2 or Standalone).

[bk147]

Sorry about my late response!
First we're using DomainV2 on all our DFS Namespaces. We have several domains in the same forest and what we usually do is that we run the following PowerShell command as the first thing:

Set-DfsnServerConfiguration -ComputerName localhost -UseFqdn $true

This enables support for FQDN in the DFS roots, but the server has to be rebooted before the setting becomes active - failure to do so results in shortnames being using instead of FQDNs.

We've tried to add this, but the main problem is the reboot of the server and making sure that the roots does not get added before this has happened. We're still quite new to DSC :-)

Thanks,
-Brian

[PlagueHO]

@bk147 - no problem sir! I had no idea about the -UseFQDN parameter! Can I reopen this as I'd actually like to come up with something for you.

I think what we need is a new DSC resource to allow us to configure the DfsnServer. We can manage the reboot OK by making this resource require a reboot if the UseFQDN value changes. This may actually mean that the FQDN sill just start working.

[iainbrighton]

@PlagueHO I think there has been some change here when it comes to the Server 2016 implementation? It now seems that I need to specify the FQDN in the TargetPath on 2016 - otherwise it always fails the Test-TargetResource method. Have you seen this too?

[PlagueHO]

@iainbrighton - actually I haven't yet looked. Thanks for the heads up. I'll make some time this week to look in to it. Cheers!