SAPGUI Installation Server Part 5 - Scripting

[Matt_Fraser]

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

• Scripting

• Create Shared Configuration Files
  
  
  
  • Edit Services File (optional)
  
  
  • Create CustomerFiles Folder
  
  
  • Start SAP Logon with Command-Line Switch
  
  
  • Create Connection Subfolders and Entries
    
    
    
    • Single Application Server
    
    
    • Load-Balanced Group
    
    
    
    
  
  
  • Sample Configuration Files
    
    
    
    • saplogon.ini
    
    
    • SapLogonTree.xml
    
    
    
    
  
  
  • How to Use Server Configuration Files
  
  
  
  


• Create Package Event Scripts
  
  
  
  • On Installation Start
  
  
  • On Installation End
  
  
  • Optional Registry Settings for Interface Layout
  
  
  • Package Event Script Wrapup
  
  
  
  

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.

<--->

Continue on to SAPGUI Installation Server Part 6 - LSH and Distribution.

[Former Member]

Hi Matt,

I was wondering if you know whether 740 will make us of the CustomerFiles single location for the new versions of the ini file info.

thanks,

Debbie

[Matt_Fraser]

Hi Debbie,

I haven't had the opportunity to play with 740 yet, so I can't really speak to this. I believe that it will, though, at least if you install it without including NWBC in the same install.

Regards,

Matt

[Former Member]

Thanks, Matt!

I will install w/o NWBC and find out.

Debbie

[Former Member]

Dear Matt,

I would like to thank you for this excellent blog. It is detail to the t.

Good work and thanks again !

[Johan_sapbasis]

Hi Matt and everyone,

This would give some additional assistance where necessary.

This one points to SAPGUI administration 740 patch level 3 which includes all your necessary commands/switches for whatever you need.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40f5a092-743b-3210-e681-ed1dc9fbd...

This one points to SAPGUI administration 730 compilation 3

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/a0b08d62-769b-2f10-8fbe-9db5efe92...

Thanks to melanie.reinwarth for publishing these links for us.

@Matt - I have used your basic scripting option will test my installation shortly I know in my case I had to disable sound as well as the corbu styled icons. Tx for your very good documenation.

Johan

[Former Member]

Nicolas,

Is the last URL reference  supposed to be 7.30?  That is what the URL is brining up.  Thanks.

Dan Mead

[Johan_sapbasis]

yes thanks for the note it is corrected now, Matt apologies for all the scn emails you are receiving haha

[Matt_Fraser]

No worries. That's why I turned off email notifications. :wink:

[Johan_sapbasis]

Hi all,

I just rolled out

SAP GUI 740 Patch Level 3 Hotfix 1 File version: 740.1.3.1104 in conjunction with NWBC 5.0 Patch level 7.

Used Matt's very good scripts as is, and just substituted 2 values.

In the guide I previously posted the link to SAP GUI 740 Administration Guide pg 52.

XML Configuration File on Server

Here there are two options:

Configuration with INI files (SAP UI Landscape inactive)

[HKEY_CURRENT_USER\Software\SAP\SAPLogon\Options]

“ConfigFileOnServer” (REG_EXPAND_ SZ) [Default: ””] {valid path to the correct configured XMLFile}

SAP UI Landscape active (NWBC 5.0 or higher is installed)

[HKEY_LOCAL_MACHINE\SOFTWARE\SAP\SAPLogon\Options]

“LandscapeFileOnServer” (REG_EXPAND_ SZ) [Default: ””] {valid path to the correct configured

XML-File}

For more information on the configuration when using NWBC together with SAP GUI, see the SAP

GUI for Windows Installation Guide, chapter 2.2 ‘Configuration with SAP NetWeaver Business

Client’,

I just changed the ConfigFileOnServer to LandscapeFileOnServer and SapLogonTree.xml to SAPUILandscape.xml

Hope this helps someone. Matt thanks again for being an inspiration on SCN I really need to try and be more involved.

Johan

[Matt_Fraser]

Good work.

[Former Member]

Can I add my thanks for this very useful series of guides - Especially number 5!!

Geoff Stephenson

[raoul_serra2]

Not sure if it would be the right place to comment or ask a question related to it...

I was wondering if the gui installation server could also be used only to execute the start VBS script without having a real package t odeploy, for example if gui is already installed, it would be nice to have a second packge created with no components to deploy but with a script that would do the configuration only and deploying new INI or XML files.

I did try to create a package wit hno components but then when it runs it does not start the execution of the scripts, not even the one at "isntall start"

If the scripts written for the gui installation server would have to be converted into independent VBS scripts it would need some work and not all could be accomplished exactly in the same way

Thanks already to anyone who will comment further or give some good hints.

[Matt_Fraser]

Hi Raoul,

I've had this same idea, of using "empty" packages as a means of triggering execution of scripts, but hadn't actually tried it. Sounds like it doesn't actually work, from your experiments? Did you double-check that the test client had the "package" installed first, so it would look for updates? And did you increment the package version number?

