Software Deployment

I've recently packaged and deployed SAP 7.10 to more than 3,200 (and rising) machines and the one thing I was told before starting was to NOT repackage it into a MSI. In fact, I was told that if we did use an MSI that SAP wouldn't provide support for the client. I don't know how true the threat was but it was still there.

I used the SAP method (see file NwCreateInstServer.exe) of creating a "Server Installation" of the software and then using SMS to deply this to machines and a VB script to run the install. The Server Installation is basically a folder containing all the files / folders etc that SAP needs to be installed onto a PC. When the install command runs from the VB script it installs SAP onto the PC using the data in the Installation Server folder.

It's quite a neat way of doing it as makes patching / upgrading the client really easy. All you need to do is patch the Server Installation folder (using the NwUpdateInstServer.exe tool), upload this back onto the SMS Distribution Points and re-run the advert. I've tailored the VB script to check to see if SAP 7.10 is already installed on the PC, if it is, the install is run but with a "/update" switch. This applies only the patch / update stuff; there is no need to remove & reinstall the application.

Have a look [url=http://www.id.uzh.ch/dl/sw/sap/SAPGUI/SAP_FE_Instguide_710.pdf]here[/url] for more information on creating non-MSI installation.

Good Luck!

Hi ajasra

I have just successfully packaged SAP GUI 7.10 after encountering the same problem as you. After capturing the install (with installshield - repackager) and building a dirty MSI (e.g. an .msi that has not been cleaned up just to check basic functionality of the app.) I found that when it was installed and I clicked a shortcut nothing happened.

After a lot of head scratching I got to the bottom of it.

I installed my non functioning .msi on a machine with a vanilla clean build of XP. I then used a lightweight capturing tool called InstallRite which is freeware to take a snapshot. I then uninstalled my MSI (you would not usually need to do this but SAP can tell that it is installed and will not install over the top of it) and installed SAP GUI again from source. I then ran a capture using InstallRight. I then, using InstallRight created an .exe containing everything it had captured.

After reinstalling my faulty .msi again I ran the new .exe created by InstallRight. When I then clicked the shortcut (advertised) the .msi started a repair and the application launched correctly.

Ok so what was wrong?

What had installshield missed?

Well after narrowing it down, the files that we not installed were files destined for the C:\WINDOWS\WinSxS directory. This directory falls under windows file protection and your .msi will not install to it. Installshield/Wise would have captured these files but they should have been excluded and if included in your .msi they would not have been installed.

The files destined for C:\WINDOWS\WinSxS are actually installed by a .msi located within the SAP GUI 7.10 source. If you look you will find 3 .msi files and the one causing the problem is Microsoft c++ Redistributable. You will notice it gets installed first during your capture of SAP GUI 7.10

So what do you need to do well first, get the 3 .msi files packaged up as pre-rec's for your capture of SAPGUI ( just slap a transform on them ;-) ) or manually install them for the purpose of your capture. (One of he golden rule's of packaging is you don't capture .msi files, if you want to know why you dont capture .msi files google Darwin Descriptors)

Install them on your capture machine

Then capture the install of SAP GUI 7.10 as normal. (SAP will see the prerecs are installed and will not try to install them)

Build your .msi and your shortcuts should now work.

Other points regarding SAP GUI 7.10

Services file wrote to. Try adding a custom action to handle this. (Both adding and removing)

One of the shortcuts icons was missing and it was showing as un-associated. The icon is a .cpl. Not sure if it is just installshield that does not like .cpl extensions. This might not happen using WISE. But if it does try exporting the binary data from the icon table to a file, renaming the file to .ico and then re-importing back to the icon table to be stored as binary data again. You will also need to change the file type on any related table as well. This procedure will need to be done directly on the .msi using ORCA.

Anyway hope this helps. Any questions please feel free to message me and I will do my best to help.

Good luck & Happy packaging.

ORIGINAL: tennis1
what was your command line parameters for sms, i am getting dll errors when using sms.


I used this:

[font="courier new"] SAPCHKFIL = "C:\Program Files\SAP\SapSetup\setup\SapATL71Wksta.xml"

If objFSO.FileExists(SAPCHKFIL) Then
SapInstCmd = "SAP-GUI-7-10\SAP-7-10-BASE\Setup\NWSAPSetup.exe /package:"&Chr(34)&"SAP-7-10-BASE"&Chr(34)&" /update /noDlg"
Upg = 1
Else SapInstCmd = "SAP-GUI-7-10\SAP-7-10-BASE\Setup\NWSAPSetup.exe /package:"&Chr(34)&"SAP-7-10-BASE"&Chr(34)&" /noDlg"
End If

XErr2 = oShell.Run(SapInstCmd,1,True)
[font="courier new"]
It checks for the existance of the SapATL71Wksta.xml file.
If found, a /update install is performed so that if the base installation has been upgraded, it will be applied to the client
If the file is not found, a full install is run

If run directly from the command line (i.e. not using SMS) the install commands would look like this:

SAP-GUI-7-10\SAP-7-10-BASE\Setup\NWSAPSetup.exe /package:"SAP-7-10-BASE" /update /noDlg
SAP-GUI-7-10\SAP-7-10-BASE\Setup\NWSAPSetup.exe /package:"SAP-7-10-BASE" /noDlg

Where SAP-7-10-BASE is the name of my application server installation.

It's worked for me!

No-one here will have a clue what your re-package contains, so how will they know what could be wrong? Use a process monitor like ProcMon to see what's missing.

BTW, as a matter of routine, having been burned early on in the process of learning about packaging, part of my packaging process is to run the vendor's install over the top of mine, using a lightweight snapshotting tool (I use Ziff-Davis's In Control - Google for 'InCtrl5.ZIP) to determine any changes. Your situation is vaguely similar so:

- install my MSI
- do a 'Before' snapshot of the machine
- run the vendor install
- do an 'After' snapshot of the machine
- add the *relevant* changes to my MSI.

This way, you can be pretty sure you got everything the application requires in your MSI.

I've recently packaged and deployed SAP 7.10 to more than 3,200 (and rising) machines and the one thing I was told before starting was to NOT repackage it into a MSI. In fact, I was told that if we did use an MSI that SAP wouldn't provide support for the client. I don't know how true the threat was but it was still there.

I used the SAP method (see file NwCreateInstServer.exe) of creating a "Server Installation" of the software and then using SMS to deply this to machines and a VB script to run the install. The Server Installation is basically a folder containing all the files / folders etc that SAP needs to be installed onto a PC. When the install command runs from the VB script it installs SAP onto the PC using the data in the Installation Server folder.

It's quite a neat way of doing it as makes patching / upgrading the client really easy. All you need to do is patch the Server Installation folder (using the NwUpdateInstServer.exe tool), upload this back onto the SMS Distribution Points and re-run the advert. I've tailored the VB script to check to see if SAP 7.10 is already installed on the PC, if it is, the install is run but with a "/update" switch. This applies only the patch / update stuff; there is no need to remove & reinstall the application.



No vendor ever supports repackaging their app, so this isn't a revelation. It's good that SAP's resource-intensive, proprietary and (I'm guessing) very expensive installation method worked for you, but a lot of people have to repackage into an MSI if the vendor doesn't do that. We looked into SAP's method and they would have had to get expensive SAP consultants to set up the back end, server, etc. So I did the repacakage and we've deployed it to thousands of machines. By the time it gets fully installed it'll be 20,000. So far, so good -zero problems, zero support calls relating to the package/installation. Not to brag or anything, but I am pretty hot stuff! [8D]

