Skip to Content

Local Security Handling (LSH) is our problem child. The problem with LSH is not so much in the implementation itself, but a lot in the way the deployment landscapes have changed since the days this feature was first invented (days of Win NT). Security is a buzzword today, and a lot of modern Windows security measures block all that they allowed a few years back. Hence, this FAQ to help you out!

 

How LSH works? 

Before I go on to explain solutions to prospective problems, let me first give an overview of what LSH is, and how it works:

SAP Front-End Software Installation is primarily an administrative activity i.e. you need to have full administrative privileges on the computer you wish to install on. This is important so that software be installed once and for all on a workstation, and for all users who wish to use it there. However, this prerequisite means that every employee gets full control on his workstation — a requirement that is not very appealing to many network administrators who shudder at the thought of allowing each of their (say 10000 or more) employees add and remove software on their workstations, at free will. This is why Local Security Handling was implemented.

 

Essentially, LSH is a service configured by the Domain Administrator on his Installation Server (typically a Windows Server machine) where he feeds in his credentials to the LSH Wizard in NWSAPSetupAdmin, the administrative console for SAP Installation Server Management. His credentials are stored securely by the service. When an employee with non local-administrative privileges wishes to install from this Installation Server, the SAP Front-End Installer contacts the LSH service. The latter remotely installs another service on the workstation (as the LSH service runs with Domain Administrative Privileges, it can do such things… ). This “workstation service” then restarts the installation from the Installation Server, and naturally under Administrative credentials. Thus, user can install SAP software on their workstation without requiring local-administrative privileges, if the administrator has configured LSH.

 

Great! So, why’s it not working?

Reasons, as seen below, range from the obvious to the obscure.

 

Windows Vista with Windows Firewall

Workstations with Vista will not allow LSH by default. The reason for Vista-related failures are:

  • Remote Service Configuration is disabled by default. 
  • Remote Registry Configuration is disabled by default.

Solution: Configure Windows Firewall options on workstations to switch “Remote Service Configuration” ON.

(Once remote service configuration is enabled, the LSH service will configure remote-registry access automatically.)

 

Windows XP with Windows Firewall

Workstations with Windows Firewall are by default not reachable from an Installation Server outside their subnet. In other words, the LSH Service on the Server is not allowed to contact the workstation and setup the workstation service remotely.

Solution: Configure Windows Firewall options to change the scope of “File-Sharing” access to “Any computer”. Alternatively, enable access from your installation server, exclusively, using steps as described here.

 

Changed Administrative Credentials

Administators configure LSH using their domain username / password. However, a few months later, a change of password is enforced by company policy and the credentials saved with the LSH Service are no longer correct. So, the system stops working.

Solution: Reconfigure LSH via NWSAPSetupAdmin.exe using the latest, correct credentials.

To report this post you need to login first.

5 Comments

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

  1. Lieven De Bock
    I am trying to get LSH working with a DFS-fileshare.

    Unfortunately this fails?
    Opening the ‘pipe’ does not return ‘credentials’..

    14:23:44  NwSapFeiUt  1   Distribution server expected as pidpant.local
    14:23:44  NwSapFeiUt  1   Going to call pipe “\\NTDOMAIN.local\PIPE\_nw_sapfeids_is_pipe_” sending XPOFF2007-12 /fs=”\\NTDOMAIN.local\Filesystem\SoftDist\SAP710c4\setup” /cmdline=’ /elevated’ /isversion=”8.1.0.201″ /_upid=1804 /winsta=”WinSta0″ /desktop=”Default” /event=”Global\IS_NW_SAPSETUP_Sync_Event5420843″
    14:23:44  NwSapFeiUt  1E  CallNamedPipe failed; maybe DS is not running or networking problem occurred: Het systeem kan het opgegeven bestand niet vinden.## Error code 0x2 (2)
    14:23:45  NwSapSetup  1E  * LSH failed *
    14:23:47  NwSapSetup  1E  LOCAL SECURITY HANDLING FAILED

    A local Server works fine..

    14:17:30  NwSapFeiUt  1   Distribution server expected as hkcron
    14:17:30  NwSapFeiUt  1   Going to call pipe “\\[ServerName]\PIPE\_nw_sapfeids_is_pipe_” sending XPOFF2007-12 /fs=”\\[ServerName]\SAPGUI710\setup” /cmdline=’ /elevated’ /isversion=”0.0.0.0″ /_upid=504 /winsta=”WinSta0″ /desktop=”Default” /event=”Global\IS_NW_SAPSETUP_Sync_Event5047093″
    14:17:37  NwSapFeiUt  1   NamedPipe received Pidpant\IS_SAP710
    14:17:38  NwSapSetup  2   Environment : Installer Service will run under account ‘Pidpant\IS_account’, SID S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzzzz-qqqqqqq
    14:17:38  NwSapSetup  1   Signal IS to start second process

    Any Clue how to address this ?

    (0) 
    1. Holger Mairon
      I think there is no general reason, why LSH should not work in an ADS environment. Could you please open a CSN ticket on BC-FES-INS? I would like to see both the complete client AND server side logs …
      regards
      HoM
      (0) 
        1. Holger Mairon
          there is not spezial programming in LSH for DFS. We use the windows network functions (anything like WNet…) and we deduce the computername from the UNC kind of writing a network resource. If this is compatible with your DFS – it might work.

          regards
          HoM

          (0) 

Leave a Reply