Otherwise, I have used a simple VBscript as a "Reset Defaults" tool. When users call in to say that their GUI isn't working correctly, I start by sending them the link to the script and asking them to execute it. In 90% of cases, that fixes the problem. For the remainder, 90% of what's left is fixed by an uninstall and reinstall (so I have an uninstall script ready to go, which wipes all settings from the PC after removing the GUI). But, you're right, by running these scripts outside of the Installation Server setting, care has to be taken that it is the user and not a helpful PC tech who is logged on, and local administrative rights can come into play.

[raoul_serra2]

Hello Matt, Thanks for your reply, my first attempt was using "On Install Start/End" and obviously nothing did happen, now I'm using the "On Update" but with a content in the package and that is working fine... will try today the On Update without content... If you have an example of VBScript doing what usually we do in those NW event scripts I would be interested (copying ini and xml files, updating etc\services file, adding/changing registry keys) ... I'm trying to do the same as what you already do, having scripts for restting the defaults with some parameters set as the Company globally did want and also full clean-up  removing the gui, uninstall... as you are saying inside installation server it would be more comfortable, no admin rights problems

[Former Member]

Many thanks for the new additions to this topic.

Wish there was an on-line course which went into more complex scripting. 

We have both Technical Users and Standard Users which get a saplogon.ini file update.  Our Active Directory Admins pushed out an update which overwrote the technical user's customized ini file.  There is probably a way script an if statement so it appends information instead of replacing the file.

Complex scripting isn't my skill set but I can imagine our new ASCS project could benefit from a simple find and replace script.

Thanks to those who keep posting examples.

Cheers,

Dan Mead

[Matt_Fraser]

Daniel, I agree about the scripting. I don't do this often enough to consider myself any kind of expert. I rely heavily on MSDN:

VBScript Language Reference:

https://msdn.microsoft.com/en-us/library/d1wf56tt%28v=vs.84%29.aspx

Win32 Provider:

https://msdn.microsoft.com/en-us/library/aa394388%28v=vs.85%29.aspx

Methods (Windows Script Host):

https://msdn.microsoft.com/en-us/library/2x3w20xf%28v=vs.84%29.aspx

FileSystemObject Methods:

https://msdn.microsoft.com/en-us/library/6tkce7xa%28v=vs.84%29.aspx

StdRegProv class:

https://msdn.microsoft.com/en-us/library/aa393664%28v=vs.85%29.aspx

As for the saplogon.ini files, I don't like storing them on enduser computers, so the method I outlined in the blog was to store them centrally on a server, then use registry settings to have the clients point to that central location instead of anything local. Not only does that avoid something nasty happening out of your control to the file on the local client, it also makes it much, much easier to update the settings globally. You just edit the one file, and everyone gets the change instantly.

[Matt_Fraser]

Raoul,

I'm just about ready to start a project here to upgrade our 7.30 SAPGUIs throughout the organization to 7.40 (yes, I know, I know, we're way late with doing this). When I've done that, I'll see about writing a blog on upgrading the Installation Server, but also, when I've validated that my SapResetDefaults script still works with 7.40, I'll post it up here.

I was just looking through my installation script and the resetDefaults script, and there's a clear progression in how my knowledge of VBScript improved. In the earlier script I used whatever tricks I could find online for things like figuring out if the user was running WinXP or Win7, and for whether it was 32-bit or 64-bit. In the later script, I still needed to find out those things, but I had figured out much cleaner methods using some of the functions in VBScript.

Since then, we no longer have users running XP, and now we're starting to get some users on Win10, so some of the needs have changed.

[raoul_serra2]

I will start to convert some of my NW scripts in the installation server into VBScripts, then I can even publish here as examples... thanks already for all the good URL links provided

[Former Member]

Hi Matt,

Thanks for information.  I have some vendors who come in through VPN and their business profiles restrict their access to specific areas to our backend systems and it varies by multiple business partners.

My preference is to create a package containing just updates to splogon.ini, services, and sapmsg.ini and not overwrite existing files and just append new content.  Compensating for 32-bit or 64-bit Microsoft OS releases as needed.

I am pushing to use the consolidated server option leveraging SAPUILandscape.xml but it hasn't been made a project of any importance by our management.

Page 26 on the new SAPSetup Guide SAPSetup 9.0 User Guide 2016-06-07 looks promising.

Cheers,

Dan Mead

[daniel_leal4]

The new SAPSetup Guide 9.0 from 2016-06-07 now includes a full documentation for the SAPSetup Visual Basic script objects. A very welcomed addition.

Link to this guide is available in Note 1587566.

Regards,

Daniel Leal

[Matt_Fraser]

It does indeed! I just recently discovered this myself while working on upgrading my Installation Servers to 7.40. And, this new guide can be found in the root folder of any 7.40 Installation Server installed or upgraded with NwCreateInstServer or NwUpdateInstServer.

Thanks, Daniel.

Cheers,

Matt

[daniel_leal4]

I am still trying to confirm, but it looks like you have to be in PL 9 of SAPGUI 7.40 to get the PDF Guide with the new scripting information, but it places a version of the document dated from May/12.  The link in the Note I mentioned above retrieves a version dated from June/07.  I do not know if there is another document or Note that always refers to the most current version of the SAPSetup Guide, or if indeed Note 1587566 is the official place.  Any idea?

