SUITE INSTALL: .NET 3.5 install fails on XP sp3

[DLee65]

I have a suite package that I am trying to test the install on Windows XP sp3

My log file states the following:
2-18-2014[11:23:33 AM]: Launching EXE as elevated process
2-18-2014[11:24:06 AM]: Timed out waiting for proxy to respond
2-18-2014[11:24:06 AM]: Could not obtain proxy handler for launching elevated EXE parcel
2-18-2014[11:24:06 AM]: Windows feature install result status: 0x800700e9
2-18-2014[11:24:06 AM]: Failed installing Windows features for parcel 'Amazing Charts Installer', error 0x800700e9

running the command I have in the install from a CMD prompt using the same helper.exe and dotNetFx35setup.exe will work.

Configuration:
Transaction:
Microsoft .Net Framework 3.5 SP1 (Web Download) <-- imported from InstallShield's 2013 PRQ file
Target: Helper.exe
EXE Command Line: /p dotNetFx35setup.exe /l 1033 /v "/q /norestart"
EXE Silent Command Line: same as above
Exit Behavior: Ask whether to continue the setup
Reboot Request: Prompt, then exist or reboot the machine
Reboot Codes: 1641, 3010

Now is another thing that concerns me:
1. I have staged in my setup Windows Installer 4.5 for Windows XP SP2 and later (x86) - However this does not seem to have been installed. It is not a transactional package because transactions require Windows Installer 4.5 first.
I have this package sequenced well before the transactions but it seems like the transactions execute first. I cannot see in the log file where it attempts to execute the packages that are not sequenced within a transaction.
The file is staged properly.
Actually I think this is related to it trying to install windows features first. I have sequenced the .NET35 feature 'NetFx3' so that this feature is enabled properly on systems like Server 2008 R2, Windows 8, and Windows Server 2012. However I think it is trying to install on Windows XP as well and failing. NOTE that I am noticing this as I am crafting this post and reviewing the debuglog from the suite package.

I definitely require the windows feature option for these other operating systems and there isn't any mechanism for restricting the windows feature option for operating systems > 600.

I suspect that the issue is what the log file states, it cannot find the handle to the elevated EXE. The problem is that I cannot see what I need to do to resolve the issue. I have not seen how this behaves on Vista yet.

UPDATE: I just tested on a Vista SP2 x64 system and the same installation works and installs .NET 3.5 successfully. So I do not know what to say.

UPDATE2: I rebuilt the package without any 'Windows Features' added to any of the packages. This solves the problem of the .NET 3.5 not installing. So the problem is with the Windows Feature for .NET 3.5 and it is trying to enable a feature on XP possibly? I do not know how this feature has been enabled for the suite package. I am also getting errors returned from installing the Windows Installer 4.5 for Windows XP SP2 and later but I suspect that it because it is incorrectly evaluating the version for msi.dll.

UPDATE 02/19/2014: I talked with Flexera support this morning and they indicate that this window feature should not have been attempting to install on Windows XP at all. They are in the process of researching this. I will continue to update this with their results.

[DLee65]

BTW - this requirement for XP was a late date add by management. I fought tooth and nail to make the system requirements Vista and newer. Alas I cannot break the customer base. :rolleyes:

[DLee65]

FOLLOW-UP 3: I created a new VMware workstation image of Win XP sp3 just to be sure of my test. Again, when I add in the Windows Feature the setup fails at this point. If I remove the Windows Feature object from the install then the setup proceed. My next step is to try to replicate this with a simple Suite project and MSI package to see if it is reproducible.

FOLLOW-UP 4: I created a new suite package and added in orca.msi as the primary package. I then just added the Windows Feature 'NetFx3' and compiled everything to extract from Setup.exe
I was able to easily replicate the problem this way. There is nothing else to set, nothing else to configure. Just orca.msi and this feature. Change Orca's location to Extract from Setup.exe and compile. Test on your local XPsp3 VMware workstation and voila you have problems. Please note that there is nothing magical about using Orca.msi ... I am using it because it is small and available to everyone.

So my question:
1. How do I work around this problem?
2. I need both the Windows Feature option and the .NET 3.5 install for XP to work
3. I need the detection for Windows Installer 4.5 to work after it has installed and restarted the system. The msi.dll file is the correct version and the parameters are set correctly in the suite package. However, the system still reports back that it is not installed correctly.

[DLee65]

This is a documented 'feature'.
The windows feature option is only designed to work for Vista and newer. Looking more closely at the help documentation for 'Windows feature' option this is listed.
The only solution if you want to include this and still support Windows XP or earlier platforms is to do the following:[LIST=1]

Add a small EXE process that does nothing for Vista and Newer

Add the Microsoft .NET 3.5 SP1 PRQ to the Suite package

Modify the eligibility platform condtions of the MS .NET PRQ event added - remove all references to Vista and Server 2008 platform. Leave Windows XP, XP x64, and Server 2003

Add the Windows Feature to the Small EXE process

Add an eligibility platform condition to the EXE process that does nothing for Vista and higher

Add a detection condtion that mirrors the condtion for .NET 3.5 SP1 so that it does not have to execute if .NET is already installed.

So I created a small C# EXE that I schedule to execute in the proper sequence. Windows Features install first so there is no conflict with missing .NET files.

The help file was not so obvious in outlining this solution, they actually suggested duplicating a package, which can significantly increase the size of your install. If you ask me this is a poorly thought out implementation. The windows feature for .NET should be detecting if the OS it is running on is supported and not execute if not supported. It is a basic and simple check. This would allow us as Release engineers to couple the windows feature with the Microsoft .NET 3.5 SP1 PRQ as one clean organizational unit.

Hopefully this helps someone else.

[DLee65]

The secondary problem for Windows Installer 4.5 was due to a faulty detection condition from some of the PRQ files.
I noticed that some of the PRQ files were using LESSTHAN and some EQUAL to. The ones that use LESSTHAN work, the ones using EQ do not. I just adjusted the detection and all is good.