SAPGUI Installation Server Part 2 - Initial Installation

[Matt_Fraser]

This 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

• Initial Installation

• Actions on the Server Console
  
  
  
  • Create Share
  
  
  • Configure Distribution Service User (optional)
  
  
  
  


• Install Installation Server Files
  
  
  
  • Create Server Shell
  
  
  • Update Server With Products
  
  
  
  

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.

<--->

Continue on to SAPGUI Installation Server Part 3 - Patching.

[Johan_sapbasis]

The quality of your documentation is just exceedingly good, so much so that I will have to put a lot more detail into my next blog/document post.

[Matt_Fraser]

Thanks, Johan! Though, not every blog is so fully detailed and screenshotted (is that a word?), as it takes quite a bit of time to do that.

[Johan_sapbasis]

hehe in past tense it seems yes 🙂

 

https://www.merriam-webster.com/dictionary/screenshot

[Matt_Fraser]

Nice!

[belezyc]

Dear Matt,

Thank you for your excellent series of how-to regarding SAP GUI installation server.

I still have a doubt on the understanding. Could you please confirm that if I configured an installation server with product SAP GUI for Windows 7.50, it would be possible to add product SAP GUI for Windows 7.60 CORE without impacting packages configured for SAP GUI for Windows 7.50 ?

That would be interesting to know as a server is ressources. And ressources are costs. And costs are hell… I haven’t seen such information in the install guide.

Thanks in advance for your answer.

Kind regards,

Clément

[Matt_Fraser]

Hello Clément, and thank you for your kind comments on this now admittedly-rather-old blog. I'm glad to learn that some folks are still finding value in it.

I'm a little unclear on your question, so I'll address it in two ways, and hopefully one of these will be the answer you seek (though perhaps you may not like the answer).

If you mean, upon upgrading the Installation Server's product for SAPGUI 7.50 to SAPGUI 7.60, will the various Installation Packages you created for SAPGUI 7.50 still work, the answer is yes, they will. An upgrade is a good time to evaluate your package event scripts and the package contents, of course, but you will find that in your existing packages (such as the "Basic" package I use in the examples for this blog) that the product content has been upgraded appropriately. So, if this is what you mean, then the process is really quite easy.

On the other hand, if you mean that you would like to maintain two versions of the same product, i.e. SAPGUI 750 and SAPGUI 760, at the same time on a single Installation Server, then no, I don't believe you can do that. In this case, I would assume when you say "package" that you actually mean "product." You can have many products on the Installation Server, and group them in various ways into various packages, but you can only have one version and one patch level of a single product at a time.

The best way to handle this, in my experience, and the way we handle it in my organization, is to have multiple Installation Servers. I recommend a SBX-DEV-QAS-PRD sequence, much as you would for the backend SAP servers. This way you can test the upgrade in a SBX environment that perhaps only impacts your Basis team, and then move onto DEV for your core configuration/development/support team, then QAS for your testing group and power users who help with testing, and finally PRD for the remainder of your users.

This has the added advantage that for each of these Installation Servers you can have different central configuration files, so that you automatically distribute all available SAP systems to your SBX and perhaps also DEV groups, distribute only PRD and QAS systems to your QAS group, and only PRD systems to your PRD group, etc.

But yes, you are right, this means more resources, and thus more costs. Fortunately, the "hardware" requirements for a SAPGUI Installation Server are very light, even for a PRD system with central config files supporting many hundreds of users. I put "hardware" in quotes because, if you have a virtualization environment, such as VMware, then I would simply provision separate VMs for each of these servers. Give them some minimal amount of RAM, perhaps around 8 GB, or 16 GB if that's your organization's minimum standard for servers, and 1 or 2 virtual CPU cores, and a relatively minimal amount of disk space, and you're good to go. If they are virtual servers, the cost is quite minimal. If not VMware, you could do this with virtual servers in the cloud, such as Azure, AWS, etc. All you need is a basic Windows Server.

I hope this has answered your question, and perhaps alleviated your concerns.

Cheers,
Matt

[belezyc]

Dear Matt,

Thank you for your answer! You perfectly answered my question and some doubts I had.

I think as long as there is a SAP GUI, there will be a need for an enterprise grade deployment tool. And your blog is the best source of information after the standard documentation.

According to our deployment strategy, I will adapt our server landscape and go for a SBX-DEV-PRD. Then I will stop deployment service while i'm updating "products" and "packages".

Again thank you very much for the time you spent to share your knowledge and experiences.

Kind regards,

Clément