Scenario Description

On the Microsoft Windows application platform, SAP application servers cannot access a network resource using a simple mapped network drive. This issue is caused by the isolation between various user accounts running on the Windows environment. In essence, a drive mapping by the administrator cannot be accessed by a different user account like that of the SAP Service <SAPServiceSID>.

Background

SAP application instances are installed on the Microsoft platform to run as a specific Windows service account <SAPServiceSID>. You can see this easily when looking at the installed services and how the logon security is defined for that service, as shown in the two screenshots below:

The SAP service account <SAPServiceSID> is normally created with limited privileges (by the SAP installer) and specifically cannot logon or interact with the desktop. Below is an example of trying to launch a CMD window as the SAP service account <SAPServiceSID> and the associated error which demonstrates this issue:

 Now, let’s say that I want to login with the interactive SAP administrator account <sidadm> and map a network drive M: to the location \\SAPIDES\share. I then want this drive mapping to be accessible from all accounts and specifically from the <SAPServiceSID>.

 Let’s start with setting up the share. First, I created a directory on the Z: drive and then a share called “share”. I set the permissions to have the SAP_IDE_GlobalAdmin (SAPServiceIDE is a member) have full control as shown below:

 Next, I map a drive from the command prompt as shown:

 Below, you can see that the M: network drive is accessible. I called the directory listing and also displayed the content of the TestFile.txt. Additionally, you can see that Windows Explorer also now has access to the share via the M: drive.

 

The problem is that this drive mapping is only available to the <sidadm> account and as show with AL11, the SAP application instance cannot access the drive. When I try to access the mapped drive M:\ you can see the error message being thrown on the status bar.

 

Solution #1 – Using UNC (Universal Naming Convention)

There are a few ways to solve this issue. Firstly, do not use mapped drives but instead use UNC (Universal Naming Convention) naming conventions. As shown below, I can access the network share by simply changing the AL11 entry to use UNC (Universal Naming Convention):

 I can now see my TestFile.txt and even the content in the next two screenshots:

 

 

Solution #2 – Using a Symbolic Link from a local file system

Second, you can use a symbolic link that is accessible from any local drive. In my case, I will create a link from the \usr\sap (SAPMNT) location to the shared drive. I then update the AL11 entry as shown to point at this new location:

 

Again, I can now see my TestFile.txt and even the content in the next two screenshots via the symbolic link.

More information on MKLINK can be found at: http://technet.microsoft.com/en-us/library/cc753194(v=ws.10).aspx

 

Solution #3 – Map the network drive with higher privileges

Finally, for those who cannot let go of the mapped drive concept you can have this by mapping the drive using the SYSTEM account. This essentially makes the mapped drive available to all users on the local machine. There are a few steps to making this work:

Step #1: Create a small batch/command file as shown:

 

 

Step #2: Next, create a Windows task schedule that will run the batch file at system startup. The screen shot below shows the overview:

 

Step #2.1: There are some parameters that are needed here to make this work correctly. As shown, change the user to SYSTEM and also run the task with the highest priviledges.

 

 

Step #2.2: Trigger the task to run at system startup with a 1 minute delay. This delay is to ensure that the network and other underlying services are available before the script is run.

 

 

Step #2.3: You can see from the screenshot below that this task has been configured to launch my ZMap.cmd script as its default action.

 

 

Step #2.4: Finally as an extra precaution, I will use the condition that my corporate network connection is available before running the action. This together with the delay ensures that the network is available and ready for the drive mapping command (net use).

 

 

So, now I will test the command by running it manually from the task scheduler:

 

 

You can see that a new drive mapping has been inserted into my File Explorer:

 

Back to AL11, and setup the original entry that through the error:

 

 

But now, we can access the M:\ drive via the SAP system due to the mapping running under the SYSTEM account.

 

 

 “DON’T TURN SAP SERVERS INTO FILE SERVERS!!!!”

Turning an SAP application or database server into a network file server can have disastrous impacts on the security of the system. More and more of our customers want our solutions to be secure by default. This means no direct connections between clients and SAP infrastructure.

 

We highly recommend and suggest that customers to have a File Server *outside* their SAP VLAN. Further, we recommend using the SAP transaction FILE to define LOGICAL FILE NAMES as shown below:

 

Step #1.      Create an interface path – here “BANK DATA” – but you could create one called “INTERFACE_UPLOAD_DOWNLOAD”

  

Step #2.      Click here

 

 

3.      Press New Entries

 

 

4.      Specify UNC path – we don’t need drive letters

 

 

 5.      Save and transport from development (DEV) to production (PRD).

 

Acknowledgements

Special thanks to the Jock Williams, Cameron Gardiner, Mark Weber and Juergen Thomas for their contributions to this blog entry.