none
Configuration store xy01\rtc does not match with any central management store in Topology RRS feed

  • Question

  • Hi there,

    we have encountered with a strange issue. I hope someone have seen something like this.

    Topology:
    I have 3 pools: 2 FE pools in 2013 with configured resiliency and 1 FE pool in 2019. CMS hosted in 2013.

    Steps performed:
    I've performed a CMS failover which was ran from 2019, it was successful. Afterwards I've performed a pool failover from 2013, also the pool failback was completed. I have issues only with the Set-CSEdgeServer cmdlet as I cannot set back the Edge server's registrar pool.

    Error:
    When I run the Set-CSEdgeServer cmdlet on 2019 I get the following error:

    Configuration store "xy01\rtc", does not match with any central management store in Topology
    The CMS is placed exactly on the location what the above error message says. I have a working replication, the CMS is not in failover mode, if I run the Get-CsManagementConnection, Get-CsManagementStoreReplicationStatus -CentralManagementStoreStatus cmdlets then it shows that the CMS is hosted on xy01 correctly. Backup service and stuffs like that has no issue also. In AD in the config partition I can also see the correct server.
    If I run the same cmdlet on 2013 then I basically get that I have to run this from 2019. So it is kind of a paradox.

    I cannot failover the CMS from the 2019 FE now (it has worked before) as I get the following error:
    Invoke-CsManagementServerFailover : Central Management service is not installed in the current topology.

    Have you seen such issue? Any idea what can be done?

    Thank you in advance.

    Wednesday, July 17, 2019 8:47 AM

Answers

  • Hi,

    just a quick update we found out why we get the error.

    In AD, in the config partition where the CMS placement is stored (msRTCSIP-BackEndServer attribute) there was the backend server's FQDN used, for example xy01.company.com\rtc.

    In the topology, the SQL stores was added by the servers' NetBIOS name, for example: xy01\rtc

    This is what caused the confusion for the SfB 2019 and that's why it said the Central Management service is not installed in the current topology. When we had only the 2013 system this was not the issue for that system. But it is definitely an important thing to have an eye on, only FQDN-s should be used!

    We fixed this in AD (as in the topology it cannot be edited currently, only if we move it to 2019, modify there and move back if it is required by the customer), it was the faster solution. In the long term this is not really good for us, so it should be corrected in the future to FQDNs.


    I hope it can help for someone in the future.

    • Marked as answer by Salieri_92 Monday, July 22, 2019 12:58 PM
    Monday, July 22, 2019 12:58 PM

All replies

  • Hi Salieri,

    What is the xy01, the backend sql server?

    Please run “get-CsConfigurationStoreLocation” to check the result.

    Rerun “Invoke-CsManagementStoreReplication” and “Get-CsManagementStoreReplicationStatus” to check all the CMS replication status are up to date.

    In addition, try to modify it in topology builder and check if there is any event error on the servers.


    Best Regards,
    Shaw Lu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Thursday, July 18, 2019 2:40 AM
    Moderator
  • Hi,

    thank you for your answer.

    Yes, xy01 is the primary dedicated SQL server of the first FE pool of the 2013 environment.

    The Get-CsConfigurationStoreLocation cmdlet shows that my backend server is xy01\rtc which is correct and the mirror is xy02\rtc which is the mirror SQL server of the first FE pool of 2013. So I would say it is correct.

    The replication works flawlessly across all of the 3 FE pools. There are zero events about any CMS related issues on the FE servers, also there is no sign of any error on the SQL servers.

    Thursday, July 18, 2019 12:53 PM
  • Hi Salieri,

    How about trying topology builder? Check if there is any error when you set back the Edge server's registrar pool.

    In another way, you may schedule a downtime and try to reboot the servers.


    Best Regards,
    Shaw Lu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Friday, July 19, 2019 8:25 AM
    Moderator
  • Hi,

    sadly the same thing can be experienced if I switch the registrar in the topology builder. When I would like to publish the topology I get an error message.

    Also both environment have been restarted at the weekend, no improvement can be experienced.

    I'm thinking of moving the CMS somehow or rebuilding that in the new environment. The only good thing is that this is "only" a pre production environment so drastic measures can be taken if necessary and possible.

    Monday, July 22, 2019 7:32 AM
  • Hi Salieri,

    Have a try to use “remove-CsConfigurationStoreLocation” and re-publish the topology. Maybe you should use FQDN for the location (xy01.domain.com\rtc).

    Refer to this thread:

    https://social.technet.microsoft.com/Forums/office/en-US/d5041099-f5b7-494f-a8b2-35406d68d40b/lync-server-2010-error-publishing-topology-and-installing-server-components?forum=ocsplanningdeployment

    Also, do a backup first.


    Best Regards,
    Shaw Lu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Monday, July 22, 2019 7:52 AM
    Moderator
  • Hi,

    just a quick update we found out why we get the error.

    In AD, in the config partition where the CMS placement is stored (msRTCSIP-BackEndServer attribute) there was the backend server's FQDN used, for example xy01.company.com\rtc.

    In the topology, the SQL stores was added by the servers' NetBIOS name, for example: xy01\rtc

    This is what caused the confusion for the SfB 2019 and that's why it said the Central Management service is not installed in the current topology. When we had only the 2013 system this was not the issue for that system. But it is definitely an important thing to have an eye on, only FQDN-s should be used!

    We fixed this in AD (as in the topology it cannot be edited currently, only if we move it to 2019, modify there and move back if it is required by the customer), it was the faster solution. In the long term this is not really good for us, so it should be corrected in the future to FQDNs.


    I hope it can help for someone in the future.

    • Marked as answer by Salieri_92 Monday, July 22, 2019 12:58 PM
    Monday, July 22, 2019 12:58 PM
  • Glad to see you find it out.

    Thanks for your sharing, it is quite useful.


    Best Regards,
    Shaw Lu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Tuesday, July 23, 2019 12:39 AM
    Moderator