By the way Matt, thank you very much for authoring this blog.  Has been very helpful for me, and I am sure for many others.

Daniel Leal

[Former Member]

Hi Matt,

I opened and incident with SAP on this and their response was that "there should be some kind of update to the package or the component., So that the script will run, otherwise if there is no correction in the packages or to the component then the script will not run."

So I rebuilt my package with your code in the "on Installation End" Tab and included core patch 9.  The update ran on my PC and laid down the patch 9 but did not update the saplogon.ini or SapLogonTree.xml.

Is there some sort of code checker for your script?

[Matt_Fraser]

Dan, if you were updating your workstation with the new patch, rather than installing the package for the first time, then the On Installation End script wouldn't run. Did you try putting your script into On Update End?

[Former Member]

Matt,

I have the script under both "On Installation End" and "On Update End".  I will remove it from on Installation End and rebuild to see if that makes any difference.

[Former Member]

Matt,

I just created a new build version with you vb script only in "On Update End".  The script updated SAP GUI 7/40 patch 2 to patch 9 and still didn't overwrite the existing saplogon.ini or SapLogonTree.xml.

I know I am doing something wrong just haven't figured it out.

Thanks for the help.

[former_member225288]

Dear Matt

I have to keep the NWBC configuration files "NWBCOptions.xml" and "NWBCOptions.xsd" central on the server shared drive.

Is it possible to distribute the XML link file to the end users (%ALLUSERSPROFILE%\SAP\NWBC\NwbcRemoteOptions.xml) via SAPGui Installation Server?

Thanks a lot!

Jurij

[Matt_Fraser]

Hi Jurij,

We don't use NWBC on desktops in my organization, so I haven't played with those options myself. We're only just migrating to GUI 7.40, but we're sticking with the traditional saplogon.ini and saplogontree.xml configuration for now.

However, you should be able to adapt the overall method described here to your requirements. Just be sure to pay close attention to the SAPGUI Installation Guide, especially the chapter for installation with NWBC, for the minor differences.

Cheers,

Matt

[Former Member]

Updated the GUI Server with SapSetup patch 79.  It had some sort of scripting Fix.  Still no success with replacing the saplogon.ini using a Single File Installer.

Dan Mead

[former_member352704]

Hello everyone,
Thank you for your contributions, I have been very helpful!

I have implemented SAP GUI Server and want to deploy it to all workstations and I have the following questions:

1- It is possible to include a script in an event such as "On Uninstallation" to uninstall the version currently installed in the workstation (SAP GUI 7.3) and later install the SAP GUI Server version (SAP GUI 7.40), all in the same process and Installation package? If you have any reference to this, I thank you.

2 - how can I see the workstations that are stored in the SAP GUI Server, taking into account the component "SAP Automatic Workstation Update"

3- Can I export the bookmarks of NWBC 5 and import them as favorites in the SAP GUI client?

I will be grateful for your comments and contributions.

 

[Matt_Fraser]

Hi Giovanny,

.

Thanks for your comments. With regard to your questions:

1. Including the uninstallation of the old GUI in the "On Uninstallation" script for the new GUI won't work, unfortunately. The reason for this is that the "On Uninstallation" script doesn't fire until the new GUI is pretty much completely installed. Usually you don't need to worry about uninstalling the old GUI, as the installation program will detect the old one and perform an upgrade. However, sometimes you may want to get a fresh start, and I certainly understand that. In that circumstance, you could potentially create a separate package that has nothing in it but an uninstallation script. Or you could write a VBscript that performs the uninstall -- this is what I did. Bear in mind that the basic /uninstall option on nwsapsetup.exe will still leave behind old registry entries and configuration files, which can impact the new installation. In that circumstance you'll want your VBscript to additionally seek out and remove those config files and registry entries, which means you'll need the script to run in "administrator" mode. That might be one reason for using an nwsapsetup package to do it, as you could use LSH. Alternatively, you could use a tool like Microsoft Systems Center to push the uninstallation.


2. The workstations aren't really "stored" by the Installation Server or in NwSapSetupAdmin. It isn't that smart of a tool, and doesn't provide quite that level of central control. If you want to keep a list of which workstations run the package install, you could write some centralized logging into the OnInstall or OnUpdate script. Otherwise, the installation logs are stored locally on each workstation. There is a feature within NwSapSetupAdmin to remotely view those logs, assuming you already know the workstation hostname and that you have remote WMI permissions to do so.


3. I haven't yet worked with NWBC, so I can't answer this question. I'd suggest raising this as a separate question or discussion thread.

Cheers,
Matt

[former_member352704]

Hi Matt,

Thank you for your comments and contributions.

Regarding your comments on point 1, you have some model of script that you have tried and can serve as a guide.

What I have planned is to uninstall the old version of SAP GUI, delete the registry entries as you recommend and delete the SAP directory stored in the user profile, which has the local Saplogon configuration, so that there is no conflict with The saplogon configuration of the SAP GUI SERVER package, I hope I can do everything from a script, although I think the option you propose to make a separate package to uninstall and delete such previous configurations, this is possible ?, how could it be done?

