Software Deployment

FWIW, because of GP's....shall we say...foibles, I always a) use a specific group to assign to each package and b) set packages to uninstall when users are no longer members of the relevant group. This means that upgrades never happen: the old version is removed, then the new one installed. That doesn't help you, though, does it?

Although the log you took may not contain any errors, it *will* contain the information required to work out why the upgrade hasn't been performed. Is it possible, for example, that 6.5 was installed per-user whereas XI is per-machine?

You say that *you* set the package to upgrade. I presume this means that you have manipulated the Upgrade table, etc.? I would think that, if a straight upgrade were possible/supported, the vendor would have set that up. Does the documentation for XI say that any previous version must be uninstalled first?

Hey VBScab - thanks for your quick reply! In this case, the team who requested the BO rollout wanted it on all machines, so we didn't scope it down to a specific group. Also, I don't think this would've helped in our case, as it seems the uninstall logic in the MSI is somehow broken - so regardless of how the uninstall is triggered, it's not gonna work.

I definitely set 6.5 to install per machine - we generally do everything on a per machine basis to prevent delays from a user's perspective. If I run the msiexec /x command, with a /lv <logfile> switch, is that the log that will provide useful info?

Regarding the upgrade - I haven't manipulated the MSI at all. I'm using the upgrade feature in GP where you specify "Advanced" when assigning the package to the Computers section, then on the Upgrades tab choose the GPO/package that you're upgrading, and specify that windows installer should remove the selected package first before installing the one you're adding. We've used this method a lot in the past and it's been helpful - as you can then stagger the upgrade by using a group to control who can read the upgrading GPO (instead of having to remove the package from the old GPO, uninstalling it from ALL machines). But I'm not too worried about the upgrade process - it's just the uninstall of BO6.5 (even manually) that's the bugbear...

Appreciate your help!
Ray

I assume the answer is yes as it's one of the most basic QA checks but does the app install / uninstall manually (forgetting group policy for now) ?

Cheers,
Rob.

the team who requested the BO rollout wanted it on all machinesAny vacancies there, Ray? Clearly, the company/organisation has money to burn so this sounds like a great opportunity for me to bump up my rate.

The log file switch I use is '/L*V <logfile>'. That'll get you everything.

You may want to add a process/file/registry monitor to the mix, to pick up any absent files or permission issues.

Rob, from the sound of it it's just the uninstall of BO6.5 (even manually) that's the bugbear. the answer's "No."

Rob - i must've forgotten to check the uninstall - doh! Silly me.

Hehe no vacancies i know of vbscab ;-) Access to BO is controlled via the login I think - that's probably how they justify the rollout to all machines - only certain users have access to log in to BO.

What should I check for in the log file? Right at the end, it's got an entry indicating successful removal:-

MSI (s) (D8:38) [13:42:53:416]: Product: BusinessObjects 6 -- Removal completed successfully.

Yet it's still there... any ideas?

What should I check for in the log file? Right at the end, it's got an entry indicating successful removal:-

MSI (s) (D8:38) [13:42:53:416]: Product: BusinessObjects 6 -- Removal completed successfully.You should see a whole L O A D of entries removing files, directories and registry entries as well. Are they present? Examples (not for BO, but you can use as a template for what to seek out):MSI (s) (30:CC) [13:02:50:747]: Executing op: FileRemove(,FileName=igMdi3.2.1.0.xideSettings,,ComponentId={B8E3FE58-C731-4FCC-9B88-6A3CEBE596AC})
MSI (s) (30:CC) [13:02:50:763]: Verifying accessibility of file: igMdi3.2.1.0.xideSettings
MSI (s) (30:CC) [13:02:50:763]: Executing op: ProgressTotal(Total=2,Type=1,ByteEquivalent=175000)
MSI (s) (30:CC) [13:02:50:763]: Executing op: FolderRemove(Folder=C:\Documents and Settings\All Users\Start Menu\Programs\SOLCORP ProductXpress\Designer 3.2.1\,Foreign=1)

Nope, don't see any entries like that in mine...suspect it's not even getting to that stage. Can I send u my log somehow? Or should i post the whole thing here? How did you post your example in a block like that? Sorry man, not too experienced with windows installer logs, don't really know what to look for...

You can post the whole log - just use the <% code tag on the toolbar, otherwise the post will be huge!

You can always preview the post first if you are unsure.

Cheers,
Rob.

