Skip to Content

SAPGUI Installation Server Part 6 – LSH and Distribution

This is it, the wrap-up of our six-part series about setting up an SAPGUI Installation Server for centralized control of clients.  The last step is to configure Local Security Handling and then to distribute SAPGUI to end user workstations.

The six parts of the series are:

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

LSH and Distribution

Configure Local Security Handling

LSH Background

Local Security Handling (LSH) is an optional but recommended feature that enables end users to install SAPGUI from an Installation Server using a predefined Package even if they do not have local Administrator privileges on their workstation (meaning, they cannot normally install software for themselves).  Depending upon the security policies of your organization, users may or may not have such privileges.  LSH isn’t intended to circumvent policy, but to enable a controlled distribution in a manner prescribed by the administrator.

Without going into deep technical detail, LSH works by setting up a service on the Installation Server, called the Distribution Service (DS), that runs in the context of a domain user account that is a member of the local Administrators group on every domain workstation (the DS User).  A member of Domain Admins would work for this, but it isn’t necessary for the account to be a Domain Admin, only that it be a local Administrator on the Installation Server and on every workstation.  There are a number of ways to achieve this using Active Directory Group Policy and/or Logon Scripts, and it is common to do so with “workstation administrator” or “PC technician” groups.  The exact steps for setting this up are outside the scope of this document and fall into the responsibility of the network or Active Directory administrator.  Due to having administrator privileges to the workstation, the DS is able to remotely push certain activities, which we’ll discuss momentarily.

When the end user calls the NwSapSetup program to start the installation, one of the first actions of the program is to check whether the user has local Administrator privileges.  If the user does, NwSapSetup proceeds normally.  If the user does not, NwSapSetup triggers the DS to make a call to the workstation and then exits.  Now the DS, running as a service on the server, takes over and makes a remote call to the workstation.  The DS checks to see whether another service account, the IS User (Installation Service User), is a member of the local Administrators group, and if not, tries to make the IS User such a member.  Note that often the DS User and IS User will be the same service user account, but they do not have to be.

With the IS User’s credentials established, the DS installs a service remotely onto the workstation, the Installation Service or IS, and then triggers the IS to start in the context of the IS User.  At this point the DS is done with its part.

Now the IS, running as the IS User on the workstation, once again calls NwSapSetup, but this time in the context of the IS User.  Because the IS User is a local administrator, the setup program is able to proceed with the SAPGUI installation.  When the installation is complete, there is one final extra step, which is to stop the IS and uninstall it, so it isn’t left behind.  In the event of an update or upgrade, the same process of install IS, run NwSapSetup, then uninstall IS will be repeated.

If you do not have access to an AD global group besides Domain Admins that is in the local Administrators group on all your workstations, then you can use separate DS and IS users to manage pushing the IS service for SAPGUI installation.  In this case, the DS User will need to be a member of Domain Admins, but the IS User will not.  The IS User can be a simple Domain User account.  The DS will establish the IS User as a local Administrator temporarily before remotely installing the IS service.

In most cases, however, creation of the appropriate AD group is easy enough or already exists, and in this circumstance the DS User only needs to be in this lesser group.  If this is the case, it is simpler to use the same user account for both DS and IS User, and that is what we will do here.

Install LSH on Server

If you are not still in the Installation Server Administration Tool from the last step, start the tool by calling:

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

In the tool, click on Services… Configure Local Security Handling.

The Local Security Handling (LSH) Wizard starts.

Click on Next, and on the next screen, enter the logon credentials for your DS User.  Be sure to enter the username in the format domain\user.  In this example, we are using a service account called sys$sap_maint, but the username can be whatever fits your organization’s naming convention for service accounts.

When you click Verify, the tool verifies that the passwords as typed match each other; it does not yet verify that the password is correct or that the user has the required credentials.  That will happen at the end.

Now the tool asks for the logon credentials of the IS User.  This may be a different user from the DS User, but in our example we will use the same user account for both.

Again, clicking Verify will confirm you entered the same password in both fields, and then on the next screen, clicking Next will actually start the configuration of the DS on the server, which is very quick.  If all goes well, you will shortly see a success message.

At this point, you are done.  If the LSH configuration was not successful, by far the most common reason is not entering a correct password for the DS/IS User.  Check that you have the correct password, and that the DS User is configured as a local Administrator on the Installation Server.

Clicking Close returns you to the NwSapSetupAdmin tool.  Look at the status bar at the bottom of the window, where you will see an indicator of the Distribution Service State, Active or Inactive.

You might still see the service as inactive here, even after successful configuration.  In that case, close NwSapSetupAdmin and then restart it, and this will refresh the service status.