Now I have one more question and it is in relation to the deployment and update of sap gui server components for workstations in remote sites, this can affect the bandwidth, I had read that it is best to create a sap gui server for each remote site and Each one is updated from the sap guí server master, as I can make it replicate and do not work independently.

Thank you!!

[Matt_Fraser]

This is a VBscript that I put together three years ago to remove all traces of SAPGUI from a workstation. If I was rewriting it today I'd change a few things, so don't look at this as an example of good script code! Also, back then we didn't have Windows 10, so the part at the beginning that detects the OS version will need updating (since then, in later scripts, I came up with a much better way of doing this). However, for Win7 (or XP) clients, this works, assuming the user running it has local administrator privileges.

 

On Error Resume Next
Set Shell   = CreateObject("WScript.Shell")

'Determine operating system version
Set getOSVersion = Shell.exec("%comspec% /c ver")
version    = getOSVersion.stdout.readall
Select Case True
Case InStr(version, "n 5.") > 1 : GetOS = "WinXP"
Case InStr(version, "n 6.") > 1 : GetOS = "Win7"
Case Else : GetOS = "Unknown"
End Select

'If in Windows 7, run as Administrator
If GetOS = "Win7" And WScript.Arguments.length = 0 Then 'Restart script as Administrator
Set objShell  = CreateObject("Shell.Application")
objShell.ShellExecute "wscript.exe", """" & WScript.ScriptFullName & """" & " RunAsAdministrator", , "runas", 1
Else 'do the work

'Confirm user really wants to proceed
strConfirmText  = "This will completely remove SAPGUI from your computer.  Do you want to continue?"
intButton   = Shell.Popup(strConfirmText,,"SapSweep",4+48+256)
If intButton = 7 Then
WScript.Quit
End If

'Set up environment objects
Set oServices  = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set oReg   = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
Set fso    = CreateObject("Scripting.FileSystemObject")

'Determine operating system address width
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

Select Case True
Case Is64BitOS : GetBits = "64"
Case Is32BitOS : GetBits = "32"
End Select

'Set up registry paths
Const HKCU   = &H80000001
Const HKLM   = &H80000002
sKeyCU    = "Software\SAP"
sKeyLM32   = "SOFTWARE\SAP"
sKeyLM64   = "SOFTWARE\Wow6432Node\SAP"

'Get user-independent files and folders
sAllUsersProfile = Shell.ExpandEnvironmentStrings("%ALLUSERSPROFILE%")
sWinDir    = Shell.ExpandEnvironmentStrings("%windir%")
sSapLogon   = sWinDir & "\SapLogon.ini"
sSapMsg    = sWinDir & "\Sapmsg.ini"
sSapfCpl   = sWinDir & "\System32\sapfcpl.cpl"
sSapRegSv   = sWinDir & "\System32\sapregsv.exe"

'Get OS-specific paths
If GetOS = "Win7" Then
sAppDataSapSub  = "\AppData\Roaming\SAP"
sLocalDataSapSub = "\AppData\Local\SAP"
sVirtualStoreIniSub = "\AppData\Local\VirtualStore\Windows\saplogon.ini"
sStartMenuSAP  = sAllUsersProfile & "\Microsoft\Windows\Start Menu\Programs\SAP Front End"
ElseIf GetOS = "WinXP" Then
sAppDataSapSub  = "\Application Data\SAP"
sLocalDataSapSub = "\Local Settings\Application Data\SAP"
sStartMenuSAP  = sAllUsersProfile & "\Start Menu\Programs\SAP Front End"
End If

'Get AddressWidth-specific paths
If GetBits = "64" Then
sProgramFiles  = Shell.ExpandEnvironmentStrings("%ProgramFiles(x86)%")
sCommonFiles  = Shell.ExpandEnvironmentStrings("%CommonProgramFiles(x86)%")
sSapBtmp   = sWinDir & "\sysWOW64\SAPbtmp.dll"
ElseIf GetBits = "32" Then
sProgramFiles  = Shell.ExpandEnvironmentStrings("%ProgramFiles%")
sCommonFiles  = Shell.ExpandEnvironmentStrings("%CommonProgramFiles%")
sSapBtmp   = sWinDir & "\System32\SAPbtmp.dll"
End If
sProgramFilesSAP = sProgramFiles & "\SAP"
sCommonFilesSAP  = sCommonFiles & "\SAP Shared"

'Get profiles parent folder
sUserProfile  = Shell.ExpandEnvironmentStrings("%USERPROFILE%")
Set oUserProfileFolder = fso.GetFolder(sUserProfile)
sProfileRoot  = oUserProfileFolder.ParentFolder

'Enumerate all existing user profile folders
Set oFolder   = fso.GetFolder(sProfileRoot)
Set colSubfolders = oFolder.Subfolders

'Reusable functions
Function DelSubKeys(cHive, strKey)
Return = oReg.EnumKey (cHive, strKey, arrSubKeys)
If Return = 0 Then
If IsArray(arrSubKeys) Then
For Each SubKey in arrSubKeys
DelSubKeys cHive, strKey & "\" & SubKey
Next
End If
oReg.DeleteKey cHive, strKey
End If
End Function

