Skip to Content

In some cases it is necessary to provide different SAP GUI system list configurations. For example there could be the requirement that the system list of an IT Department must differ from the list in the rest of the company.

In this blogpost the focus is on the implementation of centralized configuration files and different ways to switch between them in Windows Enterprise Environments.

Step 1: Don’t use Local Files -> Change to Server Configuration Files

This setting is realized by the RegKey:

HKEY_CURRENT_USER\Software\SAP\SAPLogon\Options

LandscapeFileOnServer

In Windows Enterprise Environments it is useful to implement this RegKey (and all other settings) in a separate “SAP GUI Policy” Group Policy Object (GPO) in the Active Directory Domain.

 

Step 2: Implement multiple SAPUILandscape.xml files

Create different XML files in your SAPLogon Console (-> “Add New Entry”).

Now you have a “Local Configuration File” ready to use it as a central file in your network. Local Configuration Files are stored in %appdata%\SAP\Common\

Copy each XML file in a corresponding network folder share. In this case we have a “Default”-, “IT Department”- and “HR”-Configuration file:

 

Step 3: How to switch between the SAPUILandscape.xml files

There are different ways to switch between the XML files.

One solution could be three different Active Directory Groups. Each Domain-User is member of such a group.

A scheduled task, deployed by the GPO, uses a small configuration script (also stored in a shared folder) to read the group and to set the correct network location.

The task runs

cscript.exe “\\Server\SAPUILandscape_Config-Script\sapgui740config.vbs”

at user logon:

On Error Resume Next

Wscript.Sleep 15000 ' We need a short delay for network initialization

Set Wshell = WScript.CreateObject("WScript.Shell")
Set fso = CreateObject("Scripting.FileSystemObject")

' Get Active Directory Informations
dn=Wshell.regread("HKLM\software\microsoft\windows\currentversion\group policy\state\machine\distinguished-name")
Set cObj=GetObject("LDAP://"&dn)
	
' Read Active Directory Groups and set corresponding Server Configuration File Path in Registry
groups = cObj.GetEx("memberOf")
For Each group In groups
	mdn=Split(group,",")
	Select Case mdn(0)
		' AD-Group "sapuilandscape_default"
		Case "CN=sapuilandscape_default"
			Wshell.RegWrite "HKCU\Software\SAP\SAPLogon\Options\LandscapeFileOnServer", "\\server\SAPUILandscape_Default\SAPUILandscape.xml", "REG_EXPAND_SZ"
			Wscript.echo "SAPGUI Standard"
		' AD-Group "sapuilandscape_itdepartment"
		Case "CN=sapuilandscape_itdepartment"
			Wshell.RegWrite "HKCU\Software\SAP\SAPLogon\Options\LandscapeFileOnServer", "\\server\SAPUILandscape_ITDepartment\SAPUILandscape.xml", "REG_EXPAND_SZ"
			Wscript.echo "SAPGUI IT"
		' AD-Group "sapuilandscape_hr"
		Case "CN=sapuilandscape_hr"
			Wshell.RegWrite "HKCU\Software\SAP\SAPLogon\Options\LandscapeFileOnServer", "\\server\SAPUILandscape_HR\SAPUILandscape.xml", "REG_EXPAND_SZ"
			Wscript.echo "SAPGUI HR"
	End Select
Next

An Alternative to this solution could be the registry part in the GPO combined with item level targeting.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Matt Fraser

    Excellent blog post, Kai. Thanks for this.

     

    Indeed, we use different SAPLogon system lists for different groups in my organization, though we do it a little differently. Mainly, we recognize a difference between development/support teams, who need access to sandbox, development, quality assurance, and production systems, functional testing teams who need only quality assurance and production, and then everyone else who need only production. But, what we did was to have different SAPGUI Installation Servers entirely, each with their own configuration files (hosted on the server! this is an important point, and thank you for reinforcing this), and the different groups install from (and receive SAPGUI updates from) the different servers. This allows me to have a phased rollout of SAPGUI patches as well as providing different configuration files, which is useful. Also, with VMware, it’s not a big deal to have several small servers to host the different Installation Servers.

     

    I like your solutions for easy switching between configurations.

     

    Cheers,
    Matt

     

    (2) 
  2. Lutz Rottmann

    Hi Kai, thanks for describing this quite sophisticated solution!

    When we tried to make use of “XML configuration file on server” quite a while ago (it was the time of .ini files, do you remember? 😉 ), we ran into an issue that was quite serious to us: Connections defined via “XML configuration file on server” were invisible in several SAP Clients. These were at least Analysis for Office, BO Design Studio and ABAP in Eclipse.

    Our bug reports were answered that everything works as designed and that we should file a feature request for each client to get support for “XML configuration file on server”. Quite frustrating.

    So we are still struggling with our mass of system connections that need to be managed in a user friendly and reliable way.

    I lost this question out of sight, but I am afraid that this issue is still not fully solved. Did you run into this issue and what were your experiences today?

    Cheers, Lutz

    (0) 
    1. Kai Bauer Post author

      Hi Lutz, thank you for your feedback. To this day we did not run in such an issue, so there are no experiences that I can share with you.
      Regards,
      Kai

      (0) 

Leave a Reply