SAP GUI connection closed when connecting to SAP system in Azure

Following the successful release of SAP on Azure we have received feedback from customers and our support organizations about an issue that occurs only on one particular deployment pattern. In all the cases the deployment of the SAP NetWeaver based application was in a so called Azure-Only (please read the documentation here if the term Azure-Only deployment of SAP is not clear) deployment scenario as shown in the picture below.

As you can see there is no site-to-site or private connection between Azure and on-premise. The VMs that run SAP NetWeaver based applications are not part of the on-premise domain which hosts the on-premise SAP systems. Nevertheless the customers wanted to connect to the systems in Azure with their SAP GUI on the local computers/laptops. This definitely is possible, even with not having site-to-site or private connectivity between Azure and on-premise. Here are the steps how to make this work without problems.

Define entry in SAP Logon

First step is to create an endpoint for the VM that covers the SAP dispatcher port of the SAP instance running within the VM. Means it needs to be a TCP/IP endpoint. The external and internal port number should be the port number of the dispatcher of the instance which usually is 3200 + <Instance Number>. A full list of ports required for SAP applications is documented in this whitepaper.

So the list of endpoints for a given VM could look like:

Second step is to enter the data of the system into SAP Logon. The entries to be made in the SAP Logon are the very same you need to make as for on-premise systems:

• Description of the system as it shows up in the SAP Logon list
• Application Server
• Instance Number
• System ID

The only difference to addressing on-premise systems is the input for the application server. This entry is usually the name of the server or VM which runs the instance which the SAP GUI should connect to or the IP address of such a system. For the scenario above you need to change the entry to the DNS name of the VM in Azure. The DNS name is the name of the Cloud Service. You can get the DNS name of the VM in the Azure Portal in the list of VMs. The outer right column is displaying the DNS name of the VM. Copy that name and put it into the application server column.

With these settings you should be able to connect to the SAP GUI in an Azure-Only deployment scenario from our workstations/laptops which are running on-premise through the internet to a SAP instance hosted din a VM on Azure.

Important: These steps are only necessary if the connection of SAP GUI to the SAP system is using the external endpoint of an Azure VM (see below)

Why is the SAP GUI connections getting closed?

The SAP GUI connection that comes through the internet, addressing the public IP address of the VM, is routed through a Load Balancer in Azure as described below in the graphics

The Load Balancer is in place independent of the number of VMs within the Azure Cloud Service. Even with one VM within a Cloud Service it is there and does its job. For more information on how the Azure Load Balancer works, please see this article: https://azure.microsoft.com/en-us/documentation/articles/load-balance-virtual-machines/.

Please don’t be confused about the actual function of load-balancing which only is part of the logic the load balancer performs. As long as the endpoints of the VMs are not enabled for load balancing, the actual work going against the port of the VM is not being balanced across different VMs having the same end as described in the article. Nevertheless, the traffic is going through the instance of the load balancer. The Azure Load Balancer, in the configuration above, has a time-out period of a few minutes for idle connections. Means if there are connections established that remain idle for a few minutes, the Load Balancer will close these connections. On the other side it is very normal that you log into a SAP application using SAP GUI and remain logged in the whole day. Or at least until auto logout by the SAP instance would close the open SAP GUI connection during a longer break eventually (SAP ABAP instance profile parameter rdisp/gui_auto_logout ). Usual times set for the auto logout are between 30min and a few hours. Means way longer than the Azure Load Balancer accepts for idle connections. As a result the experience is that after some minutes of inactivity, the connection between the local SAP GUI and the Azure hosted SAP instance is closed.

However SAP foresaw cases like the Azure Load Balancer long time ago already. Over the last twenty years there were many scenarios of SAP GUI connecting to SAP instances through complex network configurations with firewalls, load balancers, etc which reacted similar to the Azure Load Balancer. For this purpose the SAP ABAP instance has the ability to ping the SAP GUI through the established connection. Or in other words the SAP application instance would send a keepalive signal to the GUI. Firewalls, routers, load balancers, etc would recognize the connection as busy and would restart their countdown to the idle threshold time again. The default values for this keepalive signal by the SAP ABAP instance are set higher than the Azure Load Balancer idle threshold. Therefore the period the SAP instance sends out the keepalive signal needs to be changed. In detail the parameters in the Default.pfl that need to be changed are:

The important parameter to be set is rdisp/keepalive which in the example above is set to 20sec. For the current time threshold settings of the Azure Load Balancer, it would be fine to set this value between 60 and 120 sec.

With these two instance profile parameters set, the SAP GUI connection can be kept alive for the Azure-Only scenario described above.

Why is it not necessary to set these parameters in Hybrid-IT scenarios?

The reason why this problem does not show up in scenarios where you connect from on-premise through site-to-site or ExpressRoute connections to SAP instances in Azure, is that you are connecting to the internal IP address of the VM without having a load balancing instance between the client and the VMs. Therefore no instance exists that closes an idle connections after a certain time. In Hybrid-IT scenarios where your on-premise infrastructure is extended into Azure, it is normal that connections can be established between a software component in Azure and on-premise which can remain idle for hours. Therefore changing the keepalive default value of a SAP instance are not necessary in a Hybrid-IT scenario.