Function DelFolder(sFolder)
If (fso.FolderExists(sFolder)) Then
fso.DeleteFolder sFolder, true
End If
End Function

Function DelFile(sFile)
If (fso.FileExists(sFile)) Then
fso.DeleteFile sFile, true
End If
End Function

'Stop running services
Set colListOfServices = oServices.ExecQuery ("Select * from Win32_Service Where Name ='NWSAPAutoWorkstationUpdateSvc'")
For Each objService in colListOfServices
Return = objService.StopService()
Next

Set colProcess = oServices.ExecQuery ("Select * from Win32_Process Where Name = 'saplogon.exe'")
For Each objProcess in colProcess
Return = objProcess.Terminate()
Next

'Uninstall SAP Frontend 7.10 and higher
Shell.Run "\\snocsapgus21\sapgui\Setup\NwSapSetup.exe /uninstall /all /nodlg",,true

'Uninstall SAP Frontend 6.40
Shell.Run "\\snocfmn1\sapgui640\Setup\SapSetup.exe /uninstall /nodlg",,true

'Remove left-behind registry keys
DelSubKeys HKCU, sKeyCU
DelSubKeys HKLM, sKeyLM32
DelSubKeys HKLM, sKeyLM64

'Remove non-user-specific left-behind folders and files
DelFolder sProgramFilesSAP
DelFolder sCommonFilesSAP
DelFolder sStartMenuSAP
DelFile sSapLogon
DelFile sSapMsg
DelFile sSapfCpl
DelFile sSapRegSv
DelFile sSapBtmp

'Remove all user-specific left-behind folders and files
For Each objSubfolder in colSubfolders
sProfile  = sProfileRoot & "\" & objSubfolder.Name
sSapWorkDir  = sProfile & "\SapWorkDir"
sAppDataSap  = sProfile & sAppDataSapSub
sLocalDataSap = sProfile & sLocalDataSapSub

DelFolder sAppDataSap
DelFolder sLocalDataSap
DelFolder sSapWorkDir
If GetOS = "Win7" Then
sVirtualStoreIni = sProfile & sVirtualStoreIniSub
DelFile sVirtualStoreIni
End If
Next

strDone    = "All SAP registry entries, files, and folders removed, except for temporary files.  Reboot recommended."
strDoneTitle  = "SAP Uninstall Complete"
Shell.Popup strDone,10,strDoneTitle,64

End If 'Close out the ELSE statement from line 17

 

Otherwise, if you were going to use an "uninstall" package within NwSapSetupAdmin, the package event script might look something like this:

 

'Remove obsolete configuration files

NwEngine.Context.Log.Write "Event:  On Uninstallation End"

strIniFile640 = NwEngine.Variables.ResolveString( "%windir%\saplogon.ini" )

strMsgFile640 = NwEngine.Variables.ResolveString( "%windir%\sapmsg.ini" )

strIniFile720 = NwEngine.Variables.ResolveString( "%SapFrontEndDir%\saplogon.ini" )

strMsgFile720 = NwEngine.Variables.ResolveString( "%SapFrontEndDir%\sapmsg.ini" )

strIniFile730 = NwEngine.Variables.ResolveString( "%AppData%\Roaming\SAP\Common\saplogon.ini" )

strShcFile730 = NwEngine.Variables.ResolveString( "%AppData%\Roaming\SAP\Common\sapshortcut.ini" )

strXmlFile730 = NwEngine.Variables.ResolveString( "%AppData%\Roaming\SAP\Common\SapLogonTree.xml" )

strIniFileVst = NwEngine.Variables.ResolveString( "%LocalAppData%\VirtualStore\Windows\saplogon.ini" )

If NwEngine.Shell.FileExist( strIniFile640 ) Then

NwEngine.Shell.DeleteFile strIniFile640

End If

If NwEngine.Shell.FileExist( strMsgFile640 ) Then

NwEngine.Shell.DeleteFile strMsgFile640

End If

If NwEngine.Shell.FileExist( strIniFile720 ) Then

NwEngine.Shell.DeleteFile strIniFile720

End If

If NwEngine.Shell.FileExist( strMsgFile720 ) Then

NwEngine.Shell.DeleteFile strMsgFile720

End If

If NwEngine.Shell.FileExist( strIniFileVst ) Then

NwEngine.Shell.DeleteFile strIniFileVst

End If

 

That one isn't handling the registry entries, only the config files, but you can add registry editing to a package event script easily enough (the latest sapsetup guide has a pretty decent scripting reference, finally, and otherwise it's just like VBscript).

Long ago, early versions of the Installation Server code included logic for having "master" and "slave" servers, with the slaves auto-updating from the master. The current incarnation no longer does that. It's easy enough (and more reliable, less problematic, which I think is why the functionality was removed) to just manually update each of your installation servers when you need to. I don't do that for my setup: we have approximately a hundred buildings spread throughout the city, all connected by a fibre WAN, and the fibre connections are fast enough that it's not an issue for the remote sites to install from one central Installation Server. I do have multiple Installation Servers, but it's not for load balancing or anything like that. Rather, it's so that I can separate sandbox, DEV, QAS, and PRD groups from each other, giving them different sets of centralized config files, and also rolling out SAPGUI patches in a controlled and tested manner, much like I would transports or updates to the SAP applications.

