Skip to Content
Author's profile photo Matt Fraser

SAPGUI Installation Server Part 1 – Getting Started

Managing a large landscape of SAP Frontend clients requires a central location from which to maintain configurations as well as push updates, upgrades, and the initial distribution.  The SAPGUI Installation Server has a number of features to help the system administrator achieve these goals.  In this six-part series I will take you from the initial download, through the installation, to the configuration of scripted packages for a fine level of workstation control.  I will show how to maintain central control of the SAP Logon configuration, and I will make some recommendations that may help ease the administrator’s burden.

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 at the beginning and move sequentially through the steps.

  1. Getting Started (this document)
    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
  6. LSH and Distribution

Getting Started

Assumptions and Prerequisites


  • SAPGUI:  The SAP Graphical User Interface; the standard client, usually installed locally on each end user’s workstation; also written as SAP GUI.
  • SAP Frontend:  An alternative name for SAPGUI.
  • SAP Logon:  A component of the SAPGUI installation for managing server connections.
  • SAPGUI Installation Server:  A central installation source, usually installed on a server accessible to all users and managed by a system administrator.
  • SAPGUI Distribution Service:  A service running on the Installation Server utilized for Local Security Handling (LSH; see below).
  • Package:  A set of SAPGUI components, often with associated scripted actions, preconfigured for ease of installation and administration.
  • Package Event Script:  Customizable scripts which run at the beginning or end of an installation, uninstallation, or update of SAPGUI.
  • LSH (Local Security Handling):  An optional feature of the Installation Server which allows users without local Administrator privileges to their workstations to install SAPGUI.
  • saplogon.ini:  A configuration settings file for SAP Logon, usually stored locally on the end user’s workstation, but which can be stored centrally for shared access.
  • SAP Service Marketplace:  SAP’s customer support website, typically accessed via (customer S-user logon required).

Assumptions and Prerequisites

  • You are distributing SAPGUI for Windows 7.30 (this series does not pertain to SAPGUI for Java or SAPGUI for HTML (aka WEBGUI)).
  • Your end user workstations are members of an Active Directory domain.
    • The examples are on systems running Windows 7 Enterprise Edition, variously 32-bit and 64-bit, but Windows XP (no longer supported), Windows Vista, and Windows 8 or 8.1 should also work.
  • You have access to and Administrator control over a Windows server that is a member of the same AD domain (or has an established trust relationship).
    • The examples are on a system running Windows Server 2012 R2, but any supported Windows Server version will work.  The Installation Server can even be installed on a workstation, but this is not recommended.
  • You are familiar with navigating the Windows Server user interface, especially the Computer Management tool.
  • You have access to or control over a domain user account that can be granted local Administrator access to all domain workstations (for LSH).
    • The user account does not need to be a member of Domain Admins, unless your organization does not have an alternative means of pushing membership in the local Administrators group on member workstations; this is usually controlled by Group Policy and/or AD logon scripts.
    • In this series the sample account will be called sys$sap_maint, but it can be whatever fits your organization’s naming conventions.
    • LSH is an optional feature which is only required if you have end users without local Administrator privileges to their workstations, or who are otherwise prevented from installing software for themselves.
  • You have a customer S-user with which to logon to the SAP Service Marketplace.


Official Documentation

  • SAP Setup Guide
    • This document describes installation and basic configuration of an Installation Server, and installation of an SAPGUI from an Installation Server.  It includes sample Package Event Scripts to achieve various purposes.
    • The latest version (7.30 Compilation 3) can be found on your local hard drive after download and extraction of the setup files at:
      • \NW_7.0_Presentation_\PRES1\GUI\WINDOWS\WIN32\
    • Later it can also be found at the root of your Installation Server at \\<server>\<share>, and can be accessed through online help within the Installation Server Administration Tool (NwSapSetupAdmin).
  • SAP Front End Installation Guide
    • This document covers much of the same ground as the SAP Setup Guide, however it does not go into as much detail about Package Event Scripts.
    • The latest version (7.30 Compilation 3) can be found on your local hard drive after download and extraction of the setup files at:
      • \NW_7.0_Presentation_\PRES1\DOCU\
    • Later it can also be found on your Installation Server at \\<server>\<share>\ReadMe.
    • An earlier version (7.30 Compilation 2) is on SCN at SAP GUI for Windows 7.30 Frontend Installation Guide.
    • Currently, the version found within the Installation and Upgrade Guides on the SAP Service Marketplace is older still (7.20).
  • SAP GUI Administration Guide
    • This document provides a reference for the many registry settings which can control the appearance and behavior of SAP Logon and SAPGUI, and which can be manipulated via Package Event Scripts.
    • The latest version (7.30 Compilation 3) can be found on your local hard drive after download and extraction of the setup files at:
      • \NW_7.0_Presentation_\PRES1\DOCU\
    • An earlier version (7.30 Compilation 2) is on SCN at SAP GUI Administration Guide.
  • Many other documents will be found in the \DOCU folder of your extracted setup files, as described above.

