Hi Pedro,
- Regarding the hostnames... We're going to maintain all the SIDs, but regarding the hostnames and/or ip addresses,what's the usual procedure on a case like this one?
- I was thinking in after the copy, using anh procedure to change the hostname of the machine. is it possible? And since this a homogeneous system copy, alot of follow-up activities (if i can change the hostnames) don't make sense to me, what will i need to change from the post-processing activities, and will stay the same?
With regard to changing hostnames, for the most part the system copy follow-up procedures will take care of the parts that need to happen internal to the newly copied system. Most of this is making sure that hostname values in various profile parameters are correctly set. After you've completed the copy and start the system for the first time, it will be started with default profiles like a newly installed system. In transaction RZ10 you will want to do Utilities... Import Profiles... Of Active Servers.
This will make copies of the external profiles (stored as files in the \usr\sap\<SID>\SYS\profile folder) in the database. Afterwards, you'll be able to see both the new profiles and the old profiles that came with the database copy from the source system. You will eventually delete those old profiles, but you may want to copy some of the parameters into the new profiles. It might be easier to print out lists of the parameter values from the source systems first as a reference. Decide on each parameter on a case-by-case basis.
The harder part is locations where the hostname is referenced in RFC connections in other systems. In any system that interfaces with the copied system, you will need to go into SM59 and edit the RFC connection to reference the correct hostname. You'll also need to go into STMS on your transport domain controller (probably your DEV system) and update the TMS settings to reference the new hostname.
Then the hardest part is updating the SAP Logon connection entries of all your SAPGUI clients to reference the new hostname. Depending on your SAPGUI landscape is setup, this may be easy (if you use a centrally managed saplogon.ini file), or very difficult (if you have to edit saplogon.ini entries individually on each and every workstation). If you don't use a centrally managed saplogon.ini for your SAPGUI clients, this is a great time to push out a SAPGUI upgrade with some scripting to change this.
- Regarding the kernels... How do i check if a kernel is a EXT or not from GUI Fronted? Status view isn't clear to me...
- The actual kernel is 7.21 for (ERP and BW ) and 7.20 for Solution Manager. Should i upgrade the kernels in the source system for EXT kernel (if they're not already (that's why i've asked the question 3)? Or can i just install the target with those kernels?
You're right, it's not always obvious if you are using the EXT version of a kernel or not. Not all of the usual places will tell you. But there are a few ways. From within SAPGUI, go to transaction SM50, highlight the system in question, and click Release Notes.
The result will tell you the kernel version and patch level of the disp+work.exe executable, which should match the kernel as a whole. This place will include whether it is EXT or not.
Note that this does not tell you the OS or DBMS version. This system I'm looking at, for instance, is running on SQL Server 2012, which is SQL_Server_11.xx, not 9.xx, and on Windows Server 2012 R2, which is not NT 6.0. This is just stating what OS/DBMS releases the kernel executables were compiled in back at SAP.
There are other methods as well, not all of which require a SAPGUI login. A great one is via the SAPMMC. Peter Simon has a great blog on this at 7 Methods To Retrieve The Version Of SAP Executables.
Regards,
Matt