Skip to Content

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.

/Once

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

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

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

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.

To report this post you need to login first.

13 Comments

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

  1. Thomas Broussal

    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.

    Second:

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

    How to do that thing?

    (0) 
    1. Matt Fraser Post author

      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.

      Regards,

      Matt

      (0) 
      1. Thomas Broussal

        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?

        Regards,

        (0) 
        1. Matt Fraser Post author

          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.

          (0) 
          1. Thomas Broussal

            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.

            (0) 
            1. Matt Fraser Post author

              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.

              (0) 
  2. Stian Windsland

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

    (0) 
    1. Matt Fraser Post author

      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.

      Cheers,

      Matt

      (1) 
  3. Giovanny Gonzalez

    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.

    (0) 
    1. Matt Fraser Post author

      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.

       

      Cheers,

      Matt

      (1) 
      1. Giovanny Gonzalez

        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)

         

        (0) 
    2. Matt Fraser Post author

      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.

      (1) 

Leave a Reply