So I entered the hostname rather than the FQDN in the Topology Builder for my first Front End, ooooops! You’ll probably see this error, however there is no way to update the FQDN once the Topology is published:
“NetBIOSNameNotAllowed: This topology contains the following servers or clusters that use a NetBIOS name as the fully qualified domain name (FQDN) value, which is not supported. Please update the NetBIOS name to an FQDN, for example pool01.contoso.com.”
To avoid the pain and suffering I went through, here’s what I did:
- First I created a new Front End pool to install the CMS (in my case Std. Edition)
- Next I needed to get my CMS moved from the original and incorrectly named Front End. The trouble is that this naming problem will stop you being able to do this. Moving the CMS may result in an error such as follows: “This central management store is being moved to another location. No changes can be made until this move is completed”
- Instead I re-created the CMS on the new Front End pool using the following PowerShell command:
1Install-CsDatabase -CentralManagementDatabase -Clean -SqlServerFqdn <Server to host CMS> -SqlInstanceName <Instance e.g. RTC> -Verbose - I then had to change the SCP location in AD using the following command:
1set-csconfigurationstorelocation -sqlserverfqdn <Server to host CMS> -sqlinstancename Rtc -report c:\logs\storelocation.html - I then re-defined my topology and published
- Afterwards I notice some broken ApplicationEndpoints that referenced the original Front End. I fixed most of these using the following PowerShell:
1Get-CsApplicationEndpoint | Move-CsApplicationEndpoint -TargetApplicationPool "<New Pool>" -force - The remainder had to be deleted using ADSIEdit, then a re-publish of the topology re-created them. Use PowerShell to identify any objects that are incorectly assigned to a Front End:
1Get-CsApplicationEndpoint | Select DisplayName, RegistrarPool, OwnerUrn, Identity, ApplicationDestinationDN
Hopefully you never have to do this 🙂
File stores could be entered that way, as well – NETBIOS instead of FQDN. That being said, the aforementioned statement WAS true up until Skype for Business Server 2015 Topology Builder. Topology Builder in S4B 2015 now has validation checks that validate the file store format. Discovered this little nugget back in May of 2016:
https://ucvnext.org/2016/05/preliminary-primary-filesharename-parameter-is-unusable-with-lync-server-2013/
Sadly, there are other validation checks I assumed TB would perform that have been proven to be untrue over the years. Just the tip of the iceberg and super frustrating.
Hadn’t spotted that! Strange they have fixed the file store validation but not the pool name which causes some major issues once published. Agreed, pretty frustration when you make a simple mistake that takes hours to fix.
Trunks with NetBIOS name are also now flagged in Skype TB where they weren’t in Lync TB.
Thanks for the feedback 🙂