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 part I of the blog series :
it was described that one important aspect of private cloud is automation. It also mentioned that System Center 2012 plays an essential role in the Microsoft private cloud story. While Hyper-V or products like App-V add key capabilities for virtualization it's System Center which offers automation and self-service.
This blog will show a first use case in the SAP world. It's about a fully automated installation of a SAP dialog instance in an existing SAP landscape. Question is if and how this can be accomplished using System Center 2012. Contrary to the SCOM integration sample in the first blog one can get very far just using the Microsoft products. The challenge comes up again once it is necessary or desirable to access the SAP system. Like with SCOM 2012 there is no out-of-the-box SAP integration with VMM 2012 or Orchestrator 2012.
As an example for SAP system access the assignment of the newly created dialog instance to a SAP "Logon Group" was chosen. While it's not a big deal to do this manually via SAP GUI transaction SMLG the idea was to also automate this last step of the whole dialog instance installation process. Similar to the SCOM-SAP integration described in the first blog a 3rd-party tool was used to connect to the SAP system and fulfill the task.
"EasyCloud" from connmove was used in the following sample to cover the logon group assignment. They are working on a new version of "EasyCloud" which will be a collection of PowerShell cmdlets to access a SAP system and execute all kinds of typical tasks. The approach also allows an easy integration into Orchestrator.http://connmove.eu/en/software/easycloud/
The usage of the "Set-SMLGLogonGroup" cmdlet out of the new connmove "EasyCloud" product can be seen in the walkthrough section of the blog further down.System Center 2012 is a product suite which consists of several components :App Controller, Configuration Manager, Data Protection Manager, Endpoint Protection, Operations Manager, Orchestrator, Service Manager, Virtual Machine ManagerTo implement the SAP dialog instance sample two components of the System Center 2012 suite were used :1. Orchestrator 2012 „Orchestrator is a workflow management solution for the data center. Orchestrator lets you automate the creation, monitoring, and deployment of resources in your environment.“
http://technet.microsoft.com/en-us/library/hh237242.aspx2. Virtual Machine Manager VMM 2012 „Virtual Machine Manager (VMM) is a management solution for the virtualized datacenter, enabling you to configure and manage your virtualization host, networking, and storage resources in order to create and deploy virtual machines and services to private clouds that you have created.” http://technet.microsoft.com/en-us/library/gg610610.aspx
The following walkthrough should be seen as an example how automation in a SAP landscape using System Center could look like. The use case is one piece of a full SAP private cloud implementation. More scenarios will be described in the next upcoming blogs.IMPORTANT - here are two key prerequisites for the following walkthrough which are not described in detail in this blog :1. a simple VM template with Windows 2008 R2 was created in VMM 2012 ( http://technet.microsoft.com/en-us/library/hh427282.aspx )2. a sapinst installation in unattended mode was prepared as described in SAP Note 950619 ( SAP Note 950619 - Installation of SAP Systems with Unattended Mode )The basic workflow of the automated installation of a SAP dialog instance which is described in detail in the walkthrough section looks like this :a, create a new VM with Windows 2008 R2 from a VM template in VMM 2012b, run a sapinst installation of the new dialog instance in unattended mode on the newly created VM ( the SAP software is placed on a share in the network outside of the VM )c, once the new dialog instance is installed it will be assigned to a new logon group
Figure 1 : starting point is an existing SAP system with SID "B74" and system number 10
Figure 2 : the instance with system number 10 is assigned to logon group "LogonGprivCloud1"
Figure 3 : the Orchestrator "Runbook Designer" was used to define the workflow which would automate the installation of a new SAP dialog instance. There are a lot of out-of-the-box "activities" which can be easily put together via drag&drop to build a complete workflow / process chain
Figure 4 : in addition to the default "activities" it's possible to install so-called "integration packs" which extend the list of available "activities" in the Orchestrator Runbook Designer. The screenshot shows a list of activities which are part of the VMM 2012 integration pack.This allows easy access to VMM functionality ( e.g. start / stop VM ) out of an Orchestrator runbook ( Orchestrator integration packs : http://technet.microsoft.com/en-us/library/hh295851.aspx )
Figure 5 : for the SAP sample two runbooks were created. The first one includes just one activity to set some parameters like the name of the new VM which will include the new SAP dialog instance ( wsiv5200 ) as well as the system number for the new instance ( 09 ). Not everything was parameterized in the workflow ( e.g. domain join is hard-coded ). But the used parameters prove that it's possible to fully parameterize all critical values. The activity will invoke the second runbook and hand over the parameters
Figure 6 : the second runbook includes the whole workflow which will install a new SAP dialog instance. It's pretty straight forward : 1. activity : Initialize Data - get parameters from the calling runbook 2. activity : Create VM from Template ( triggers the creation in VMM 2012 ) 3. activity : Start the newly created VM 4. activity : Create a share on the file system in the new VM 5. activity : Copy a zip file to the share in the new VM ( sapinst related ) 6. activity : Unpack the zip file 7. activity : Prepare the infile.xml for sapinst in unattended mode 8. activity : Create directories and copy files for sapinst 9. activity : Start sapinst in unattended mode to install the new SAP instance 10. activity : Assign a new SAP logon group to the new dialog instance
Figure 7 : a short excursion to VMM 2012. The runbook will create a new VM from an existing VM template. For those who haven't seen VMM yet - it has a simple "create VM template wizard" which makes it really easy to create templates and store them on a template library
Figure 8 : there are many options defining the details of a VM template which is beyond the scope of this blog. One important setting can be seen here - the domain information. Instead of defining it in the VM template the domain join will be done via the Orchestrator runbook to be more flexible
Figure 9 : the first activity in the installation workflow "Initialize Data" just takes the parameters from the calling runbook and provides them to the other activities in the workflow. It's the starting point of the process chain and the next activity will be triggered
Figure 10 : the second activity in the runbook will create a new VM from an existing template in VMM. It's an activity out of the VMM 2012 integration pack and needs a connection to an existing VMM server. In this sample the domain join of the new VM was defined within the runbook activity. This gives much more flexibility than defining it inside the VM template.
Figure 11 : other parameters in the list for creating a new VM are the path on the file system where the vhd file should end up ( cluster shared volume in this sample ), hostname of the new VM, name of the VM template and so on. The VM name was parameterized to show how it works and that in principle all of the settings could be variables.
Figuer 12 : parameterization of the activities in a runbook is a key feature to keep everything flexible. Just do a right-click on the value field and then select "Subscribe". There will be a choice between runbook variables and "Published Data" which comes from other activities
Figure 13 : after selecting "Published Data" one gets a dialog which shows a list of activities and the data which they provide and which can be used as input for the current activity settings. Therefore only activities will show up in the list which will be processed before the current one except the "Initialize Data" activity. The latter one is always available like a global variable. In the sample one parameter for calling the runbook is the name of the new VM. As it's a parameter of "Initialize Data" it can be used anywhere by every activity in the whole chain.
Figure 14 : the third activity is of type "run program" and allows to run programs or commands on remote computers. Here it is used to create a simple share on the new VM to prepare for the sapinst unattended install. More details will follow below. For those who are interested in how the program start will be done : http://technet.microsoft.com/en-us/library/hh206096.aspx “The Run Program activity is based on PsExec.”
Figure 15 : after creating the share it's easy to use a "copy file activity" to copy a prepared zip file from the local Orchestrator server to the new VM. The content of the zip file is explained on figure 16 below
Figure 16 : the zip file prepared on the local Orchestrator server includes the following files : - copy_sap_files.bat ( a simple bat file to create directories and copy files ) - doc.dtd, inifile_template.xml, keydb.dtd ( files related to sapinst unattended install ) - prep_inifile.ps1, replace_SAP_var.bat ( two scripts to create inifile.xml ) - start_dir.cd ( related to sapinst -> includes path to SAP software ) - start_sapinst.bat ( simple bat file to start sapinst in unattended mode ) SAP Note 950619 ( "Installation of SAP Systems with Unattended Mode" ) describes the details regarding the installation process in unattended mode. One outcome is the inifile.xml. For the sample this file was renamed to "inifile_template.xml" and some key values like hostname were replaced by placeholder strings. The simple prep_inifile.ps1 script will then replace these placeholder strings by the actual parameters of the Orchestrator runbook and provide the final inifile.xml for sapinst
Figure 17 : the start_dir.cd file simply includes the path to the SAP software. In the sample case it was also placed on the local Orchestrator server
Figure 18 : there is a dedicated "Decompress File" activity available. The purpose is self-explanatory.
Figure 19 : another "run command" activity was used to prepare the inifile.xml. As mentioned above there is an inifile.xml template in the custom zip file which includes some placeholders. The bat file calls the ps1 script to replace these strings. This was done to evaluate different ways of calling a Powershell script out of Orchestrator. It's not as easy as it looks like. The issue was that control wasn't given back to the runbook and the activity remained in status "running". A partner in Germany ( http://www.vaserv.eu/index.php/en ) found an interesting workaround by putting the following two lines at the end of the Powershell script : $objCurrentPSProcess = [System.Diagnostics.Process]::GetCurrentProcess(); Stop-Process -Id $objCurrentPSProcess.ID;
Another possibility how to call a Powershell script directly is described when calling the SAP logon group assignment script further down.
Figure 20 : this is the trivial Powershell script which will replace some self-defined placeholders in the infifile_template.xml file and create the inifile.xml required by sapinst in unattended mode.
Figure 21 : now as the inifile.xml is prepared the next activity in the runbook will call a little bat file to create some directories and copy the content of the zip file to the correct places
Figure 22 : the simple bat file which is called out of the runbook does the following : a, create two directories for sapinst in unattended mode b, it's necessary to put inifile.xml, keydb.dtd and doc.dtd in a different directory than start_dir.cd. In addition sapinst has to be called in the same directory where start_dir.cd was copied to c, another directory will be created to unpack sapinst.exe - see details below
Figure 23 : now everything is ready to call sapinst. There is again a little script which was part of the zip file which will be called out of a "Run Program" activity
Figure 24 : the script to start sapinst shows a little issue which has to be considered. For the unattended mode some parameters are required. But this would NOT work when calling sapinst.exe directly on the SAP software share. Reason for this is that sapinst.exe on the SAP media is in fact a self-extractor. There is an option how to extract the files from the sapinst.exe package : sapinst.exe -extract It turned out to perform more stable when doing the extract on the new VM. Therefore a separate directory was created for this purpose. The extract call will then unpack all the related programs and so on into the newly created directory on the new VM including the "real" sapinst.exe installer. Afterwards sapinst.exe will be called using the appropriate parameters for unattended mode ( see SAP Note 950619 ) : SAPINST_PARAMETER_CONTAINER_URL SAPINST_EXECUTE_PRODUCT_ID SAPINST_SKIP_DIALOGS=true -nogui -noguiserver SAPINST_START_GUI=false <SAP Software Share\SAP_Netweaver_7.30_OS-DB_dependent.........>\product.catalog
Figure 25 : to make it more clear this screenshot shows the file size of the sapinst.exe self-extractor on the SAP software share
Figure 26 : after extracting all files from the sapinst.exe package one will find the "real" sapinst.exe installer which is of course considerably smaller than the self-extractor
Figure 27 : last but not least after the new dialog instance was installed the ps1 script will be called to assign the new instance to a new logon group. As already mentioned earlier there is a problem when simply calling a ps1 script out of Orchestrator. It doesn't realize when the script is finished and remains in running mode. Here is a workaround how it can be accomplished :
cmd.exe /c | C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -c c:\SAP_Software\SAP_assign_lg.ps1 < parameters > The little ps1 script was stored on the local Orchestrator server.
Figure 28 : the ps1 script which assigns the new logon group to the new dialog instance shows the usage of the SMLG cmdlet from the connmove EasyCloud product. It's straight forward. A variable stores the connection data and then a simple call of Set-SMLGLogonGroup does the job. For the sample the password of the SAP user was just put into the script. connmove is working on SNC support for their new cmdlet based EasyCloud version.
Figure 29 : once the Orchestrator runbook started one can check the VMM side. There should be a job triggered by the runbook to create the new VM out of the existing VM template
Figure 30 : at the end there should be "success" for every activity in the runbook
Figure 31 : transaction SMLG shows that the new dialog instance with instance number 09 was correctly assigned to the new logon group "myLGgroup"
Figure 32 : it's a good idea to double-check via transaction SM51 that the new dialog instance is really available
Figure 33 : last check is the SAP MMC which also shows the correct entry for the new instance