Hey guys - sorry i'm not having any luck posting the log - there's too much data :-( and slow internet speeds here in Africa don't help!!

Any chance I could email you guys? I could zip the file first (it's 3MB unzipped) and hopefully get it down to a more reasonable size...

Thanks!

Zip it up, upload it to senduit.com then post the link

Wow what a helpful site!! Will definitely use senduit.com in future!! Have a great weekend guys...

Here's the URL: http://senduit.com/a8d86b

Sorry, folks, my client has wised-up and blocked Senduit :( Could someone else have a peek at Ray's log, please?

upgrade BO 6.5, I discovered that BO 6.5 can't be removed! I then tested with a machine in an empty OU, with JUST the policy for

Not sure, but if I recall correct, BO had to be uninstalled in a specific sequence:
Uninstall the Fix Pack for 4.5
Uninstall the SP4
Uninstall the FixPack for SP3
Uninstall the SP3 ..and so on

Note sure, but I see this:

MSI (s) (D8:38) [13:42:41:806]: Command Line: REMOVE=ALL CURRENTDIRECTORY=C:\Documents and Settings\<censored> CLIENTUILEVEL=2 CLIENTPROCESSID=900
<...>
MSI (s) (D8:38) [13:42:41:822]: PROPERTY CHANGE: Adding REMOVE property. Its value is 'ALL'.
<...>
MSI (s) (D8:38) [13:42:44:806]: Feature: bo; Installed: Local; Request: Null; Action: Null
<...>
MSI (s) (D8:38) [13:42:44:806]: Feature: bo.vba.common; Installed: Local; Request: Local; Action: Local
<...>
MSI (s) (D8:38) [13:42:44:822]: Feature: bo.vba.en; Installed: Local; Request: Local; Action: Local
<etc>

At the bottom of the log, I see that REMOVE is still ALL, so nothing seems to be changing that. However, I also see "Property(S): INSTALLVBA = 1", and I notice from the log (including some of the lines above) that it looks like the vba features in particular are selected to be installed Local.

This leads me to wonder if adding INSTALLVBA=0 on the command line would remove the program. Maybe this was forced to '1' in the transform?

Hi guys, thanks for your comments. The below entries are in the transform:

On the registry table:

Key:
SOFTWARE\Business Objects\Suite 6.0\default\BusinessObjects\BusObj General Preferences\busobj\Options\Addin\WebConnect

Value:
[INSTALLDIR]addins\WebConnect.rea

On the Property table:

MIGRATION - 0
AgreeToLicense - Yes
MIGRATIONPROMPT - 0
THREETIERBUSOBJ - 1
INSTALLLANG - en

I suspect the problem may have something to do with the entry "THREETIERBUSOBJ=1". I notice in the log file, this entry appears near the end of the log:-

Property(S): ADDDEFAULT = bo.3TierBusinessObjects,bo.vba.en,bo.vba.common

Surely it shouldn't be adding components at this stage? How would I change this property from the command line? I've tried modifying the MST on the install share that it's using, and changing the THREETIERBUSOBJ to '0', but it didn't help. Have also tried:-

msiexec /x {E989CB68-9F75-4AE3-9A34-69144502D82D} ADDDEFAULT=
msiexec /x {E989CB68-9F75-4AE3-9A34-69144502D82D} ADDDEFAULT=""
msiexec /x {E989CB68-9F75-4AE3-9A34-69144502D82D} ADDDEFAULT=0

Setup.exe doesn't seem to take any parameters aside from /v, which passes parameters to msiexec e.g. /v /x {E989CB68-9F75-4AE3-9A34-69144502D82D}

aek, we haven't installed any additional service packs etc - if I look in add/remove programs, there's just a single entry for BusinessObjects 6.

As you may have read elsewhere, BO's MSI is a joke.

For installation, I added impossible-to-meet conditions to 2 CAs: 'BOValidateFeaturesStates' and 'BOSetLanguageProperties'. You may want to look at the first one. Also, IIRC, the many, many 'state_bo.' properties may need to be altered for uninstalls.

Check out http://itninja.com/question/gnu,-freeware-and-shareware-programs-to-cloning2867&mpage=1&key=business%2Cobjects

VBScab - would you believe it, that guys fix from the link you sent fixed my problem as well. Deleting the reg key:

HLKM--Software---Classes---Installer--Products---B.O GUID---Transform

... allows BO 6.5 to remove fine (manually via ARP as well as via GPO).

BUT now I've discovered that my MSI for BO XI 3.1 has the same (or similar) problem! I can't uninstall it. At least XI crashes with an error though (although the error gives no detail - just says there was a fatal error.) I'll have to examine the logs and see if I can see why it's also failing to remove. *sigh* maybe I should just repackage XI 3.1 - but in the past I've normally found that vendor MSI's are far more reliable than custom created ones using Wininstall LE. Haven't tried the free packager from AppDeploy yet, maybe this is a good opportunity to.

Perhaps the "fix" for uninstalling BO 6.5 will work for XI too. I'd prefer to roll it out without knowing there will be problems down the line when we have to remove it though.

I seem to recall that, before responding to that reply, I trawled through the MSI looking for any reference to that key and didn't find it. I can only assume it's read by one of the many Custom Actions in there.

*sigh* maybe I should just repackage XI 3.1Trust me - that's the very LAST thing you want to do, especially with a clunker like BO. If you think you know pain now, re-package BO and get to a WHOLE new level.

Yeah will avoid repackaging at all costs :-) My guess would be that that key is used by Windows Installer to determine which transforms to use when removing the app - so by deleting the entry it's ignoring the transform, and whatever condition that was breaking the uninstallation is thus avoided...? When uninstalling it definitely reads the transform - at one point I tried renaming the server-side copy of the transform I used on my Install share, and the uninstallation died with an error, saying that the transform was inaccessible.

My guess would be that that key is used by Windows Installer to determine which transforms to use when removing the app Your guess would be wrong! :) The list of transforms is read from HKEY_CLASSES_ROOT\Installer\Products\[MungedProductCode]\Transforms.

ORIGINAL: VBScab
Your guess would be wrong! :) The list of transforms is read from HKEY_CLASSES_ROOT\Installer\Products\[MungedProductCode]\Transforms.


HKEY_CLASSES_ROOT is in fact a merged presentation of HKLM\Software\Classes and HKCU\Software\Classes - see http://support.microsoft.com/kb/256986 for more info. So deleting it in HKLM would also "delete" it from HKCR. So I am somewhat right :-)

Oops! You're quite right. I omitted to check the key path [sic] in full. I had something completely different in my head, for some reason. My apologies.

Hey guys - ok so i've discovered that my new BO rollout is also broken - uninstall just dies with a fatal error :-( I thought maybe the transform was somehow the problem, so I've tried writing the transform directly to the MSI to avoid applying a separate transform file, but it doesn't help. I've uploaded the log to here:-

http://senduit.com/ad9469

Any advice would be much appreciated.