[former_member352704]

Hi Matt,
A thousand thanks have been great help your answers and comments.

Finally, take your comment as a guide and create a script to uninstall the current gui.

 

[former_member352704]

Hi everyone,

Is possible include the component sapgui for Java (Mac) + jdk (java) in sap guí server and configure a file with connexion string in a folder shared, as the file .ini in OS windows.

Thanks for your comments.

[former_member604313]

Hello Matt

I wonder if you have this step available with scripts for sapgui 7.5. When I run the command to deploy sapgui, it installs successfully, but I can not get my .ini file and .xml file to copy over to the computer for the systems to show up when sap is launched. I am thinking it may have to do with the scripts since your tutorial is for sap 7.3. Any help would be greatly appreciated.

[Matt_Fraser]

Hi Mario,

First, my apologies for a late reply. I've been away from the office for the past three weeks and have just returned today.

Since I wrote this blog series, we have upgraded our environment to use SAPGUI 7.40, but we haven't yet made the leap to 7.50 (despite 7.40 no longer being in support). I can say that with only minor tweaks everything I wrote here still works in 7.40, but I'm aware that with 7.50 the .xml and .ini configuration file landscape changes somewhat. So, I would imagine that some adjustment to the procedure for managing config files will be necessary.

Nevertheless, you should still be able to utilize a central configuration file (or set of files) on a network share that your users can all access, as I describe here. This should avoid the necessity of copying any files over to their workstations, which can indeed become problematic for local access permissions, version control, etc.

Does it make a difference if the install script is launched by someone with local Administrator permissions vs someone without? If so, then something about the Local Security Handling may not be correctly configured (perhaps a mistyped password in the LSH setup in the NwSapSetupAdmin tool).

You should be able to find troubleshooting hints in log files on the workstation at C:\Program Files (x86)\SAP\SapSetup\LOGs.

Cheers,
Matt

[former_member352704]

Hello Matt, I hope everything goes well.

This blog has been published some years ago for other versions, and it is still very helpful for many of us, I value it very much.

This time my query is related to the configuration of the entries for SAP Fiori Launchpad, probably the access to SAP Fiori is not configured from the SAPGUI Server, but in your experience you think it is possible to configure the entries to SAP Fiori Launchpad from the SAPGUI Server. Any comment I would appreciate.

Regards,

Giovanny G.

 

[Matt_Fraser]

Hi Giovanny,

Thanks for your kind comments.

We have only just started our journey to Fiori Launchpad here, but what I can say is that it really has nothing to do with the SAPGUI Installation Server at all. Most likely you'll have your users accessing the FLP via web URLs. Possibly it could be with the NetWeaver Business Client. And if they accessing it via the SAPGUI, then it's only in the sense of using a transaction code shortcut that launches the web URL. Either way, it ends up opening as a web page, not a GUI transaction.

If you really want to integrate this with SAPGUI Installation Server and/or central configuration files, the only thing I can think of is to create Shortcut entries in the configuration that will connect a user to a system with the LaunchPad tcode defaulted for immediate execution. This strikes me as inefficient, however, as why have users start a SAPGUI at all if the only purpose is to immediately open a web page for the FLP?

Cheers,
Matt

[former_member352704]

Thanks Matt for your prompt response.

I commented, here we have centralized the deployment of SAP GUI packages, Business Client and SAP Secure Login Client, also as you mention here we are also starting in SAP Fiori LanchPad, and we will access FLP through the client business client, some users will continue using SAPGUI and some others only FLP.
For users who use SAPGUI we have the configuration file centralized and we want to do the same for FLP (Business Client), centralize the entries to the system from a configuration file for FPL (Business Client).

The centralization of the inputs to the system allows me to have a complete administration and management according to the accesses required by the user.

Now, according to what you say, it makes sense when you want to include a new entry or update an existing one and not do it locally team by team, in this way I want to make FLP work (Business Client).

You have advanced in this respect with some similar configuration, or what you suggest.

[Matt_Fraser]

We aren't using Business Client here, so I can't speak to that (though I know you can distribute it via the Installation Server, or it can be web-based). We've only just started with FLP, but currently we plan to use our Enterprise Portal as a "front door" for users to access the FLP. So, it will be entirely web-based, not tied to the GUI at all.

[former_member352704]

the configuration files for SAP logon and SAP Business Client 7.0 PL1 can share the same file “SAPUILandscape.xml”, however I found an error in SAP Business Client 7.0, PL1, when I updated the configuration file “SAPUILandscape.xml” for example, including new FLP and SAP Logon entries, when SAP Logon opens it again it takes the changes and is correctly reflected, SAP Business Client 7.0, PL1 when opening it is not updated and does not reflect the changes, I’m still investigating ..

[fahad_ishaq]

Hi Matt,