Having said that, it is a very complex package that I'd never want to give to a newbie, and even I was on pins and needles for a while until I'd reached a comfort level (this was a very important app and user tested more than the usual MSI). When it comes down to it, the vendor EXE does the same thing an MSI does: files, registry entries, environment variables, etc. With SAP you've even got .NET assemblies to worry about (that was fun to capture!).
So, let's say that he has to repackage this. Here is the advice I'd give:

The more transparent you can make your repackaging process the better; do what Ian suggested with incntrl, look in the cab files if there are any or temp folder when installing to see exactly the files that get installed and where; copy the shortcuts off so that you can make your MSI shortcuts exactly like the vendor's; strip out any dependencies like MDAC and .NET and handle them separately; before you start your capture make sure you've got .NET installed on your packaging machine and have .NET installation set as your package type in your repackaging tool (I use Wise, assume Installshield has th same option).

I hear that 8.x is going to be MSI but I don't work closely with SAP. You may want to check on that and see if that's an option.

Good luck!

No vendor ever supports repackaging their app, so this isn't a revelation ... I know this but when there is so much riding on a successful deployment of something like SAP, I thought (for once!) it would be better to do as I'm told. It was thr first time in 3 years of packaging I've actually followed a vendors / managers instructions [:D]

We had already got the teams in place for the back end servers and as for the cost of deployment, as we're using AD & SMS (as we do with all our apps), SAP 7.10 is no different. I'd be interested to know how you go about patching / upgrading SAP 7.10 after it has been installed on a machine as an MSI? This is the first non-MSI package I've ever deployed and I have to admit I too had some scary moments but looking back at it now, the SAP packaging method is pretty easy.

