(imported comment written by SystemAdmin)
Looks straightforward enough. My thought was to have the new server take on the name and IP of the old. Does that make things easier…does it even matter…or is it best practice to change it? Thanks.
Mike
(imported comment written by SystemAdmin)
Looks straightforward enough. My thought was to have the new server take on the name and IP of the old. Does that make things easier…does it even matter…or is it best practice to change it? Thanks.
Mike
(imported comment written by jessewk)
Mike,
The new machine needs to match the information in your masthead. That is certainly the recommended technique and it does matter. If you need to switch the information from that in the masthead, it is equivalent to redeploying BES.
Hopefully your masthead uses a DNS name to supply the server address. If so, you will just need to point the DNS record to the new machine when it is ready. If your masthead uses an IP, then you will need to ensure your new server receives the same IP as the old server. The hostname of the machine does not matter.
-Jesse
(imported comment written by SystemAdmin)
Masthead is setup by IP. So, looks like I can make the new box a new name. Looks like I’ll have to manually copy everything over prior to the install. Once I get all the data on the new box and get ready to install - I’ll have to take the old box off the network and then rename the new with the same IP and server name. So, the fail over script won’t work for me on that. But I know what has to go over. Thanks.
There is a chance I won’t get this going by Thursday - in which I will have to wait a few weeks to start it up. Got a big project starting on Thursday. Will keep you posted though. Hopefully you won’t have to answer and crys for help on the support line
Mike
(imported comment written by SystemAdmin)
So that I have the steps down. Does this look correct? At least a the break down point. Using article 133 as a guide as well. Thanks.
Old Server - Win2003SP1 w/ MSSQL 2000 SP4
New Server - Win2003x64 w/ MSSQL 2005 x64
New server will retain name and IP of old server
(New server is prepped and ready - SQL installed)
Copy over all relevent BES folders from old box to bkup directory on new server.
Migrage SQL accounts to new server - verify migration in SQL.
Stop all BES services and detach DB on old server - copy DB to new server.
Disconnect old server from network - physically.
Rename new server to old name and IP from old server - run NewSID utility to registery SID in domain properly and quicker.
Attach already moved DB into SQL.
Install BES (pointing to exisitng DB and masthead).
Overwrite the necessary (3) folders with what was copied over from old server.
Open BES and verify that the DB connects.
Verify in the console that clients are reporting in.
Verify that a console installed on a general workstation opens.
Verify that a push to a client works.
(imported comment written by StacyLee)
I’m very interested in hearing how the migration goes. We are coming up for a hardware refresh soon and this what I want to do. My biggest concern is we have over 100 Console Operators and want to make sure that they get migrated to SQL 2005 instance seemlessly.
(imported comment written by SystemAdmin)
I just started the kickoff of a unrelated project today - so I hope to get back to this maybe middle of next week. If not, it might be closer to Christmas or shortly after. I want to have at least 2 days set aside - incase of issues. I’m a bit nervouse about it - but if support blesses my process list above, then it should be fairly easy. Looks like the biggest pain is migrating the SQL users from 2000 to 2005. It is not a nice clean process. I only have about 15 console users - so worst case I could recreate them and have them reset their password after logging in. Which I might just do anyway. I’ll post how it all goes.
Jesse or Tyler…should I open a support call with you say that morning - incase there are issues? Or just wait till something comes up (which hopefully it won’t).
(imported comment written by SystemAdmin)
Hi Mike,
I would arrange the migration like this:
(New server is prepped and ready - SQL installed)
Stop all BES Services on primary BES Server.
Create a backup of the BFEnterprise and BESReporting databases.
Attach databases on new box.
Migrate SQL logins to new server. You’ll need to run a query to do this… http://msdn2.microsoft.com/en-us/library/ms174378.aspx
Install BES Server on new computer. It should find and use the existing databases.
Stop BES Server services on new box.
Copy over the following folders from the old BES Server to the new BES Server:
C:\Program Files\BigFix Enterprise\BES Server\ClientRegisterData\registrationlist.txt
C:\Program Files\BigFix Enterprise\BES Server\sitearchive
C:\Program Files\BigFix Enterprise\BES Server\wwwrootbes\bfsites
C:\Program Files\BigFix Enterprise\BES Server\wwwrootbes\bfmirror\bfsites
C:\Program Files\BigFix Enterprise\BES Server\wwwrootbes\bfmirror\downloads
C:\Program Files\BigFix Enterprise\BES Server\Mirror Server\Inbox
C:\Program Files\BigFix Enterprise\BES Server\wwwrootbes\Uploads
Also, copy your site level and user keys as well if they are stored on the main BES Server.
Restart services on new BES Server
Redirect traffic to the new BES Server (drop the old servers IP and give the new BES Server the IP in this case).
The new BES Server should be fully functional at this point,. To verify install the BES Console and take an action targeted at all computers. You should see them all respond in a timely manner.
At this point you should disable the services on the old BES Server and leave it as is to be a failover point if you have no other use for the server. Or, you could make it a Web Reports server, a Terminal Server for BES Consoles or a top level BES Relay
(imported comment written by SystemAdmin)
Ok, phew! The deed has been completed. The entire process took me a couple of hours to prepare and about an hour to do the actual migration.
Migration was I think more scary in preparation than the reality. BES Document ID 133 was very helpful. Also, I used SysInternals NewSID to make the SID of the new server the same as the old server (server name was staying the same). That I believe saved me a ton of time dealing with domain and WINS issues. That was slick - I highly recommend it (free utility from SYSInternals).
The SQL conversation was actually not bad at all. I followed the instructions from MS KB246133 (as BES ID 133 states). And although it seemed a bit daunting at first - it really only took about 5 minutes for the entire process. So far, I have only had one user that I had to reset their SQL password (and my thinking is that they actually forgot what it was). Only think I strayed from in ID 133 was that instead of doing a DB detach and attach - I did a backup and restore (just preference).
Performance on the console is about 20% better than the old 32bit server. Not huge - but this migration was more about hardware refreshing and future expansion. Getting a performance boost of anything was a plus. And for most part the console is running 32bit workstations. The console on the 64bit server actually runs about 30% better.
If I can be of any assistance or any questions on what I did - please give a shout. Thanks.
Thanks BES support for all your guidence.
Mike
(imported comment written by SystemAdmin)
Update on the SID Changer utility.
I found afterwards that I had some issues with really being on the domain. I ended up removing the server from the domain (joing workgroup) - and then rejoing the domain. That cleared up my issues. So, my suggestion is if you use the SID changer - go with a new SID and not use the SID of the old box.
(imported comment written by SystemAdmin)
Tyler,
I just now realized that there was a page 2 to this forum. I had been only checking checking for new posts on page 1 all this time. So, I never saw your post about migration steps above - prior to my move. Everything you mention was done except for the copying over of the registrationlist.txt, mirrorserver\inbox folder and Uploads folder. Do you think it is too late to do that now (I migrated on Monday). Thanks.
Mike
(imported comment written by Shlomi91)
Hi All,
my configuration is a bit different:
BES Server on an IBM X series 336 (dual Xeon 3.2 GHz, 2 GB RAM)
central SQL 2005 database (IBM X series 336 (Dual Xeon 1.5 GHz, 4 GB RAM)
console running from my 32 bit Vista enterprise PC, (Pentium D, 2.8 GHz, 2 GB RAM)
i’m migrating the Database server to a new HP machine (4 CPU’s, 8 GB RAM, Windows 2003 ent. 64 bit OS).
im planning to migrate the database this way:
stop BES services
backup the database
detach and copy the database files to the new server
re-create users on the new SQL server
attach the database and map users
change ODBC connectors on the server and console computers
start BES services
keep my fingers crossed.
actually, i already migrated the database before, so i dont expect any problems.
i am hoping for faster performance, however.
i am also thinking about installing 64 bit Vista for the console.
ill let you know how it goes (migration and performance wise)
cheers,
Shlomi
(imported comment written by SystemAdmin)
Hi Shlomi,
Your migration procedure looks solid. This procedure is only for moving a remote database to another server, if you had it locally installed there might be additional complications but in your case you just need to make sure the logins transfer over and the BES Server/Consoles know where the new database location is. You should also make sure the ‘BFEnterprise Reindex Job’ moves to the new server as well, if it doesn’t your database will become fragmented and slow.
What is different about the new server that you will hope improve performance? If you could also share your your disk/RAID arrays are set up for the database that will help as well.
(imported comment written by Shlomi91)
Hi Tyler,
we got a new toy (4x8 64 bit machine with fiber disk storage) to play with, and are moving all the databases to the new server.
this is now done, and there is some marginal improvement… (could it be only psychological? i dont know…).
the only difficulty i had was when migrating users, i had to reset the passwords (since these are encrypted on the database).