Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Best practices for SAP GUI 730 options?

Former Member
0 Kudos

I'm responsible for rolling out SAP GUI 730 to my global organization, replacing our current SAP GUI 720 desktop installation package.  Since there are now more options for administrators to configure SAP GUI using the Windows registry (thanks SAP!) I wanted to ask what other organizations are doing before we finalize our choices.  Here are the options we're planning to implement:

- Grant ability for SAP GUI to read/write/delete files on the local client by default

SAP’s default setting is to ask the user whenever an action that passes SAP GUI’s security rules will access the client machine’s file system (this
is the authorization pop-up you get when you try to download a file from SAP to your desktop)  

I think our risk of SAP GUI performing rogue activity on client machines is very low, plus few of our users would be able to classify activity as
harmful by interpreting the information in the pop-up.  This setting is suggested as a convenience to our user community, most members of whom will probably allow any activity anyway.

- Delete the cache of documents downloaded from SAP each time SAP Logon is shut down

Other options are to prevent caching of downloaded files altogether or to delete them after a specific number of days

I believe deletion when SAP Logon is closed as a compromise between convenience and security since users access many more documents from
DMS that aren’t sensitive

Any document written to the hard drive could potentially be recovered even after erasure by someone using data recovery tools until the
hard drive sectors are physically overwritten.  Turning document caching off completely might reduce that risk, although additional research would be required to confirm that documents are never written to the hard drive if not cached.

- Allow SAP GUI trace files to remain on the client indefinitely

This is the SAP standard setting

While trace files could potentially contain sensitive input data, the likelihood is low.  The alternative is to prevent caching or delete the trace file
cache after a defined number of days

Prevent Firefighter passwords from being saved in the local SAP input history database

SAP currently stores all user input, except SAP login passwords, in an unencrypted local database.  Apparently Firefighter passwords aren’t recognized as SAP passwords.  This is from SAP Note 1250351

I personally find the input history helpful when using SAP GUI for business transactions so I don’t suggest deactivating it altogether.  Any other commonly-used sensitive data elements that should be considered; SSNs or credit card numbers?   

- Allow SAP GUI scripting

This is the SAP standard setting

My organization currently disables SAP GUI scripting at the server level out of a concern that a technically-savy user who writes a bad script could really do some (likely inadvertent) damage to our production systems.  Maintaining control at the server level makes it easier to adjust on an as-needed basis

- Prevent end users from changing selected SAP GUI options set by the administrator

The only features to be made unchangeable by users are:

  • SAP GUI security rules
  • Retention of the document cache (we want to be sure it is always
    deleted when the user leaves SAP Logon)
  • Branding image location (so users can’t replace the Perrigo logo
    in the upper right corner of the screen with their own image)

Thanks everyone for your input, and I hope the suggestions I've shared above are helpful to others.

Robert Garst

SAP Basis Administrator, Perrigo Company

1 ACCEPTED SOLUTION

Matt_Fraser
Active Contributor
0 Kudos

Hi Robert,

That's quite a comprehensive plan you have going there, and it sounds like you're still working on it now a few months later?  We're in the early-to-middle stages of a 7.30 rollout ourselves, distributing to perhaps 500 users across 100 different physical sites (most of our 7000 users are pure ESS, so no SAPGUI required for them).  I have a similar plan to yours of rolling out first to the SAP Support Team (11 people total, and this phase is already done, with only one problem so far (the input history issue with patch 5, now resolved)), then to a core group of non-IT power users experienced with support-pack-style testing co-located in my building (about another dozen people, and this phase is half done, with problems encountered that I'm now working on), then to a wider group of about two dozen regular but moderately experienced end users at varying skill levels spread throughout our other sites who volunteered to be in a pilot, and then eventually to everyone else who needs it.