Troubleshoot LSH

Most issues with LSH can be resolved by repeating the configuration steps from above and ensuring that you are using the correct password.  However, if this doesn’t work, Note 1162270 contains detailed troubleshooting steps and hints.

Patching with LSH

Before applying patches to your Installation Server, especially SAPSetup patches, it is best practice to shut down LSH.  From within NwSapSetupAdmin, click on Services… Stop Distribution Service (if this option is greyed out, either LSH is not currently running, or you may need to refresh its status by restarting NwSapSetupAdmin).

Proceed with patching as described in SAPGUI Installation Server Part 3 – Patching, then reconfigure LSH again as described in this document.

If you do not stop LSH before applying the patch, the patch will still be successful, but you will need to reboot your server afterwards.

Note that it is also possible to stop and start LSH from the server console, via Computer Management or the Services applet, by stopping or starting SAP Front-End LSH Service.

Distribute SAPGUI

Your Installation Server is now fully functional and ready for users.  Users have several options for how to install, but my recommendation is the ‘NoDialog’ option.  This option, when used with a Package, is fully automated, requiring no interaction from the user (other than perhaps a User Account Control prompt from their workstation’s operating system), but still displaying progress bars so they know what is going on.  Another option is ‘Silent’, which is also fully automated, but displays nothing to the user.  With ‘Silent’ users may not even be aware that an installation is occurring.

The command line to install the ‘Basic’ Package with ‘NoDialog’ is:

  • \\server\sapgui\Setup\NwSapSetup.exe /package=”Basic” /nodlg

If you prefer to use ‘Silent,’ substitute /silent for /nodlg.  Substitute your server’s actual hostname for server, and the share name chosen for your Installation Server for sapgui.


Users can initiate the installation themselves by executing the command line as shown, or you can add this command to a logon script.  It is also possible to push installations via Microsoft System Center Configuration Manager (SCCM, previously known as Systems Management Server, or SMS), and NwSapSetupAdmin contains an option to create Package Definition Files to be used with SCCM.  The use of SCCM is beyond the scope of this document, however.

Subsequent executions of the same command-line will detect the presence of SAPGUI on the workstation and the presence of the defined Package.  The installer will compare the version of the Package and the versions of the SAPGUI components with those in the same Package on the server, and if they are the same or higher, the installer will exit.  If the version found is lower, the installer will execute in ‘update’ mode and update the SAPGUI components to the versions found on the server.  This is one way you can easily distribute patches to your users.


If you do use logon scripts, you may wish to add another command-line switch, /once, to keep subsequent executions of the installer very fast for those who have already installed.  While the installer will exit fairly quickly if it finds nothing in need of updating, it still displays a splash screen (unless you use /silent) and takes a moment before exiting.  The /once switch causes NwSapSetup to first check for a defined registry value.  If it’s found, NwSapSetup exits immediately without checking versions and without displaying any splash screen, so it is very fast.  If the registry value doesn’t exist, or it doesn’t match the value defined in the switch, then the installer proceeds.

To use /once effectively, you need to define a standard for the values used.  I recommend something along the line of:

  • <GUI Release>.<Compilation>.<Patch>.<Hotfix>.<Package Version>

So, in our example where we are distributing SAPGUI 7.30 Compilation 3 with Patch 8 Hotfix 1, and not having made subsequent changes to our Package such that it is in version 1, the switch value would be:

  • 730.

To use this in the installer, the command line would be:

  • \\server\sapgui\Setup\NwSapSetup.exe /package=”Basic” /nodlg /once=”730.″

Next time we update the Package, we would also update the ‘Once’ value in the logon script to match, thus causing the installer to check versions and, in most cases, apply the updates.

Note that in the event the SAPGUI is uninstalled, the ‘Once’ registry key is not removed, so unless it has changed in the logon script, the installer will detect the value and not proceed with the installation.  Thus, if the intent is to reinstall (perhaps to fix a problem), it will be necessary to manually execute the installer without the /Once switch.

Other Topics

You have now fully configured an Installation Server and pushed SAPGUI to your users.  This is all that is required for a functional installation.  However, there are other more advanced topics which may be the subjects of future documents going into more detail:

  • Automatic Workstation Update Service (AWUS)
    • This is a mechanism for automatically keeping your workstations in sync with the server.  If you followed the example used as a Package in this document series, you have already distributed and enabled this feature for your users, such that their workstations will check for new versions of GUI components or Package versions on the server at each boot-up or every 24 hours.
  • Single File Installer
    • NwSapSetupAdmin enables compressing all components of a Package, including scripts and custom configuration files, into a self-extracting installer which can then be distributed for use on machines that are only intermittently connected, such as users’ home PCs that occasionally connect via VPN, or workstations connected over a slow WAN.  For this, you will want a different strategy for centralized configuration files than the one outlined in this document series.

