GUI 7.40 GUI Installation Server - Hardware requirements?

[jamie_mclean]

Good day all.

We are looking to establish a GUI Implementation Server to manage our GUI deployments, etc.

Our SAP environments are hosted by a 3rd party, running on IBM/AIX servers using DB2 database.  We currently have a mix of GUI 7.30 and 7.40 deployed and are looking to move everyone to 7.40 with network config for SSO, etc.

We want to have the GUI Implementation Server locally and manage it ourselves.  Our server team is hesitant to build a server due to the lack of specific details in the guide.  Could someone please provide the hardware / OS configuration that has worked for you?

Thanks in advance!

Jamie Mc.

[Matt_Fraser · Accepted solution]

Hi Jamie,

We use a Win2012R2 VM instance for this. We have separate installation servers for Sandbox, DEV, QAS, and PRD, so we can rollout upgrades and patches, etc, in a controlled and tested manner. In the PRD environment I use a VM with two CPU cores and 16 GB of RAM, and it is not taxed at all (about 500 SAPGUI users across 100 buildings around the city). I do use central configuration files (saplogon.ini, etc) on this box.

For the non-PRD instances I use a single CPU core and 8 GB of RAM, and they're fine.

Cheers,

Matt

[jamie_mclean · Accepted solution]

Thanks Matt!  That sounds exactly like what my server guy is asking for.  I appreciate your prompt response.

[Former Member · Accepted solution]

Hi Matt,

How to you handle Active Directory/Domain and Desktop  authorizations when rolling out the SAP GUI patches/upgrades?  I have looked into doing this but I needed a special domain ID and then I needed to throttle installations to various subnets.

How do you throttle the delivery of your upgrades so it doesn't take all the bandwidth up?

With the saplogon.ini I have a technical and non- technical version.  So I use a standalone vb script which install's the file based on a user select. I have 200 systems and six landscapes. The non-technical users just need access to the production instances.  it's a major pain deploying ASCS.

Cheers,

Dan Mead  

[Matt_Fraser · Accepted solution]

Hi Dan,

In terms of AD and local permissions, I pretty much described the full setup I used in my organization in my SAPGUI Installation Server blog series, which I know you've seen. A link to the full series is at . Specifically, describes the setup of Local Security Handling and how to use scripted installs on workstations for which the users don't have local administrator rights. describes the domain permissions needed on your Installation server and how to setup the share permissions.

Part 6 also talks a little bit about different options for distributing the installation. For instance, you could put the script you mentioned into logon scripts, and there is a command-line switch for NwSapSetup (/once) which can be used to quickly bypass running the full setup if it detects that it has already been done on that workstation. This should keep the logon script fairly quick for those who have already installed. Then you could use various AD groups to determine who gets that particular logon script.

Another alternative is to use Microsoft SCCM (I think there's a new name for this tool now, but I forget what it is). The Installation Server has a utility to create a Package Definition File which can be used with SCCM to push the installation out that way. We haven't done that here, but we're looking into it for the future.

Or, you can simply publish the link to your script, perhaps on a departmental intranet webpage, or by sending out group emails, etc, and let users self-select when to click on it and start the install/upgrade. This is what I chose to do, just to keep things simple. Yes, there's a slight risk that everyone might click it at the same time, but in fact that didn't happen here. I did worry about the Automatic Workstation Update Server (AWUS), since it checks every 24 hours from the last workstation startup for updates, whether that would mean that when I pushed out a patch everyone would update at the same time in the morning, but again this turned out to be a non-issue. As it happens, many of our users don't bother to reboot very much, they just leave their workstations on all the time. Also, many of them come in at different times in the morning, so if they do reboot, it's not all at the same hour. Finally, we now have a central mechanism of controlling workstation (windows) patches that triggers reboots, so many people's workstations get auto-rebooted late in the evening a couple times per week. All of this has meant that in practice users hit the Installation Server at all different times, or at times of low network activity (at night), etc, so it just isn't much of a problem.

But, worry about this is why I put two cores and more RAM on my PRD Installation Server. If you use a VM, it's easy to add more CPU cores and RAM "on the fly," so you can just monitor utilization, and if it spikes -- beef up the VM.

Cheers,

Matt