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