Skip to Content
Technical Articles

How to realize different SAP GUI SAP Logon system list configurations with centralized Landscape-Files

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:



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
	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


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

You must be Logged on to comment or reply to a post.
  • 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.




  • 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

    • 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.

  • Hi Kai,

    Thanks for this article. Can you tell me what the SAPUILandscapeGlobal.xml file is for? I am wondering how its contents surface in the GUI and how I should use it, if at all, in a network server implementation as you describe above. I have searched SAP’s documentation and the rest of the Internet and so far have not been successful in finding an answer as to this file’s purpose.

    Thank you,

    Jay Michaud


    • Hi Jay,

      I cannot remember having seen a SAPUILandscapeGlobal.xml file.

      Where did you find that “global” file?

      • SAPGui-Settings?
      • Registry-Value?
      • %appdata%- or %programfiles(x86)% folder?

      For general Documentation about “SAPUILandscape” XML-Files and “LandscapeFileOnServer” Parameter look at “SAP GUI Administration” Guide (Release 7.50, page 67, chapter “Server Configuration Files Page”).

      Greetings Kai

      • SAPUILandscapeGlobal.xml is created alongside SAPUILandscape.xml in the folder “%APPDATA%\SAP\Common” the first time a user runs SAP Logon. It has the following contents:

        <?xml version=”1.0″ encoding=”UTF-8″?>

        I noticed that if I have a message server configured in my services file (%SystemRoot%\System32\Drivers\etc\services), it gets picked up automatically during the first launch of SAP Logon and inserted into the SAPUILandscapeGlobal.xml file like this:

        <?xml version=”1.0″ encoding=”UTF-8″?>
        <Landscape><Messageservers><Messageserver uuid=”00000000-0000-0000-0000-000000000000″ name=”MyMessageServer” description=”MessageServerDescription” port=”3600″/></Messageservers></Landscape>

        (identifying information replaced)

        I just don’t know this file’s purpose.

  • Thank you for this information however at the top of the article you say ‘Don’t use local files -> Change to server configuration files’, but there are no instructions on how to disable the use of local configurations. With this in testing, we have successfully got SAP GUI 750 to use the server configuration files but we have double entries as the machine is still using the local files as well.

    Can you please advise how we disable use of the local configuration files?


    • In this case (blogpost is based on SAP GUI 7.4) Local Configuration Files are mirrored from Server Configuration Files.

      As you enable the RegKey “HKEY_CURRENT_USER\Software\SAP\SAPLogon\Options\LandscapeFileOnServer” SAP GUI synchronizes entries from “\\<hostname>\<networksharename>\SAPUILandscape.xml” to “C:\Users\<Username>\AppData\Roaming\SAP\Common\SAPUILandscape.xml”

      Unfortunately, I can not answer (yet) how this behavior works in version 7.5.

      • Thank you Kai.

        I can confirm that the information from the server file does synchronise with the local file. In our case however we had to delete the local xml file that was converted from the .ini files of the previous SAP GUI version we were using, and only then would the two xml files become synchronised. This is something we can manage with a small amendment to an install script, we will just delete the ini files after the old GUI has been removed and before the new GUI begins installing.

        This in itself may be particular to the way we set up our environment, we use folder redirection for the appdata location so there is no existing C:\Users\…\%appdata%\…