This Blog provides information about running SAP Applications on the Microsoft Platform. The Blog is written by people who are working with SAP on the Microsoft Platform for decades.
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 aquick 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.
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 differenthostnames. 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 ?
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 wholeprocess. 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 hostname7. 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 bringa SAP system up again after the hostname changed. It's based on the sapinstframework 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 thetool allows to automate the basic adaptions there is still some post-processing workleft. The walkthrough paper will talk about this aspect.
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 runbook2. the second part describes the SAP System Rename Tool