Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Cloning a BOE server 1
- Thread starter Rivdog
- Start date
-
1
- #2
Hi,
Could be a very difficult task, considering the number of components affected by an Install ( web server configuration, some development tools, like VisualStudio, etc) and the many registry entries it creates..
Far better to do the fresh install and import as needed...
![[profile]](/data/assets/smilies/profile.gif "[profile] [profile]")
To Paraphrase:"The Help you get is proportional to the Help you give.."
Could be a very difficult task, considering the number of components affected by an Install ( web server configuration, some development tools, like VisualStudio, etc) and the many registry entries it creates..
Far better to do the fresh install and import as needed...
To Paraphrase:"The Help you get is proportional to the Help you give.."
- Thread starter
- #3
Turkbear,
Thanks for your reply. Yes, you're confirming what I'm already have heard from others. Just want to double-check.
I asked BO and they gave me some non-official documentation on cloning. It was not for cloning at the server level but for cloning of the CMS and the files for the Input and Output servers.
Sorry, forgot one important facotr: the OS is Windows Server 2003, SP1.
Regards, mrivney
Thanks for your reply. Yes, you're confirming what I'm already have heard from others. Just want to double-check.
I asked BO and they gave me some non-official documentation on cloning. It was not for cloning at the server level but for cloning of the CMS and the files for the Input and Output servers.
Sorry, forgot one important facotr: the OS is Windows Server 2003, SP1.
Regards, mrivney
Hi,
Yes, that type of 'cloning' is used to create a clustered BOE environment which helps with load balancing and has fail-over capabilities..
We duplicate all our BOE services on 2 servers with both CMSs connecting to the same database ( in our case, an Oracle instance on another server).
To Paraphrase:"The Help you get is proportional to the Help you give.."
Yes, that type of 'cloning' is used to create a clustered BOE environment which helps with load balancing and has fail-over capabilities..
We duplicate all our BOE services on 2 servers with both CMSs connecting to the same database ( in our case, an Oracle instance on another server).
To Paraphrase:"The Help you get is proportional to the Help you give.."
The problem with "cloning" is that when you make a copy of the database, it still points to the original CMS server. So, when you first bring the new CMS up, it thinks it is in a cluster with the original server and very strange things can happen.
For example, our production staging environment has an exact copy of the production databases that is made every time we do a software release to production. The first time we did this after we BObj running in production, I ran into some major problems when I brought the prod staging CMS up. I changed the CMS properties to point to the correct database, but that database said it was part of the production cluster. So I renamed the "cluster" in the CMS properties to point it back to the prod staging server. At that point, no one could log into production because it had changed the name of the production cluster in the production database even though the prod staging CMS should have been reading the prod staging database! I suspect that if the production cluster had been down, I wouldn't have had the problem. However, we now export the prod staging CMS database prior to the db copy and then truncate the tables to remove the production data and add the correct data back to it before we ever bring prod staging back up.
So, I would be very wary of just cloning the database! If you're moving from one server to another, I've outlined the steps here: thread782-1361382.
-Dell
A computer only does what you actually told it to do - not what you thought you told it to do.
For example, our production staging environment has an exact copy of the production databases that is made every time we do a software release to production. The first time we did this after we BObj running in production, I ran into some major problems when I brought the prod staging CMS up. I changed the CMS properties to point to the correct database, but that database said it was part of the production cluster. So I renamed the "cluster" in the CMS properties to point it back to the prod staging server. At that point, no one could log into production because it had changed the name of the production cluster in the production database even though the prod staging CMS should have been reading the prod staging database! I suspect that if the production cluster had been down, I wouldn't have had the problem. However, we now export the prod staging CMS database prior to the db copy and then truncate the tables to remove the production data and add the correct data back to it before we ever bring prod staging back up.
So, I would be very wary of just cloning the database! If you're moving from one server to another, I've outlined the steps here: thread782-1361382.
-Dell
A computer only does what you actually told it to do - not what you thought you told it to do.
- Status
Similar threads
- Locked
- Question