This is the fifth of a six-part series bringing us from initial download and installation through to scripted packages and distribution to clients.  In this part we’ll cover how Package Event Scripts can help maintain central control of the SAP Logon configuration as well as explore some SAPGUI customizing.

As parts of this process are likely already familiar to many of you, I have broken it up into stages.  Please feel free to jump to the sections most relevant for you.  If you are setting up an Installation Server for the first time, however, I recommend you start with SAPGUI Installation Server Part 1 – Getting Started and move sequentially through the steps.

  1. Getting Started
    1. Includes download of all required files
  2. Initial Installation
  3. Patching
  4. Package Creation
    1. Includes initial installation of the administrator’s SAPGUI
  5. Scripting (this document)
  6. LSH and Distribution


If you are continuing on from the previous step (SAPGUI Installation Server Part 4 – Package Creation), then you have created a Package called Basic with several SAPGUI components in it, and you have installed SAPGUI on your own workstation using the Basic Package.  You don’t yet have any entries in SAP Logon, however.  Now it’s time to create those entries in a central configuration file that you can share with your users.

Create Shared Configuration Files

The connection data for SAPGUI is stored in a file called saplogon.ini, and additional data about how connections are organized and displayed in SAP Logon is stored in SapLogonTree.xml.  Depending on options you set within SAPGUI or SAP Logon, there may be other configuration files as well, but these two are the ones of primary concern.  By default, when SAPGUI 7.30 (or 7.20) is installed on a Windows 7 system, these two files will be created in:

  • C:\Users\<username>\AppData\Roaming\SAP\Common

On Windows XP (from which hopefully by now all of you have migrated away, right?) the path would have been:

  • C:\Documents and Settings\<username>\Application Data\SAP\Common