As for being hot stuff ... I got a personal letter of thanks from our CEO for my deployment of SAP, so I'm a tad over luke warm [;)]

No vendor ever supports repackaging their app, so this isn't a revelation ... I know this but when there is so much riding on a successful deployment of something like SAP, I thought (for once!) it would be better to do as I'm told. It was thr first time in 3 years of packaging I've actually followed a vendors / managers instructions [:D]

We had already got the teams in place for the back end servers and as for the cost of deployment, as we're using AD & SMS (as we do with all our apps), SAP 7.10 is no different. I'd be interested to know how you go about patching / upgrading SAP 7.10 after it has been installed on a machine as an MSI? This is the first non-MSI package I've ever deployed and I have to admit I too had some scary moments but looking back at it now, the SAP packaging method is pretty easy.

As for being hot stuff ... I got a personal letter of thanks from our CEO for my deployment of SAP, so I'm a tad over luke warm [;)]

That's cool, and I certainly didn't mean to criticize or imply that you guys are less than proficient. There were times I'd have liked to hand over the project and say, "you guys (SAP people) deal with it!" However, doing things the supported SAP way took more time and resources than we had, so here we are.
We actually repackaged 6.4 (don't ask....) but it's probably similar to 7.1 being non-MSI. For upgrading and patching, we'll add the upgrade code to either a repackage of 7.1 or (hopefully) to the 8.x version which is supposed to be MSI. If a patch comes out that needs to be deployed we'll have to manually create a patch and roll it out.

Cheers Owen!

The previous versions of SAP our company used (6.20, 6.40 etc) were re-packaged into MSI's and deployed as such but I was asked / told to not do this with 7.10 for the support reasons.I have to admit that I haven't actually tried to re-package 7.10 into an MSI but I guess it probably could be. However, and this did surprise me, I actually quite like the SAP install method as it meant that for once, I didn't have to worry about MSI errors, custom actions, install executre sequences etc - it's been like a packaging holiday :)

ORIGINAL: DLL_HELL
I then uninstalled my MSI (you would not usually need to do this but SAP can tell that it is installed and will not install over the top of it) and installed SAP GUI again from source. IIRC, the installer does a file-existence check, that's all, so renaming that file obviates the need to unistall everything. As ever, ProcMon will show you that kind of thing.

As for vendors not supporting re-packaged apps? In my experience, they barely manage to support their own products to what I would regard as a professional level, much less their installers. However, doing the "snapshotting the vendor install over the top of your own" exercise enables you to be sure your package mimics the vendors. Admittedly SAP is probably a special case but dangling a purchase order for a competitor's product or contemplating the cancellation of the support contract generally focuses the mind: threats work both ways.

This directory falls under windows file protection and your .msi will not install to it News to me...check your IS/WPS help files if you're unsure.

Thanks,
This information is very useful,as i was facing the same issue & after preinstallation of these three msi it works fine for me too.

Keep sending such valuable inputs.

This thread is pretty old, but now i've been tasked with (shudder) repackaging SAP 7.1 and I'm running into the same problems a lot of other folks have described. Beginning to wonder if anybody has actually repackaged this successfully. 6.4 seemed pretty straightforward compared to this, although it was also big and ugly. Before wasting hours, weeks or months of time I'd like to at least investigate the other method. If it doesn't require an army of expensive SAP consultants to set it up, this might be the way to go. thanks! Owen

We used the SAP Installer and it was a bit of a nightmare as when you run it with the /Silent switch it loses all its intelligence (what little it had) and if it goes on a machine twice it breaks. Luckily we deployed via SMS so unless an advertisement was forced to re-run it wasn't too much of a problem This is what we did anyway:

We used the SAPSetup Installation Server Administration Tool (NwSapSetupAdmin.exe). A new SAP package called “FULLINST” was created that performs a full installation of SAP and Business Explorer. This is then written to the xml files. We went for a full installation so I would never have to revisit it to add components. We could just deploy patch levels on top instead which installed ok.
The command line install the program was: \Setup\NwSapSetup.exe /Silent /Package="FULLINST" The SMS deployment consists of a SMSNotify popup, a directory and registry cleanup script, the SAP GUI installer and a Finishup script which copied over some dlls that we need for some SAP integrated Word macros.

