Blogs by Ashwin

  To read part 1 please click  here Azure Active Directory Integration with SAP Fiori Benefits of integrating Azure AD with SAP Fiori: You can use Azure AD to control who has access to SAP Fiori. Users can be automatically signed in to SAP Fiori with their Azure AD accounts (single sign-on). You can manage your accounts in one central location, the Azure portal.  For the configuration of Azure AD with SAP Fiori, you will need the following items: An Azure AD subscription. A SAP Fiori subscription with single sign-on enabled. SAP Fiori 7.20 or later is required. Add SAP Fiori to Azure portal Firstly, you have to add SAP Fiori from the SaaS application gallery to your list of managed SaaS apps, if you want to integrate Azure AD with SAP Fiori. Configure Azure AD single sign-on You have to perform the following tasks to configure Azure AD single sign-on with SAP Fiori: Configure Azure AD single sign-on to enable your users to use this feature. Configure SAP Fiori single sign-on. Assign Az

  To read part 2 please click  here SAP Cloud Platform Identity Authentication Add SAP Cloud Platform Identity Authentication from the gallery If you want to configure the integration of SAP Cloud Platform Identity Authentication into Azure AD, then firstly we have to add SAP Cloud Platform Identity Authentication from the Azure AD application gallery to the list of managed SaaS apps. Implement Azure AD single sign-on After that you have to configure and test Azure AD-based SSO with the help of following steps: Configure Azure AD Single Sign-On - to enable your users to use this features. Configure SAP Cloud Platform Identity Authentication Single Sign-On - to configure the Single Sign-On settings on application side. Assign Azure AD users to SAP Cloud Platform Identity Authentication. Configure Azure AD single sign-on First of all select Single sign-on at the SAP Cloud Platform Identity Authentication application integration page in the Azure portal. Next select SAML/WS-Fed mode to en

  Overview After deploying the VM, the Azure VM agent is automatically installed within the guest OS to further install the Azure Enhanced Monitoring Extension for SAP, which is readily available in the Azure Extension Repository. The extension can be installed by using PowerShell or CLI. Configuring the Azure Enhanced Monitoring Extension for SAP Azure PowerShell for Linux & Windows VMs You can install the Azure Enhanced Monitoring Extension for SAP by using PowerShell as follows: Make sure that you have installed the latest version of the Az PowerShell module. For a list of available environments, run commandlet Get-AzEnvironment. If you want to use global Azure, your environment is AzureCloud but for China select AzureChinaCloud. The script can deploy the required extensions while enabling the required features which might take several minutes. The Set-AzVMAEMExtension configuration can handle all the steps required to configure host monitoring for SAP. The script output include

  Overview If you want to go for an on-premises development to establish high availability for SAP HANA, then you can either use shared storage or HANA System Replication which consists of one primary node and at least one secondary node and the changes to the data on the primary node are easily replicated to the secondary node synchronously or asynchronously. SAP HANA System Replication setup has a dedicated virtual hostname as well as a virtual IP address, but for Azure, a load balancer is needed to use the virtual IP address. The configuration of the load balancer is shown below: Front-end configuration: IP address 10.0.0.13 for hn1-db Back-end configuration: Connected to primary network interfaces of all VMs that should be a part of HANA System Replication. Probe Port: Port 62503 Load-balancing rules: 3013 TCP, 30315 TCP, 30317 TCP Implementing & Verifying HA SAP HANA on Azure VMs Provision Azure resources The SUSE Linux Enterprise Server for SAP Applications contains the resou

  To read part 1 please click  here Add registry entries on both cluster nodes of the SAP ASCS-SCS instance If you want to add registry entries on both cluster nodes of the SAP ASCS-SCS instance, then you have to add them on both Windows cluster nodes for SAP ASCS/SCS: Path HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Variable name KeepAliveTime Variable type REG_DWORD (Decimal) Value 120000 Path HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Variable name KeepAliveTime Variable type REG_DWORD (Decimal) Value 120000  You have to restart both the cluster nodes to apply the changes.  Set up a Windows Server failover cluster for SAP ASCS-SCS instance It involves the following tasks: Add cluster nodes to the cluster. Configure Cloud witness  Add cluster nodes to the cluster You have

  To read part 2 please click  here Single SID 3-tier SAP NetWeaver HA AnyDB Deployment The three-tier SAP Azure Resource Manager templates supports high-availability scenarios and if you want to prepare a highly available infrastructure, for deploying the templates, then you have to set the SYSTEMAVAILABILITY parameter to HA. The templates can easily create: Azure VMs (and, if applicable, their managed disks): Network cards for all VMs, along with the associated IP addresses Availability groups for SAP Application Server VMs, SAP ASCS /SCS cluster VMs, and DBMS cluster VMs. Azure internal load balancer: With all ports for the ASCS/SCS instance and IP address With all ports for the SQL Server DBMS and IP address Network security group with an open external Remote Desktop Protocol (RDP) port to the first SAP Application Server VM. By default, all the IP addresses of the network cards as well as Azure internal load balancers are dynamic but you have to convert them to static IP addresses

  Overview If you want go for a NetWeaver AnyDB deployment, then you can readily follow the standard (2-tier) or distributed (3-tier) NetWeaver installation options in SAP Software Provisioning Manager (SWPM). But, for the HANA-based ones, you will have to choose from one of the following methods: Use SAP Software Provisioning Manager (SWPM) as a part of the standard (2-tier) or distributed (3-tier) NetWeaver installation, followed by HANA installation. Use the SAP HANA database lifecycle manager (HDBLCM) tool, and then install NetWeaver. The installation can start by an ASCS instance and the /sapmnt share, which have the SAP profile directory, should be shared with the SAP DB server VM. Depending on the OS of the DB server, the best way to provide access is via either SMB or NFS.  The /sapmnt is shared via NFS while using Linux OS with the help of rw and no_root_squash options which may lead to problems while installing the database instance. Finally, the installation provisions the p

  Azure VM Deployment Methodologies VM images & disks It is one of the main considerations in which installing the operating system and the associated SAP workloads, which allows you to choose from three options. Azure Marketplace Images In this approach you can deploy the VMs based on Microsoft or third-party including the VM images from Azure Marketplace. After that, the same method and tools can be used to install the SAP software and/or DBMS inside your VM which can be performed manually or in an automated manner, with the help of configuration management tools, like PowerShell DSC, Custom Script, Ansible, Puppet, or Chef. Custom Images In this approach you can deploy the VMs based on customer-specific images, if Azure marketplace images doesn't fit your needs. If the SAP content is already installed in your on-premises VM (mainly for 2-tier systems), then you can easily adapt its settings after the deployment of Azure VM through the instance rename procedure supported by t

  Strategies for Migrating SAP systems to Microsoft Azure Generally, all the enterprises have their own SAP systems for business function such as Enterprise Resource Planning (ERP), global trade, Business Intelligence (BI), and others; with their environments like sandbox, development, test as well as production. Horizontal strategy It can help you to start from the bottom of the stack as it's a safe way to experiment as well as gain experience with Azure and it can also be used while redefining your operational, deployment, and approval processes. This strategy works as follows: To limit risk, you should start with low-impact sandbox or training systems. If something goes wrong, there's very little danger of affecting many users or mission-critical business functions.  After that, as you gain experience with running, hosting, and administering SAP systems in Azure, you can apply this knowledge to the next layer of systems up the stack. For each layer, you have to estimate cost

  SAP HANA on Azure (Large Instances) Security Encryption of data on transit Data transferred between HANA Large Instance and VMs is generally not encrypted but you can enable the application level encryption between the HANA DBMS and JDBC/ODBC- based applications. Encryption of data at rest You can enable this encryption easily whenever you want to deploy a HANA Large instance unit and you can also change the encrypted volumes after the deployment. However, the move from non-encrypted to encrypted volumes is transparent and doesn't require downtime.  By default, the HANA Large Instances uses stirage encryption based on TDE (Transparent Data Encryption) for the data at rest. Data in transit between HANA Large Instances and the VMs is not encrypted and you have to enable the application-specific encryption to encrypt the data transfer. Isolation provides security between the tenants in the multi-tenant HANA Large Instance environment according to which tenants are isolated using the

  The storage infrastructure in SAP HANA on Azure (Large Instances) supports storage snapshots of volumes while both backup as well as restoration of volumes is supported by the following considerations: Instead of full database backup, storage volume snapshots are taken on a frequent basis. Whenever a snapshot is triggered over /hana/data and /hana/shared, which includes /usr/sap, volumes, the snapshot technology initiates a SAP HANA snapshot before it runs the storage snapshot. You need an active HANA instance, for a HANA snapshot to be successful. A storage snapshot is not supported on the current secondary node where a HANA snapshot can't be performed, in an HSR scenario. After the storage snapshot runs successfully, the SAP HANA snapshot is deleted. Transaction log backups are taken frequently and stored in the /hana/logbackups volume that consists of the transaction log backups or in Azure and can be triggered to take a snapshot separately.  If you want to restore a database

  SAP HANA on Azure (Large Instances) HA & DR High Availability (HA) and Discovery Recovery (DR) are important to work with SAP, your system integrator, or Microsoft to properly architect and implement the correct high-availability as well as disaster recovery strategies; also to consider the Recovery Point Objective (RPO) as well as the Recovery Time Objective (RTO), which are specific to your environment. Microsoft readily supports some SAP HANA High-availability capabilities with HANA Large Instances which includes: Storage Replication- The storage system's ability to replicate all data to another HANA Large Instances also stamp in another Azure region. SAP HANA operates independently of this method and it is the default disaster recovery mechanism offered for HANA Large Instances. HANA System Replication- It is the replication of all data in SAP HANA to a separate SAP HANA system which minimizes the recovery time objective at regular intervals. SAP HANA can support both asy

  To read part 1 please click  here To read part 2 please click  here Express Route Global Reach With the help of ExpressRoute Global Reach, customers are able to link the ExpressRoute circuits together to make a private network between on-premises networks. Global reach helps in the following two scenarios of HANA Large Instances: Enable direct access from on-premises to HANA Large Instance units deployed in different regions. Enable direct communication between your HANA Large Instance units deployed in different regions.    Direct Access from on-premises Wherever the global reach is provided within the Azure regions, the global reach functionality can be enabled for your ExpressRoute circuits that can connect your on-premises network to your Azure virtual network that in turn also connect to your HANA Large Instance units. There is no additional cost for you related to the circuit that connects the HANA Large Instance unit(s) to Azure, but, there are certain cost implications for th

  To read part 1 please click  here To read part 3 please click  here ExpressRoute Fast Path Microsoft is offering ExpressRoute Fast Path since May 2019 to optimize connectivity of HANA Large Instances to Azure virtual networks that host the SAP application VMs which helps in not routing the data to flow between VMs and HANA Large Instances through the ExpressRoute Gateway anymore.  The ExpressRoute Fast Path functionality needs that the subnets running the SAP application VMs are in the same Azure virtual network that connects to the HANA Large Instances while the VMs located in Azure virtual networks connected directly to the HANA Large Instance units are not profitable through ExpressRoute Fast Path. Additionally, ExpressRoute Fast Path does not support User Defined Routing (UDR) rules and requires an UltraPerformance ExpressRoute gateway.  Single & Multiple SAP Systems Single SAP system The ExpressRoute gateway for the VMs hosting the SAP application instances is connected to o