I looked into using SCCM for distribution, then ruled it out as it's still in early stages of being implemented itself here, and I don't feel that we have enough experience with it yet to trust it completely; I also don't think it will be fully rolled out in time to support my project.  So, I'm back to using a logon script approach to the install, with an AD group controlling who gets it and who doesn't, and making use of the /once parameter of nwsapsetup.exe to prevent folks who've already had the install from suffering repeated executions of the installer every day.  That parameter seems to work quite well.

The issues I'm encountering are that we have a wide variety of desktop environments that I have to control for:  some are on Win7, most are on WinXP; some are 64-bit, most are 32-bit; some have SAPGUI 7.20, some 7.10, and most are still on 6.40 (yes, Jude, I know, long long since out of support); users in our central location have local administrative access, but in our other sites they do not, and GPO policies lock them down moderately; some users used the SAPGUI 'package' I prepared in prior versions, but some mistakenly hit 'select all' and installed every SAPGUI component; some have rather corrupted but still moderately working current installs; and there are lots of inadvertent browser toolbar/add-ons (Google, Yahoo, Ask, among others) that may or may not be interfering with the upgrade process.  I have found in my second phase testing that people cannot be relied upon to shut down running SAPLogon processes, and if their current installation is... um, unclean?... then the upgrade doesn't necessarily handle that as well as it does if they have a clean installation, with the result that they can end up with a mix of 6.40, 7.10, and 7.30 components when it's done, resulting in all sorts of interesting errors when they try to run the GUI afterwards. 

So, I'm focusing a lot of my time on tuning the 'on-start-install' and 'on-end-install' (and upgrade) package event scripts to test for and 'clean up' these various situations.  At the moment I'm working out methods using VBscript/WMI to find and shutdown any running SAPGUI processes at the start of the install/upgrade, which works great on the XP machines but has UAC issues on the Win7 machines.  I found a workaround for the UAC issue, but that workaround then causes problems on the XP machines, so now I have to build in logic to test for XP vs Win7 and branch appropriately.  On top of that, the saplogon.ini files distributed today have all sorts of mistaken entries in them, so I'm starting clean and using centralized ini files to control who sees which server in their SAPLogon.

I toyed with the idea of locking down some of the other registry options such as you've mentioned, especially the security setting for read/write of local files, but I've already spent so much time just insuring a clean install, and am nearly two months behind schedule with the project, that I may just need to let that go, and possibly follow up with a 'patch' for it later.  At least, when this is done, I will finally have a decent built-in mechanism for distributing patches and later GUI upgrades, which I didn't have before (and is the reason there are still so many 6.40 GUIs out there).  I will be interested to learn how well that works out for you, and may follow your example at a later date if we gets lots of help desk calls about it (we haven't, so far, from the handful of 7.20 users, but they were all power users to begin with).

Thanks for sharing your strategy, and best of luck!

Regards,

Matt

9 REPLIES 9

Former Member
0 Kudos

Hello,

Nice explanation Did you got a Plan to Roll out? We are planning to do the same on Citrix Environment along with Our Major Go-Live. Kindly let us know if you have something in place.

THanks,

Iqbal

0 Kudos

Hello Iqbal,

Our roll-out plan is:

- formal testing: first an "installation qualification" run by the Basis & Windows teams, then a "functional verification" run by of our business analysts to make sure key transations continue working as we expect in 7.30.

-  After our quality group signs off on the testing we'll deploy using a Wise installation package that we advertise to users with Microsoft SCCM.  We'll push it to desktops by on a site-by-site basis to spread out the loan on the network and hopefully minimize the impact of any issues.  It will also be added to the desktop applications installation package at that point.

- We also enable access via Citrix and will add all of our SAP GUI users to a Citrix access group for the 730 version.

- All of the deployment steps are documented in a change control document, along with our training plan.  720 isn't that different for end users so the training plan will be pretty light, just a powerpoint presentation covering new features.

Hope that helps!

Robert

0 Kudos

Hello Robert,

Just be advised that SAP don't support up repackaging the sapgui into an .msi package.

