Microsoft and SAP NetWeaver – step by step up to the cloud – Part IV : simple offline copy of a central system
Intro
in the first three blogs of the series the following topics were discussed :
1. SCOM integration :
2. automated installation of a dialog instance :
3. automated guest-OS Windows patching :
In part IV I want to talk about SAP system copy. This is another complex topic. Therefore the idea
was to start with a very simple use case and describe more complicated ones in the next blog(s).
So what could be such a simple use case ? Well - just imagine a single VM with a central instance
including everything which is needed to run e.g. a demo or do some training or use it to do a
quick prototype of some new customization. There are situations where it's perfectly fine to just take
a snapshot of the VM. But in other scenarios you want a separate copy to continue working with the
original VM at the same time.
This blog will describe an option how this could be accomplished.
The challenge
As mentioned in the intro section the task was to figure out how a simple copy of a SAP central
system in a VM could be done. The test was run using System Center 2012 and Windows 2008
and a SAP system based on SQL Server 2012.
Like in the blogs before an Orchestrator runbook was used to automate the whole process. But
looking at the VMM integration pack for Orchestrator it turned out that the "create VM from VM"
activity doesn't allow to change the hostname of the VM. That's of course an issue. Working with
both VMs ( the original source VM and the new copy ) in the same network requires different
hostnames. In addition the activity requires that the source VM is offline. While this would be an
issue when copying a production system it should be ok for the other scenarios. It also makes
sure that the disk content is consistent before the copy starts.
Everyone who works with SAP NetWeaver knows that it's not possible to simply change the
hostname of a central system. There are some basic adaptions necessary like SAP profiles and
depending on the complexity of the landscape quite some additional post-processing.
So how could one solve this even for the first most simple scenario ?
The solution
Let's first have a look at the VM copy process. Here is a description of the basic workflow.
As mentioned in the section before Orchestrator 2012 was used to control the whole
process. So all necessary steps were started/called out of an Orchestrator runbook :
1. create a snapshot on the source VM which is up and running
2. then run sysprep unattended on the source VM which will change the hostname
3. sysprep will shut down the source VM via a sysprep parameter
4. now make a copy of the source VM via the VMM activity in the integration pack for
Orchestrator which is called "create VM from VM". This way the copy will have
the new hostname which was specified for sysprep
5. start the new VM and join it to a domain
6. reset the source VM to the snapshot which is an undo of the sysprep. Start the original
source VM again. Afterwards the source VM will have its original hostname
7. at the end both VMs with different hostnames will be up and running in the same
network
While the steps above can be easily automated to do the VM copy - what about SAP ?
There is a SAP Rename Tool available which makes all necessary changes to bring
a SAP system up again after the hostname changed. It's based on the sapinst
framework and therefore it can be automated like an unattended sapinst installation.
The attached walkthrough paper will show how to use the SAP rename tool manually.
An automated call of the tool via an inifile will be described in a future blog. While the
tool allows to automate the basic adaptions there is still some post-processing work
left. The walkthrough paper will talk about this aspect.
Walkthrough
I attached a walkthrough paper which describes the steps of the solution in detail :
1. the first part talks about the VM copy via an Orchestrator runbook
2. the second part describes the SAP System Rename Tool