General advice on using SCCM (SMS) to deploy SAPGUI

[Former Member]

I was curious for anyone's opinion on the use of Microsoft's SCCM tool for deploying SAPGUI. At our organization, I am hoping to take advantage of this capability so that the SAP technical team is not "too" involved in the day-to-day deployment activities.

Some specific questions:

1. The only way to do this is to create an SAP installation server so that you can then create the single installation package (and then hand it over to SCCM)?

2. Assuming I am correct on #1, to patch the GUI, youu2019d have to patch the installation server and create a new installation package and let SCCM advertise it out (i.e. not make use of any of the SAP techniques (e.g. the new automatic workstation updated).

3. How have you managed the distribution/update of files (saplogon to the u2018newu2019 location, services, etc) on the PCs --- via the package scripting capability of the SAP installer (OSS 1035560)? I had the idea to request this capability of the SCCM team as well!

Thanks for any input!

[Former Member]

Thanks for the great info.

If you have a need to make changes to the 'other things' (INI, services, etc) that you do with Wise, how do you manage deploying them without building a new overall package (i.e. without patching the SAPGUI)? In Add/Remove Programs, do you have one entry for SAPGUI and another for your custom things?

[Former Member]

If there are any updates to the INI's in the future, they are pushed to machines through SMS and updated in the Wise script. That way if its a fresh install, it is already updated with the installer..

For the add/Remove programs, we have 1 single uninstall point. It is a Wise script which calls the SAP GUI uninstaller.. Upon completion, removes our registry entries, updates the services file (removes the info we added), desktop shortcuts we create and folders. It took a few months with the help of an SAP consultant but it works rather well.

Regards,

Zecher

[macarranza]

Something that works really well for us:

1. Create the package on the installation server.

2. Compress the package to a single-file installer (executable). This feature is available in the installation server.

3. Use whatever method (SMS?) to run that executable on the client PC. There is a silent option if you prefer.

4. Have a standard .ini file that resides on a network drive (a DC is an excellent place for this). After all, if your users don't have access to the network, then they don't have access to SAP.

5. Push an icon to the user's PC that runs saplogon with the /INI_FILE option to point to the network .ini file.

6. If your users use NWBC, push the registry entries needed for the connections.

That's it! Any changes to the .ini file that you need to distribute can be easily done by changing the .ini file in your network drive. Just make sure it's read-only to your users so only you can change it. Any changes to the NWBC connections can be distributed by pushing a registry entry.

For GUI updates, you can update the installation server and repeat steps 2 - 3.

[Former Member]

More good feedback!

Two questions:

1. What if it is just the network share where the INI file is located that is not available -- and not the whole network?

2. Did you make use of the SAP installation server package scripting to do services file udpates (e.g. sapmsSID)?

FYI - I have done the approach of the self-installer and are having mixed results so far (and have a ticke topened)

- on my machine that had SAPGUI 710 from another installation server, it said it finished, but did not actually seem to work - tried multiple times and nothing stood out in the nwsapsetup logs. i ended up running from the install server and it worked.....

- worked great on a machine without SAPGUI installed

[macarranza]

1. Use a high availability system like the domain controller for the .ini file... if the DC is down, nobody gets to the network anyway

2. We push a standard services file via SCCM to every user. So they have the SAP entries that they'll need there

We've had very few issues with the self installer. On PCs that have issues, we use a different sms package that uninstalls the old GUI, forces a reboot and then installs the new GUI. So far it's worked well.

Be careful with your packages... especially on 7.20. It's very picky as to the pre-requisites. So if you install the Outlook or MS Office addons but the PC doesn't have the product installed, you'll get some cryptic errors. Always have a basic (SAPGUI only + NWBC if you use it) with no addons that you can deploy to problem PCs to rule out incompatibilities or missing dlls.

[Former Member]

We have multiple agencies which have thier own method of deploying out to their end users. Mostly through SMS (or whatever it is called now a days) but that is up to the agencies requirements.

Here I will elaborate on your questions and divulge a little of our situation.

1 - Correct. Create a Installation server and build the package. From that package it can be put into a SMS package and deployed. (we use this method)

2 - Yes and also. Yes, you can update the Installation server and re-create your package with the updated patch included. I believe you would also need to remove the SAP GUI to re-install the new with the updated information. My advice would be to utilize SMS to push just the patch from SAP to your end users which will update the existing machines with the already installed SAP GUI. (We use this method)

3 - We utilize the variable SAPLOGON_INI_FILE which you can point the machine to an area of your choice to where your saplogon.ini file is located.

Our use:

We use both the installation server as well as Wise Studio for our package. Installation server creates the SAP GUI deployment. Wise Studio comes in and allows us to set variables and allows us to have a predetermined INI laid on the machine. (We have low speed connections as well as disability users and General users etc. Depending on switches used during the push install or manually, it will drop a copy of the INI as requested which is built into the Wise "wrapper" we created) It also allows us to place SSO information and files, registry info, additional INI's which are specific to our landscape. The Wise installation then calls the SAP GUI installer created from the Installation server. At the end of the GUI install, it places the predetermined INI file over the one created at the point of install. (Keep in mind this is just a brief overview)

I am sure there are other possibilities but these are just from our experiences here. I would have to let others speak to how they perform such operations.

Regards,

Zecher

Edited by: Michael Zecher on Jun 10, 2011 10:39 AM