See note  http://service.sap.com/sap/support/notes/507996

Regards,

Jude

Matt_Fraser
Active Contributor
0 Kudos

Hi Robert,

That's quite a comprehensive plan you have going there, and it sounds like you're still working on it now a few months later?  We're in the early-to-middle stages of a 7.30 rollout ourselves, distributing to perhaps 500 users across 100 different physical sites (most of our 7000 users are pure ESS, so no SAPGUI required for them).  I have a similar plan to yours of rolling out first to the SAP Support Team (11 people total, and this phase is already done, with only one problem so far (the input history issue with patch 5, now resolved)), then to a core group of non-IT power users experienced with support-pack-style testing co-located in my building (about another dozen people, and this phase is half done, with problems encountered that I'm now working on), then to a wider group of about two dozen regular but moderately experienced end users at varying skill levels spread throughout our other sites who volunteered to be in a pilot, and then eventually to everyone else who needs it.

I looked into using SCCM for distribution, then ruled it out as it's still in early stages of being implemented itself here, and I don't feel that we have enough experience with it yet to trust it completely; I also don't think it will be fully rolled out in time to support my project.  So, I'm back to using a logon script approach to the install, with an AD group controlling who gets it and who doesn't, and making use of the /once parameter of nwsapsetup.exe to prevent folks who've already had the install from suffering repeated executions of the installer every day.  That parameter seems to work quite well.

The issues I'm encountering are that we have a wide variety of desktop environments that I have to control for:  some are on Win7, most are on WinXP; some are 64-bit, most are 32-bit; some have SAPGUI 7.20, some 7.10, and most are still on 6.40 (yes, Jude, I know, long long since out of support); users in our central location have local administrative access, but in our other sites they do not, and GPO policies lock them down moderately; some users used the SAPGUI 'package' I prepared in prior versions, but some mistakenly hit 'select all' and installed every SAPGUI component; some have rather corrupted but still moderately working current installs; and there are lots of inadvertent browser toolbar/add-ons (Google, Yahoo, Ask, among others) that may or may not be interfering with the upgrade process.  I have found in my second phase testing that people cannot be relied upon to shut down running SAPLogon processes, and if their current installation is... um, unclean?... then the upgrade doesn't necessarily handle that as well as it does if they have a clean installation, with the result that they can end up with a mix of 6.40, 7.10, and 7.30 components when it's done, resulting in all sorts of interesting errors when they try to run the GUI afterwards. 

So, I'm focusing a lot of my time on tuning the 'on-start-install' and 'on-end-install' (and upgrade) package event scripts to test for and 'clean up' these various situations.  At the moment I'm working out methods using VBscript/WMI to find and shutdown any running SAPGUI processes at the start of the install/upgrade, which works great on the XP machines but has UAC issues on the Win7 machines.  I found a workaround for the UAC issue, but that workaround then causes problems on the XP machines, so now I have to build in logic to test for XP vs Win7 and branch appropriately.  On top of that, the saplogon.ini files distributed today have all sorts of mistaken entries in them, so I'm starting clean and using centralized ini files to control who sees which server in their SAPLogon.

I toyed with the idea of locking down some of the other registry options such as you've mentioned, especially the security setting for read/write of local files, but I've already spent so much time just insuring a clean install, and am nearly two months behind schedule with the project, that I may just need to let that go, and possibly follow up with a 'patch' for it later.  At least, when this is done, I will finally have a decent built-in mechanism for distributing patches and later GUI upgrades, which I didn't have before (and is the reason there are still so many 6.40 GUIs out there).  I will be interested to learn how well that works out for you, and may follow your example at a later date if we gets lots of help desk calls about it (we haven't, so far, from the handful of 7.20 users, but they were all power users to begin with).

Thanks for sharing your strategy, and best of luck!

Regards,

Matt

0 Kudos

I recently completed the build of an installation package to upgrade colleagues at my company from SAP GUI 7.20 to SAP GUI 7.30.

