码上快乐

相关内容   简体   繁体

SAPGUI Installation Server

本文转载自  查看原文  2020-12-10 13:56  390    SAP/ BASIS

https://launchpad.support.sap.com/#/notes/2283941

https://max.book118.com/html/2018/0201/151417292.shtm

 

Part 1 – Getting Started

Managing a large landscape of SAP Frontend clients requires a central location from which to maintain configurations as well as push updates, upgrades, and the initial distribution.  The SAPGUI Installation Server has a number of features to help the system administrator achieve these goals.  In this six-part series I will take you from the initial download, through the installation, to the configuration of scripted packages for a fine level of workstation control.  I will show how to maintain central control of the SAP Logon configuration, and I will make some recommendations that may help ease the administrator’s burden.

As parts of this process are likely already familiar to many of you, I have broken it up into stages.  Please feel free to jump to the sections most relevant for you.  If you are setting up an Installation Server for the first time, however, I recommend you start at the beginning and move sequentially through the steps.

  1. Getting Started (this document)
    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

Getting Started

Assumptions and Prerequisites

 

Definitions

  • SAPGUI:  The SAP Graphical User Interface; the standard client, usually installed locally on each end user’s workstation; also written as SAP GUI.
  • SAP Frontend:  An alternative name for SAPGUI.
  • SAP Logon:  A component of the SAPGUI installation for managing server connections.
  • SAPGUI Installation Server:  A central installation source, usually installed on a server accessible to all users and managed by a system administrator.
  • SAPGUI Distribution Service:  A service running on the Installation Server utilized for Local Security Handling (LSH; see below).
  • Package:  A set of SAPGUI components, often with associated scripted actions, preconfigured for ease of installation and administration.
  • Package Event Script:  Customizable scripts which run at the beginning or end of an installation, uninstallation, or update of SAPGUI.
  • LSH (Local Security Handling):  An optional feature of the Installation Server which allows users without local Administrator privileges to their workstations to install SAPGUI.
  • saplogon.ini:  A configuration settings file for SAP Logon, usually stored locally on the end user’s workstation, but which can be stored centrally for shared access.
  • SAP Service Marketplace:  SAP’s customer support website, typically accessed via http://service.sap.com/support (customer S-user logon required).

Assumptions and Prerequisites

  • You are distributing SAPGUI for Windows 7.30 (this series does not pertain to SAPGUI for Java or SAPGUI for HTML (aka WEBGUI)).
  • Your end user workstations are members of an Active Directory domain.
    • The examples are on systems running Windows 7 Enterprise Edition, variously 32-bit and 64-bit, but Windows XP (no longer supported), Windows Vista, and Windows 8 or 8.1 should also work.
  • You have access to and Administrator control over a Windows server that is a member of the same AD domain (or has an established trust relationship).
    • The examples are on a system running Windows Server 2012 R2, but any supported Windows Server version will work.  The Installation Server can even be installed on a workstation, but this is not recommended.
  • You are familiar with navigating the Windows Server user interface, especially the Computer Management tool.
  • You have access to or control over a domain user account that can be granted local Administrator access to all domain workstations (for LSH).
    • The user account does not need to be a member of Domain Admins, unless your organization does not have an alternative means of pushing membership in the local Administrators group on member workstations; this is usually controlled by Group Policy and/or AD logon scripts.
    • In this series the sample account will be called sys$sap_maint, but it can be whatever fits your organization’s naming conventions.
    • LSH is an optional feature which is only required if you have end users without local Administrator privileges to their workstations, or who are otherwise prevented from installing software for themselves.
  • You have a customer S-user with which to logon to the SAP Service Marketplace.

References

Official Documentation

  • SAP Setup Guide
    • This document describes installation and basic configuration of an Installation Server, and installation of an SAPGUI from an Installation Server.  It includes sample Package Event Scripts to achieve various purposes.
    • The latest version (7.30 Compilation 3) can be found on your local hard drive after download and extraction of the setup files at:
      • \NW_7.0_Presentation_\PRES1\GUI\WINDOWS\WIN32\
    • Later it can also be found at the root of your Installation Server at \\<server>\<share>, and can be accessed through online help within the Installation Server Administration Tool (NwSapSetupAdmin).
  • SAP Front End Installation Guide
    • This document covers much of the same ground as the SAP Setup Guide, however it does not go into as much detail about Package Event Scripts.
    • The latest version (7.30 Compilation 3) can be found on your local hard drive after download and extraction of the setup files at:
      • \NW_7.0_Presentation_\PRES1\DOCU\
    • Later it can also be found on your Installation Server at \\<server>\<share>\ReadMe.
    • An earlier version (7.30 Compilation 2) is on SCN at SAP GUI for Windows 7.30 Frontend Installation Guide.
    • Currently, the version found within the Installation and Upgrade Guides on the SAP Service Marketplace is older still (7.20).
  • SAP GUI Administration Guide
    • This document provides a reference for the many registry settings which can control the appearance and behavior of SAP Logon and SAPGUI, and which can be manipulated via Package Event Scripts.
    • The latest version (7.30 Compilation 3) can be found on your local hard drive after download and extraction of the setup files at:
      • \NW_7.0_Presentation_\PRES1\DOCU\
    • An earlier version (7.30 Compilation 2) is on SCN at SAP GUI Administration Guide.
  • Many other documents will be found in the \DOCU folder of your extracted setup files, as described above.

SCN Blogs and Documents

Download Setup Files

 

Initial Installation Download

Ok, let’s get started!  First, you need to acquire the installation files.  You may have received these on a DVD-ROM labeled Presentation along with the rest of your SAP system installation media.  However, to ensure you are using the latest available version, it is usually best to download the latest SAPGUI compilation from the SAP Service Marketplace, along with the latest SAPSetup and GUI patches.

The path to the compilation is:

  • http://service.sap.com/swdc
    • Installations and Upgrades
      • Browse our Download Catalog
        • SAP Frontend Components
          • SAP GUI FOR WINDOWS
            • SAP GUI FOR WINDOWS 7.30 CORE
              • Installation

