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>.
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.
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:
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
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:
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.
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:
Special thanks to the Jock Williams, Cameron Gardiner, Mark Weber and Juergen Thomas for their contributions to this blog entry.