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.