Do not yet select the Win32 link.  On the Info Page, find the SAPSetup 9.0 component, and then to the right of that select the link.

This will open up a second browser tab or window.  In that window you will usually see six different options for a patch to download.  Three of them will be for the latest available patch, and three for the most recent previous patch that is still supported (there will likely have been patches in between that are no longer recommended for use).  Unless otherwise advised by SAP Customer Support, always go for the latest available patch (patch 46 as of this writing).

That still leaves three options, P1, P2, and P3.  It is not always readily apparent what the differences are.  All three will patch the core SAPSetup files, but with some variations:

  • P1 is the core SAPSetup files only; it does not include patches for the Automatic Workstation Update Service (AWUS).  If you do not use AWUS, you may select this patch, but I recommend using AWUS so we will not use it in this example.
  • P2 is the same patch, except AWUS is included.  This is the patch I recommend.  Note that even if you do not use AWUS at this time, this patch is safe to use.
  • P3 is the same patch, except it additionally includes the PDB Support Files.  These are descriptive message files not needed for normal operation, but which can be useful when troubleshooting problems with your installation server.  Typically you will only need these upon the advice of SAP Customer Support, and/or when other mechanisms of troubleshooting have already failed to reveal the problem.

Look carefully at the names of the patch files.  The patch number (46 in this example) will be fairly obvious, but the P1/P2/P3 distinction requires looking for the label embedded in the patch title or filename.  The filename will follow the format SAPSETUP90PxSP00P_xx-20008539.EXE.  The first x is the P1/2/3 number, and the second xx is the patch number (46).  In this example, we will choose SAPSETUP90P2SP00P_46-20008539.EXE.  Add it to your download basket.

A brief side note about the download page title for Windows Server on IA32 32bit.  It does not matter whether your Installation Server is installed on a 32-bit or 64-bit server, and it does not matter whether your workstations are running 32-bit or 64-bit Windows.  The SAPGUI is a 32-bit application (at this time) and will run fine in either environment.  So, even though you may be planning for all 64-bit environments, the 32-bit download is still appropriate.

Now close this second browser tab, returning to your original tab.  Now click the Win32 link that I previously told you to ignore.

This will take you to the Downloads page, and there will be a long list of available patches.  Again, it takes some careful consideration to find exactly the right patch to download.  For instance, you will again see most or all of the patches in a PDB version and a non-PDB version.  You do not need the PDB files at this time, so you may ignore those.  You will see various GUI patch levels (currently from 0 through 9) as well as hotfixes for some of the patch levels.  The patches and hotfixes are all cumulative, so you only need one file.  The hotfixes are typically listed before the core patches, so you must scan the list to see if the latest core patch has a hotfix for it or not.  In this example, the latest patch is 9, and there is no hotfix for it, although you can see that patch 8 has hotfix 1 available.  Here, you would normally choose patch 9, but if it were not yet available, you would choose patch 8 hotfix 1, and not patch 8 without the hotfix.

Add your GUI patch to your download basket, and save both the SAPSetup patch and GUI patch to a location on your local workstation’s hard drive.  Do not extract or execute the patch files.  Patch application will occur using the NwSapSetupAdmin tool at a later stage.

 

Part 2 – Initial Installation

his is the second of a six-part series progressing from initial download, through installation, to configuration of scripted packages for a fine level of workstation control via an SAPGUI Installation Server.  Later in the series I will show how to maintain central control of the SAP Logon configuration, and I will make some recommendations that may help ease the administrator’s burden.

As parts of this process are likely already familiar to many of you, I have broken it up into stages.  Please feel free to jump to the sections most relevant for you.  If you are setting up an Installation Server for the first time, however, I recommend you go back to SAPGUI Installation Server Part 1 – Getting Started and move sequentially through the steps.

Previously we discussed basic prerequisites and assumptions, defined some general terms, located official documentation and helpful blogs, and downloaded all the installation and patch files required for our Installation Server.  Now we will move on to the initial installation of our server.

  1. Getting Started
    1. Includes download of all required files
  2. Initial Installation (this document)
  3. Patching
  4. Package Creation
    1. Includes initial installation of the administrator’s SAPGUI
  5. Scripting
  6. LSH and Distribution

Initial Installation

Actions on the Server Console

Now it’s time to prepare your server for installation.  I do not recommend using one of your SAP application servers for this purpose, although it is possible.  Ideally, this will be a dedicated server.  It does not need to be very large or powerful, however, as its main purpose will be to make a file share available.  If you elect to use Local Security Handling, however, then you will also have a service running on the server, and if care is not taken during patching of a server with LSH running, you may need to reboot it.  If you are not using LSH, reboots should not be necessary in most circumstances.

Please note that if you are using LSH, then you cannot have more than one SAPGUI Installation Server installed on the same host.  If you are not using LSH, it is technically possible, but it is not supported by SAP, and it is not recommended.  Reasons for having more than one Installation Server could include maintaining multiple SAPGUI versions or patch levels, or maintaining separate DEV and TEST Installation Servers for patch and upgrade testing before release to end users.  It is not necessary to have multiple Installation Servers just to maintain different collections of products or components, as a single Installation Server can easily handle multiple Packages.

SAPGUI Installation Server is fully compatible with VMWare and lends itself well to virtualized hosts.

Logon to the server console as an administrative user, via Remote Desktop or other means.  Launch Computer Management (in Windows Server 2012 R2, this is found in Administrative Tools; in Windows 2008 or 2003, it can be accessed on the Start menu by right-clicking Computer and choosing Manage).

Create Share

In Computer Management, expand System Tools and Shared Folders, then select Shares.  Right-click in the blank space and select New Share.  Follow the wizard to create a new share of a new folder called sapgui, with Administrators having Full Control and Everyone having Read-Only access (if your organization’s policies dictate, you may need to give Read-Only to Domain Users instead of Everyone).

Configure Distribution Service User (optional)

