Software Deployment

The majority of conditions tested for end up being referred to an a negative context e.g. "[AppName] requires that [SomeOtherApp] is installed first" but that text is customisable in the LaunchCondition table's 'Description' field. So, your AppSearch could look for, say, the app's EXE file and, if present, populate a property called APPISPRESENT with the value "YES", for example. The LC Condition would be APPISPRESENT="YES" and the Description would be "There is a version of [AppName] already installed. Go and have lunch instead."

Of course, the question you asked "if an MSI has already been installed" is actually moot, since the Windows Installer engine already traps the installation of the same MSI (or, more correctly, the same Package Code) by offering the Modify/Repair/Remove options.

VBScab,

Thanks for this. My context is as follows:

We have mostly completed an AD domain migration, which included migration of a large number of GPOs containing assigned MSI files. Unfortunately, certain GUIDs change when a domain migration takes place (not the MSI GUIDs, but other AD GUIDs). The behaviour of AD group policies is to remove and reinstall an existing MSI that has ben deployed by a "different" GPO. This means that all our migrated workstations will remove and re-install all existing assigned MSI files. This won't be nice.

I wish to tweak the MSI's so that they check for the existence of their own application and if it is already installed quit with "success" (when I say "success", I mean no error and a return code of "0"). I think just changing the LaunchCondition description will not change the return code, prevent an error in the event log or prevent the workstation from attempting the install again on next reboot.

Cheers,
Richard.

Interesting...

In theory, you need do nothing. I don't think this is any different to the scenario when you select to re-deploy a package. New GUIDs get assigned to the GP packages then, don't they?

Certainly, you won't need to do anything to the MSI. The Windows Installer engine will see that the relevant packages/products are installed already at deployment time. AD handling *should* simply set the relevant registry flags to indicate that the product has been installed in a managed environment. Of course, you can test all of this by filtering the GPOs on groups and/or OUs.

ORIGINAL: VBScab

Interesting...

In theory, you need do nothing. I don't think this is any different to the scenario when you select to re-deploy a package. New GUIDs get assigned to the GP packages then, don't they?



Yes, I guess that is what happens when you select to re-deploy and I'm guessing that is what is happening here. But when you say "new GUIDs get assigned to the GP packages", you mean GUIDs within AD's own logic rather than within the MSI/MST files themselves, right?

ORIGINAL: VBScab

Certainly, you won't need to do anything to the MSI. The Windows Installer engine will see that the relevant packages/products are installed already at deployment time. AD handling *should* simply set the relevant registry flags to indicate that the product has been installed in a managed environment. Of course, you can test all of this by filtering the GPOs on groups and/or OUs.



Does this not contradict your above comment? If the behaviour is equivalent to selecting "re-deploy", then the package will reinstall, right, which is in fact what is being seen? Don't worry, I think I need to investigate further.

Cheers,
Richard.

when you say "new GUIDs get assigned to the GP packages", you mean GUIDs within AD's own logic rather than within the MSI/MST files themselves, right? Yes.

Does this not contradict your above comment? If the behaviour is equivalent to selecting "re-deploy", then the package will reinstall, right, which is in fact what is being seen? The package will try to re-install, in that GP will kick that process off, but the WI engine will 'see' that the product is already installed and either exit without doing anything or instigate a repair which, given that nothing's broken, will result in the same thing.

As you say, some experimentation, with suitable filtering, will nail it. I'd be interested in knowing how it turns out so please be sure to post your results back here, won't you?