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.