what was your command line parameters for sms, i am getting dll errors when using sms.

Anybody have any suggestions on how to package and deploy this using wise package studio and group policy. This has been a struggle.

If the NWSAPSetup.exe isn't already an wrapper for installing an embedded MSI then why not create an MSI wrapper instead to execute the NWSAPSetup.exe + parameters?

What wrapper package are you using.

What wrapper package are you using. Er, Kim was suggesting that YOU wrap up the EXE in an MSI.

Our organization has decided to go with the SAP admin install for 7.1. Although not MSI, it does seem to be a well thought out system (netweaver is the name of the installation engine). Also influencing the decision: it removes previous SAP install versions 6.2 AND 6.4, command lines can be packaged for SMS, the difficulty with repackaging into an MSI, and of course lack of any vendor support for repackaging. Also, I remember hearing last (6.4) rollout that it would take "SAP consultants" (read $$$) to set up the admin server. Apparently this necessity is no longer. I'll keep an eye out for problems already brought up here. If anybody has run into any other "gotchas" doing it this way I'm sure we'd appreciate hearing about it. Thanks!

Also progressing through creating an MSI for 7.10.

Installed .net Framework 2.0, MSXML4 SP2 and Visual C++ 2005 SP1 as prerequisites. .net 2.0 is in our standard image, the other two are unpacked temporarily by the SAP exe, I used our estates existing packages for these apps and they worked fine.

If you do a standard install using the SAP installer then it creates a number of log files depending on your system configuration, these were installed under a separate directory under the Program Files->SAP folder. Can be useful for investigating what the default install does.

I had to create some ini files manually for the default connections, I expect this may differ for other organisations. These are stored in the system32 folder, not tested it yet but I would assume the user will need write access to one or more of these files for adding or changing entries.

Also required is Sun JRE but this isn't needed as a prerequisite for installation.

If UAT produces anything else I'll post again.

I repackaged this a while ago after some initial problems with the capture. One of the main problems is Wise choosing to populate the SelfReg Table with hundreds of entries. Remove these, if your Wise Setup has entered them.

Obviously each organisation will be different with regards to configuration settings and management of saplogon.ini etc but there are lots and lots of separate threads on this forum regarding the MSI repackage. This is simply a message to let you know that it is entirely possible, not that difficult, and I've deployed to 3,500 machines without one MSI induced issue.

Apart from the gobshites who had created customised shortcuts on their desktops and raised priority calls the day after rollout when they couldn't open their tills for customers! You can't legislate for this unfortunately. :)

One of the main problems is Wise choosing to populate the SelfReg Table with hundreds of entries. Remove these, if your Wise Setup has entered them. ...but only if you're daft enough to let Wise use it. Most WPS users will have theirs set up to use the advertising tables instead.

Hello All,
I am a newbee on SAP. I need to deploy SAPGUI 7.10 to some users. I have packaged the the software with NwCreateInstServer.exe as written on Earl's post.
My problem is this: I have a SMS site server and 5 DP. I created a SMS pacakge from the install server package I created thru NWSAPSetupAdmin and distributed to all DPs. The clients at the regional sites with DPs are pulling from the site server. I need to make the clients pull from their DPs. because pulling from the site server took 1 hour for the software to install. I pointed SMS to run this batch file at the program level:

\\Server\Shared folder\NwSapSetup.exe /NoDLG /Package="my package"

Everytime the clients at the regional site try to run the file pointing to the site server which I do not want.
PLEASE HELP IS NEEDED URGENTLY. I am running out of time.
Any suggestions will be highly appreciated.

I think your post really belongs in the 'SMS' forum, since your problem seems to me to be more to do with the deployment than the package itself.

[font="Times New Roman"][font="Times New Roman"]I found that their is a server component in the setup file called NWSAPSetupAdmin.exe. This is cool I installed it on my vm winxp of course. From here you can create your own package yes it is a setp.exe, but half the job is done all you have to do is create a batch file. Another way of setting this up is install it on a windows server, Create a package then Execute Remote Application wmi. Sorry i don't have that much wise experience but i needed to roll this out or my boss would kill me.



http://www.id.uzh.ch/dl/sw/sap/SAPGUI/SAP_FE_Instguide_710.pdf






Don't try so hard[/quote]

[font="Times New Roman"]In advertisement Properties click the tab Advanced Client

1. When a distribution point is available locally:

Run program from distribution point


2. When no distribution point is available locally

Run program from a remote distribution point.