on 06-29-2013 2:27 PM
Hello
We have a Solution Manager 7.1 SPS5 system where we have already configured the following features
A lot of SAP notes were applied +
System Monitoring based on the new MAI infrastructure(diagnostic agents etc etc) +
CHARM (with a lot of customizing enhancements to meet our requirements) +
Other miscellaneous features like DVM, EEM, Dashboards etc +
Now we interested to build a landscape for our solution manager with a D system in place so that future changes can be tested before being done directly on production (the above is already being used productively)
My understanding is that though the system copy tools allow copying Solution Manager based on the existing system copy guides for NW 7.02, its still not clear how my target would be usable?
Does anyone have experience with copying a Solution Manager system 7.1 > SPS5 and were successful in using the target operationally without any big difficulties? I was wondering would it be a more clean approach to install again a new Solution Manager SPS5 ? and then again configure these ffeatures (trying to "copy" wherever possible?)
I have seen sap note 1797014 which tells that system copy of solution manager is in general possible, but wanted to hear some experiences
Appreciate if you could answer in details
Many thanks in advance
Chandrakanth
hi
we recently done so, i prefer system copy, the reason very simple, solman_Setup is the only thing you need to execute again, but tat also most of the steps automatically pops with green (like DB, RFC connection). other big advantage is your custom modifications are safe, no need to do it again. your logical components, bpmon and other monitoring stuffs are safe, no need to do again, just verify back after solman_setup
its regular system copy approach, align with the proper post system copy activity.
Thanks
Jansi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Jansi
Thanks for your answer. Helps to some extent
but what if i tell you that the only stuff on the source system which want to copy (or we are interested in) is the charm config. Because the source system has a complete different set of systems/solutions/ and hence logical components. It basically belongs to a different landscape
considering this, i am assuming after the copy, i would need to run LMDB to bring my own systems into this target solution manager, configure the initial and basiic setup , configure my own managed systems and hence rfc's /logical components/solutions . i am NOT interested to keep any of the managed systems there were on the source .
so, you still think copy is the quick and right option?
In other words, do you think there is a clean way to copy only the charm config from one solution mnager to the other. The workbench is easily copyable by package export/import. but how about customizing and master data.
Thanks
Chandrakanth
Hello Jansi
Thanks for your answer. Helps to some extent
but what if i tell you that the only stuff on the source system which want to copy (or we are interested in) is the charm config. Because the source system has a complete different set of systems/solutions/ and hence logical components. It basically belongs to a different landscape
considering this, i am assuming after the copy, i would need to run LMDB to bring my own systems into this target solution manager, configure the initial and basiic setup , configure my own managed systems and hence rfc's /logical components/solutions . i am NOT interested to keep any of the managed systems there were on the source .
so, you still think copy is the quick and right option?
In other words, do you think there is a clean way to copy only the charm config from one solution mnager to the other. The workbench is easily copyable by package export/import. but how about customizing and master data.
Thanks
Chandrakanth
Hi Chandrakanth
As already suggested it is better if you go ahead with System copy option so that all your config will remain intact and it reduces time
further if you install a new system you have to transport all the config and create master data again which is a cumbersome process of duplicating efforts
in addition if you are making a copy of solman as a dev make sure the about the landscape strategy not all systems must be connect with solman dev like you connected with solman production.
check this maintenance guide for the landscape strategy as well because it is better to plan now itself
https://service.sap.com/~sapdownload/011000358700000639422012E/MaintPlan_Guide_71_SP05.pdf
hope this helps
Regards
Prakhar
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Chandrakanth
This scenario is full supported by SAP, the only thing is you should know all the task that need post-processing once is the system is up, like put on hold all jobs, Adjust the profiles, etc
and for the specific Solman Configuration all the checks you need to do ( check all functionality you have) remember that you already have some scenarios in place that are working on productive mode with DA in production, with the copy of the systems it will has another SID, and change the hostname, you can consider to connect some developtment of qa system with this system to be useful your validation before it goes to production ( this is the objective of this copy)
even you can considere this copy as developtment as part of your landscape for solution manager
to do that you can follow the standar guide for system copy in a dual stack.
put focus in the validation of the scenarios you already have cause im pretty sure it will need ajustments on each ones
Regards
Ernesto
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I did a database refresh for 7.01, to allow for a validation testing of SolmanUP to 7.1; while the upgrade failed I did refresh the Dev solman with what Prod was.
That being said, the ABAP portion was the easy part...the Java side of things however is difficult to accomplish. Even by using the sap_inst to export the Prod Java information and import it into the Dev system, I spent the better part of a week with the offline config tool changing old values of the Java stack to the new values (SIDs, Instance numbers, etc).
I also did not have much in functionality of 7.01 (Charm, monitoring, other services) working, so there was no validation done to know if that will break when or if you do a refresh.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Billy
I think (yes .. with some pain 🙂 ) , we shoudl be able to copy the dual stack
but i was interested more in the area of solman specific stuff. How usable would it be after the copy.
i assume things like solman_setup / initial/ basic/ managed system setup etc needs to be done again on the target after the copy. Having said this , would it really make any sense to copy a solution manager or just install a new one and start configuring it from scratch
The one aspect though in our case is that the source has a lot of 7.1 CHARM customization and workbench developments. So the efforts to install a new SM and copy the charm specific stuff is being evaluated against the efforts of copying the SM and removing unecessary stuff
Thx
Chandrakanth
User | Count |
---|---|
87 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.