on 04-26-2010 11:58 AM
Hello
I've been asked to create a clone , on a new machine, of a productive Business Objects installation.
The aim is to connect this clone to test systems.
The operation will be done replicating the snap of the productive BO. This means that the ip and the server name will change. Then all the links to the connected systems must be changed to the test systems.
I'm looking for a manual or a best practice to perform this activity.
Has anybody performed a similar activity or knows about a valid document?
Thanks a lot,
Dino
You cannot clone BOE installation.
You need to install a new BOE system, patch it to the same patch level as original. You need to use a new CMS DB for this new system.
Once that new system is up and running, you can migrate all content from original system by using any of the 3 methods below :
1. CMS DB copy process + FRS copy
2. Import Wizard
3. LCM
First 2 methods are described in the Admin guide, last one in the Life Cicle Manager documentation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Denis,
Is this still the case - you cannot clone BO servers as a way to stand up new environments? I wasn't sure given the age of this posting... and no version listed...
We are about to clone our dev environment to support 2 additional dev environments, one will be BO 4.0 like our current dev and the other we will upgrade to 4.1. We will be creating new CMS/Auditing schemas in a new database, but imagine there will still be a lot of config changes to make from the cloning process.
I didn't see anything in the admin guide saying it should not or could not be done, but there also was no instruction on how best to do it either...
Thanks,
Missy
Hi Kim,
We ended up not doing a clone. We were going to clone VM to VM and use and then reconfigure actually. Since we found no success stories of cloning, we decided to build from 'scratch' mostly instead. So we did something similar to what Anupam says below...
We took a CMS database backup and restored it to a different schema. We did not run the delete queries, but it didn't seem to think it was part of the other cluster. Oddly, the issue we ran into was that, when time to set up server2, it thought it was part of a cluster with new server1. Neither server thought it was part of a cluster with the original server where our CMS database originated - they just thought they were part of the same new cluster. Hopefully that made sense... not sure how best to describe what happened!
We did not use a backup of the FRS. We just used Promotion Management and ran imports between the original system and our new systems. That worked fine. We broke up the imports into chunks. It did not take that long and we have a couple thousand reports, universes, etc.
We use Windows AD for authentication. After setting that up, we thought that if we used LCM to bring over the Access Levels, Connections, Universes, and lastly Folders, it would preserve the permissions and user/groups settings, but this was not the case. I still had to go through the top level folders and set permissions/groups, etc. to be inherited/denied.
I am not sure how the way Anupam suggests would preserve the rights differently, but if that did work fine, it would be good to know!
Hope that helps!
-Missy
Hi,
You can also create a replica from current running system using the CMS Database backup and FRS Backup.
Steps in short would be:
Take a backup of CMS Database and FRS
Restore CMS Database backup on a different schema.
Execute following queries on the restored database
For 3.x: delete from cms_infoobjects6 where parentid=16 or parentid=59
For 4.x: delete from cms_infoobjects7 where parentid=16 or parentid=59
Above queries will delete all references to the other system (we dont want to have a cluster of two systems)
Install Business Objects on a different machine. (Preferable the same version of which the backup was taken)
Create a new SIA on the new machine pointing to the restored database. In case of 4.x use the same cluster key of the source system
Restore the FRS backup taken on the New machine on the default location.
Before starting SIA change the Cluster name from SIA Properties
Start SIA and you will have a replica of the source environment.
All reports/users/rights will be same as the one in the source.
Hope it helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Anupam,
See my reply to Kim above... we used LCM import to bring in content. How does the method you suggest differ in terms of bringing in the user rights? I would have thought that LCM method would have preserved them too - some were, but others weren't. There was no rhyme or reason to it... so it seemed.
Thanks,
Missy
Missy,
Refer the SAP note 1275068. The KBA is to restore a system from a backup.
It can also be used to create a clone of a system as Dino has said in his original question.
Well 'Clone' word is tricky as it usually means a VM Clone.
'Replica' would be a better term.
KBA: http://service.sap.com/sap/support/notes/1275068
-Anupam
User | Count |
---|---|
90 | |
10 | |
10 | |
10 | |
7 | |
7 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.