This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

With SAP LaMa you can auto-save on your Azure Managed Disk Costs

By now, most people know that after you’ve moved your SAP landscape to the cloud, you could save hosting costs by shutting down SAP system VMs when they are expected to not be used.
(There are caveats around this as it depends on whether you’re paying for reserved instances).

But did you know there’s also an extra saving that can be had in the cloud?

For SAP to support your SAP systems in Microsoft Azure, you must use Premium tier storage.
The reason for this is primarily because Premium tier storage comes with an SLA from Microsoft, which means you are expected to receive a certain level of performance from those disks.
However, you pay more for this SLA and the proposed performance. Which is quite correct, when you’re using the disk but what about when you’re not using the disk?

Right now, in the Azure “West Europe” region, a Premium tier P10 disk (SSD, 128GiB in size with 500 IOPS and 100MB/s throughput), will cost you £16.16 per month, excluding any deals and discounts (such as Azure Managed Disk Reservation).
The P10 is probably the work-horse of the majority of mid-sized server estates. Microsoft recommend a P10 as the Linux root disk for SUSE Linux based HANA database M-Series Azure VMs.

At the other end, the cost of a Standard tier E10 disk (SSD, 128GiB with 500 IOPS and 60MB/s throughput) is £7.16 per month, with the only performance difference being the throughput and the SLA:

So for the same size disk, although with lower throughput, we pay £9 per month less (55% less). I am going to say this saving is roughly 30 pence per day.

(There is one caveat and that is for standard SSD disks like the E10, you pay a transaction fee of 0.1 pence (£0.001) on the disk for every 10,000 256KiB I/O operations.
However, we will see that this transaction fee will not impact us and our saving, in a moment.)

Here’s how we can save money on this Premium managed disk.

In Microsoft Azure, you can change the disk tier from Premium to Standard, when the VM on which the disk is attached is shutdown (deallocated).
It’s simple, you just use the Azure Portal to change the disk configuration once the VM is shutdown.

While this is nice for just a couple of disks, this is not something you’re going to want to do on a regular basis.
Don’t forget, before you start the VM you need to switch the disk tier back to Premium (to retain your SAP support).
So for mass-changes, you may want to use PowerShell to adjust the disks before starting the VMs.
This itself could become a bit of a burden, since you now lose the ability to mass-power-on VMs from the Azure Portal completely.  You would need to use PowerShell all of the time, or setup an Azure based operation schedule (a.k.a. Power Automate – previously Microsoft Flow).

This is where SAP Landscape Manager (LaMa) really comes into its own.
With SAP LaMa, your BASIS team can:

  • Perform the start-up & shutdown of the SAP relevant VMs.
  • Perform the start-up & shutdown of the SAP systems on the VMs once they have been started (or the reverse).
  • Use the inbuilt scheduling capability of SAP LaMa to schedule the VM and SAP system operations (full automation of start-up and shutdown operations of the whole stack).

The security capabilities of Azure, coupled with SAP LaMa mean that the BASIS team can only perform specific VM related operations on the SAP VMs. Which gives the cloud Ops team peace of mind.

Now for the best bit.
To be able to save money on managed disk costs in Azure, the SAP BASIS administrator has to merely tick a tickbox in the SAP LaMa cloud provider settings, to “Change Storage Type to save costs”:

The next time the VM is de-allocated, SAP LaMa automatically changes the disk configuration in Azure, to a lower cost disk tier.
As we mentioned earlier, since the start/stop is controlled by SAP LaMa, it knows to switch the disk back to Premium tier during the start-up operation.

How simple is that!

As mentioned, there are some complications around any reservation payments for managed disk, so you need to understand what you’re paying for, before just enabling the tick-box!

Here are my very basic calcs for our P10/E10 disk combination example:

  • Weekends per year: 52
  • Saving per weekend: 60 pence
  • Total possible saving per year for 1 disk if it was unused every weekend: £31.20

Now let’s imagine that saving opportunity was applied across your 100 server estate, whereby every server had at least 1x P10 disk.
You can’t shutdown production, because it’s 24/7, but you don’t do development & testing round-the-clock and you have no international locations, so we are going to imagine our SAP estate is maybe 70% applicable to this saving opportunity. That’s 70 servers x £31.20 equals a saving of £2,184 per year on managed disk, by ticking a tickbox.

These are obviously just best guesses, but it shows how costs can build up and can also be reduced.

Happy ticking.

How an Azure hosted SAP LaMa Controlled SAP System Starts Up

We all know how this works in the old “pre-cloud” world.
To start a SAP system on a physical server which is currently shutdown, you would:

  1. Power on the physical host (through whatever means, ILO or a button or other).
  2. You log into the host as “adm” and run: “sapcontrol -nr ## -function StartSystem”.

We then moved from physical, to virtual:

  1. Power on the hypervisor physical host (through whatever means, ILO or a button or other).
  2. Power on the VM.
  3. You log into the VM as “adm” and run: “sapcontrol -nr ## -function StartSystem”.

Now we have cloud:

  1. Power on the VM (through cloud control software e.g. Azure Portal).
  2. You log into the VM as “adm” and run: “sapcontrol -nr ## -function StartSystem”.

How Does SAP LaMa Work In this Context?

With SAP LaMa, it has the ability to perform both steps #1 and #2 in the last list.
Here’s a diagrammatic overview that I hope shows accurately the interaction between the Azure,  Linux and SAP layers:

