Need to Relocate Existing VM Windows Beacon onto another Windows VM Server

[bruce_giles]

Hi Everyone, just wondering if anyone else has had to relocate an existing Beacon onto another Server. I have opened up a Case asking the same question but thought someone may have already been faced with this and could offer some encouragement and perhaps some steps to follow if there are any.

I was just informed that due to end of life support for Windows Server 2012 I need to move 7 Beacons onto a newer version of operating system. I asked about simply doing a In Place Upgrade but apparently the infrastructure team does not offer that.

My initial thought is .. this will be a nightmare to say the least. We run many business adapters along with the Studio so having to rebuild things from scratch will be next to impossible I'm thinking.

Just throwing this out there just in case someone has been faced with a similar scenario. I will update this thread when I hear something back from Support, as  I am thinking it will happen to us all at some point.

Thanks in Advance

Bruce

[adrian_ritz1]

Hi,

What I can think of is the following:

Create DNS alias for each beacon server.

Configure the Alias on beacon server to be send out to agents.

After you are sure that all agents received the updated policy, change the alias to point to your new beacon server.

Regarding business adapter, they are xml files, and I think they can be moved.

May by other have other suggestions. 

[erwinlindemann]

Agree with Adrian. It might be easier if you could re-use the DNS alias name of the old Beacon(s) for the new replacement Beacon(s). That way, you don't have to do any changes to the Beacon configuration in FNMS, to the FNMS Policy (Beacon Names), FNMS Rules or to the FNMS subnet configuration.

Some additional thoughts:

When installing your replacement Beacon servers using a newer Windows OS, a new Beacon can use the same Beacon name, DNS name and same BeaconUID value as the old Beacon.

The BeaconUID value is being created and initialized with a random string when the Beacon software is being installed. You can find the existing BeaconUID value in the Windows registry on the old Beacon here:

HKLM / Software / WOW6432Node / ManageSoft Corp / ManageSoft / Common

Update the BeaconUID value on the new Beacon to match the BeaconUID of the old Beacon after installing the Beacon software, but before configuring the parent connection.

For Business Adapter XML configuration files: In case you have stored credentials with encryption, you may have to open the XML configuration file in Business Adapter Studio and save a copy where credentials are not encrypted.

In case you are using HTTPS on your Beacon(s) and you are re-using DNS names, the HTTPS certificate could be transferred from the old Beacons to the new Beacons and configured in IIS, too. When updating HTTPS certificates and/or Beacon DNS names, an updated certificate (CERT file) will have to be copied to all computers running a Flexera Agent on a non-Windows OS.

[adam_young]

That's good timing, I have a similar challenge in that i need to move my Beacon servers from physical to virtual servers in the next couple of months.
I was thinking along the lines of Adrian and Erwinlindermann and was going to look at setting up aliases for my beacon servers and then moving the alias to the new servers when built.
I'll be interested to see what support have to say, hopefully it's an option.

[bruce_giles]

Hi Everyone, thanks very much for the suggestions on how this could be accomplished .. really appreciate it. I have now found out that I can  re use the same existing server name and IP address if I like. I would simply shut down each beacon one at time, taking it out of rotation sort of speak and rebuild it on the new operating system. The other method I thought of which was also suggested above, was to build the 7 new beacons, add them into the mix so that the agent policies get updated with the new available Beacons .. let that sit for a week or two to make sure all agents receive the new policy and then remove or delete the original ones, where once again the agents will receive new policies leaving only the new Beacons.

Looks  like there are a couple of methods  .. I am speaking with the Support Team today so I will bring up the ideas that you suggested to see what they think. I will also update this thread after speaking with them to let you know what their thoughts are in terms of what may work the best with the least amount of headaches.

Thx Again

Bruce

[bruce_giles]

Hi Everyone, as promised  .. I had a discussion with the Flexera Team yesterday regarding their thoughts on how best to migrate or relocate Beacons from one environment to another. During my conversation I mentioned the scenarios identified  in this thread leveraging the alias dns names as part of the solution along with some others.

Primarily we kicked around 2 scenarios 

One being able to rebuild the server on the new operating system using the same Server Name and IP address from the hardware / instance perspective, along with using the same "actual" Beacon name currently in the FNMS environment. Just thinking out loud here .. this method would make it easier in terms of proxy bypass settings not having to be changed along with any other specific network type of changes. Other things that would not have to change would be the subnet mappings, discovery rules since the subnet mapping to beacon names remain the same, business adapters could probably remain as well. The messy side would be copying the UID details over as mentioned in this thread and probably a few others things we have not thought  of.

The other scenario is to build brand new Beacon servers with new Server Name and IP with brand new Beacon names and add these to the existing pool of Beacons doubling the number of current Beacons for a short time until all devices receive updated policies. The upside to this method is that you have both old and new working at the same time to ensure everything is working as expected before deleting/removing the old ones. More effort is required to re assign all of the subnets over the testing period to the new Beacon names but you could control what Discovery Rules along with any Business Adapters you wanted to test by only re assigning those related to the rules or adapters. All the associated Network type of things like proxy bypass rules etc. would have to be updated accordingly.

As you can see, lots to think about no matter which way you choose to go and I am sure I am leaving some pieces out but I think you get the idea. The individual I was talking with suggested the second scenario would be a lot cleaner and I think we would all agree .. much lower risk of things going dramatically wrong since the old is still available. Either way, the option of creating a Case to resolve any challenges is always available but as we know is not something immediate so you would want to factor that piece in as well. Me personally, I am still thinking about which way but leaning towards the latter. One other thing to mention regarding the Business adapters, since the xml details are kept on the Beacon of choice, they could be copied from the old server to the new one  along with creating new tasks in the task scheduler. He was pretty confident that just copying the xml over would work but again something that would need to be tested in a dev/test environment before attempting in production.

Please take this as simply my personal view of how it may be accomplished but by all means submit a Case yourself, if you have any questions or concerns. Lots of things to think about for sure, so take your time and plan things out accordingly.

Bruce