HPNZNB asked a question.
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!
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
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
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!
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/s/FlexNet-Manager-Knowledge-Base/How-are-the-failover-settings-built-for-FlexNet-inventory-agents5474
1. The FQDN to access the beacon is changing; AND
2. HTTPS is being used (i.e. so the FQDN used to access the beacon must match the server name as specified the SSL certificate on the beacon)
then another option to consider would be to stand up a new beacon in the new domain while keeping the old beacon running for a period of time. This will give deployed agents a chance to update their policy and failover settings to get the new beacon details from the old beacon before it is turned off. If they are unable to do update their settings before the old beacon is turned off, you will need to find a way to update the configuration settings each deployed agent so it knows about the new beacon
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!
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.
1. The FQDN to access the beacon is changing; AND
2. HTTPS is being used (i.e. so the FQDN used to access the beacon must match the server name as specified the SSL certificate on the beacon)
then another option to consider would be to stand up a new beacon in the new domain while keeping the old beacon running for a period of time. This will give deployed agents a chance to update their policy and failover settings to get the new beacon details from the old beacon before it is turned off. If they are unable to do update their settings before the old beacon is turned off, you will need to find a way to update the configuration settings each deployed agent so it knows about the new beacon