Walkthrough - SAP Central System “offline copy”
Attachment to blog “Microsoft and SAP NetWeaver – step by step
up to the cloud – Part IV : simple offline copy of a central system”
Author : Hermann Daeubler, Program Manager, Microsoft
Date : Aug 2012
Figure 1 : starting basis for the offline-copy sample was a central instance installation. SAP, SQL Server
and SAP GUI were all installed inside a single VM. SAP SID was “CT1”
Figure 2 : the offline-copy sample uses the VMM “clone” feature. It’s therefore a good idea to first
check manually in VMM that everything works as expected by going through the VMM
clone wizard for the source VM which should be copied
Figure 3 : at the end of the VMM clone wizard one can look at the Powershell script which implements
the clone. To narrow down any issues it makes sense to copy these commands one by one
and run them. That’s how I figured out a problem related to the VM name ( NOT the VM
hostname but the name under which one can see the VM e.g. in Hyper-V manager ).
Looking at the error message of one of these commands it became clear pretty quickly
that using a hyphen or brackets in a VM name is not a good idea …
Figure 4 : this is a picture of an Orchestrator runbook which prepares the source VM for the copy
process. All individual steps will be explained below. The VMM integration pack for
Orchestrator was used to provide all the necessary VM-related activities.
The basic idea is like this :
- create a snapshot on the source VM
- then copy a Powershell script to the VM which will be used later on to join a domain
- also copy a XML file to run sysprep in unattended mode
- change the hostname in the sysprep file
- run sysprep and shutdown the source VM
- then run another Orchestrator runbook to continue with the copy process
Figure 5 : some global variables were used in Orchestrator to define the target host and
storage where the VM copy should be placed as well as the new hostname of
the copied VM and the source VM hostname as well as logical name of the
source VM
Figure 6 : there is a “get VM” activity which returns all kinds of data for a given VM. It was used
to retrieve the VM ID which is needed as a parameter for other activities
Figure 7 : a VM snapshot was taken on the source VM.
Running sysprep after taking the snapshot allows to change the hostname
for the VM copy. At the end the snapshot will be deleted to return the
source VM to its original state and hostname
Figure 8 : there is an activity which allows to copy a file between machines. Here a Powershell
script was copied from the local Orchestrator server to the source VM. The script
was used later on to join the copied VM to a domain :
param ($domain, $user, $dpwd )
$duser = $domain + "\" + $user
$localmachine = get-wmiobject Win32_Computersystem
$rc = $localmachine.JoinDomainOrWorkgroup(
$domain, $dpwd, $duser, $null, 3 )
Figure 9 : afterwards an xml file was copied from the local Orchestrator server to the source VM in order
to run an unattended sysprep. The placeholder “%NAME% was replaced by the new hostname
which the VM copy should get :
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="generalize">
<component name="Microsoft-Windows-PnpSysprep" processorArchitecture="amd64"
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<DoNotCleanUpNonPresentDevices>true</DoNotCleanUpNonPresentDevices>
<PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>
</component>
</settings>
<settings pass="specialize">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64"
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ComputerName>%NAME%</ComputerName>
<TimeZone>UTC</TimeZone>
<DisableAutoDaylightTimeSet>true</DisableAutoDaylightTimeSet>
</component>
<component name="Microsoft-Windows-TerminalServices-LocalSessionManager"
processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral"
versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<fDenyTSConnections>false</fDenyTSConnections>
</component>
</settings>
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64"
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<TimeZone>UTC</TimeZone>
<DisableAutoDaylightTimeSet>true</DisableAutoDaylightTimeSet>
<OOBE>
<ProtectYourPC>3</ProtectYourPC>
<SkipMachineOOBE>true</SkipMachineOOBE>
<SkipUserOOBE>true</SkipUserOOBE>
</OOBE>
<UserAccounts>
<AdministratorPassword>
<Value>………………………………………………………………………………………………………</Value>
<PlainText>false</PlainText>
</AdministratorPassword>
</UserAccounts>
</component>
</settings>
</unattend>
Figure 10 : and here is the next activity in the runbook which simply replaced the placeholder
in the unattended sysprep xml file with the new hostname
Figure 11 : details of the file path. As one can see parameters from the former copy activity were used
Figure 12 : then sysprep was called on the source VM :
cmd.exe /c %WINDIR%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown
/unattend:c:\unattend.xml
Figure 13 : then a get VM activity was used to wait until the source VM was off
Figure 14 : it turned out during the tests that there might be still a timing issue even if the activity
before is in a loop until the state says “off”. A simple ping on the local Orchestrator server
was used to add a 90sec break before moving on
Figure 15 : after the preparation another Orchestrator workbook was called using the snapshot ID
as a parameter. This was used for further activities in the second runbook
Figure 16 : this was the second Orchestrator runbook. The basic idea was like this :
- create a copy from the source VM
- start the new copy and join a domain
- get rid of the snapshot of the source VM and reset to its original state
The following screenshots will explain the individual steps
Figure 17 : the “initialize data” activity was used to get the snapshot ID from the calling runbook
Figure 18 : then the get VM activity was used again to retrieve the VM ID
Figure 19 : the “create VM from VM” activity created the copy of the source VM
Figure 20 : in VMM the creation of the new VM copy showed up in the VMM job list
Figure 21 : the first branch after creating the new copy reset the source VM to its
original state
Figure 22 : the “restore checkpoint” activity restored the snapshot of the source VM
and therefore an undo of the sysprep was done. By deleting the snapshot
the source VM also got back its original hostname
Figure 23 : after restoring the snapshot was simply deleted
Figure 24 : then it was possible to start the original source VM again
Figure 25 : the second branch of activities after creating the new VM copy took care of the
domain join
Figure 26 : first step was to start the new VM
Figure 27 : the get VM activity was used to wait until the VM was running
Figure 28 : via the looping properties of the activity one can define when the loop should
be finished
Figure 29 : there was again a timing issue due to some post-processing after sysprep. The next
activity which needed to access Powershell on the new VM failed to start. A simple
workaround was to add a break. It’s possible to solve this in a more efficient way
by checking if all the sysprep post-processing is finished
Figure 30 : to call the Powershell script on the new VM to join a domain first required the policy
setting as it’s not allowed by default. There are items which one could put already
in the sysprep unattended XML file or do it later by calling e.g. a script.
There are pros and cons. For the domain join the decision was made to just call a
Powershell script. Here is the command which was used to set the PS policy :
cmd.exe /c | C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
set-executionpolicy unrestricted –force
Figure 31 : after setting the policy the script was called to join a domain :
cmd.exe /c | C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
-c c:\joindomain.ps1 domain_xyz user_xyz password_xyz
Here is an example how the domain join could be done via the sysprep unattended XML file.
The component would be part of the <settings pass="specialize"> section :
<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64"
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Identification>
<Credentials>
<Domain>domain_xyz</Domain>
<Password>password_xyz</Password>
<Username>user_xyz</Username>
</Credentials>
<JoinDomain>domain_xyz</JoinDomain>
</Identification>
</component>
Figure 32 : the new VM was shut down after the domain join
Figure 33 : and then the new VM was started
Figure 34 : all single steps of the runbook should be “green” in the log
Figure 35 : same thing for the log of the first runbook – all steps should be “green”
Walkthrough - SAP System Rename 1.0
Attachment to blog “Microsoft and SAP NetWeaver – step by step
up to the cloud – Part IV : simple offline copy of a central system”
Author : Hermann Daeubler, Program Manager, Microsoft Corporation
Date : Aug 2012
Figure 1 : after copying the source VM the SAP system didn’t come up due to the change of the
hostname. Only the DAA instance came up using the new hostname correctly. But e.g.
SQL Server as well as SAP profile files still included the old hostname
Figure 2 : there is a standalone tool available on the SAP Service Marketplace which helps
to make all the necessary changes related to the new hostname to make sure
that the SAP system will start. There is still some post-processing required which
will be mentioned further down
Figure 3 : the tool can be found on the support portal under “Software Downloads”. On the left side
select “Search for Support Packages and Patches” and then type “System Rename”
Figure 4 : the search result should then include a link to the System Rename tool
Figure 5 : especially to support SQL Server 2012 but also in general only the latest version should be
downloaded
Figure 6 : the tool was built using the sapinst framework. The look&feel is the same as if one would
install a new SAP system. For the use case described in the blog the first option of the tool
was used. The description doesn’t include a hint about the hostname. But the following
screenshots will show that a hostname change is covered by this option too
Figure 7 : for the blog sample the SID was also changed from CT1 to CT2. The value for “SAP Global Host”
reflects the change of the hostname during the VM copy process
Figure 8 : for the sample the SAP instance number wasn’t changed
Figure 9 : the database connection had to be adapted to the new hostname
Figure 10 : the database name was adapted to reflect the new SID
Figure 11 : a domain was selected for the SAP system accounts
Figure 12 : passwords ….
Figure 13 : more passwords
Figure 14 : domain information for the SAP system was entered
Figure 15 : no license installation was done. The tool will still continue in this case and install a temp
license. There is some additional info related to the SAP license at the end of the
walkthrough
Figure 16 : like with a standard sapinst installation there was a summary screen at the end
Figure 17 : at the time when the summary screen shows up there is an inifile available. This could be
used to do the whole thing in unattended mode as described for the regular sapinst in
SAP note 950619 ( Installation of SAP Systems with Unattended Mode ). An example will
be shown in a future blog
Figure 18 : finally the tool started to make all the changes. Again the look&feel is the same as for a
normal SAP installation via sapinst
Figure 19 : Bingo ! After the tool finished - the SAP system came up correctly. The database schema was
changed to ct2 and the SAP profiles were renamed using the new hostname
Figure 20 : the topic “post-processing” was mentioned before. The System Rename tool will only
cover the basics to make sure the SAP system comes up. Depending on the system
there will be a small or a huge list of items left which have to be adapted. One example
is SAP Logon. The new CT2 entry was made manually
Figure 21 : as one can see at the bottom of the screenshot – the transport system is another item
which was not touched by the System Rename tool
Figure 22 : last but not least there is the SAP license question. The picture shows that a temp license
was installed by the rename tool
Figure 23 : the important point is that the hardware key changed. It’s different between the source
VM and the new VM