Older SAPGUIs used a different storage mechanism, and so if you upgrade from one of these to 7.30, saplogon.ini may still be found in the old locations (or may be copied from the old location to the new location).  SAPGUI 7.10 stored saplogon.ini in the program’s installation folder (C:\Program Files\SAP\FrontEnd\SAPGUI (on 32-bit; for 64-bit machines substitute Program Files (x86) for Program Files), while SAPGUI 6.40 and earlier stored it in C:\Windows.

In many organizations, the administrator would create a default saplogon.ini and use scripting to push it to the client workstation in the appropriate folder during the SAPGUI installation.  This worked well for new installs, but it didn’t help much with upgrades, or for distributing changes when the server landscape underwent a change.  Then the administrator would be required to use new scripts to push out new copies of the file, which would overwrite any customization the end user may have made.  Furthermore, the end user might change the file inadvertently, modifying or deleting an entry unintentionally, invariably resulting in a call to the Help Desk.  In this case, the administrator might have to resort to walking the user through editing their own settings to get things working again.

SAPGUI 7.30 offers a better way.  It is now possible to store saplogon.ini and SapLogonTree.xml in a shared location on a server and configure SAP Logon on the workstation to use these shared files instead of the local ones.  This means that all users are always using one version of the truth as defined by you, the system administrator.  If you need to distribute a landscape change, you only need to edit one set of files in one location, and all users will immediately see the change without having to do anything on their workstations.

We’ll discuss how to configure SAP Logon to use the shared files in a moment, but first we need to set up the server location and create the two configuration files to put there, and the first part of that is to configure our own SAPGUI, just installed on our workstation.

Edit Services File (optional)

If you use Logon Groups for message server-based load balancing or for directing different user groups to different application servers (configured via transaction code SMLG), then there are one or more additional entries which you will need to make to the services file which are not made by NwSapSetup during the base SAPGUI install.  Later you will use your Package Event Scripts to push this change to your users, but first you must make the change manually to your own workstation.

If you don’t use Logon Groups, you can skip this step.

On your workstation, navigate to:

  • C:\Windows\System32\drivers\etc

There you will find a text file called services.  You can examine it with Notepad, but in order to edit it in Windows 7 you must first open Notepad with Administrator privileges.  This is because services is a protected operating system file, and making a mistake with it could negatively impact Windows (as well as SAPGUI) operation.  Windows XP does not have this restriction, so you may simply open the file with Notepad and edit away.

In Windows 7, click Start… All Programs… Accessories and then right-click Notepad.  In the context menu choose Run as administrator and confirm Yes at the prompt.  In Notepad, choose File… Open and navigate to the services file you located earlier.

Be careful not to change any of the lines in the file.  Scroll to the end, where you will see numerous lines added by the SAPGUI install.  At the end of the list, add a new line something like the following:

sapmsSID     36nr/tcp

In this example, SID represents the System ID of your load-balanced system and nr represents the System Number.  So, if your System ID is PRD and System Number is 00, the line will be

sapmsPRD     3600/tcp

For the blank space between ‘sapmsSID’ and ’36nr/tcp’ you can use either a TAB or hit the SPACEBAR a few times; it doesn’t matter.  Be sure to hit ENTER at the end of the line, so that the last line of the file is a blank line.

So, when you’re done, the last few lines of your services file may look something like:

sapgw98     3398/tcp

sapgw99     3399/tcp

sapmsPRD     3600/tcp

Save the file.

Create CustomerFiles Folder

Now you need to create a folder on your server that your users will have read-only access to.  I recommend putting this folder under the root of your Installation Server share, as your users already have this access there.  Furthermore, I recommend calling the folder CustomerFiles (exactly like that) for the very specific reason that later, if and when you make a self-extracting single-file-installer, such a folder will be automatically included in the single-file-installer.  If you call the folder something else, such as ConfigFiles (as some of the documentation shows in examples), it will not work with single-file-installers.

So, navigate to your Installation Server at \\server\sapgui, and create CustomerFiles there.  When you are done, the contents of your sapgui share will look something like this:

Start SAP Logon with Command-Line Switch

The next step is to start SAP Logon in such a manner that it will create a new set of configuration files in the CustomerFiles folder.  You will want to have an easy way of doing this whenever you need to make changes to the published SAP Logon configuration, so I recommend making a small batch program and saving it on your Desktop.

Right-click on your Desktop and choose New… Text Document.  Rename the new document to saplogon_ini_file.cmd and confirm the prompt for changing the file extension.  Right-click on saplogon_ini_file.cmd and choose Edit.  Put the following lines into your new batch program:


cd \Program Files (x86)\SAP\FrontEnd\SAPgui

saplogon.exe /ini_file=\\server\sapgui\CustomerFiles\saplogon.ini

If you are working on a 32-bit machine, change Program Files (x86) to Program Files.  Remember to substitute your server’s hostname for server.

Save your changes and close the editor.  Now you have an easily-accessible and quick way of starting SAP Logon in such a way that you will be able to edit the configuration.  Let’s do that now.  Double-click your batch file to execute it and start SAP Logon.

Create Connection Subfolders and Entries

Although it is optional to do so, if you have numerous SAP systems, or systems of different types or purposes that can be logically grouped, then you may want to make the organization easier for your users by creating an hierarchical folder structure for the connections.  However, you can also just create a flat structure of all relevant systems without any subfolders.

In SAP Logon, highlight the Connections folder.  Right-click it and choose Add new subfolder.

Give the new subfolder an appropriate name and click OK.

Single Application Server

To add a direct connection to a specific application server, or a system without any load balancing, select your new subfolder and click on the New icon.

The Create New System Entry window will open.  Click Next.

On the next screen, set Connection Type to Custom Application Server, type in an appropriate system name to be displayed to users in the Description field, and fill in the relevant connection information for Application Server, Instance Number, and System ID.  If a SAProuter sits between your users and the server, fill in the information needed for that; otherwise, leave SAProuter String blank.

Optionally, you may check the box for Use this page as the first page for subsequent entry creations to skip the first screen next time.  I recommend using fully-qualified domain names for the Application Server, but depending upon your local network configuration it will usually work just as well with an unqualified hostname.  Click Finish.

Load-Balanced Group

You are now back in the SAP Logon window.  If you additionally (or instead) need to set up a load-balanced system connection, click on New again just as before to launch the Create New System Entry dialog.  On the System Connection Parameters page, this time you will make a different selection for Connection Type, and as a result you will have some different fields to fill in.

For Connection Type select Group/Server Selection.  Enter an appropriate Description, type in the System ID, and give the fully-qualified domain name (or simple hostname) for the Message Server of your load-balanced system group.  Click the drop-down arrow for Group/Server and you should see a list of the defined logon groups as well as the individual application servers that make up the system.  Choose the group you intend to use (previously created in SMLG).

You should now see the systems and/or groups you defined in SAP Logon.

Close SAP Logon to save your changes to the configuration files.

Sample Configuration Files

You should now see two files created in your CustomerFiles folder on the server:

  • saplogon.ini
  • SapLogonTree.xml

There is nothing more you need to do directly with these files, but if you open them you will see, among other things, entries similar to the following:






Item2=Quality Assurance












Notice that last group for MSSrvPort, and how the Item entry for your load-balanced group uses the TCP port name that incorporates the System ID.  This port name is then referenced to the entry you manually created in your services file to find the actual TCP port number (in this example, and in most systems, it would be 3600).


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

<!– SAPGUI for Windows 7300 4 29 5 2014 10:1:27 Pacific Standard Time –>

<SAPTREE version=”7300.3.8.1085″>


<File name=”saplogon.ini” type=”Connections”/>

<File name=”sapshortcut.ini” type=”Shortcuts”/>



<Favorites name=”Favorites” uuid=”…” expanded=”1″> </Favorites>

<Shortcuts name=”Shortcuts” uuid=”…” expanded=”1″> </Shortcuts>

<Connections name=”Connections” uuid=”…” expanded=”1″>

<Node name=”ERP” uuid=”…” expanded=”0″ memo=””>

<Item name=”Quality Assurance” type=”connection” uuid=”…”/>

<Item name=”Production” type=”connection” uuid=”…”/>





From this you can see how the XML file defines the folder structure you see in SAP Logon.

How to Use Server Configuration Files

Now that you have configuration files to share, how do you configure your users’ SAPGUIs to use them?  One way is via SAP Logon Options, which is accessed by clicking the icon in the upper left corner of SAP Logon, then choosing Options in the drop-down box.

On the screen that opens, drill down to SAP Logon Options… Server Configuration Files and then in the field XML Configuration File on Server type in the path to your XML file:  \\server\sapgui\CustomerFiles\SapLogonTree.xml.

However, you don’t want to run around to every user’s workstation and configure that option, so there’s a better way.  This parameter, like most of the others that can be set via SAP Logon Options or SAP GUI Options, is maintained in a registry setting, and registry settings can be configured by Package Event Scripts.

Create Package Event Scripts

Open up the Installation Server Administration Tool (NwSapSetupAdmin):

  • \\server\sapgui\Setup\NwSapSetupAdmin.exe

Switch to the Packages tab, select your Package, and switch to the Package Configuration tab.  Toward the bottom of the screen you will see a series of tabs labeled On Installation Start, On Installation End, On Uninstallation Start, On Uninstallation End, On Update Start, and On Update End.  There is also a small link to the right just above them for Expand Editor.  Click that to make it a little easier to work in the script editors.

As the tab names imply, here you can enter scripts that will execute during the install (or uninstall or patch update).  Upgrades execute the ‘install’ scripts, whereas patch updates execute the ‘update’ scripts.  For now, we will focus on Installation.  You can have two scripts, one that will execute nearer to the beginning of the installation, and one that executes at the end as a wrap-up.  Depending on the functions you intend to execute, one or the other may be more appropriate.

Package Event Scripts are essentially VBscript and follow VBscript conventions.  Some additional shell options have been preset by the install program, which unfortunately are not well documented, but you can get an idea of the possibilities from the SAP Setup Guide located at the root of your Installation Server share, in chapter 3.6.2, or by clicking the link for Insert Script Sample and examining (and adapting) the code snippets found there.  The samples include functions for adding custom logging to the setup log file, checking files and registry keys for existence, manipulating files and registry keys, and so forth.  Much of the scripts you will see below are adapted from these script samples.

On Installation Start

First we’ll look at some code to execute at the beginning of your installation.  The purpose of this piece of code is to duplicate the manual work you did earlier on your own workstation, editing the services file to put the logon group TCP port entry into it.  Again, if you don’t use logon load balancing or logon groups, then you don’t need this script at all.  This is adapted straight from the script examples.

The script begins by writing to the setup log file.  Every time we write to the log we prefix the line with “Event:  ” as a way of making our custom log entries searchable.  We let anyone reading the log know that this is where the “On Installation Start” script is running.  We include some comments in the script to let future sysadmins know what’s going on, then write a log entry to say exactly what we’re doing.  We resolve the %WinSysDir% environment variable and add the rest of the path to the services file and put that into the strFile variable.  Here, the sapsetup program provides some useful text file parsing utilities, and we make use of those.  We look in the services file to see if a line with our desired entry of “sapmsPRD” exists already.  If it does, just to be safe, we replace the line entirely, just in case it exists with an incorrect TCP port number.  If it doesn’t exist, we add the line.  That whole part is encapsulated in an If… Then structure as a way of capturing any error in finding the services file.


NwEngine.Context.Log.Write “Event:  On Installation Start”

‘Check whether a line containing the string “sapmsPRD” exists.

‘If so, replace that line with

‘”sapmsPRD 3600/tcp”

‘otherwise simply append the new line to the end of the services file.

NwEngine.Context.Log.Write “Event:  Appending or replacing lines in the services file”

strFile = NwEngine.Variables.ResolveString( “%WinSysDir%\drivers\etc\services” )

Set objTextFile = CreateObject(“NwSapSetupATLCommon.TextFileParser”)

If objTextFile.Parse( strFile ) Then

     NwEngine.Context.Log.Write “Event:  Modify the file ” & Chr(34) & strFile & Chr(34)

     If objTextFile.DoesStringExist( “sapmsPRD” ) Then

          objTextFile.ReplaceLineEx “sapmsPRD”, “sapmsPRD 3600/tcp”


          objTextFile.AppendLine “sapmsPRD 3600/tcp”

     End If

     objTextFile.Save( strFile )


     NwEngine.Context.Log.WriteWarning “Event:  Could not open the file ” & Chr(34) & strFile & Chr(34)

End If


That’s it.  That’s the entire script.  You can add more if you wish, but this script will execute as it stands.

On Installation End

Now we get to the meatier part of our scripts.  After the installation is essentially complete, we want to configure the user’s SAP Logon to use our shared server configuration files created earlier.

This script first checks to see whether this option has already been set in the registry hive HKEY_CURRENT_USER, as that setting will take precedence if it exists.  We don’t want that, we want all users of the workstation to use the same shared files, so we want to set the key in HKEY_LOCAL_MACHINE and make sure it isn’t set in HKEY_CURRENT_USER.  So, the first step is to check if it’s there, and if found, delete it.

Note that in Package Event Scripts, as in VBscript, you can abbreviate the registry hives to HKCU and HKLM.

Next we need to know whether we are running in a 32-bit or 64-bit version of Windows, as that influences the correct path to the registry key in HKLM (but not in HKCU).  Because SAPGUI is 32-bit software, if it is installed in 64-bit Windows, it will be registered, along with all other 32-bit software, in HKLM\Software\Wow6432Node.  If we are in 32-bit Windows, it will be directly under HKLM\Software.  We check WMI (Windows Management Instrumentation) to determine the AddressWidth with a pair of functions that return a TRUE or FALSE result.  Based upon the result, we set a variable for our registry path appropriately.  This particular method of determining the OS address width is based upon some ideas developed by DavidRR at StackOverflow (User DavidRR – Stack Overflow).

Having set our registry path appropriately, we set the registry value HKLM\Software<\Wow6432Node>\SAP\SAPLogon\Options\ConfigFileOnServer to point to \\server\sapgui\CustomerFiles\SapLogonTree.xml, and we’re done!  If we want to set other registry values, we would do so here, but this was our primary objective, so let’s take a look at the code.


NwEngine.Context.Log.Write “Event:  On Installation End”

‘Redirect SAPLogon to server configuration file but allow local custom entries

If NwEngine.Shell.RegValueExist(“HKCU\Software\SAP\SAPLogon\Options\ConfigFileOnServer”) Then

     NwEngine.Context.Log.Write “Event:  Deleting Previous HKCU ConfigFile Value”


End If

Function Is32BitOS()

     Const Path = “winmgmts:root\cimv2:Win32_Processor=’cpu0′”

     Is32BitOS = (GetObject(Path).AddressWidth = 32)

End Function

Function Is64BitOS()

     Const Path = “winmgmts:root\cimv2:Win32_Processor=’cpu0′”

     Is64BitOS = (GetObject(Path).AddressWidth = 64)

End Function

If Is64BitOS Then

     NwEngine.Context.Log.Write “Event:  64-bit OS detected”

     strRegPath = “HKLM\Software\Wow6432Node\SAP\”

ElseIf Is32BitOS Then

     NwEngine.Context.Log.Write “Event:  32-bit OS detected”

     strRegPath = “HKLM\Software\SAP\”

End If

strRegConfigValue = strRegPath + “SAPLogon\Options\ConfigFileOnServer”

strXmlFile = NwEngine.Variables.ResolveString(“%SapSrcDir%\CustomerFiles\SapLogonTree.xml”)

NwEngine.Context.Log.Write “Event:  Pointing SAPLogon to Server Configuration Files”

NwEngine.Shell.SetRegValue strRegConfigValue, “REG_EXPAND_SZ”, strXmlFile


If you have multiple Installation Servers, each with its own different CustomerFiles folder and different saplogon.ini settings, the user will be pointed at the saplogon.ini within the Installation Server being used, even without changing a line of code in the script.  That’s where the %SapSrcDir% environment variable comes into play.

Optional Registry Settings for Interface Layout

Now that you have a method for setting registry values during the installation, there are many other settings which you might choose to preconfigure.  For instance, you might choose to resize the SAP Logon window and reposition the column widths to make it a bit more user-friendly out of the box.  You might choose to maximize the SAPGUI window the first time it’s opened.  You might want the Transaction Code entry box to be open by default, and the system information in the status bar to show.  For users who frequently have sessions open to multiple systems, it can be useful for the Windows Taskbar to display some system information when the mouse hovers over it.  So, here are some registry settings, and the Package Event Script code to set them, that I find useful for an initial SAPGUI install.  Note that while I would put the script above for the config file location into both On Install and On Update scripts, the following is something I would only put into On Install.  Once SAPGUI is installed, users are likely to customize it to their own liking, so you don’t want to overwrite their customizations with your defaults every time you push out a patch.


‘Configuring window size and SAPLogon option initial defaults

NwEngine.Context.Log.Write “Event:  Setting Registry Values for SAPLogon Options”

strRegSapFrontPath     = “HKCU\Software\SAP\SAPGUI Front\SAP Frontend Server\”

strRegSapLogonPath     = “HKCU\Software\SAP\SAPLogon\Settings\”

strRegTaskbarTitle    = strRegSapFrontPath + “Administration\ShowAdditionalTitleInfo”

strRegCmdLine        = strRegSapFrontPath + “Customize\ShowCmdLine”

strRegStatusBar        = strRegSapFrontPath + “Customize\Statusbar.Layout”

strRegShowKeys        = strRegSapFrontPath + “Customize\Dropdown.ShowKey”

strRegSortKeys        = strRegSapFrontPath + “Customize\Dropdown.SortKey”

strRegGuiWindow        = strRegSapFrontPath + “Window\Maximize”

strRegSplitPos        = strRegSapLogonPath + “SplitterPosition”

<pstyle=”padding-left: 30px;”>strRegBottom        = strRegSapLogonPath + “Connections\Bottom”

strRegCol1        = strRegSapLogonPath + “Connections\ColumnWidth1”

strRegCol2        = strRegSapLogonPath + “Connections\ColumnWidth2”

strRegCol3        = strRegSapLogonPath + “Connections\ColumnWidth3”

strRegCol4        = strRegSapLogonPath + “Connections\ColumnWidth4”

strRegCol5        = strRegSapLogonPath + “Connections\ColumnWidth5”

strRegCol6        = strRegSapLogonPath + “Connections\ColumnWidth6”

strRegCol7        = strRegSapLogonPath + “Connections\ColumnWidth7”

strRegLeft        = strRegSapLogonPath + “Connections\Left”

strRegRight        = strRegSapLogonPath + “Connections\Right”

strRegTop        = strRegSapLogonPath + “Connections\Top”

strRegNode        = strRegSapLogonPath + “LastSelectedNodeKey”

‘SAP Logon Options, Interaction Design, Visualization 2, Show system name in taskbar button

NwEngine.Shell.SetRegValue strRegTaskbarTitle, “REG_DWORD”, 1

‘Open Transaction Code Entry Field

NwEngine.Shell.SetRegValue strRegCmdLine, “REG_DWORD”, 1

‘Display Information in Status Bar

NwEngine.Shell.SetRegValue strRegStatusBar, “REG_DWORD”, 1

‘Interaction Design, Visualization 1, Show keys within dropdown lists

NwEngine.Shell.SetRegValue strRegShowKeys, “REG_DWORD”, 1

‘…Sort by keys within dropdown lists for most efficient keyboard input

NwEngine.Shell.SetRegValue strRegSortKeys, “REG_DWORD”, 1

‘Maximize SAPGUI window

NwEngine.Shell.SetRegValue strRegGuiWindow, “REG_DWORD”, 1

‘Set SAPLogon window and column options

NwEngine.Shell.SetRegValue strRegSplitPos, “REG_SZ”, “19”

NwEngine.Shell.SetRegValue strRegBottom, “REG_SZ”, “523”

NwEngine.Shell.SetRegValue strRegCol1, “REG_SZ”, “195”

NwEngine.Shell.SetRegValue strRegCol2, “REG_SZ”, “25”

NwEngine.Shell.SetRegValue strRegCol3, “REG_SZ”, “37”

NwEngine.Shell.SetRegValue strRegCol4, “REG_SZ”, “206”

NwEngine.Shell.SetRegValue strRegCol5, “REG_SZ”, “26”

NwEngine.Shell.SetRegValue strRegCol6, “REG_SZ”, “164”

NwEngine.Shell.SetRegValue strRegCol7, “REG_SZ”, “25”

NwEngine.Shell.SetRegValue strRegLeft, “REG_SZ”, “169”

NwEngine.Shell.SetRegValue strRegRight, “REG_SZ”, “1059”

NwEngine.Shell.SetRegValue strRegTop, “REG_SZ”, “213”

NwEngine.Shell.SetRegValue strRegNode, “REG_SZ”, “de4aeca7-6c46-49f8-bf55-ba5ae43537ca”


A note about that last line with the UUID (“de4ae…” etc).  This line sets the cursor focus when SAP Logon is opened into the “ERP” folder we created earlier.  You will need to open your SapLogonTree.xml file and look up the correct UUID for the node you want to have as the initial focus and use that in the place of the example I gave here.

Package Event Script Wrapup

Once you have entered your scripts, you just need to click on the Save button.

The Package Version will increment by 1 when you do this.  Note that any clients (such as your own workstation) installed using this Package will now auto-update if the Package includes SAP Automatic Workstation Update (which our example does), either the next time the AWUS service starts, or within the defined interval for checking for updates (24 hours by default).  However, such clients will only run the On Update scripts, not the On Install scripts.

Your Package, including scripts, is now fully defined.  All that remains is to optionally configure Local Security Handling and then distribute the installation to clients.


Continue on to SAPGUI Installation Server Part 6 – LSH and Distribution.

To report this post you need to login first.


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

  1. Debbie Gawlik

    Hi Matt,

    I was wondering if you know whether 740 will make us of the CustomerFiles single location for the new versions of the ini file info.



    1. Matt Fraser Post author

      Hi Debbie,

      I haven’t had the opportunity to play with 740 yet, so I can’t really speak to this. I believe that it will, though, at least if you install it without including NWBC in the same install.



  2. Nicolaas Johannes Van Zyl

    Hi Matt and everyone,

    This would give some additional assistance where necessary.

    This one points to SAPGUI administration 740 patch level 3 which includes all your necessary commands/switches for whatever you need.…&nbsp;

    This one points to SAPGUI administration 730 compilation 3…&nbsp;

    Thanks to Melanie Reinwarth for publishing these links for us.

    @Matt – I have used your basic scripting option will test my installation shortly I know in my case I had to disable sound as well as the corbu styled icons. Tx for your very good documenation.


  3. Nicolaas Johannes Van Zyl

    Hi all,

    I just rolled out

    SAP GUI 740 Patch Level 3 Hotfix 1 File version: 740.1.3.1104 in conjunction with NWBC 5.0 Patch level 7.

    Used Matt’s very good scripts as is, and just substituted 2 values.

    In the guide I previously posted the link to SAP GUI 740 Administration Guide pg 52.

    XML Configuration File on Server

    Here there are two options:

    Configuration with INI files (SAP UI Landscape inactive)


    “ConfigFileOnServer” (REG_EXPAND_ SZ) [Default: ””] {valid path to the correct configured XMLFile}

    SAP UI Landscape active (NWBC 5.0 or higher is installed)


    “LandscapeFileOnServer” (REG_EXPAND_ SZ) [Default: ””] {valid path to the correct configured


    For more information on the configuration when using NWBC together with SAP GUI, see the SAP

    GUI for Windows Installation Guide, chapter 2.2 ‘Configuration with SAP NetWeaver Business


    I just changed the ConfigFileOnServer to LandscapeFileOnServer and SapLogonTree.xml to SAPUILandscape.xml

    Hope this helps someone. Matt thanks again for being an inspiration on SCN I really need to try and be more involved.


  4. Raoul Serra

    Not sure if it would be the right place to comment or ask a question related to it…

    I was wondering if the gui installation server could also be used only to execute the start VBS script without having a real package t odeploy, for example if gui is already installed, it would be nice to have a second packge created with no components to deploy but with a script that would do the configuration only and deploying new INI or XML files.

    I did try to create a package wit hno components but then when it runs it does not start the execution of the scripts, not even the one at “isntall start”

    If the scripts written for the gui installation server would have to be converted into independent VBS scripts it would need some work and not all could be accomplished exactly in the same way

    Thanks already to anyone who will comment further or give some good hints.

    1. Matt Fraser Post author

      Hi Raoul,

      I’ve had this same idea, of using “empty” packages as a means of triggering execution of scripts, but hadn’t actually tried it. Sounds like it doesn’t actually work, from your experiments? Did you double-check that the test client had the “package” installed first, so it would look for updates? And did you increment the package version number?

      Otherwise, I have used a simple VBscript as a “Reset Defaults” tool. When users call in to say that their GUI isn’t working correctly, I start by sending them the link to the script and asking them to execute it. In 90% of cases, that fixes the problem. For the remainder, 90% of what’s left is fixed by an uninstall and reinstall (so I have an uninstall script ready to go, which wipes all settings from the PC after removing the GUI). But, you’re right, by running these scripts outside of the Installation Server setting, care has to be taken that it is the user and not a helpful PC tech who is logged on, and local administrative rights can come into play.

      1. Raoul Serra

        Hello Matt, Thanks for your reply, my first attempt was using “On Install Start/End” and obviously nothing did happen, now I’m using the “On Update” but with a content in the package and that is working fine… will try today the On Update without content… If you have an example of VBScript doing what usually we do in those NW event scripts I would be interested (copying ini and xml files, updating etc\services file, adding/changing registry keys) … I’m trying to do the same as what you already do, having scripts for restting the defaults with some parameters set as the Company globally did want and also full clean-up  removing the gui, uninstall… as you are saying inside installation server it would be more comfortable, no admin rights problems

        1. Matt Fraser Post author


          I’m just about ready to start a project here to upgrade our 7.30 SAPGUIs throughout the organization to 7.40 (yes, I know, I know, we’re way late with doing this). When I’ve done that, I’ll see about writing a blog on upgrading the Installation Server, but also, when I’ve validated that my SapResetDefaults script still works with 7.40, I’ll post it up here.

          I was just looking through my installation script and the resetDefaults script, and there’s a clear progression in how my knowledge of VBScript improved. In the earlier script I used whatever tricks I could find online for things like figuring out if the user was running WinXP or Win7, and for whether it was 32-bit or 64-bit. In the later script, I still needed to find out those things, but I had figured out much cleaner methods using some of the functions in VBScript.

          Since then, we no longer have users running XP, and now we’re starting to get some users on Win10, so some of the needs have changed.

          1. Raoul Serra

            I will start to convert some of my NW scripts in the installation server into VBScripts, then I can even publish here as examples… thanks already for all the good URL links provided

  5. Daniel Mead

    Many thanks for the new additions to this topic.


    Wish there was an on-line course which went into more complex scripting. 

    We have both Technical Users and Standard Users which get a saplogon.ini file update.  Our Active Directory Admins pushed out an update which overwrote the technical user’s customized ini file.  There is probably a way script an if statement so it appends information instead of replacing the file.

    Complex scripting isn’t my skill set but I can imagine our new ASCS project could benefit from a simple find and replace script.

    Thanks to those who keep posting examples.


    Dan Mead

    1. Matt Fraser Post author

      Daniel, I agree about the scripting. I don’t do this often enough to consider myself any kind of expert. I rely heavily on MSDN:

      VBScript Language Reference:

      Win32 Provider:

      Methods (Windows Script Host):

      FileSystemObject Methods:

      StdRegProv class:

      As for the saplogon.ini files, I don’t like storing them on enduser computers, so the method I outlined in the blog was to store them centrally on a server, then use registry settings to have the clients point to that central location instead of anything local. Not only does that avoid something nasty happening out of your control to the file on the local client, it also makes it much, much easier to update the settings globally. You just edit the one file, and everyone gets the change instantly.

      1. Daniel Mead

        Hi Matt,

        Thanks for information.  I have some vendors who come in through VPN and their business profiles restrict their access to specific areas to our backend systems and it varies by multiple business partners.

        My preference is to create a package containing just updates to splogon.ini, services, and sapmsg.ini and not overwrite existing files and just append new content.  Compensating for 32-bit or 64-bit Microsoft OS releases as needed.

        I am pushing to use the consolidated server option leveraging SAPUILandscape.xml but it hasn’t been made a project of any importance by our management.

        Page 26 on the new SAPSetup Guide SAPSetup 9.0 User Guide 2016-06-07 looks promising.


        Dan Mead

  6. Daniel Leal

    The new SAPSetup Guide 9.0 from 2016-06-07 now includes a full documentation for the SAPSetup Visual Basic script objects. A very welcomed addition.

    Link to this guide is available in Note 1587566.


    Daniel Leal

    1. Matt Fraser Post author

      It does indeed! I just recently discovered this myself while working on upgrading my Installation Servers to 7.40. And, this new guide can be found in the root folder of any 7.40 Installation Server installed or upgraded with NwCreateInstServer or NwUpdateInstServer.

      Thanks, Daniel.



      1. Daniel Leal

        I am still trying to confirm, but it looks like you have to be in PL 9 of SAPGUI 7.40 to get the PDF Guide with the new scripting information, but it places a version of the document dated from May/12.  The link in the Note I mentioned above retrieves a version dated from June/07.  I do not know if there is another document or Note that always refers to the most current version of the SAPSetup Guide, or if indeed Note 1587566 is the official place.  Any idea?

        By the way Matt, thank you very much for authoring this blog.  Has been very helpful for me, and I am sure for many others.

        Daniel Leal

        1. Daniel Mead

          Hi Matt,

          I opened and incident with SAP on this and their response was that “there should be some kind of update to the package or the component., So that the script will run, otherwise if there is no correction in the packages or to the component then the script will not run.”

          So I rebuilt my package with your code in the “on Installation End” Tab and included core patch 9.  The update ran on my PC and laid down the patch 9 but did not update the saplogon.ini or SapLogonTree.xml.

          Is there some sort of code checker for your script?

          1. Matt Fraser Post author

            Dan, if you were updating your workstation with the new patch, rather than installing the package for the first time, then the On Installation End script wouldn’t run. Did you try putting your script into On Update End?

            1. Daniel Mead


              I have the script under both “On Installation End” and “On Update End”.  I will remove it from on Installation End and rebuild to see if that makes any difference.

            2. Daniel Mead


              I just created a new build version with you vb script only in “On Update End”.  The script updated SAP GUI 7/40 patch 2 to patch 9 and still didn’t overwrite the existing saplogon.ini or SapLogonTree.xml.

              I know I am doing something wrong just haven’t figured it out.

              Thanks for the help.

            3. Daniel Mead

              Updated the GUI Server with SapSetup patch 79.  It had some sort of scripting Fix.  Still no success with replacing the saplogon.ini using a Single File Installer.

              Dan Mead

  7. Jurij Rudnik

    Dear Matt

    I have to keep the NWBC configuration files “NWBCOptions.xml” and “NWBCOptions.xsd” central on the server shared drive.

    Is it possible to distribute the XML link file to the end users (%ALLUSERSPROFILE%\SAP\NWBC\NwbcRemoteOptions.xml) via SAPGui Installation Server?

    Thanks a lot!


    1. Matt Fraser Post author

      Hi Jurij,

      We don’t use NWBC on desktops in my organization, so I haven’t played with those options myself. We’re only just migrating to GUI 7.40, but we’re sticking with the traditional saplogon.ini and saplogontree.xml configuration for now.

      However, you should be able to adapt the overall method described here to your requirements. Just be sure to pay close attention to the SAPGUI Installation Guide, especially the chapter for installation with NWBC, for the minor differences.



  8. Giovanny Gonzalez

    Hello everyone,
    Thank you for your contributions, I have been very helpful!

    I have implemented SAP GUI Server and want to deploy it to all workstations and I have the following questions:

    1- It is possible to include a script in an event such as “On Uninstallation” to uninstall the version currently installed in the workstation (SAP GUI 7.3) and later install the SAP GUI Server version (SAP GUI 7.40), all in the same process and Installation package? If you have any reference to this, I thank you.

    2 – how can I see the workstations that are stored in the SAP GUI Server, taking into account the component “SAP Automatic Workstation Update”

    3- Can I export the bookmarks of NWBC 5 and import them as favorites in the SAP GUI client?

    I will be grateful for your comments and contributions.


    1. Matt Fraser Post author

      Hi Giovanny,


      Thanks for your comments. With regard to your questions:

      1. Including the uninstallation of the old GUI in the “On Uninstallation” script for the new GUI won’t work, unfortunately. The reason for this is that the “On Uninstallation” script doesn’t fire until the new GUI is pretty much completely installed. Usually you don’t need to worry about uninstalling the old GUI, as the installation program will detect the old one and perform an upgrade. However, sometimes you may want to get a fresh start, and I certainly understand that. In that circumstance, you could potentially create a separate package that has nothing in it but an uninstallation script. Or you could write a VBscript that performs the uninstall — this is what I did. Bear in mind that the basic /uninstall option on nwsapsetup.exe will still leave behind old registry entries and configuration files, which can impact the new installation. In that circumstance you’ll want your VBscript to additionally seek out and remove those config files and registry entries, which means you’ll need the script to run in “administrator” mode. That might be one reason for using an nwsapsetup package to do it, as you could use LSH. Alternatively, you could use a tool like Microsoft Systems Center to push the uninstallation.
      2. The workstations aren’t really “stored” by the Installation Server or in NwSapSetupAdmin. It isn’t that smart of a tool, and doesn’t provide quite that level of central control. If you want to keep a list of which workstations run the package install, you could write some centralized logging into the OnInstall or OnUpdate script. Otherwise, the installation logs are stored locally on each workstation. There is a feature within NwSapSetupAdmin to remotely view those logs, assuming you already know the workstation hostname and that you have remote WMI permissions to do so.
      3. I haven’t yet worked with NWBC, so I can’t answer this question. I’d suggest raising this as a separate question or discussion thread.


      1. Giovanny Gonzalez
        Hi Matt,
        Thank you for your comments and contributions.
        Regarding your comments on point 1, you have some model of script that you have tried and can serve as a guide.
        What I have planned is to uninstall the old version of SAP GUI, delete the registry entries as you recommend and delete the SAP directory stored in the user profile, which has the local Saplogon configuration, so that there is no conflict with The saplogon configuration of the SAP GUI SERVER package, I hope I can do everything from a script, although I think the option you propose to make a separate package to uninstall and delete such previous configurations, this is possible ?, how could it be done?
        Now I have one more question and it is in relation to the deployment and update of sap gui server components for workstations in remote sites, this can affect the bandwidth, I had read that it is best to create a sap gui server for each remote site and Each one is updated from the sap guí server master, as I can make it replicate and do not work independently.
        Thank you!!
        1. Matt Fraser Post author

          This is a VBscript that I put together three years ago to remove all traces of SAPGUI from a workstation. If I was rewriting it today I’d change a few things, so don’t look at this as an example of good script code! Also, back then we didn’t have Windows 10, so the part at the beginning that detects the OS version will need updating (since then, in later scripts, I came up with a much better way of doing this). However, for Win7 (or XP) clients, this works, assuming the user running it has local administrator privileges.


          On Error Resume Next
          Set Shell   = CreateObject(“WScript.Shell”)

          ‘Determine operating system version
          Set getOSVersion = Shell.exec(“%comspec% /c ver”)
          version    = getOSVersion.stdout.readall
          Select Case True
          Case InStr(version, “n 5.”) > 1 : GetOS = “WinXP”
          Case InStr(version, “n 6.”) > 1 : GetOS = “Win7”
          Case Else : GetOS = “Unknown”
          End Select

          ‘If in Windows 7, run as Administrator
          If GetOS = “Win7” And WScript.Arguments.length = 0 Then ‘Restart script as Administrator
          Set objShell  = CreateObject(“Shell.Application”)
          objShell.ShellExecute “wscript.exe”, “””” & WScript.ScriptFullName & “””” & ” RunAsAdministrator”, , “runas”, 1
          Else ‘do the work

          ‘Confirm user really wants to proceed
          strConfirmText  = “This will completely remove SAPGUI from your computer.  Do you want to continue?”
          intButton   = Shell.Popup(strConfirmText,,”SapSweep”,4+48+256)
          If intButton = 7 Then
          End If

          ‘Set up environment objects
          Set oServices  = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2”)
          Set oReg   = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv”)
          Set fso    = CreateObject(“Scripting.FileSystemObject”)

          ‘Determine operating system address width
          Function Is32BitOS()
          Const Path = “winmgmts:root\cimv2:Win32_Processor=’cpu0′”
          Is32BitOS = (GetObject(Path).AddressWidth = 32)
          End Function

          Function Is64BitOS()
          Const Path = “winmgmts:root\cimv2:Win32_Processor=’cpu0′”
          Is64BitOS = (GetObject(Path).AddressWidth = 64)
          End Function

          Select Case True
          Case Is64BitOS : GetBits = “64”
          Case Is32BitOS : GetBits = “32”
          End Select

          ‘Set up registry paths
          Const HKCU   = &H80000001
          Const HKLM   = &H80000002
          sKeyCU    = “Software\SAP”
          sKeyLM32   = “SOFTWARE\SAP”
          sKeyLM64   = “SOFTWARE\Wow6432Node\SAP”

          ‘Get user-independent files and folders
          sAllUsersProfile = Shell.ExpandEnvironmentStrings(“%ALLUSERSPROFILE%”)
          sWinDir    = Shell.ExpandEnvironmentStrings(“%windir%”)
          sSapLogon   = sWinDir & “\SapLogon.ini”
          sSapMsg    = sWinDir & “\Sapmsg.ini”
          sSapfCpl   = sWinDir & “\System32\sapfcpl.cpl”
          sSapRegSv   = sWinDir & “\System32\sapregsv.exe”

          ‘Get OS-specific paths
          If GetOS = “Win7” Then
          sAppDataSapSub  = “\AppData\Roaming\SAP”
          sLocalDataSapSub = “\AppData\Local\SAP”
          sVirtualStoreIniSub = “\AppData\Local\VirtualStore\Windows\saplogon.ini”
          sStartMenuSAP  = sAllUsersProfile & “\Microsoft\Windows\Start Menu\Programs\SAP Front End”
          ElseIf GetOS = “WinXP” Then
          sAppDataSapSub  = “\Application Data\SAP”
          sLocalDataSapSub = “\Local Settings\Application Data\SAP”
          sStartMenuSAP  = sAllUsersProfile & “\Start Menu\Programs\SAP Front End”
          End If

          ‘Get AddressWidth-specific paths
          If GetBits = “64” Then
          sProgramFiles  = Shell.ExpandEnvironmentStrings(“%ProgramFiles(x86)%”)
          sCommonFiles  = Shell.ExpandEnvironmentStrings(“%CommonProgramFiles(x86)%”)
          sSapBtmp   = sWinDir & “\sysWOW64\SAPbtmp.dll”
          ElseIf GetBits = “32” Then
          sProgramFiles  = Shell.ExpandEnvironmentStrings(“%ProgramFiles%”)
          sCommonFiles  = Shell.ExpandEnvironmentStrings(“%CommonProgramFiles%”)
          sSapBtmp   = sWinDir & “\System32\SAPbtmp.dll”
          End If
          sProgramFilesSAP = sProgramFiles & “\SAP”
          sCommonFilesSAP  = sCommonFiles & “\SAP Shared”

          ‘Get profiles parent folder
          sUserProfile  = Shell.ExpandEnvironmentStrings(“%USERPROFILE%”)
          Set oUserProfileFolder = fso.GetFolder(sUserProfile)
          sProfileRoot  = oUserProfileFolder.ParentFolder

          ‘Enumerate all existing user profile folders
          Set oFolder   = fso.GetFolder(sProfileRoot)
          Set colSubfolders = oFolder.Subfolders

          ‘Reusable functions
          Function DelSubKeys(cHive, strKey)
          Return = oReg.EnumKey (cHive, strKey, arrSubKeys)
          If Return = 0 Then
          If IsArray(arrSubKeys) Then
          For Each SubKey in arrSubKeys
          DelSubKeys cHive, strKey & “\” & SubKey
          End If
          oReg.DeleteKey cHive, strKey
          End If
          End Function

          Function DelFolder(sFolder)
          If (fso.FolderExists(sFolder)) Then
          fso.DeleteFolder sFolder, true
          End If
          End Function

          Function DelFile(sFile)
          If (fso.FileExists(sFile)) Then
          fso.DeleteFile sFile, true
          End If
          End Function

          ‘Stop running services
          Set colListOfServices = oServices.ExecQuery (“Select * from Win32_Service Where Name =’NWSAPAutoWorkstationUpdateSvc'”)
          For Each objService in colListOfServices
          Return = objService.StopService()

          Set colProcess = oServices.ExecQuery (“Select * from Win32_Process Where Name = ‘saplogon.exe'”)
          For Each objProcess in colProcess
          Return = objProcess.Terminate()

          ‘Uninstall SAP Frontend 7.10 and higher
          Shell.Run “\\snocsapgus21\sapgui\Setup\NwSapSetup.exe /uninstall /all /nodlg”,,true

          ‘Uninstall SAP Frontend 6.40
          Shell.Run “\\snocfmn1\sapgui640\Setup\SapSetup.exe /uninstall /nodlg”,,true

          ‘Remove left-behind registry keys
          DelSubKeys HKCU, sKeyCU
          DelSubKeys HKLM, sKeyLM32
          DelSubKeys HKLM, sKeyLM64

          ‘Remove non-user-specific left-behind folders and files
          DelFolder sProgramFilesSAP
          DelFolder sCommonFilesSAP
          DelFolder sStartMenuSAP
          DelFile sSapLogon
          DelFile sSapMsg
          DelFile sSapfCpl
          DelFile sSapRegSv
          DelFile sSapBtmp

          ‘Remove all user-specific left-behind folders and files
          For Each objSubfolder in colSubfolders
          sProfile  = sProfileRoot & “\” & objSubfolder.Name
          sSapWorkDir  = sProfile & “\SapWorkDir”
          sAppDataSap  = sProfile & sAppDataSapSub
          sLocalDataSap = sProfile & sLocalDataSapSub

          DelFolder sAppDataSap
          DelFolder sLocalDataSap
          DelFolder sSapWorkDir
          If GetOS = “Win7” Then
          sVirtualStoreIni = sProfile & sVirtualStoreIniSub
          DelFile sVirtualStoreIni
          End If

          strDone    = “All SAP registry entries, files, and folders removed, except for temporary files.  Reboot recommended.”
          strDoneTitle  = “SAP Uninstall Complete”
          Shell.Popup strDone,10,strDoneTitle,64

          End If ‘Close out the ELSE statement from line 17


          Otherwise, if you were going to use an “uninstall” package within NwSapSetupAdmin, the package event script might look something like this:


          ‘Remove obsolete configuration files

          NwEngine.Context.Log.Write “Event:  On Uninstallation End”

          strIniFile640 = NwEngine.Variables.ResolveString( “%windir%\saplogon.ini” )

          strMsgFile640 = NwEngine.Variables.ResolveString( “%windir%\sapmsg.ini” )

          strIniFile720 = NwEngine.Variables.ResolveString( “%SapFrontEndDir%\saplogon.ini” )

          strMsgFile720 = NwEngine.Variables.ResolveString( “%SapFrontEndDir%\sapmsg.ini” )

          strIniFile730 = NwEngine.Variables.ResolveString( “%AppData%\Roaming\SAP\Common\saplogon.ini” )

          strShcFile730 = NwEngine.Variables.ResolveString( “%AppData%\Roaming\SAP\Common\sapshortcut.ini” )

          strXmlFile730 = NwEngine.Variables.ResolveString( “%AppData%\Roaming\SAP\Common\SapLogonTree.xml” )

          strIniFileVst = NwEngine.Variables.ResolveString( “%LocalAppData%\VirtualStore\Windows\saplogon.ini” )

          If NwEngine.Shell.FileExist( strIniFile640 ) Then

          NwEngine.Shell.DeleteFile strIniFile640

          End If

          If NwEngine.Shell.FileExist( strMsgFile640 ) Then

          NwEngine.Shell.DeleteFile strMsgFile640

          End If

          If NwEngine.Shell.FileExist( strIniFile720 ) Then

          NwEngine.Shell.DeleteFile strIniFile720

          End If

          If NwEngine.Shell.FileExist( strMsgFile720 ) Then

          NwEngine.Shell.DeleteFile strMsgFile720

          End If

          If NwEngine.Shell.FileExist( strIniFileVst ) Then

          NwEngine.Shell.DeleteFile strIniFileVst

          End If


          That one isn’t handling the registry entries, only the config files, but you can add registry editing to a package event script easily enough (the latest sapsetup guide has a pretty decent scripting reference, finally, and otherwise it’s just like VBscript).

          Long ago, early versions of the Installation Server code included logic for having “master” and “slave” servers, with the slaves auto-updating from the master. The current incarnation no longer does that. It’s easy enough (and more reliable, less problematic, which I think is why the functionality was removed) to just manually update each of your installation servers when you need to. I don’t do that for my setup: we have approximately a hundred buildings spread throughout the city, all connected by a fibre WAN, and the fibre connections are fast enough that it’s not an issue for the remote sites to install from one central Installation Server. I do have multiple Installation Servers, but it’s not for load balancing or anything like that. Rather, it’s so that I can separate sandbox, DEV, QAS, and PRD groups from each other, giving them different sets of centralized config files, and also rolling out SAPGUI patches in a controlled and tested manner, much like I would transports or updates to the SAP applications.

          1. Giovanny Gonzalez

            Hi Matt,
            A thousand thanks have been great help your answers and comments.

            Finally, take your comment as a guide and create a script to uninstall the current gui.



Leave a Reply