This step is required if you intend to use Local Security Handling (LSH).  This is an optional feature which enables users to self-install SAPGUI from an Installation Server via predefined packages even if they do not have local Administrator privileges to their workstations.  Without LSH, your users must either be Administrators of their own machines, or you will have to use other mechanisms to distribute the SAPGUI to them.  I recommend configuring LSH.

You will need a Domain User service account which is a member of an Active Directory group that is added to the local Administrators group on every workstation in the domain.  By default, only the group Domain Admins has this status, but you can use Group Policy or Logon Scripts to add a custom global group without requiring members to be Domain Admins.  As a service account, it should also be exempt from password expiration rules typically applied to end user accounts.  In this example, the account is called sys$sap_maint, but you may call it whatever fits with your organization’s naming conventions for service accounts.  We’ll also refer to this as the DS User.

While still in Computer Management on your installation server from the previous step, add the DS User to the local Administrators group.  Expand System Tools, then Local Users and Groups, then select Groups.  Double-click Administrators, then click Add, and select your DS User.

You are now done on the server console and can logout of it, returning focus to your own workstation.

Install Installation Server Files

Create Server Shell

On your workstation, navigate to the location to which you expanded the SAP Frontend Compilation.  Drill down to:

  • \NW_7.0_Presentation_
    • \PRES1
      • \GUI
        • \WINDOWS
          • \WIN32
            • \Setup

In the Setup folder, double-click:

  • NwCreateInstServer.exe

The SAP Installation Server Creation screen appears.

Click Next.

Click Browse.  In the Browse for Folder window, in the Folder field, type in the name of your Installation Server host and the share you created earlier (i.e. \\server\sapgui).

Click OK.  You are returned to the SAP Installation Server Creation window, and your server and share name should now appear in the entry field.

Click Verify.  This will confirm that the installation program has access to the share.  Look for a Verification successful message.

Click Next.  The initial installation of the setup files will now proceed.  It will be very quick.

When it’s done, you will see the message Your installation server was created.

 

Update Server With Products

At this point, your Installation Server is basically an empty shell.  The next step is to import actual products into it that can be used on end user workstations.  As a side note, it is also possible to return to this step in future to add additional products to your server.  To do so, use the tool NwSapSetupAdmin.exe which will be found at \\server\sapgui\Setup once your server is created, and which we will discuss further in the following parts.  However, for now the server creation tool will move straight to this step and import all the products included with SAPGUI.  Click Next.

This part will take a little longer than the previous import.  When it’s done you will see the message Your installation server was updated.

Note that the option Start the SAP Installation Server Administration Tool is checked.  Leave it this way.  When you click Close the program will automatically launch the tool for applying patches and creating packages.  Working in this tool will be the major focus of the rest of this series.

You now have a working SAPGUI Installation Server, but you’re not quite ready for prime time yet.  Your server needs to be patched, and you will need to set up one or more Packages that define just how the SAPGUI should be installed on end user workstations.

 

Part 3 – Patching

This is the third of a six-part series progressing from initial download, through installation, to configuration of scripted packages for a fine level of workstation control via an SAPGUI Installation Server.  Later in the series I will show how to maintain central control of the SAP Logon configuration, and I will make some recommendations that may help ease the administrator’s burden.

 

As parts of this process are likely already familiar to many of you, I have broken it up into stages.  Please feel free to jump to the sections most relevant for you.  If you are setting up an Installation Server for the first time, however, I recommend you go back to SAPGUI Installation Server Part 1 – Getting Started and move sequentially through the steps.

 

In Parts 1 and 2 we downloaded all our required files and installed our Installation Server to a network shared location.  Now it’s time to bring our Installation Server up-to-date with the latest patches.

 

  1. Getting Started
    1. Includes download of all required files
  2. Initial Installation
  3. Patching (this document)
  4. Package Creation
    1. Includes initial installation of the administrator’s SAPGUI
  5. Scripting
  6. LSH and Distribution

 

Patch Installation Server

 

If you are continuing on from the previous step (SAPGUI Installation Server Part 2 – Initial Installation), then the Installation Server Administration Tool will be automatically launched for you when you click Close on the Installation and Update Tool.  If you are returning to this step at a later time, you can launch the tool manually on your workstation by navigating to your server share:

  • \\server\sapgui
    • Setup

 

From there, execute the program:

  • NwSapSetupAdmin.exe

 

You will get to know this program very well.  It is important to execute it from the location in your Installation Server share, not from the installation files you previously extracted to your local hard drive.

 

 

When you first launch it, you will notice in the title bar that it names the Installation Server that you are working in, so you can confirm that you are in the right place.  You will initially see a list of SAP frontend components that are available on your Installation Server.  Above that are several tool buttons.  Click Patch Server.

 

The Patch Installation Wizard will open.

 

 

Click Next and then click Browse.  A browse window will open.  Navigate to the location where you stored the two patches you downloaded earlier (as part of SAPGUI Installation Server Part 1 – Getting Started), and select the SAPSETUP patch.

 

 

Click Open.

 

 

Click Next.  The tool will then validate the patch.

 

 

If this is an established Installation Server already being used by end users, then you should not proceed during business hours or at a time when users may be installing or updating their SAPGUIs.  If this is the initial configuration of the Installation Server, however, then you are so far the only user.  Click Next.

 

The tool will close NwSapSetupAdmin and apply the patch.  When it’s finished, you will see a success message.

 

 

Leave the checkbox checked and click Close.  The Installation Server Administration Tool will reopen.  You aren’t done patching, however, as so far you have only patched the infrastructure of the server, and not any of the products.  As before, click on Patch Server, then Next.  This time, browse to the GUI Core patch you downloaded earlier.

 

 

This time, the patch will take longer to apply.

 

 

When the patch is complete, you are once again returned to the Installation Server Administration Tool.  Your Installation Server and the core SAPGUI product are now up-to-date, but in order to make it easier on your end users and yourself, you will now want to create a Package.  That is the subject of the next installment in this series.

 

