Software Deployment

ORIGINAL: aogilmor
ever seen this behavior? Sorry, Owen, I haven't, no.

When you say that you 'tried this', you mean using WiseComCapture instead of relying on Wise's population of the SelfReg table?

In this situation, I'd use my FindCLSID script to seek out the file which contains the class ID referred to and get into its guts, probably running WiseComCapture against it on its own. Or maybe, just maybe - if it had no dependencies other than standard-issue XP stuff or stuff in our build - take the King's Shilling and run RegSvr32 against it.

BTW, I always ditch the 'HKCR\Component Categories' stuff...

Ramesh, is it a repackage or a vendor MSI? I did a repackage on 6.4

If a repackage, become an expert in the Windows Installer database so that you can find your way around the SelfReg table. If you use Wise, several dll's will be put in there that get errors. Be aware that some components of the sap installation modify the services file so talk to your network folks and have a clean way of dealing with that, either externally or in the package. Again if a setup capture save your shortcuts from the original installation so that you'll know where the icons, working dirs etc. are supposed to be.

Lastly, have your users TEST, TEST, TEST. Then test some more. I was kind of fortunate in that there were other people doing UAT who had users hammering away at my installation. They found a few problems before it went live, which was good -- saved lots of work on the back end.

ORIGINAL: aogilmor
If a repackage, become an expert in the Windows Installer database so that you can find your way around the SelfReg table. Owen, what are you doing? Have you lost The Faith? :) Surely the advice should be to get those entries OUT of Selfeg and handled properly? I appreciate that the OP is new but we must teach good habits.

ORIGINAL: VBScab

ORIGINAL: aogilmor
If a repackage, become an expert in the Windows Installer database so that you can find your way around the SelfReg table. Owen, what are you doing? Have you lost The Faith? :) Surely the advice should be to get those entries OUT of Selfeg and handled properly? I appreciate that the OP is new but we must teach good habits.


Ian, I did see your later post regarding SelfReg in the Wise thread and I have "seen the light", hallelujah! ;-)

Seriously, I did not know some of the things you posted about the SelfReg table. I know that SelfReg is no longer recommended by MSFT. I know sometimes Wise puts DLLs into SelfReg that get errors. I did not ever consider the export/import COM registry technique (which I guess would work even if a vendor DLL insists on self-registration?....) I thought that Wise added the COM registration entries automagically. Basically I ran through and deleted all the selfreg entries that got errors. Next time I'll probably do it differently (if there is a next time, repackages are becoming more rare).

Thanks!

ORIGINAL: aogilmor
I thought that Wise added the COM registration entries automagically. It does but sometimes (careful!) it does a poor job. A case in point is JRE: some of the DLLs therein contain the DLLRegisterServer entry-point but don't actually contain any COM information. These are easy to spot after running WiseComCapture (see caveat below) as the resulting .REG files are around 78 bytes in length and contain only the .REG header.

The caveat is that WiseComCapture *sometimes* produces such files when it's not run against the DLLs in their own path. That is, if your files are in, say, 'C:\Program Files\PDF reDirect' and you do:

C:\Program Files\Altiris\Wise Package Studio\Windows Installer Editor>WiseComCapture.exe "C:\Program Files\PDF reDirect\ccrpftv6.ocx" "C:\Program Files\PDF reDirect\ccrpftv6.reg"

or

C>C:\Program Files\Altiris\Wise Package Studio\Windows Installer Editor\WiseComCapture.exe "C:\Program Files\PDF reDirect\ccrpftv6.ocx" "C:\Program Files\PDF reDirect\ccrpftv6.reg"

you may end up with a 78 bytes file. If, however, you do this:

C:\Program Files\PDF reDirect>C:\Program Files\Altiris\Wise Package Studio\Windows Installer Editor\WiseComCapture.exe "C:\Program Files\PDF reDirect\ccrpftv6.ocx" "C:\Program Files\PDF reDirect\ccrpftv6.reg"

you get a correct .REG.

In summary, I routinely ditch whatever WPS has produced automatically and run my WiseComCapture-running script which changes to the relevant directory before running the EXE. Then I can be sure that any .REG which contains just the header was produced by a DLL which has the DLLRegisterServer entry-point but no COM information.

Hey VB, I tried this on a recent package and got a lot of strange looking reg entries in Wise Installation Expert, one key hkcr\Component Categories\{guid}, one hkcr\<blank key>\CLSID\{guid}\OldFont\Obsolete Font

there are several more that look "funny" and I'm hesitant to drop the SelfReg table and substitute the reg entries themselves.

Also, Some of the components self registered already have reg entries under hkcr so maybe these are it....?

ever seen this behavior?

previous version of SAP were MSI format already. There is a packaging tool for prior versions I would think it would be a major step backwards to drop that in newer versions. (I can only assume this has been retained.)

Things to watch out for are.

Check the hosts / services files are not being replaced.

Saplogon.ini file entries could be different in various business units throughout the business. As such you may need to have multiple saplogon.ini files for each location. How you get them deployed is up to you.

May be useful to get friendly with the dns admins as well as some cleverly thought out DNS magic can help.

Has anyone successfully made an MSI out of this one? I've managed to capture the main installation with Wise but the installation behaviour of the SAP Installer is so flakey. We're bundling in the latest patch level (7) with our capture so we're up to date - yes I know this isn't the ideal scenario but it's what I've been asked to do. Sometimes the installer runs, and sometimes it doesn't... Sometimes the patches run and sometimes they dont.. The machine state is consistent so I haven't a clue whats causing it to fail! The only pre-requisites I have are .net 2.0 and JRE 1.6.

The sapsetup logs show the following when it fails to run:

SAP Setup libraries information
-------------------------------

NwSapSetupEngine.dll: 8.1.0.55
NwSapFeiUt.dll: 8.1.0.55
NwSapFeiKr.dll: 8.1.0.55
NwSapFeiLg.dll: 8.1.0.55
NwSapFeiSh.dll: 8.1.0.55

********************************************************************************

16:59:48 NwSapFeiKr 2 SAP Frontend Installation Kernel initialized
(Unicode Release build)
16:59:48 NwSapsEngn 1 SapSetup Workstation Engine Library Loaded
16:59:49 NwSapSetUI 1 SapSetup UI Library Loaded

Then Blank...

I've tried installing it on a variety of VMs and PC builds to no avail - just the same inconsistent behaviour of 'sometimes' running.

Has anyone come across this before?

Thanks

Mucho Gracis to this gentleman.

http://www.appdeploy.com/messageboards/fb.asp?m=34511

SmartMonitor hangs the installation.

Muchas gracias for the reply; I'm getting to try this again on another repackage. There may be a series of repackages I have to do.

Yes, previously I tried Wisecomcapture and ended up with some "funny" looking registry keys.
For the package I'm doing now, I "weeded out" the obvious wrong entries (the selfreg entries that get errors installing) and for the rest of the selfreg entries I am going to try WiseComCapture, keeping in mind the path anomolies you pointed out above, and if that doesn't work regsvr32. Thanks!


Owen

Thanks again, I am now starting to use wisecomcapture to generate reg files so on this package I will not have any hated selfreg entries.

I can confirm that wisecomcapture.exe is very fickle when it comes to path and won't even throw an error, just put a 1k blank reg file wherever you tell it to. So you have to juggle it and find out which path "works" If the file cannot be self registered then regsvr32 would throw an error; I suppose you could use that as a last resort to find out if you even have a file that can do this.

Owen