We’ve moved to new hardware, OS & SQL versions with a complete rebuild reusing the original masthead on a number of occasions. You do need to re-created everything from scratch so make sure to export all your custom properties, analyses, baselines etc first. Don’t install the server with the fqdn of the current server as that will cause problems. I found it best to temporarily add the fqdn of the real sever to the local hosts file so the new server resolves to its local address that way you don’t have 2 server using the same masthead and conflicting with each other.
I guess another option, though not one I’ve used myself, could be to use the license key center to create a new masthead for the new server then you can build it without fear of conflict then once its all up and running, you can move the license to the new masthead.
Thanks For the response. by the wat I don’t have problem in keepping the baselines…etc.
How about using the Same Vm with the same adresse and host name (Reinstall the OS and Database) ?
could you please tell how can I export the exist licence , mastheaded… before reinstall the OS ? and If is it possible to use it for the new installation??
I found the BESIicence Autorization file i used it in the first deployment.
Could you plz confirm to me if I reinstall the OS and The platforme using the Same Autorization file it will be accepted known that we will use the Same hostane, the same Adress??
You could build the new server with a different hostname then edit the hosts file so it resolves the real server name back to itself then you can install the Bigfix server without having to take doe the current server. Once your have it ready to go live, you can then remove the hosts entry and change the server name to the one used in your masthead. You will need your server signing key and password in order to activate the new installation with the existing masthead. As long as your client resolve the fqdn in your masthead to the new server, every should switch. Clients will reset themselves as there will be a new epoch datestamp for the new server.
Thanks a lot for the reponse.
If I understant we should Install a new server : (I suggest using the same Adress of the old one) using the Same masthead in the step of Licencing. “I want to install with an existing masthead” don’t you? known that i have the password of the private key, the masthead ?
It all depends on your masthead. If your masthead is to an IP address then you have no choice but to use the same address, but if its using fqdn then you can build it on any server name then manage name resolution via dns (that is the method I used to migrate to new hardware). Then install the server and use the options to use your existing masthead where you will then need your private key.
You can do a full migration of all data to a new server, this is basically what you would do for disaster recovery. You would just switch the FQDN from pointing at the old server to the new one once the new one is up and running and working. Regardless, you are the one that controls the hostname and address ultimately.
When you set up the new server, it does NOT need to match at first, it can be all on its own, but use the existing license and masthead and everything. It won’t be reachable by your existing clients at first, but you can force a client to think it is the right server by modifying the hosts file for testing purposes. DO NOT modify the hosts file for all clients, only as a temporary measure to make sure everything is working. Once an existing client can talk to the new server and process actions from it, then you can swap everything over on the network side and basically have one root swap places with the other.
I think this process is actually easiest if you migrate all the data from the old server to the new one… If you don’t do that, then you might have to do something more complicated to get the severs to swap places.
Thanks a lot for your responses.
The problem is in the mastheade we are using the IP adress nt the FQDN. I think the solution is to use the same IP Adress in the second server don’t you? and use the masthead for the first Bigfix server?
If the masthead has an IP address and not a FQDN you can still do the above, it is just harder to achieve.
You may want to do a masthead switch from IP address to FQDN anyway because IP address may become a problem you can’t work around in the future. If this is what you choose to do, you can setup a new root server with the same license, but a new masthead with a FQDN. Then on the old root server you can run an action to tell your clients to switch from the old root to the new root.
To use the existing masthead, you have no other option. Personally, I’d look to change to new masthead that uses fqdn so you don’t have the same problems at a future date, be in due to hardware or OS upgrade reasons. I’m sure you can create a new masthead via the licensing centre or contact IBM support to get a new masthead.
Also, the FQDN that you put in your masthead does not need to match the actual FQDN of the root server itself… it can just be a CNAME record that points to the actual FQDN of the root server, which THEN resolves into the IP address of the actual root server.
For example:
in the masthead could be: bigfix.myawesomecompany.com which is a CNAME that points to the following real FQDN.
while the real FQDN of the root could be: rootserver.it.computers.myawesomecompany.com
And that is without even considering a fake root / relay situation.
This is much better, because lets say you want to host your root server in AWS in the future, then you could point the CNAME bigfix.myawesomecompany.com to the VM in AWS that could be something like random.random.aws.com
Then lets say you decide to migrate from AWS to azure, then you can switch your FQDN to point to random.random.azure.com
This is why what in the masthead should always be a FQDN and not an IP.
I’m totally agree with you, concerning the use of the FQDN.
Unfortunately we shoud re-deploy the platfome Asap so I will keep the same masthead although it hs the @IP.
So,as a recap: I will install a new platforme with the same IP@ and during the installation procedure I will use the same masthead (of the old server)
Thanks for your responses and i will come back to you if i will need help.
If your existing “old” root is still functional, then you can migrate everything over like a disaster recovery from backup to the new server, then once everything is working, set the new root server to be a failover relay on one of the clients on the “old” root server and have it do a relay selection and it should switch over to the new server. Then you can swap the server IPs of the old root to the new one and all the clients should follow.
You can do this without really losing anything and while having both roots working at the same time for a while to make sure everything is working properly. The issue is anything done on the old root won’t show up on the new one after the restore from backup.
Thanks for the clarification.
We don’t need to keep Data on the old one, and even if want to do that to create an action to set the new server as a root server tasks don’t complete because an error message is shown saying that there is a problem om the databae.
So i will install the second from scratch with the same IP adress and use the same masthed.
I’m not sure if the clients will rejoin the new one automatically or not. They may, but I don’t have experience doing this. If you do a disaster recovery restore of the old root to the new one, then they will.
You might be able to fix this by running the bes admin cleanup, at least enough to get things working to get it switched over. I would also disable all analyses and external sites temporarily.
How many endpoints do you have total?
It might be best to do a full recovery to a new server, swap the IPs, get things working, then do another one to a totally new masthead using a FQDN and a masthead swap action.
This issue is why we no longer ship SQL Express with the trial installation.
I have also looked into relicensing SQL Express to a higher level SQL license without reinstallation or migration of the DB, which might also work, but I have never attempted it.
No matter what you do, a full DB backup is a good idea.
Clients should switch over, based on my experience. When I upgraded to new hardware and a new installation with the existing masthead (using fqdn though), as the new server had a new ActionSiteEpoch date, all our relays and clients reset, gathered from the new server then started to evaluate content and send reports back to the new server. It just took a few hours as the relays had to sync with the new server in order for clients to refresh. How long it takes will depend on the how many relays/clients and how well connected they are to the main server or top level relays but it was hassle free when I did this (it was a few years and versions ago however).
I just did this and it worked. I took a snapshot of my VM, I then ran the SQL 2008 R2 setup, clicked maintenance, and then performed an Edition Upgrade. In less than a minute I had my existing BigFix root server switched from SQL Express to an Edition without the 10GB limit.