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!

[PlagueHO]

@iainbrighton - I'm looking at this over this weekend and hope to get it figured out soon.

It would be grand if we could specify the OS version AppVeyor uses - could then set up a test matrix to test the different OS versions.

[PlagueHO]

Hi @iainbrighton - I think I've found the problem:

In Windows Server 2012 R2 the DFSN Server Configuration setting UseFQDN defaults to "False".

In Windows Server 2016 the 'UseFQDN' setting defaults to $null (not set):

This seems to cause errors to occur when creating the Namespace roots. It may be a bug in DFS in WS 2016 though because I couldn't create any DFS Namespaces using PowerShell cmdlets at all until this value was set to either $true or $false.

Are you able to confirm this on your DFS server for me by any chance by executing:

Get-DFSNServerConfiguration -ComputerName Localhost

If that is the case then this is what I think should be done:

1. All non-FQDN examples should be updated to include to ensure the setting is false:

       # Configure the namespace server
        xDFSNamespaceServerConfiguration DFSNamespaceConfig
        {
            IsSingleInstance          = 'Yes'
            UseFQDN                   = $false
            PsDscRunAsCredential      = $Credential
} # End of xDFSNamespaceServerConfiguration Resource

1. Raise the issue on User Voice.

Are you able to see if setting the UseFQDN setting using xDFSNamespaceServerConfiguration DFSNamespaceConfig fixes your issue?

Keen to get your thoughts on this.

[PlagueHO]

Hi @iainbrighton - I just realized that I'd incorrectly tagged your name in the above reply. So you won't have seen it. Sorry about that sir!

[PlagueHO]

@iainbrighton - if you get the opportunity to confirm this resolves your option, let me know. What I'll then do is update the documentation and examples to make note of this behavior with Windows Server 2016.

[iainbrighton]

@PlagueHO Apologies - been busy with that thing called work 👎. I'll attempt to have a look this week as I think this is now the only thing stopping us going Server 2016 for dev/test..

[PlagueHO]

@iainbrighton - no worries mate! I'm definitely thinking some more docs/guidance is needed as there does appear to be challenges getting these resources working at times.

[iainbrighton]

@PlagueHO As always - thanks for your efforts 👍.

I can confirm that the UseFqdn property is indeed null on a 2016 instance.

PS C:\Users\Administrator> Get-DfsnServerConfiguration -ComputerName localhost

ComputerName              : localhost
LdapTimeoutSec            : 30
PreferLogonDC             : False
EnableSiteCostedReferrals : True
EnableInsiteReferrals     : False
SyncIntervalSec           : 3600
UseFqdn                   : 

I can also confirm that the following configuration now works on a 2016 host and passes the Test-TargetResource method after the first pass:

configuration DfsFqdnTest {
    param ( )
    Import-DscResource -ModuleName xDFS;

    xDFSNamespaceServerConfiguration 'DFSNamespaceConfig' {
        IsSingleInstance = 'Yes'
        UseFQDN          = $false
    }

    xDFSNamespaceRoot 'DFSNamespaceRoot' {
        Path        = '\\test.local\Root';
        TargetPath  = '\\2016DC\DFS';
        Description = 'Distributed File System Root Share';
        Type        = 'DomainV2';
        Ensure      = 'Present'; 
        DependsOn   = '[xDFSNamespaceServerConfiguration]DFSNamespaceConfig';
    }

}

if (-not (Get-Module -Name xDFS)) { Install-Module xDFS -Scope AllUsers -Force }
DfsFqdnTest -OutputPath ~\ 
Start-DscConfiguration -Path ~\ -Wait -Verbose -Force

Therefore, I think that the examples should be updated to include the xDFSNamespaceServerConfiguration resource defaulting to $false. This certainly feels like a regression/bug though 😞.

[PlagueHO]

Awesome! Thank you again @iainbrighton - that is great info.

What I will do:

1. Raise an issue on Uservoice - I do agree this seems like a bug/regression.
2. Add info to the Readme.md identifying this as a known issue and refer to the required solution.
3. Add the xDFSNamespaceServerConfiguration to the examples.

Thanks again for helping me check this out.

[n3snah]

Is the limitation still on the cmdlets? I have used them with FQDN without too much issue however right now I am faced with other issues like not being able to added extra namespace targets.

[PlagueHO]

Hi @laywah2016 - I haven't tried this in Windows Server 2019, so not sure there. But it has not been fixed in Windows Server 2016. All that is really required to do is use the DFSNamespaceServerConfiguration as per the examples to configure the DFS Namespace server to use FQDN.

Can you clarify the issue with not being able to add extra namespace targets? It would be worth creating a new issue if this is not related though.

[n3snah]

Thanks @PlagueHO it seems it was an issue on my end. I have been able to create new namespaces now.

[n3snah]

@PlagueHO is this issue still current?
It seems to work fine on Windows Server 2016 when I try using the commands you have given

[PlagueHO]

Hi @laywah2016 - which version of WS2016 are you using? I wonder if it has been fixed in a recent update or perhaps WS2016 build 1803?

[n3snah]

This is the version I am running.

Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      14393  0