Thank you for a great blog. it has surely helped me with creating an initial file for deployment and it worked on my test laptop successfully. I deployed the package via Matrix 42 system on my main laptop where i already had SAP Gui 7.60 installed with different connection (SEP, QAS, DEV and etc). After the package ran, i received an error code stating "Execution of the windows script host failed, Access is denied". Upon discussion with my Matrix 42 team mate, we found out that this error comes from SAP installer which tries to run .vbs file which deletes the older connection if existing. In my case, it deleted all the above stated connection and added only the PROD connection which i added during installer file creation.

My question: Is there a way we can tune up few settings during installer package setup, which does not deletes existing connection from a laptop where an older version of GUI was installed and will be replaced with a new one (in my case 7,60).

How can we stop the connection cleanup during the installation process?

 

Thanks alot for your help.

 

 

Regards,

fahad

[Matt_Fraser]

Hi Fahad,

SAPGUI 760 (and 750) uses a different format for the connection information files than 740 and earlier did. One of the thing that happens when you first update an existing 740 GUI to 760 and launch SAPLogon is that it tries to import the settings from the old saplogon.ini / SapLogonTree.xml files and write new files (SAPUILandscape.xml and SAPUILandscapeGlobal.xml) to the same location.

So, I recommend that you after you apply the upgrade to a test instance of your SAPGUI Installation Server, you then use that to upgrade your admin workstation first. Then launch the admin workstation's SAPGUI via a CMD or BAT file (or from a command prompt window) with the following line:

saplogon.exe /ini_file=\\<TestInstallationServerHost>\sapgui\CustomerFiles\saplogon.ini /lsxml_file=\\<TestInstallationServerHost>\sapgui\CustomerFiles\SAPUILandscape.xml

Substitute the appropriate path to where you store your central saplogon.ini for users, of course. This should load the "old" saplogon.ini into your newly-upgraded SAPLogon on your admin workstation and automatically create a "new" SAPUILandscape.xml file from it. You'll almost certainly need to edit the file afterwards to make it work for you, but this will get you on the right path.

Afterwards, of course, you need to edit the scripts in the Package you create in NwSapSetupAdmin so that instead of creating a path to saplogon.ini for your users, they create a path to SAPUILandscape.xml. I do that in the "On Installation End" and "On Update End" scripts, editing the lines:

strRegConfigValue = strRegPath + "SAPLogon\Options\LandscapeFileOnServer"
strXmlFile = NwEngine.Variables.ResolveString("%SapSrcDir%\CustomerFiles\SAPUILandscape.xml")

This is the key. If you keep pointing clients at the old saplogon.ini, then every time they launch they will attempt to "upgrade" the old file to the new format. However, when config files are loaded from a central server like this, the SAPLogon cannot write to the server files location unless it is launched with that /lsxml_file command line switch. So, you need to do this once with your admin workstation, edit and save the new xml file, and then make sure the package event scripts point all your end users to the new xml file. If you do that, they shouldn't keep trying to "cleanup" the file every time they launch.

Cheers,
Matt

[Ahmed1]

I Added script at end of installation but not worked by add connection to registry

 

the script i add is

 

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\LandscapeFileOnServer”) Then

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

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

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\LandscapeFileOnServer”

strXmlFile = NwEngine.Variables.ResolveString(“\\SAPGUI\String\SAPUILandscape.xml”)

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

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

 

 

and error at end of install

 

InstallerEvent
Install
The resource loader cache doesn't have loaded MUI entry. Error code 0x00003b01 (15105).


0x80020101

[Matt_Fraser]

Hi Ahmed,

I have not encountered this error before myself, but from what I can tell it probably means that the workstation on which you are running the install may be in need of some Windows Updates, most particularly for .NET. To be clear, this is a Windows error and not one from the SAPSETUP program. I think Windows is complaining that it is lacking some prerequisite before you can run the SAPGUI setup.

I've also seen some references elsewhere that this Microsoft "fix it" tool can help install and uninstall issues:

https://support.microsoft.com/en-us/topic/fix-problems-that-block-programs-from-being-installed-or-r...

Cheers,
Matt

[Ahmed1]

Hi Matt

 

I use latest Windows 10 with update and .NET the strange is that there no prerequisites message appear before install for the package i install and after install there is no issue with SAP GUI it work fine and i even run check many times and different workstation.

The problem i face is "Script to add string connection not work after install" and can't find issue why it not work i wrote the script i add in post above if there any correction.

I tried GUI 7.50 and 7.60 and different workstations and didn't work on all

[Matt_Fraser]

I notice in your script you have this line:

strXmlFile = NwEngine.Variables.ResolveString(“\\SAPGUI\String\SAPUILandscape.xml”)

Whereas in mine, I use this:

strXmlFile = NwEngine.Variables.ResolveString("%SapSrcDir%\CustomerFiles\SAPUILandscape.xml")

It's a minor difference, and almost certainly not the cause of the error you're encountering. However, you might want to consider using the %SapSrcDir% variable rather than hard-coding a server host and share name. Also, while not absolutely necessary, I recommend using the \CustomerFile folder name under your primary \\<host>\sapgui share, as doing so will greatly ease the setup of single-file installers should you decide to use them.