Part 4 – Package Creation

This is the fourth of a six-part series covering initial download, server installation, configuration of scripted packages for a fine level of workstation control, and distribution to clients.  We will also cover how to maintain central control of the SAP Logon configuration, and we’ll explore some options that may help ease the administrator’s burden.

As parts of this process are likely already familiar to many of you, I have broken it up into stages.  Please feel free to jump to the sections most relevant for you.  If you are setting up an Installation Server for the first time, however, I recommend you start with SAPGUI Installation Server Part 1 – Getting Started and move sequentially through the steps.

In Parts 1 through 3 we downloaded all our required files, installed our Installation Server, and brought it up-to-date with the latest patches.  Now we’ll setup our first Package that predefines the components to actually be installed on end user workstations, and we’ll set up the first SAPGUI, the administrator’s own.

  1. Getting Started
    1. Includes download of all required files
  2. Initial Installation
  3. Patching
  4. Package Creation (this document)
    1. Includes initial installation of the administrator’s SAPGUI
  5. Scripting
  6. LSH and Distribution

Package Creation

Create Package

If you are continuing on from the previous step (SAPGUI Installation Server Part 3 – Patching), you are already in the Installation Server Administration Tool.  If not, and you are returning at a later date, from your workstation execute:

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

The purpose of the Package is to bundle the appropriate SAP Frontend components required for your installation into a single choice, making it easy for users to select (or for you to push).  You can have multiple Packages on your Installation Server, and users can install multiple Packages on their workstations, if that is appropriate for them.  Packages can share components.  Packages can also have pre- and post-install scripts associated with them that allow you to control other aspects of the SAPGUI workstation environment, such as which SAP Logon connections will appear for the user to choose.

In this example, we want to distribute a basic set of commonly used SAP Frontend components, so we will call the package Basic.  In the Installation Server Administration Tool (NwSapSetupAdmin), switch to the Packages tab, and click the button New Package.

The Package Creation Wizard starts.

Click Next.  On the next screen, choose the components you require.  In this example, we are choosing:

  • SAP GUI
  • SAP Logon
  • GUI XT
  • SAP Automatic Workstation Update
  • SNC Client Encryption

You might choose alternative components, but at a minimum you should choose SAP GUI and either SAP Logon or SAP Logon Pad (the difference is that SAP Logon allows users to create and edit connection entries, whereas SAP Logon Pad does not — it is read-only.  In our example, we will distribute a predefined set of connection entries that will not be changeable for the user, but we will allow them to create their own additional entries as well, so we are not choosing the read-only SAP Logon Pad).

When you have made your selections, click Next.  On the next screen, enter the name for your Package.

Click Next.  On the next screen, you must give the value to be used in command-line switches for this Package.  By default, it will be the same as your Package name, minus any spaces, and it is usually best to leave it that way.

Click Next, and the Package will be quickly created.

Click Close and you will be returned to the Installation Server Administration Tool main page.  Under the Packages tab you will now see your Package listed, and if you expand it you will see the hierarchy of components.  To the right, under the Package Configuration tab (not ‘Configure Packages’ as mistakenly referenced in the wizard), you’ll see some general information about the Package, including that it’s currently at Version 0.  This is where you will add scripting to the Package later, but first you need another tool on your workstation:  your own SAPGUI.

Install Administrator SAPGUI

Besides defining which components will be installed on client workstations, another benefit of using Packages to distribute SAPGUI is including predefined SAP Logon Connection entries so that users will not need to know how to configure connections to your servers on their own.  Before you can set up those predefined connections, however, you need a tool to define your own connections as a template.  It is possible to manually edit INI and XML files to do this, but it’s much easier to use SAP Logon itself as the configuration editor.  That means you now need to install SAPGUI on your own workstation, and you might as well use the Package you just created to do it.

Close NwSapSetupAdmin, and from the same folder (\\server\sapgui\Setup) execute:

  • NwSapSetup.exe

The SAP Front End Installer opens.

Click Next.  The list of available individual components on your Installation Server appears.

Click the link for Predefined packages.  Now your Package will appear instead, and if you expand it you can verify the components included.

The checkbox for your Package will not be checked by default, so you must click to select it (ensure the checkmark appears in the box).  When you are ready, click Next.

The install will take a few minutes.  Look for the success message when complete.

You now have a working SAPGUI on your computer with the components you defined in your Package.  However, your SAP Logon Connections folder is still empty at this point.  You could manually addthe connections, but don’t do that just yet.  Instead, you are going to start SAP Logon with a special command-line switch that will allow you to create and save connections in a remote configuration file instead of your local file.  This, and writing scripts to configure other clients to use that central configuration file, will be the subject of the next part in the series.

 

Part 5 – Scripting

This is the fifth of a six-part series bringing us from initial download and installation through to scripted packages and distribution to clients.  In this part we’ll cover how Package Event Scripts can help maintain central control of the SAP Logon configuration as well as explore some SAPGUI customizing.

As parts of this process are likely already familiar to many of you, I have broken it up into stages.  Please feel free to jump to the sections most relevant for you.  If you are setting up an Installation Server for the first time, however, I recommend you start with SAPGUI Installation Server Part 1 – Getting Started and move sequentially through the steps.

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

Scripting

If you are continuing on from the previous step (SAPGUI Installation Server Part 4 – Package Creation), then you have created a Package called Basic with several SAPGUI components in it, and you have installed SAPGUI on your own workstation using the Basic Package.  You don’t yet have any entries in SAP Logon, however.  Now it’s time to create those entries in a central configuration file that you can share with your users.

Create Shared Configuration Files

The connection data for SAPGUI is stored in a file called saplogon.ini, and additional data about how connections are organized and displayed in SAP Logon is stored in SapLogonTree.xml.  Depending on options you set within SAPGUI or SAP Logon, there may be other configuration files as well, but these two are the ones of primary concern.  By default, when SAPGUI 7.30 (or 7.20) is installed on a Windows 7 system, these two files will be created in:

  • C:\Users\<username>\AppData\Roaming\SAP\Common

