Hello Experts,
We are running a domain migration project for all servers. Flexera servers (App, beacon, database) and monitoring servers will migrated to a new domain. Now. we have over 2000 server installed the Flexera agent and talk to beacon properly.
Will all these servers still talk to beacon after the domain is changed?
Thanks!
‎May 11, 2020 11:44 AM
‎May 12, 2020 04:41 AM
Creating a CNAME record in DNS can be helpful as it allows agents to continue using the old FQDN for the beacon that they already have configured for communication.
Getting the SSL certificates right may be tricky: the certificate on each beacon will normally need to accurately identify the name of the beacon, and match the name that agents use for communicating. It is possible to configure agents so they do not check the certificate details - what that is possible, it is not ideal if you are trying to guard against DNS-based attacks on the network.
‎Oct 28, 2020 08:27 PM
hi @HPNZNB ,
can it be seamlessly achieved? i think you have to do required changes in IIS, SSL certificates and the complete FNMS setup for this to work everything as usual and i'm not not sure how to do this. if there is a trust relationship between the existing domain and the new domain then things might be a bit easy.
This is a peculiar scenario and i'm also very interested in knowing how this can be achieved.
@mfranz , @kclausen , @dennis_reinhardt , @ChrisG forum experts could you please share your experiences
‎May 12, 2020 02:02 AM
Hi,
There are a lot of things to consider just from a server operations perspective. Just regarding the agent question: I guess it depends on how your agents communicate. Specifically, how does the beacon report to the application server and how is it know to the agents.
If the short name is used, you may get away with it. If the FQDN is used, you may have to make sure all agents do get an alternative location to communicate to, before the actual change happens. Also maybe you can use some DNS magic to make sure the "old" Beacon name still resolves to the right IP address.
Best regards,
Markward
‎May 12, 2020 02:15 AM
Thanks for the reply!
The new domain and old domain will trust each other. Also we will upgrade the FNMS 2018 R1 to 2019 R2 (on-Prem) use the new service account in the new domain.
The App server , Beacon server and all agents use port 443 to talk. the FQDN of the beacon will be changed, maybe the IP address of the beacon will keep same.
Is there a specific solution for this?
Very appreciate!
‎May 12, 2020 03:56 AM
If you run SSL, you won't be able to trick the communicatuion with a simple DNS alias, because the server will have to answer with the requested name and the certificate need to cover that name.
I guess you will need to share the new beacon name with all agents, prior to flipping the switch. This has been discussed in the forum. One way would be to add an additional "fake" entry to the Beacon_MT table.
There's also a KB entry covering the details: https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/How-are-the-failover-settings-built-for-FlexNet-inventory-agents/ta-p/5474
‎May 12, 2020 04:13 AM
‎May 12, 2020 04:41 AM
Thank you all for the information.
After talked with our domain migration project team, we found a way that maybe works. I would like to check with you all to see if it possible.
Can we create the CNAME record that point to a-record of new Windows server 2019 (new FQDN)? The change is on the DNS server end.
Do you think this can resolve the problem? Do I need to apply new SSL certificate on each servers for agent?
Thanks a lot!
‎Oct 21, 2020 10:35 AM
Creating a CNAME record in DNS can be helpful as it allows agents to continue using the old FQDN for the beacon that they already have configured for communication.
Getting the SSL certificates right may be tricky: the certificate on each beacon will normally need to accurately identify the name of the beacon, and match the name that agents use for communicating. It is possible to configure agents so they do not check the certificate details - what that is possible, it is not ideal if you are trying to guard against DNS-based attacks on the network.
‎Oct 28, 2020 08:27 PM