Otherwise, it could be a local permissions issue. Do you observe a difference when logged onto the local workstation as an Administrator vs non-administrative User? You should be able to get around this by setting up LSH (Local Security Handling) on your Installation Server, though it does require some coordination with your Active Directory configuration. I discuss this in detail on part 6 of the blog series: https://blogs.sap.com/2014/06/09/sapgui-installation-server-part-6-lsh-and-distribution/.

Did you give the Microsoft "Fix-It" tool a try?

[Ahmed1]

I tried different workstation and installed new windows 10 withe latest update and .NET Framework

and different admin and even Domain Admin still got that error and i think it's not effective because i check sap gui installation and found no error and work fine with different users

But all workstation not add registry record after installation and checked regedit and not created

have to manually add string connection after install

 

[andrzej_wisniewski3]

Hello,
I have testing bellow script on Windows 10 during installation new SAP GUI 8.00. Old sap GUI I have removed manually. One of step new installation is switching from local XML files to central file located on server. Just in case i would like to backup original XML files users to Common.bak folder.

My idea is:
1. Create new folder Common.bak in "%appdata%\sap\ location,
2. Copy files / folder from Common to Common.bak,
3. Remove Common folder (remove all XML/ini files)
4. Create new Common (empty) folder.

But.. new empty Common folder did not create. I don't know why..

This script is puted in "On installation End":

NwEngine.Context.Log.Write "Creating Common.bak folder...."

strDstFolder = "%appdata%\sap\Common.bak"

NwEngine.Shell.CreateDirectory strDstFolder

NwEngine.Context.Log.Write "Common.bak created."



NwEngine.Context.Log.Write "Coping files from Common to Common.bak...."

strSrcFolder = NwEngine.Variables.ResolveString("%appdata%\sap\Common")

strDstFolder = "%appdata%\sap\Common.bak"

NwEngine.Shell.CopyDirectory strSrcFolder, strDstFolder

NwEngine.Context.Log.Write "Files copied from Common to Common.bak...."



NwEngine.Context.Log.Write "Removing Common folder...."

strDstFolder = "%appdata%\sap\Common"

NwEngine.Shell.DeleteDirectory strDstFolder

NwEngine.Context.Log.Write "Common removed"



NwEngine.Context.Log.Write "Creating new empty Common folder...."

strDstFolder = "%appdata%\sap\Common"

NwEngine.Shell.CreateDirectory strDstFolder

NwEngine.Context.Log.Write "Common created."

 

This is a part of log from installation process:

21:46:34.093 NwSapsAtlC 1 Executing Scripting Event...
21:46:34.094 NwSapsAtlC 1 Creating Common.bak folder....
21:46:34.094 NwSapsAtlC 1 Common.bak created.
21:46:34.094 NwSapsAtlC 1 Coping files from Common to Common.bak....
21:46:34.094 NwSapsEngn 1 Performing CopyDirectory: 'C:\Users\username\AppData\Roaming\sap\Common' -> '%appdata%\sap\Common.bak'
21:46:34.096 NwSapsAtlC 1 File type: Data file
21:46:34.096 NwSapsAtlC 1 Target directory does not exist: Attempting to create directory C:\Users\username\AppData\Roaming\sap\Common.bak
21:46:34.103 NwSapsAtlC 1 'C:\Users\username\AppData\Roaming\SAP\Common\test1.xml' successfully copied to 'C:\Users\username\AppData\Roaming\sap\Common.bak\test1.xml'
21:46:34.103 NwSapsEngn 1 Copied file '%appdata%\sap\Common.bak\test1.xml'
21:46:34.104 NwSapsAtlC 1 File type: Data file
21:46:34.107 NwSapsAtlC 1 'C:\Users\username\AppData\Roaming\SAP\Common\test2.xml' successfully copied to 'C:\Users\username\AppData\Roaming\sap\Common.bak\test2.xml'
21:46:34.107 NwSapsEngn 1 Copied file '%appdata%\sap\Common.bak\test2.xml'
21:46:34.107 NwSapsEngn 1 Finished CopyDirectory of 'C:\Users\username\AppData\Roaming\sap\Common' ---> '%appdata%\sap\Common.bak'.
21:46:34.107 NwSapsAtlC 1 Files copied from Common to Common.bak....
21:46:34.107 NwSapsAtlC 1 Removing Common folder....
21:46:34.110 NwSapsEngn 1 Deleted File C:\Users\username\AppData\Roaming\sap\Common\test1.xml
21:46:34.110 NwSapsEngn 1 Deleted File C:\Users\username\AppData\Roaming\sap\Common\test2.xml
21:46:34.112 NwSapsEngn 1 Removed directory 'C:\Users\username\AppData\Roaming\sap\Common'
21:46:34.112 NwSapsEngn 2 Shell : directory 'C:\Users\username\AppData\Roaming\sap\Common' deleted
21:46:34.112 NwSapsAtlC 1 Common removed
21:46:34.112 NwSapsAtlC 1 Creating new empty Common folder....
21:46:34.112 NwSapsAtlC 1 Common created.