Hi All,
We need to migrate a bigfix server to new build server using same license. DB will be new.
What are the recommendations we need to follow.
I’d suggest reviewing the BigFix Server migration documentation, and letting us know if you have any additional questions/concerns.
Can I use same license auth file to build a new BF server for migration ?
Server with new DNS name (complete infra migration). and old server will be sunset post migration…
You cannot use the same license auth file again, no (they are one time use). However, you can certainly generate a new license via the License Key Center to stand up a new BigFix instance, and migrate.
How many days I can run both instance (BF servers) with that same license number. ?
I may need a month time to complete migration
A separate BigFix instance will have its own license (and serial number). You can have them running concurrently as long as you wish, so long as you do not exceed your license allocation.
Yeah. that thing needs to be simplified. There should be some kind of tool where you can run some special backup process, then restore to a new server. At least for some common migrations, such as an OS upgrade.
Unless you have some need to migrate the deployment, I’d instead recommend setting up a DSA configuration with the new server as a secondary, then promote it to be the primary, then decommission the old primary and configure a DNS Alias to point the original server hostname to the new server.
No need to migrate all the clients (unless you are migrating a Windows root to Linux, or vice-versa; you can’t run a DSA configuration of mixed OS architectures.)
At a high-level, you can follow these steps to migrate to a new root BES server without having to create a new license or go the DSA route.
Obviously follow best practices published by BigFix, your RDBMS (i.e. DB2 or MSSQL) and your enterprise change management policies.
Hope the is helpful.
Best,
@cmcannady
DO I need to purchase a new license for migration purpose?
Can’t I have new authorization file created and I can use it for installation of new server then migration from old.?
Venkatraj
I like that method; seems clean. You’ve done it before I assume?
Has anyone performed an in place upgrade on a BES server?
For example: Windows 2012 R2 to Windows 2016? I know you get the warning about “upgrading a server isn’t recommended”, but it sure would be easier if you’re just looking at keeping the OS current.
Our BES is a VM with local SQL. Upgrading for the purpose of a hardware refresh is no longer a reason; just keeping the OS current.
Yes, I’ve used this method in large Linux (~100k >> P2V) and Windows (~30k+ >> V2V) environments to migrate to new root BES infrastructure.
For what it’s worth, I wouldn’t perform an in-place major OS upgrade for a root BES server (RHEL or WIN). Too much opportunities for introduction of gremlins in the system that could take weeks/months to identify. Plus the likely solution to excavate those gremlins would be to migrate to new OS/VM anyway.
We have just recently migrated to a new BF instance to get off our old 08 server, we did the license swap by creating a new license then creating a new masthead, then using the Switch BES Client Action Site Masthead - BES >= 9.0 and putting the new masthead in the uploads folder, it was a breeze. Only about 3k machines here but it was relatively straightforward. We turned the old one into DEV so we can not test in PROD. I have been told by IBM there is no issue with this setup.
Which folder did you put the new masthead? I assume you put it on the new server, then point the url to the new FQDN of the new server http://:52311/Uploads/masthead.afxm I need to do the migration and do fresh install.
Does the old masthead will stay active indefinitely or has a grace period as soon as I’m requesting a new license?
Thank you in advance
It is generally easier, if upgrading hardware or OS on the Old BigFix server, to just use the backup/restore method and keep the Old masthead. Then you don’t have to touch the clients.
https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/t_mgrt_rootapp_server.html
If you must swap mastheads, generally it is because the FQDN in the Old masthead will not reach the New BigFix server.
Migration of BigFix clients/agents from an Old BigFix server to a New BigFix server uses the Switch BES Client Action Site Masthead Fixlets from the BES Support site on the Old server. The Fixlet Description gives the details.
For that Upload folder you mention, that is usually this folder on the Old BigFix server: C:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\Uploads\ Put the New masthead there.
The New server masthead is put into a folder on the Old server so the Old server can send the New masthead to the Old clients, converting them into New clients.
Take action from the Old server console on the clients you want to send to the New server. The Old server masthead will stick around as long as you are running the Old server.
A final note, the HCL BigFix Professional Services team is expert in these types of migrations.
https://www.hcltechsw.com/bigfix/services
What are you hoping to achieve?
The options are:
Back up all the Bigfix data on your current server, build a new server, restore the data and do a fresh install of the same version of Bigfix over the restored data - this will result in the clients all reporting in to the new server with no change made to the clients and the server will still have all of its custom content and action history. You can then do in-place upgrades of the Bigfix version. The clients do have to be able to reach the new server using the original name and/or address (either
Build a new server with a new Bigfix instance, then export/import you custom content, then run migration actions from the old server to install the masthead for the new server. The clients will switch to the new server, which can be a newer OS and newer version of Bigfix, but with only the content you migrated at the cost of losing all your action history and your operators having to run two versions and instances of the console during the parallel run phase (and having to create new content and actions twice over).
I have picked up the work to do the migration for the 2nd option and done the whole of the first option. The first is much easier and is seamless for the clients and your operators.
The first also has the advantage of being able to crank up the old server as a backout if things don’t go to plan.
Thank you for your feedback @brolly33 and @trn
We have a new domain and the old domain will be decommissioned sooner or later. The masthead is associated to the old domain. There will be a new IP address, new server, and new domain on the new bigfix. After reading the migration doc, new IP and new domain are required to request a new license/masthead.
As of now, we have 2 options - leverage DNS alias or fresh install. I’m more toward a fresh install. If I go for the first route (DNS Alias), we may have an issue down the road when we decommission old domain or any other unknown issues that I can’t determine right now, and at that point we might end up doing a fresh install, where I can do a fresh install now and not having that issues in the long run.
I’m trying to find out what’s the impact requesting a new license/masthead to the old license. Will the old masthead stop working right away or there is a grace period 30,60,90 days?
You visit the HCL licensing site and generate a new license - initially it only needs a very small client count.
The old license doesn’t stop working, the two exist side by side, and you can them migrate any content you have creted (and want to keep). Then, as you move clients from the old server to the new, you simply adjust the client counts in the licensing site.
Good it. So there is no grace period when the old license will stop working.
Another challenge that come to my mind is we have users working remote during this time and they are not reporting to bigfix at the moment and we don’t open bigfix to the internet, how do I migrate them once we decomm the old bigfix server? How do we identify them at that point?
You’d need to migrate them before decommissioning the original deployment, usually by checking which machines are still reporting to the original and/or deleting their computer accounts when the successfully perform a masthead migration from the old server to the new one.
If they are normally not reporting to the original deployment, you may need to send the users a script to remove the original BigFix client and install a new one pointing to the new deployment.
If the deployment is large or complex, you might wish to engage Pro Services to assist with your migration project. Let me know if you’d like some contact info.