I took the following approach:

  • Used SAP GUI Installation Server to build out a patched version of 7.30
  • Maintained SAP portion of services file in a text file located on our installation server along with saplogon.ini, saplogontree.xml and branding logo
  • Wrote VBScript within the package to lay down registry keys pointing clients back to our server to reference a centralized SAP Logon Pad
  • Wrote VBscript to append entries to client services file based on what we have maintained in a text file on our server
  • Wrote VBScript to copy text file to client machines to track versioning (GUI Version, Hotfix, Patch, Date Compiled)
  • Compressed installation package into single file installer
  • Deployed single file installation package to to SCCM along with separate VBScript.
    • The VBScript is what we have running from SCCM on end user machines to determine whether or not the installer can be initiated (cScript is used to kick off what has been written).  The script checks to see if saplogon.exe is running.  If the process is running, we inform the colleague that an upgrade/installation is in progress and that they need to close out of their SAP sessions (including logon pad and web sessions).  They have two options - retry and cancel.  If they choose retry and have not closed their sessions, they are prompted again until they have closed out of their sessions and hit retry.  If they select cancel, the update ceases and they can run the installation on their own (as opposed to the automatic push from SCCM).  If their sessions have been closed down and retry is selected, the installation package runs in noDlg mode.
      • I decided to take these steps because I noticed that if you try to run the 7.30 installer while 7.20 sessions are open, the installation is corrupted.  Additionally, my team doesn't want to close SAP sessions via script if for some reason important work is going on (we operate 24/7, so this is often the case).  The noDlg option was chosen because I saw that end users tended not to select the package I built when prompted to do so through the installation wizard (even after providing detailed installation instructions), thus bypassing all customization provided through the scripts included in the installation.

0 Kudos

Hello Matt, Thanks for the mention
Since April,Windows XP has now also been withdrawn from support.

See note http://service.sap.com/sap.support/notes/66971


0 Kudos

Those are some really good points Jeff.

Questions:

1. It's only been a year, but any chance you've had experience moving to 740 in the hopes that the SAP installer will detect running saplogon.exe processes to remove the need for a script?!

2. Can you elaborate on the benefits you get from that text file containing version information?

3. When you have patches, do you update the product and then provide a new single-file-installer EXE to SCCM for distribution (along with something related to #2)?  I'm guessing similar saplogon.exe checking processes from #1 apply as well?

4. Any experience with the new XML central file storage (along with the pull method)?

Thanks for any input/guidance you have!!

Eric

0 Kudos

Hi Eric,

We are currently in process of preparing to roll-out SAP GUI 7.40.  From what I have read and experienced in testing, 7.40 no longer supports access method F in SPAD (which leveraged saplpd.exe included in GUI installations) - we are switching those printers using access method F over to access method G.  After confirmation that this switch will cause no issues with print procedures, we will be moving to a more formalized testing of the new GUI.

To answer your questions:

1) We will be sticking with our current installation script as it worked very well last year.  I have not tested to see if a new installation package would pick up those saplogon.exe processes.

2) Our administrator who manages SCCM did not seem to be able to pick up the patch or hotfix associated with an SAP GUI installation.  The versioning file allows us to post an updated version of an installation package, scan clients running SAP GUI to determine if an update is needed and automatically deploy the software if needed.

3) Yes to each question asked here.

4)  No experience with the new XML central file storage.  It has been several months since I looked into this, but I believe that XML file shows up when NWBC is introduced to the setup and that is something my company does not leverage.

I hope this helps.

Thanks,

Jeff

Former Member
0 Kudos

We have quite a large number of SAP Printers defined using access method 'F'.   It was simpler to download SAP Note 2028598 - SAP GUI 7.40: Front-end printing with access method 'F' no longer works.  This saved us some time in changing the printer SPAD setting or user profiles.  Just an option to think about.

Cheers,

Dan Mead