5

My installer package works on my machine but failed on my colleague's machine. Looking at the log, I can see a few properties values are not persisted during ExecuteAction phrase: there are few Ignoring disallowed property lines in his installer log file and those properties are set with the right value during UISequence. The strange thing is that we are both Admin user on local machines he is and Domain Admin as well while I am not, and we are both on Windows 7 64bit. So I don't think it is because he don't have Administrator rights.

The exact entries in the log file:

MSI (s) (3C:50) [09:14:16:583]: Ignoring disallowed property IISMAJORVERSION
MSI (s) (3C:50) [09:14:16:583]: Ignoring disallowed property IISMINORVERSION
MSI (s) (3C:50) [09:14:16:583]: Ignoring disallowed property WCF_SRV_INSTALL_FOLDER
MSI (s) (3C:50) [09:14:16:583]: Ignoring disallowed property TARGETDIR

A easy fix would be mark all those properties as Secure, but properties such as IISMAJORVERSION are not defined in my code. I discovered that I can set EnableUserControl to 1 to make Ignoring disallowed property go away. Another solution would be create my own security properties and copy whatever ignored property value I need into my own properties and read them instead of the ignored property.

After that I discovered there is an entry Machine policy value 'EnableUserControl' is 0 in his installer log, but not in my log, which seems point to set EnableUserControl to 1 is probably what I need. In that case, the question is why there are different values from those two machines?

So my number one question would be: is set EnableUserControl a good fix for my solution, or there are probably better/safer solutions given I only seems found the symptoms but not the cause?

Or if EnableUserControl seems like a reasonable fix given the information, any suggestion could help me track down the cause of the problem (a registry key value change by the Administrator, probably?).

I don't think there is anything special about my installer, but in case of anyone want to see more details:

<Package Id="*"  InstallerVersion="200" Description="Web service installer" Compressed="yes" InstallScope="perMachine" />

Edit:

As pointed out by PhilDW, those properties probably should be marked as Secure to begin with. But then shouldn't all properties be marked as Secure because of UAC, I don't think is make much sense to define a property to be not Secure if it might be used by others?

Paul L
  • 2,240
  • 5
  • 36
  • 55

1 Answers1

2

I'm pretty sure it doesn't matter if you defined them or not - try marking them Secure.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • If I put for example `IISMAJORVERSION` property and make it Secure, I got "Duplicate symbol 'Property:IISMAJORVERSION' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique.". The upside is looking at the source code for IISExtension.wxs, I now know where the value of `MAJORVRESION` is reading from, and by the look of it, I can define my own ResgistrySearch to get the value myself. But it is bit hard to do my testing on other person's machine. – Paul L Mar 17 '14 at 18:27
  • It might be useful to go directly into the MSI file and add those property names to the SecureCustomProperties list in the Property table to see if it fixes the issue. Obviously you cannot redefine those properties, but if they are defined in that extension file, I'd be tempted to go in there and mark them secure. It's possible that the wxs file is pre-UAC and needs fixing to make them secure anyway if they don't work! – PhilDW Mar 18 '14 at 16:53
  • Thanks, that should work. Not sure why it was not defined as `Secure` to begin with, but as you pointed out, it was probably back in the days without UAC. But if you define every property as `Secure`, don't seems much difference from setting `EnableUserControl`. I am currently using `EnableUserControl` solution, as it is much easier for me without the need to worry about which property I need patch it to be `Secure` so it will not fail in some particular situation. Again, unless there are side effects of using that prperty. – Paul L Mar 20 '14 at 02:23
  • Interesting. Your machine must have had the [EnableUserControl system policy](https://msdn.microsoft.com/en-us/library/windows/desktop/aa368359(v=vs.85).aspx) set (applies to all MSIs, not just one), and your co-worker must have had that policy disabled. Was he on a domain controller perhaps? I am now seeing some issue with properties set via msiexec.exe command line from a non-elevated command prompt. The UAC prompt appears but the property settings are not passed to the msiexec.exe session (unless the properties are marked secure in the package) Bug or feature? Not sure which. – Stein Åsmul Mar 07 '18 at 23:54