In the above diagram we can see that SAP LaMa is “cloud aware” and uses the Azure APIs to start and stop Azure VMs.

Once the VM is started, the usual Linux-level startup process takes over to start the services.

There is one caveat with the above and that is regarding SUSE cloud-netconfig. Find out more here: SUSE Cloud-Netconfig and Azure VMs – Dynamic Network Configuration

Why the Hostagent is Critical for LaMa

The SAP Hostagent is used as the marker point in the VM start-up process, at which point SAP LaMa knows for sure that the VM is up and running.
Before the Hostagent responds, SAP LaMa can only query the status of the VM from the Azure APIs, which basically say “starting” or “running”.

There are a number of monitoring capabilities inside SAP LaMa, but the Hostagent is the critical one.
From the Hostagent, the SAP instance agents can be unregistered and re-registered.

When setting up your SAP LaMa landscape, the SAP Hostagent is critical.  If you get it right, with automated deployment, SSL setup, common configuration, custom descriptors/operations, then you can automate almost anything in your SAP landscape.  

You need to constantly patch the SAP Hostagent to ensure that it remains compatible with other elements of your SAP landscape.  For example, to be able to patch the SAP ASE database, you need the Hostagent.  It’s also used for the BALDR (metrics gathering) inside SAP ASE from ASE 16.3 onwards.

SAP LaMa & SAP Landscape Orchestration

The SAP LaMa tool is the nice front-end and scheduler onto which you can apply your automation requirements via the Hostagent and SAP instance agents.

Not only does it provide orchestration capability, but it can also validate your landscape according to predefined in-built checks (such as Kernel component version consistency) and even validate against custom validations built and defined by you.

SAP Software Provisioning Manager System Copy

From NetWeaver 7.0 onwards, you now need to use the SAP Software Provisioning Manager (SWPM) to perform system copies.
As an example, a production MS SQL Server database PX1 is restored from backup onto a training system database server.
After the restore is completed, you now have your TX1 database refreshed, but the schema inside the database is still the source system schema and there are post-copy tasks to perform.
What media is needed?
You will need the following media:

  • SWPM SAR file.
  • The 700 and 720 SL-Controller file updates are not needed for system copies (unless you are installing/re-installing a Java AS).
  • You need both the 720_EXT unicode and non-unicode Kernels for SWPM (they are specific Kernels located in the SWDC under the NetWeaver download location.  They specifically say “… for SWPM“).  You will need the UC kernel even if your system is NUC!



  • You need the source system DDIC password for 000.
  • You need the password for the <sid>adm user.
  • You need the password for the SAPService<SID> (Windows) user.
  • The software media is around 4GB in size!

The SWPM performs approximately  the following tasks (I’ve added my own comments) taken from the detailed timings report at the end of a run.
I thought this might be useful to anyone new to the process:

  • Update System DLLs (not sure what DLLs, maybe VC++ Redist)
  • Re-Create users for SAP system (in database?)
  • Re-Install common system files (maybe SAPMMC files, HostAgent)
  • Configure database client (SNAC is already installed? maybe install MS JAVA JDBC JARs)
  • Cleanup of temp database objects.
  • Create/modify system database schema.
  • Migrate objects to new schema.
  • Delete old schema.
  • Set compatibility level for databases (sets to compatibility 100 for DB, tempdb, model, master)
  • Create SAP stored procedures.
  • Any MS SQL Server specific tasks (set PAGE_VERIFY to CHECKSUM, set AUTO_UPDATE_STATISTICS_ASYNC to ON, set ANSI_NULLS to ON, set AUTO_UPDATE_STATISTICS to ON, set AUTO_CREATE_STATISTICS to ON, configures FILESTREAM, reconfigures parallelism and min and max memory settings, enables xp_cmdshell.
  • Grant database access for the <sid>adm user,  SAPService<sid> user and SAP_<SID>_LocalAdmin group.
  • Configure database parameters.
  • Perform post-load activities.
  • Check DDIC password (client 000, if you don’t have it right it prompts you to re-enter it here).
  • Perform table depooling (RUTPOADAPT)
  • Activate SQLScript Proxies (DBPROC_ACTIVATE_PROXIES)
  • Create DDL Views (RUTDDLSCREATE)
  • Restart instance.

At the end of the process, the schema is migrated and the system is ready to use.
There are some additional database specific tasks to perform, you need to check the SAP notes for your specific database instance.
See SAP Note 888210 – “NW 7.**: System copy (supplementary note)

SWPM System Copy rdisp/msserv

Scenario: During a SAP NW731 system copy, the SWPM prompts you to set the rdisp/msserv and rdisp/msserv_internal parameters in the SCS instance profile.


The problem is, these are already set in the SCS instance profile.  You can clearly see them there.

The solution is to ensure that the same parameters and values are also set in the DEFAULT.pfl profile file too.  This is not so clear, but it is mentioned in SAP note 1421005.

SAP SWPM Checks Windows Virtual Hostname Setup

When you come to use SWPM for the first time to copy a SAP system which has a virtual hostname defined and used, be aware that the SWPM has in-built checks to ensure that the Windows registry is correctly configured according to SAP note 1564275.

If you’ve not fully implemented the note configuration in the Windows registry, even if you’re using the “SAPINST_USE_HOSTNAME=<hostname>” SAPInst.exe parameter, the SWPM will show an error and exit.

My specific setup was missing the DisableStrictNameChecking setting.  After adding this into the registry, I was able to launch SWPM.