SCN Blogs and Documents

Download Setup Files

Initial Installation Download

Ok, let’s get started!  First, you need to acquire the installation files.  You may have received these on a DVD-ROM labeled Presentation along with the rest of your SAP system installation media.  However, to ensure you are using the latest available version, it is usually best to download the latest SAPGUI compilation from the SAP Service Marketplace, along with the latest SAPSetup and GUI patches.

The path to the compilation is:

    • Installations and Upgrades
      • Browse our Download Catalog
        • SAP Frontend Components
            • SAP GUI FOR WINDOWS 7.30 CORE
              • Installation

Do not yet select the Win32 link.  On the Info Page, find the SAPSetup 9.0 component, and then to the right of that select the link.

This will open up a second browser tab or window.  In that window you will usually see six different options for a patch to download.  Three of them will be for the latest available patch, and three for the most recent previous patch that is still supported (there will likely have been patches in between that are no longer recommended for use).  Unless otherwise advised by SAP Customer Support, always go for the latest available patch (patch 46 as of this writing).

That still leaves three options, P1, P2, and P3.  It is not always readily apparent what the differences are.  All three will patch the core SAPSetup files, but with some variations:

  • P1 is the core SAPSetup files only; it does not include patches for the Automatic Workstation Update Service (AWUS).  If you do not use AWUS, you may select this patch, but I recommend using AWUS so we will not use it in this example.
  • P2 is the same patch, except AWUS is included.  This is the patch I recommend.  Note that even if you do not use AWUS at this time, this patch is safe to use.
  • P3 is the same patch, except it additionally includes the PDB Support Files.  These are descriptive message files not needed for normal operation, but which can be useful when troubleshooting problems with your installation server.  Typically you will only need these upon the advice of SAP Customer Support, and/or when other mechanisms of troubleshooting have already failed to reveal the problem.

Look carefully at the names of the patch files.  The patch number (46 in this example) will be fairly obvious, but the P1/P2/P3 distinction requires looking for the label embedded in the patch title or filename.  The filename will follow the format SAPSETUP90PxSP00P_xx-20008539.EXE.  The first x is the P1/2/3 number, and the second xx is the patch number (46).  In this example, we will choose SAPSETUP90P2SP00P_46-20008539.EXE.  Add it to your download basket.

A brief side note about the download page title for Windows Server on IA32 32bit.  It does not matter whether your Installation Server is installed on a 32-bit or 64-bit server, and it does not matter whether your workstations are running 32-bit or 64-bit Windows.  The SAPGUI is a 32-bit application (at this time) and will run fine in either environment.  So, even though you may be planning for all 64-bit environments, the 32-bit download is still appropriate.

Now close this second browser tab, returning to your original tab.  Now click the Win32 link that I previously told you to ignore.

This will take you to the Downloads page, and there will be a long list of available patches.  Again, it takes some careful consideration to find exactly the right patch to download.  For instance, you will again see most or all of the patches in a PDB version and a non-PDB version.  You do not need the PDB files at this time, so you may ignore those.  You will see various GUI patch levels (currently from 0 through 9) as well as hotfixes for some of the patch levels.  The patches and hotfixes are all cumulative, so you only need one file.  The hotfixes are typically listed before the core patches, so you must scan the list to see if the latest core patch has a hotfix for it or not.  In this example, the latest patch is 9, and there is no hotfix for it, although you can see that patch 8 has hotfix 1 available.  Here, you would normally choose patch 9, but if it were not yet available, you would choose patch 8 hotfix 1, and not patch 8 without the hotfix.

Add your GUI patch to your download basket, and save both the SAPSetup patch and GUI patch to a location on your local workstation’s hard drive.  Do not extract or execute the patch files.  Patch application will occur using the NwSapSetupAdmin tool at a later stage.