I hope you have found this document series helpful.

You must be Logged on to comment or reply to a post.
  • I want to install SAPGUI installation server on my environment but we have several site with low network bandwidth between them.

    If we use only one SAPGUI installation server on the corporate site, the installation on client could be be very slow due to network bandwith.

    How to deploy the same package on several site ?

    Is it possible to have replication on this installation server?

    First possible solution:

    With Microsoft DFS technology for example. If Yes, how to set parameter in config file to find the adress of the Distribution Service.


    One master installation server and deploy slave (replicate) installation server on other site.

    How to do that thing?

    • Hi Thomas,

      In the past (i.e. with SAPGUI 6.40 and earlier), the Installation Server included a replication concept, where one Installation Server was designated the master and then various clones would periodically update themselves from it. That way, users could simply use whichever clone, or slave, Installation Server was closest to them.

      However, the modern Installation Server doesn’t include this functionality anymore. However, it’s not really an issue, and the probable reason it’s not included is that there are better mechanisms (such as DFS, for instance) for replicating the setup.  For that matter, if the number of satellite sites is not very high, it shouldn’t be hard to manually keep things in sync, as once you have stable setup you probably won’t touch it very often, except for occasional patching.

      You don’t even need to “install” the Installation Server to each satellite — you can simply install and configure it once, and then just copy the installation folders to each location. If you plan to use LSH, or Local Security Handling, you will need to run the LSH setup inside the NwSapSetupAdmin tool separately on each site, but that’s not a big deal. It’s pretty quick and painless.

      The scripts that I used as examples utilize %SapSrcDir% as a variable, so when the client runs the installation script it will point to the location the script is run from, so you don’t even need to edit the scripts in any way for each location. The clients will also configure themselves to look for patches and/or utilize centralized configuration files from the server they install from.

      When it comes time to patch the Installation Server, you might consider patching each one separately, rather than just patching the master and then copying the folders again. This is so that the patch process will automatically increment the package version number in the configuration, thus triggering the clients to patch themselves. However, even if you do just copy the folders to distribute the server-side patches, it should still work.

      In short, what you are describing is quite easy to do. If you have a large number of sites, then using an OS-level replication service would be a good idea, but if it’s just a handful, it may be less complex to just copy things manually.



      • First of all,

        Thank you very much for the quick answer.

        I think in my case the simplest way is to choose DFS.

        If I want to activate LSH, I think I have to install the service on each instance of Windows DFS server.

        Is that right?


        • Yes, you’ll need to install the LSH service separately on each instance, but it’s pretty quick and easy, so unless you are going to have hundreds of satellite instances, it shouldn’t be a big deal.

          • Hi Matt,

            I have deploy the same SAPSetup source on all my DFS server and I have configured LSH on each server.

            if I use :

            \\domainname\dfs\sap\setup\nwsapsetup.exe /package”..”

            The client doesn’t arrive to join the distribution service.

            but if I use:

            \\localserver\dfs\sap\setup\nwsapsetup.exe /package “…”

            It’s working.

            It seems that nwsapsetup use the server name to find LSH server so it couldn’t work with DFS (domain name)

            The solution could be to have DFS on my domain controler but I don’t want that 🙂

            Maybe 2 solutions:

            1 GPO per site

            or 1 script which is able to use the good local server function of IP for example.

          • Ok, that’s good to know. I haven’t worked with DFS, so I’m not familiar with its peculiarities. It might be simpler to just not use it, and instead simply copy your master installation to each satellite location. I would agree, don’t install this on your domain controller.

  • Hi. What is the biggest advantage of using SAPGUI installation server, over just triggering the whole installation directly with Microsoft System Center Configuration Manager (SCCM)?

    • Hi Stian,

      I have not used SCCM myself — we are just beginning to use it in my shop for other client distributions, but haven’t gotten to adapting SAPGUI for it yet. However, in general, even if you are going to use SCCM to distribute the software, you will still want to use an Installation Server. In fact, the two can work together fairly well.

      Once you have setup your Installation Server and configured a Package on it, you will find an option in NwSapSetupAdmin for Create Package Definition File. That is specifically for use with SCCM and other similar tools. Many people mistake the Single File Installer option as being for use with SCCM, but that is not the case.

      The idea is that SCCM can be used to trigger deployments to workstations in a planned and controlled manner using the Package Definition File, and that definition file contains instructions for how the workstation will call the Installation Server to install a particular package.

      The other advantage in doing it this way is that then you have the option of using your Installation Server as a storage location for centrally-managed configuration files. This is by far the best way to distribute and maintain SAPLogon connection entries.



  • Hi Matt,
    I have done the LSH configuration with a domain admin user, configured a logon script to test the LSH operation, installing a package by command line.
    The service is active and running, however, when performing the test does not continue the installation by permissions, do you know if I should have any additional recommendations in the configuration?

    I assume the operation of AWU, requires LSH to do the update of new components. With AWU the update of components and patches, is detected and installed automatically by the Workstation when it detects it? Or does it require the command-line update to be forced?

    Thank you for your comments.

    • Hi Giovanny,


      If your LSH test fails to correctly install the SAPGUI, double-check the local permissions of your DS or IS service user account. Remember that this user must be a member of the local Administrators group in Windows on the workstation. The other point to keep in mind is that an LSH installation doesn’t happen in the context of the logged-on user, but in the context of the IS/DS service user, so while the SAPGUI may correctly install, user-specific items such as saplogon.ini files, etc, may not work quite as you expect. LSH can be a tricky thing to get just right.


      With regard to AWUS, whether or not it requires LSH depends on whether the user required LSH initially. However, typically AWUS will run as the Local System built-in account, or something similar, so it can likely get the privileges it needs to update installed components.


      AWUS runs as a service on the workstation, and it performs a check against the Installation Server each time it starts up (usually at bootup), or if running continuously, then every 24 hours. It checks the version of the Package on the workstation against the version of the Package on the server, and if the server version number is higher, then it will run a Package-specific update. It also checks the versions of the software components installed (i.e., the patch and/or hotfix level of the SAPGUI), and if the server has a higher version, it will update the local components on the workstation to that version. This part is Package-independent.


      There is no command-line required for AWUS to function, nor anything to do in a logon script — it is automatic. If you are using logon scripts to check for available updates, then AWUS is redundant. However, personally I prefer to rely on AWUS and not logon scripts for this purpose.




      • Thank Matt,

        It means that AWU does not require LSH to update new components, since it acts as a service and with a local system account ?.

        Any way to test the operation of AWU on the workstation?

        Do you need to configure the Additional Update Sources option with the shared directory path that contains the installation components? (SAP GUI Server)


    • You will need to test for yourself, but this is easy to do. You can check the operation of AWUS by incrementing the Package version number on your server (in NwSapSetupAdmin), then restarting the AWUS service on your test workstation to trigger it to check for updates immediately. That process is logged at C:\Program Files (x86)\SAP\SapSetup\LOGs on the workstation.


      You do not need to configure Additional Update Sources unless you have a very large setup with multiple Installation Servers in a load-balanced configuration. This is not a common setup, so generally you can just leave that blank. By default AWUS will look for updates on the server it was installed from.

      • So, very helpfully topic for me. Thank you Matt.

        Have the one question of AWUS, how to start it from domain user on local PC instead of user SYSTEM?

        A Sap setup server share have the read access only for all domain users and local SYSTEM user couldn’t read the dir

        ##Server Path \\SAP\SERVICES\Update_SAP\SAP_GUI\Setup could not be found: Error message: Access is denied.

        • Hi Denis,

          We setup the share permissions (“SERVICES” in  your example) with:

          • Everyone
            • Read
          • Administrators
            • Full Control
            • Change
            • Read

          By default, this resulted in folder security as follows:

          • Everyone
            • Read & execute
            • List folder contents
            • Read
          • SYSTEM
            • Full control
            • Modify
            • Read & execute
            • List folder contents
            • Read
            • Write
          • Administrators
            • Full control
            • Modify
            • Read & execute
            • List folder contents
            • Read
            • Write

          So, I think the difference here is the use of ‘Everyone’ instead of ‘Domain Users.’ As presumably this is inside your firewall and only available to your user base, and it’s read-only access, that should not present a security risk.


  • Thank you for quick answer. We have specific internal instructions from security department and couldn’t share file via EVERYONE, only domain users. Will try to find other solution.

  • Hi Dear Matt,
    We have installed to SAP GUI Server With SAPGUI 7.40 and we have multiple Packages configured.

    We’re planning update to version our SAP GUI Server to SAPGUI 7.50 and then update the workstations through service AWU.

    I configured a new SAP GUI Server for Testing and when I update this SAPGUI Server with the version SAPGUI 7.50, the packages installed with version 7.40 shows that there are lost components, what is the correct way to update my SAPGUI server without affecting the packages existing and additional that the work stations are updated according to the corresponding package.


    • Hi Giovanny,

      Generally speaking, there should be no issue upgrading your Installation Server to accommodate a new SAPGUI version. I’ve done it myself when we upgraded from 7.30 to 7.40 (we still haven’t distributed 7.50 yet). However, new versions can deprecate some components, so you may need to adjust your Packages to ensure you are either replacing them with the new components, or you may need to incorporate “legacy” versions of the components. It’s not uncommon for Packages to require a little tweaking after upgrading the core SAPGUI component.

      This is one of the reasons I recommend having multiple Installation Servers, so that you can test this with just a handful of pilot users (or maybe even no users except yourself) before rolling it out to the rest of your user base.

      As an additional note, when you are upgrading the SAPGUI Installation Server, and not just applying a patch to it, or when you are installing new components to it, you should use the NwUpdateInstServer.exe tool located in \\<server>\<share>\Setup.


      • Hi Matt, Thanks for your reply.

        I tried to update the version of the SAPGUI Server (7.40) with the tool NwUpdateInstServer.exe tool located in \\ <server> \ <share> \ Setup as you mention, through the wizard select the share of the server installation ( SAPGUI 7.40) when it finishes, it does not update any component and as indicated above I need to update to SAPGUI 7.5 + SAP Business Client 6.5

        As I do not update the components, I have manually downloaded SAPGUI 7.50, uncompress it, run the same tool NwUpdateInstServer.exe that is in SAPGUI 7.50 through the wizard select the shared directory of the current installation server which has the SAPGUI version 7.40 all this for Force update of the SAPGUI 7.40 server to 7.50. Is this the correct way to update the server?

        At the end of this forced update the server was updated, I have adjusted the existing packages, for example by deleting SAP Business Client and adding SAP Busniness Client 6.5 however when I try to update on the workstations these are not updated.

        Finally one more question, if initially in the installation of the SAPGUI Server, configure the AWU service to check frequently 24 hours, now I want to reconfigure the frequency to 2 hours, when you make this change in the installation server the workstations automatically take This change or what should I do to make the adjustment?

        I appreciate your comments, if the procedure of updating the server is the correct one, or what your suggestion is.

        Thank you




        • Giovanny,

          Yes, using the NwUpdateInstServer.exe tool from the SAPGUI 7.50 upgrade package may actually be the right choice. Been a while since I did that, so I may have misspoken earlier on this point.

          If you changed the name of your Packages, then the clients may not automatically update, since they will be looking for updates in a Package with the same name (or actually the same internal ID). When you update the content of the Package and save it, the tool should automatically increment the version number for the Package, but if that doesn’t happen, then you can manually increment it. The client workstations look at this version number as well, to see if the one on the server is higher than the one they already have.

          I wouldn’t really recommend changing the AWUS frequency to 2 hours, unless you only have a small number of clients. However, if you do, that should take effect after the next time the workstation checks in, i.e. it might take 24 hours before they check in and update to reflect that change.

          In other words, if right now your AWUS is set to the default of 24 hours, then the workstation will check in every 24 hours, or whenever rebooted. So, only when the workstation checks in, once per day, will it notice that there is a change to the configuration. Once that happens, it should update to the 2-hour frequency. So, it could take up to 24 hours before all your workstations switch frequencies.

          • Perfect Matt, your comments have been of great help to me, Thank you very much.

            One more thing in the menu Remote / Execute process on remote computer of SAP installation server administration, I am witnessing a remote update with several workstations and I get the same error in all: “stating remote process on hostname failed: Attempt to connect to SCM of hostname failed. Error message: Access is denied. Error Code 0x00000005 (5). ”

            I have verified the following services are enabled and running on workstations:
            – Register remote
            – Remote procedure call (RPC)
            – DCOM Server Process
            – RPC Endpoint Mapper

            I have committed the admin account of the domain this well configured in LSH.
            nevertheless the error continues, do you have any comments to solve this error?

            In the same Menu Remote / Remote task manager and Collec logs Files (WMI), if I get information about the work station.



          • I have to admit I have never been successful getting the remote execution process to work. I suspect in many organizations various levels of firewalling and so forth may block this kind of remote access to workstations, except perhaps for domain admins. I’m not sure the LSH process helps much here; you may need to login as a domain admin yourself while running NwSapSetupAdmin in order to do this.

            As I can’t really be of much help with this bit, I think you’d be better off raising it as a question against the “UI SAP GUI for Windows” tag (not the “logging of SAP GUI for Windows tag”). Sorry about that.