On Windows XP (from which hopefully by now all of you have migrated away, right?) the path would have been:

  • C:\Documents and Settings\<username>\Application Data\SAP\Common

Older SAPGUIs used a different storage mechanism, and so if you upgrade from one of these to 7.30, saplogon.ini may still be found in the old locations (or may be copied from the old location to the new location).  SAPGUI 7.10 stored saplogon.ini in the program’s installation folder (C:\Program Files\SAP\FrontEnd\SAPGUI (on 32-bit; for 64-bit machines substitute Program Files (x86) for Program Files), while SAPGUI 6.40 and earlier stored it in C:\Windows.

In many organizations, the administrator would create a default saplogon.ini and use scripting to push it to the client workstation in the appropriate folder during the SAPGUI installation.  This worked well for new installs, but it didn’t help much with upgrades, or for distributing changes when the server landscape underwent a change.  Then the administrator would be required to use new scripts to push out new copies of the file, which would overwrite any customization the end user may have made.  Furthermore, the end user might change the file inadvertently, modifying or deleting an entry unintentionally, invariably resulting in a call to the Help Desk.  In this case, the administrator might have to resort to walking the user through editing their own settings to get things working again.

SAPGUI 7.30 offers a better way.  It is now possible to store saplogon.ini and SapLogonTree.xml in a shared location on a server and configure SAP Logon on the workstation to use these shared files instead of the local ones.  This means that all users are always using one version of the truth as defined by you, the system administrator.  If you need to distribute a landscape change, you only need to edit one set of files in one location, and all users will immediately see the change without having to do anything on their workstations.

We’ll discuss how to configure SAP Logon to use the shared files in a moment, but first we need to set up the server location and create the two configuration files to put there, and the first part of that is to configure our own SAPGUI, just installed on our workstation.

Edit Services File (optional)

If you use Logon Groups for message server-based load balancing or for directing different user groups to different application servers (configured via transaction code SMLG), then there are one or more additional entries which you will need to make to the services file which are not made by NwSapSetup during the base SAPGUI install.  Later you will use your Package Event Scripts to push this change to your users, but first you must make the change manually to your own workstation.

If you don’t use Logon Groups, you can skip this step.

On your workstation, navigate to:

  • C:\Windows\System32\drivers\etc

There you will find a text file called services.  You can examine it with Notepad, but in order to edit it in Windows 7 you must first open Notepad with Administrator privileges.  This is because services is a protected operating system file, and making a mistake with it could negatively impact Windows (as well as SAPGUI) operation.  Windows XP does not have this restriction, so you may simply open the file with Notepad and edit away.

In Windows 7, click Start… All Programs… Accessories and then right-click Notepad.  In the context menu choose Run as administrator and confirm Yes at the prompt.  In Notepad, choose File… Open and navigate to the services file you located earlier.

Be careful not to change any of the lines in the file.  Scroll to the end, where you will see numerous lines added by the SAPGUI install.  At the end of the list, add a new line something like the following:

sapmsSID     36nr/tcp

In this example, SID represents the System ID of your load-balanced system and nr represents the System Number.  So, if your System ID is PRD and System Number is 00, the line will be

sapmsPRD     3600/tcp

For the blank space between ‘sapmsSID’ and ’36nr/tcp’ you can use either a TAB or hit the SPACEBAR a few times; it doesn’t matter.  Be sure to hit ENTER at the end of the line, so that the last line of the file is a blank line.

So, when you’re done, the last few lines of your services file may look something like:

sapgw98     3398/tcp

sapgw99     3399/tcp

sapmsPRD     3600/tcp

Save the file.

Create CustomerFiles Folder

Now you need to create a folder on your server that your users will have read-only access to.  I recommend putting this folder under the root of your Installation Server share, as your users already have this access there.  Furthermore, I recommend calling the folder CustomerFiles (exactly like that) for the very specific reason that later, if and when you make a self-extracting single-file-installer, such a folder will be automatically included in the single-file-installer.  If you call the folder something else, such as ConfigFiles (as some of the documentation shows in examples), it will not work with single-file-installers.

So, navigate to your Installation Server at \\server\sapgui, and create CustomerFiles there.  When you are done, the contents of your sapgui share will look something like this:

Start SAP Logon with Command-Line Switch

The next step is to start SAP Logon in such a manner that it will create a new set of configuration files in the CustomerFiles folder.  You will want to have an easy way of doing this whenever you need to make changes to the published SAP Logon configuration, so I recommend making a small batch program and saving it on your Desktop.

Right-click on your Desktop and choose New… Text Document.  Rename the new document to saplogon_ini_file.cmd and confirm the prompt for changing the file extension.  Right-click on saplogon_ini_file.cmd and choose Edit.  Put the following lines into your new batch program:

C:

cd \Program Files (x86)\SAP\FrontEnd\SAPgui

saplogon.exe /ini_file=\\server\sapgui\CustomerFiles\saplogon.ini

If you are working on a 32-bit machine, change Program Files (x86) to Program Files.  Remember to substitute your server’s hostname for server.

Save your changes and close the editor.  Now you have an easily-accessible and quick way of starting SAP Logon in such a way that you will be able to edit the configuration.  Let’s do that now.  Double-click your batch file to execute it and start SAP Logon.

Create Connection Subfolders and Entries

Although it is optional to do so, if you have numerous SAP systems, or systems of different types or purposes that can be logically grouped, then you may want to make the organization easier for your users by creating an hierarchical folder structure for the connections.  However, you can also just create a flat structure of all relevant systems without any subfolders.

In SAP Logon, highlight the Connections folder.  Right-click it and choose Add new subfolder.

Give the new subfolder an appropriate name and click OK.

Single Application Server

To add a direct connection to a specific application server, or a system without any load balancing, select your new subfolder and click on the New icon.

The Create New System Entry window will open.  Click Next.

On the next screen, set Connection Type to Custom Application Server, type in an appropriate system name to be displayed to users in the Description field, and fill in the relevant connection information for Application Server, Instance Number, and System ID.  If a SAProuter sits between your users and the server, fill in the information needed for that; otherwise, leave SAProuter String blank.

Optionally, you may check the box for Use this page as the first page for subsequent entry creations to skip the first screen next time.  I recommend using fully-qualified domain names for the Application Server, but depending upon your local network configuration it will usually work just as well with an unqualified hostname.  Click Finish.

Load-Balanced Group

You are now back in the SAP Logon window.  If you additionally (or instead) need to set up a load-balanced system connection, click on New again just as before to launch the Create New System Entry dialog.  On the System Connection Parameters page, this time you will make a different selection for Connection Type, and as a result you will have some different fields to fill in.

For Connection Type select Group/Server Selection.  Enter an appropriate Description, type in the System ID, and give the fully-qualified domain name (or simple hostname) for the Message Server of your load-balanced system group.  Click the drop-down arrow for Group/Server and you should see a list of the defined logon groups as well as the individual application servers that make up the system.  Choose the group you intend to use (previously created in SMLG).

You should now see the systems and/or groups you defined in SAP Logon.

Close SAP Logon to save your changes to the configuration files.

Sample Configuration Files

You should now see two files created in your CustomerFiles folder on the server:

  • saplogon.ini
  • SapLogonTree.xml

There is nothing more you need to do directly with these files, but if you open them you will see, among other things, entries similar to the following:

saplogon.ini

[Server]

Item1=public

Item2=qas-server.domain.org

[Description]

Item1=Production

Item2=Quality Assurance

[Address]

Item1=xx.xx.xx.xx

Item2=

[MSSysName]

Item1=PRD

Item2=QAS

[MSSrvName]

Item1=prd-msgsvr.domain.org

Item2=

[MSSrvPort]

Item1=sapmsPRD

Item2=

Notice that last group for MSSrvPort, and how the Item entry for your load-balanced group uses the TCP port name that incorporates the System ID.  This port name is then referenced to the entry you manually created in your services file to find the actual TCP port number (in this example, and in most systems, it would be 3600).

SapLogonTree.xml

<?xml version=”1.0″ encoding=”UTF-8″?>

<!– SAPGUI for Windows 7300 4 29 5 2014 10:1:27 Pacific Standard Time –>

<SAPTREE version=”7300.3.8.1085″>

<Files>

<File name=”saplogon.ini” type=”Connections”/>

<File name=”sapshortcut.ini” type=”Shortcuts”/>

</Files>

<Nodes>

<Favorites name=”Favorites” uuid=”…” expanded=”1″> </Favorites>

<Shortcuts name=”Shortcuts” uuid=”…” expanded=”1″> </Shortcuts>

<Connections name=”Connections” uuid=”…” expanded=”1″>

<Node name=”ERP” uuid=”…” expanded=”0″ memo=””>

<Item name=”Quality Assurance” type=”connection” uuid=”…”/>

<Item name=”Production” type=”connection” uuid=”…”/>

</Node>

</Connections>

</Nodes>

</SAPTREE>

From this you can see how the XML file defines the folder structure you see in SAP Logon.

How to Use Server Configuration Files

Now that you have configuration files to share, how do you configure your users’ SAPGUIs to use them?  One way is via SAP Logon Options, which is accessed by clicking the icon in the upper left corner of SAP Logon, then choosing Options in the drop-down box.

On the screen that opens, drill down to SAP Logon Options… Server Configuration Files and then in the field XML Configuration File on Server type in the path to your XML file:  \\server\sapgui\CustomerFiles\SapLogonTree.xml.

However, you don’t want to run around to every user’s workstation and configure that option, so there’s a better way.  This parameter, like most of the others that can be set via SAP Logon Options or SAP GUI Options, is maintained in a registry setting, and registry settings can be configured by Package Event Scripts.

Create Package Event Scripts

Open up the Installation Server Administration Tool (NwSapSetupAdmin):

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

Switch to the Packages tab, select your Package, and switch to the Package Configuration tab.  Toward the bottom of the screen you will see a series of tabs labeled On Installation Start, On Installation End, On Uninstallation Start, On Uninstallation End, On Update Start, and On Update End.  There is also a small link to the right just above them for Expand Editor.  Click that to make it a little easier to work in the script editors.

As the tab names imply, here you can enter scripts that will execute during the install (or uninstall or patch update).  Upgrades execute the ‘install’ scripts, whereas patch updates execute the ‘update’ scripts.  For now, we will focus on Installation.  You can have two scripts, one that will execute nearer to the beginning of the installation, and one that executes at the end as a wrap-up.  Depending on the functions you intend to execute, one or the other may be more appropriate.

Package Event Scripts are essentially VBscript and follow VBscript conventions.  Some additional shell options have been preset by the install program, which unfortunately are not well documented, but you can get an idea of the possibilities from the SAP Setup Guide located at the root of your Installation Server share, in chapter 3.6.2, or by clicking the link for Insert Script Sample and examining (and adapting) the code snippets found there.  The samples include functions for adding custom logging to the setup log file, checking files and registry keys for existence, manipulating files and registry keys, and so forth.  Much of the scripts you will see below are adapted from these script samples.

On Installation Start

First we’ll look at some code to execute at the beginning of your installation.  The purpose of this piece of code is to duplicate the manual work you did earlier on your own workstation, editing the services file to put the logon group TCP port entry into it.  Again, if you don’t use logon load balancing or logon groups, then you don’t need this script at all.  This is adapted straight from the script examples.

The script begins by writing to the setup log file.  Every time we write to the log we prefix the line with “Event:  ” as a way of making our custom log entries searchable.  We let anyone reading the log know that this is where the “On Installation Start” script is running.  We include some comments in the script to let future sysadmins know what’s going on, then write a log entry to say exactly what we’re doing.  We resolve the %WinSysDir% environment variable and add the rest of the path to the services file and put that into the strFile variable.  Here, the sapsetup program provides some useful text file parsing utilities, and we make use of those.  We look in the services file to see if a line with our desired entry of “sapmsPRD” exists already.  If it does, just to be safe, we replace the line entirely, just in case it exists with an incorrect TCP port number.  If it doesn’t exist, we add the line.  That whole part is encapsulated in an If… Then structure as a way of capturing any error in finding the services file.

——————-

NwEngine.Context.Log.Write “Event:  On Installation Start”

‘Check whether a line containing the string “sapmsPRD” exists.

‘If so, replace that line with

‘”sapmsPRD 3600/tcp”

‘otherwise simply append the new line to the end of the services file.

NwEngine.Context.Log.Write “Event:  Appending or replacing lines in the services file”

strFile = NwEngine.Variables.ResolveString( “%WinSysDir%\drivers\etc\services” )

Set objTextFile = CreateObject(“NwSapSetupATLCommon.TextFileParser”)

If objTextFile.Parse( strFile ) Then

     NwEngine.Context.Log.Write “Event:  Modify the file ” & Chr(34) & strFile & Chr(34)

     If objTextFile.DoesStringExist( “sapmsPRD” ) Then

          objTextFile.ReplaceLineEx “sapmsPRD”, “sapmsPRD 3600/tcp”

     Else

          objTextFile.AppendLine “sapmsPRD 3600/tcp”

     End If

     objTextFile.Save( strFile )

Else

     NwEngine.Context.Log.WriteWarning “Event:  Could not open the file ” & Chr(34) & strFile & Chr(34)

End If

——————-

That’s it.  That’s the entire script.  You can add more if you wish, but this script will execute as it stands.

On Installation End

Now we get to the meatier part of our scripts.  After the installation is essentially complete, we want to configure the user’s SAP Logon to use our shared server configuration files created earlier.

This script first checks to see whether this option has already been set in the registry hive HKEY_CURRENT_USER, as that setting will take precedence if it exists.  We don’t want that, we want all users of the workstation to use the same shared files, so we want to set the key in HKEY_LOCAL_MACHINE and make sure it isn’t set in HKEY_CURRENT_USER.  So, the first step is to check if it’s there, and if found, delete it.

Note that in Package Event Scripts, as in VBscript, you can abbreviate the registry hives to HKCU and HKLM.

Next we need to know whether we are running in a 32-bit or 64-bit version of Windows, as that influences the correct path to the registry key in HKLM (but not in HKCU).  Because SAPGUI is 32-bit software, if it is installed in 64-bit Windows, it will be registered, along with all other 32-bit software, in HKLM\Software\Wow6432Node.  If we are in 32-bit Windows, it will be directly under HKLM\Software.  We check WMI (Windows Management Instrumentation) to determine the AddressWidth with a pair of functions that return a TRUE or FALSE result.  Based upon the result, we set a variable for our registry path appropriately.  This particular method of determining the OS address width is based upon some ideas developed by DavidRR at StackOverflow (User DavidRR – Stack Overflow).

Having set our registry path appropriately, we set the registry value HKLM\Software<\Wow6432Node>\SAP\SAPLogon\Options\ConfigFileOnServer to point to \\server\sapgui\CustomerFiles\SapLogonTree.xml, and we’re done!  If we want to set other registry values, we would do so here, but this was our primary objective, so let’s take a look at the code.

——————-

NwEngine.Context.Log.Write “Event:  On Installation End”

‘Redirect SAPLogon to server configuration file but allow local custom entries

If NwEngine.Shell.RegValueExist(“HKCU\Software\SAP\SAPLogon\Options\ConfigFileOnServer”) Then

     NwEngine.Context.Log.Write “Event:  Deleting Previous HKCU ConfigFile Value”

     NwEngine.Shell.DeleteRegValue(“HKCU\Software\SAP\SAPLogon\Options\ConfigFileOnServer”)

End If

Function Is32BitOS()

     Const Path = “winmgmts:root\cimv2:Win32_Processor=’cpu0′”

     Is32BitOS = (GetObject(Path).AddressWidth = 32)

End Function

Function Is64BitOS()

     Const Path = “winmgmts:root\cimv2:Win32_Processor=’cpu0′”

     Is64BitOS = (GetObject(Path).AddressWidth = 64)

End Function

If Is64BitOS Then

     NwEngine.Context.Log.Write “Event:  64-bit OS detected”

     strRegPath = “HKLM\Software\Wow6432Node\SAP\”

ElseIf Is32BitOS Then

     NwEngine.Context.Log.Write “Event:  32-bit OS detected”

     strRegPath = “HKLM\Software\SAP\”

End If

strRegConfigValue = strRegPath + “SAPLogon\Options\ConfigFileOnServer”

strXmlFile = NwEngine.Variables.ResolveString(“%SapSrcDir%\CustomerFiles\SapLogonTree.xml”)

NwEngine.Context.Log.Write “Event:  Pointing SAPLogon to Server Configuration Files”

NwEngine.Shell.SetRegValue strRegConfigValue, “REG_EXPAND_SZ”, strXmlFile

——————-

If you have multiple Installation Servers, each with its own different CustomerFiles folder and different saplogon.ini settings, the user will be pointed at the saplogon.ini within the Installation Server being used, even without changing a line of code in the script.  That’s where the %SapSrcDir% environment variable comes into play.

Optional Registry Settings for Interface Layout

Now that you have a method for setting registry values during the installation, there are many other settings which you might choose to preconfigure.  For instance, you might choose to resize the SAP Logon window and reposition the column widths to make it a bit more user-friendly out of the box.  You might choose to maximize the SAPGUI window the first time it’s opened.  You might want the Transaction Code entry box to be open by default, and the system information in the status bar to show.  For users who frequently have sessions open to multiple systems, it can be useful for the Windows Taskbar to display some system information when the mouse hovers over it.  So, here are some registry settings, and the Package Event Script code to set them, that I find useful for an initial SAPGUI install.  Note that while I would put the script above for the config file location into both On Install and On Update scripts, the following is something I would only put into On Install.  Once SAPGUI is installed, users are likely to customize it to their own liking, so you don’t want to overwrite their customizations with your defaults every time you push out a patch.

——————-

‘Configuring window size and SAPLogon option initial defaults

NwEngine.Context.Log.Write “Event:  Setting Registry Values for SAPLogon Options”

strRegSapFrontPath     = “HKCU\Software\SAP\SAPGUI Front\SAP Frontend Server\”

strRegSapLogonPath     = “HKCU\Software\SAP\SAPLogon\Settings\”

strRegTaskbarTitle    = strRegSapFrontPath + “Administration\ShowAdditionalTitleInfo”

strRegCmdLine        = strRegSapFrontPath + “Customize\ShowCmdLine”

strRegStatusBar        = strRegSapFrontPath + “Customize\Statusbar.Layout”

strRegShowKeys        = strRegSapFrontPath + “Customize\Dropdown.ShowKey”

strRegSortKeys        = strRegSapFrontPath + “Customize\Dropdown.SortKey”

strRegGuiWindow        = strRegSapFrontPath + “Window\Maximize”

strRegSplitPos        = strRegSapLogonPath + “SplitterPosition”

<pstyle=”padding-left: 30px;”>strRegBottom        = strRegSapLogonPath + “Connections\Bottom”

strRegCol1        = strRegSapLogonPath + “Connections\ColumnWidth1”

strRegCol2        = strRegSapLogonPath + “Connections\ColumnWidth2”

strRegCol3        = strRegSapLogonPath + “Connections\ColumnWidth3”

strRegCol4        = strRegSapLogonPath + “Connections\ColumnWidth4”

strRegCol5        = strRegSapLogonPath + “Connections\ColumnWidth5”

strRegCol6        = strRegSapLogonPath + “Connections\ColumnWidth6”

strRegCol7        = strRegSapLogonPath + “Connections\ColumnWidth7”

strRegLeft        = strRegSapLogonPath + “Connections\Left”

strRegRight        = strRegSapLogonPath + “Connections\Right”

strRegTop        = strRegSapLogonPath + “Connections\Top”

strRegNode        = strRegSapLogonPath + “LastSelectedNodeKey”

‘SAP Logon Options, Interaction Design, Visualization 2, Show system name in taskbar button

NwEngine.Shell.SetRegValue strRegTaskbarTitle, “REG_DWORD”, 1

‘Open Transaction Code Entry Field

NwEngine.Shell.SetRegValue strRegCmdLine, “REG_DWORD”, 1

‘Display Information in Status Bar

NwEngine.Shell.SetRegValue strRegStatusBar, “REG_DWORD”, 1

‘Interaction Design, Visualization 1, Show keys within dropdown lists

NwEngine.Shell.SetRegValue strRegShowKeys, “REG_DWORD”, 1

‘…Sort by keys within dropdown lists for most efficient keyboard input

NwEngine.Shell.SetRegValue strRegSortKeys, “REG_DWORD”, 1

‘Maximize SAPGUI window

NwEngine.Shell.SetRegValue strRegGuiWindow, “REG_DWORD”, 1

‘Set SAPLogon window and column options

NwEngine.Shell.SetRegValue strRegSplitPos, “REG_SZ”, “19”

NwEngine.Shell.SetRegValue strRegBottom, “REG_SZ”, “523”

NwEngine.Shell.SetRegValue strRegCol1, “REG_SZ”, “195”

NwEngine.Shell.SetRegValue strRegCol2, “REG_SZ”, “25”

NwEngine.Shell.SetRegValue strRegCol3, “REG_SZ”, “37”

NwEngine.Shell.SetRegValue strRegCol4, “REG_SZ”, “206”

NwEngine.Shell.SetRegValue strRegCol5, “REG_SZ”, “26”

NwEngine.Shell.SetRegValue strRegCol6, “REG_SZ”, “164”

NwEngine.Shell.SetRegValue strRegCol7, “REG_SZ”, “25”

NwEngine.Shell.SetRegValue strRegLeft, “REG_SZ”, “169”

NwEngine.Shell.SetRegValue strRegRight, “REG_SZ”, “1059”

NwEngine.Shell.SetRegValue strRegTop, “REG_SZ”, “213”

NwEngine.Shell.SetRegValue strRegNode, “REG_SZ”, “de4aeca7-6c46-49f8-bf55-ba5ae43537ca”

——————-

A note about that last line with the UUID (“de4ae…” etc).  This line sets the cursor focus when SAP Logon is opened into the “ERP” folder we created earlier.  You will need to open your SapLogonTree.xml file and look up the correct UUID for the node you want to have as the initial focus and use that in the place of the example I gave here.

Package Event Script Wrapup

Once you have entered your scripts, you just need to click on the Save button.

The Package Version will increment by 1 when you do this.  Note that any clients (such as your own workstation) installed using this Package will now auto-update if the Package includes SAP Automatic Workstation Update (which our example does), either the next time the AWUS service starts, or within the defined interval for checking for updates (24 hours by default).  However, such clients will only run the On Update scripts, not the On Install scripts.

Your Package, including scripts, is now fully defined.  All that remains is to optionally configure Local Security Handling and then distribute the installation to clients.

 

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.

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

 


免责声明！

本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系本站邮箱yoyou2525@163.com删除。



猜您在找 Teamcenter10 step-by-step installation in Linux env-Teamcenter Server Installation 免密自动登陆SAPGui libvirt Installation Dynamics CRM 2013 installation VirtualBox Guest Additions installation The Installation and Compilation of OpenCASCADE Installation-Clash (Ubuntu) The Apache Tomcat installation at this directory is version 8.5.24 Tomcat 8.0 installation is expect Plugin 'Lombok Plugin' is incompatible with this installation Plugin 'Scala' is incompatible with this.installation
 
粤ICP备18138465号  © 2018-2025 CODEPRJ.COM