Continue on to SAPGUI Installation Server Part 2 – Initial Installation.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Matt, I'm really speachless from the low number of likes/ratings this blog series have received on SCN. (And I'm not just saying this because you also said nice things about my blog. 🙂 ) Even though SAP GUI space might not be as glamorous as HANA/Mobility/Cloud, surely we, the SCN members, should be able to appreciate the quality of writing, extent of preparation this must have taken and wealth of technical information and reference provided.

      Even though I'm not sure SAP GUI Server installation is in my near future, these days I have to wear many hats (Basis sometimes is one of them - we don't have one on staff), and blogs like this are always helpful because they make the process approachable to anyone.

      Thank you for sharing!

      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author

      Jelena, thank you! I figured it was just the niche aspect of the topic, although I continue to see forum questions related to using the Installation Server (obviously they didn't search, or they'd have found this series, right? 😉 ). I suspect most Basis administrators would rather spend their time tuning and tweaking their ERP servers, wringing the utmost in performance and usability from their Enterprise Portals, optimizing their PI integrations, and -- of course -- migrating their BI implementations to HANA, than they would in managing the perhaps unglamorous desktop clients that still dominate most corporate cubicles. Yet, still, we must manage to deploy, maintain, and periodically upgrade those clients, and my hope here has been to make that job easier and more nimble so we can all get back to the greater fun of figuring out our mobility and cloud strategies. 🙂

      Author's profile photo Former Member
      Former Member

      After searching for a while I reached this tutorial, it was great help. Everything works like a dream.

      Now I'm trying to add a shared config files for NetWeaver Business Client 4.0, same as we did with the config files for SapLogon. Could you please direct me in the right place for how to create those files? Are they going to be in the same folder as the others (CustomerFiles)? Should I start NetWeaver Business Client in the same way we did with SapLogon.. etc?

      Any help would be highly appreciated.

      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author

      Hi Ahmed,

      I haven't installed NWBC myself, so I cannot speak directly to it. For SAPGUI 7.40 and NWBC 5.0, it is my understanding that the configuration file setup is quite a bit different. However, with SAPGUI 7.30 and NWBC 4.0, I believe the configuration of NWBC into the Installation Server is much the same as any other SAPGUI component that you might configure in a package. You should be able to use the same CustomerFiles folder, just ensure that your package event scripts include the necessary language to point clients to it.

      Perhaps someone else with more direct NWBC experience can jump in on this; otherwise, I'd love to learn what you find out as you move forward with your project.



      Author's profile photo Former Member
      Former Member

      Hi Matt,

      Thanks for the super quick response. I will try to find out and post back here.

      Author's profile photo Nicolaas Johannes Van Zyl
      Nicolaas Johannes Van Zyl


      This is indeed a very useful link thanks for your time and effort Matt!



      Author's profile photo Jude Bradley
      Jude Bradley

      I hope you don't mind me sharing this content on LinkedIn.


      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author

      Not at all!

      Author's profile photo Jude Bradley
      Jude Bradley

      Thanks so much Matt.

      Author's profile photo Former Member
      Former Member


      Thanks for putting together such a comprehensive series of articles on this topic.  2 years old and still very helpful!


      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author

      Jamie, you're very welcome!

      Author's profile photo Former Member
      Former Member

      Hi Matt,

      I just need to clarify, what kind of access does end user workstation need to be able to install SAPGUI thru installation server? Thank you! 🙂



      Author's profile photo Jude Bradley
      Jude Bradley

      Hello Denver,

      The end-user needs access to the HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE

      branches of the registry. Typically, the packages are pushed from the installation server, out to the workstation. Refer to the installation guide help for more information.



      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author

      Hi Denver,

      To follow-up on Jude's response, if you are using LSH, then the end-user doesn't require anything other than to be a member of the Users local group on the workstation (which Domain Users global group is part of, by default). LSH handles the permissions required to install the software locally. If you aren't using LSH, then the user needs to be able to install software for themselves, which is typically handled by being a member of the Administrators local group. Many organizations do allow their users to be administrators of their own workstations, but many others do not, so whether or not you use LSH will depend upon your organization's policies.

      Note that if you use a tool like Microsoft SCCM to push out software, then this tool can take care of the permissions required for installation in a manner similar to LSH.



      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer

      Even 6 years later, this blog helped me setup a SAPGui update server to generate sscm packages.



      One of the tricky bits I just ran into, is that you still can't have multiple versions in one GUI server. 🙁

      So when I tried to create a test pacakge for version 770, it crashed my version 760 package. (booh)

      Author's profile photo Matt Fraser
      Matt Fraser
      Blog Post Author

      Thanks, Tom! That's a super nice validation, for someone who hasn't had much time for any blogging in the past couple years. I'm really glad it helped! Kind of amazing that a blog I wrote for v730 still (mostly) works for v760 (with a few tweaks on the server configuration files). I haven't given v770 any tries yet. We're currently productive with 760 pl8 hf1, and I'm about to push out pl9 due to a security update contained in it. However, I usually try not to push SAPGUI updates on my users more than once a year, except in urgent cases (like security updates). And, 770 is very new, so you're brave! I am excited about some of the new features it is supposed to bring, however (like finally dropping the reliance upon IE11 in favor of Edge).

      That said, yep, you can still only have one version of the GUI served up by one Installation Server, though you can have multiple Packages of difference component combinations and with different scripts. I solve that by having four Installation Servers, in SBX, DEV, QAS, and PRD instances. The SBX instance is only for our Basis team (2 people), the DEV instance is for our full in-house SAP support team, QAS for those power users who help us with testing in our QAS ECC systems, and PRD is, well, everyone else. Splitting it up this way not only allows me to run patch and version updates through a regular DEV-QAS-PRD cycle, but it also allows me to easily serve up different landscape configuration files to the different groups. PRD users, for instance, don't need to have connection entries for DEV and QAS. And (at least for now), no one outside Basis needs access to SolMan.

      Cheers, and thanks for the lift to my spirits today!