Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

installer mis-placing files in root


9 replies to this topic

mikemio

mikemio
  • Full Members
  • 12 posts

Posted 29 November 2007 - 21:15

Hi,

I have an msi package that has been working normally for sometime. One user is now reporting that the installer is placing the files in the root of a USB drive instread of the default Program Files folder (e.g. C:\Program Files\OurCompanyName\)

If he unplugs the USB drive, and re-installs, the files are installed in the root of his C:\ drive.

He is using Vista. If he uses the Vista Administator account it makes no difference. If he browses to a different location, the same thing happens. He has tried installing for all users or single user.

My question is: has anyone heard of this before or does anyone have an idea what might cause it?

Thanks for any thoughts,
Mike

VBScab

VBScab
  • Full Members
  • 436 posts

Posted 29 November 2007 - 21:47

My guess is that a property is being set "incorrectly" somewhere. Is the PC USB-bootable? That might be a clue.

As ever, re-install with MSI logging enabled. That will tell you what's happening with the relevant properties (ROOTDRIVE, etc, etc)

Edited by VBScab, 29 November 2007 - 21:48.

- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.

spdygnlz

spdygnlz
  • Full Members
  • 106 posts

Posted 30 November 2007 - 01:42

I ran into a problem where files were going to C:\ incorrectly. I don't know if it applies to your situation, but you might want to take a look anyway. smile.gif Had to do with .NET files particularly.

http://forum.install...c=16702&hl=root

-- spdygnlz --

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 30 November 2007 - 15:31

If you're installing anything to ROOTDRIVE (instead of ProgramFilesFolder) that could explain the behaviour. ROOTDRIVE is the drive with the most free space, which might be a large USB drive (is the USB drive mounted as removable drive?).

mikemio

mikemio
  • Full Members
  • 12 posts

Posted 30 November 2007 - 19:01

Thanks for all your suggestions.

I am not installing anything to ROOTDRIVE (at least not intentionally). The only properties set to C:/ are ROOTDRIVE and WindowsVolume.

I will find out if the USB drive is bootable or mounted as removeable and will get a log of the installation. This may take a few days.

I'll let you know what I find out.

Cheers,
Mike

mikemio

mikemio
  • Full Members
  • 12 posts

Posted 01 December 2007 - 17:56

Ok, this is what I have found out from the user:

- The USB drive is not set to be bootable
- The drive is not recognized as a "Removable Storage", but rather as a "Hard Disk Drive"

I have a complete log of one installation.

Keeping in mind that I know just (barely) enough about Windows Installer to be dangerous, this is one suspicous area I see:

The paths are set correctly at one point
e.g.

MSI © (6C:4C) [09:04:21:813]: Target path resolution complete. Dumping Directory table...
MSI © (6C:4C) [09:04:21:813]: Note: target paths subject to change (via custom actions or browsing)
MSI © (6C:4C) [09:04:21:813]: Dir (target): Key: TARGETDIR , Object: C:\Program Files\Virtual Mechanics\
MSI © (6C:4C) [09:04:21:813]: Dir (target): Key: WindowsFolder , Object: C:\Windows\

Then this happens:

SI (s) (40:DC) [09:05:41:001]: Product not registered: beginning first-time install
MSI (s) (40:DC) [09:05:41:002]: Product {826C3E36-A1C6-4183-B220-34A113E0CE9F} is not managed.
MSI (s) (40:DC) [09:05:41:036]: Machine policy value 'AlwaysInstallElevated' is 1
MSI (s) (40:DC) [09:05:41:036]: User policy value 'AlwaysInstallElevated' is 1
MSI (s) (40:DC) [09:05:41:036]: MSI_LUA: No credentials required as all installs will run elevated due to AlwaysInstallElevated policy setting
MSI (s) (40:DC) [09:05:41:036]: PROPERTY CHANGE: Adding ProductState property. Its value is '-1'.
MSI (s) (40:DC) [09:05:41:037]: Entering CMsiConfigurationManager::SetLastUsedSource.
MSI (s) (40:DC) [09:05:41:038]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (40:DC) [09:05:41:038]: Adding new sources is allowed.
MSI (s) (40:DC) [09:05:41:039]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'.
MSI (s) (40:DC) [09:05:41:040]: Package name extracted from package path: 'SiteSpinnerV270f(3).msi'
MSI (s) (40:DC) [09:05:41:041]: Package to be registered: 'SiteSpinnerV270f(3).msi'
MSI (s) (40:DC) [09:05:41:041]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (40:DC) [09:05:41:048]: Note: 1: 2262 2: AdminProperties 3: -2147287038
MSI (s) (40:DC) [09:05:41:048]: PROPERTY CHANGE: Adding ALLUSERS property. Its value is '2'.
MSI (s) (40:DC) [09:05:41:048]: PROPERTY CHANGE: Modifying ALLUSERS property. Its current value is '2'. Its new value: '1'.
MSI (s) (40:DC) [09:05:41:048]: Machine policy value 'AlwaysInstallElevated' is 1
MSI (s) (40:DC) [09:05:41:048]: User policy value 'AlwaysInstallElevated' is 1
MSI (s) (40:DC) [09:05:41:048]: Running product '{826C3E36-A1C6-4183-B220-34A113E0CE9F}' with elevated privileges: All apps run elevated.
MSI (s) (40:DC) [09:05:41:049]: Machine policy value 'EnableUserControl' is 0
MSI (s) (40:DC) [09:05:41:049]: PROPERTY CHANGE: Adding RestrictedUserControl property. Its value is '1'.
MSI (s) (40:DC) [09:05:41:093]: Ignoring disallowed property TARGETDIR
MSI (s) (40:DC) [09:05:41:093]: Ignoring disallowed property _971DEA7252C5446CB04AE4844B7A53A8
MSI (s) (40:DC) [09:05:41:093]: Ignoring disallowed property _9F9A6025E937470C98280CF7C899845D
etc.

And the next time TARGETDIR is refered to it is being set to J:/ (which I assume it the USB drive)

Action start 9:05:41: CostFinalize.
MSI (s) (40:DC) [09:05:41:758]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'.
MSI (s) (40:DC) [09:05:41:758]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'.
MSI (s) (40:DC) [09:05:41:758]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'.
MSI (s) (40:DC) [09:05:41:758]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'.
MSI (s) (40:DC) [09:05:41:758]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'.
MSI (s) (40:DC) [09:05:41:760]: Note: 1: 2262 2: Condition 3: -2147287038
MSI (s) (40:DC) [09:05:41:760]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'J:\'.


Now, I wonder, is this saying that a stream cannot be found and that is causing a problem? If so, why is that? Or I am way of track?

I can post all or some of the log. It is about 1.4MB. If I do, post it, is there anything I should remove (aside from perhaps user name and company) since this is not my data and I don't want to post anything that may be private for this user.

Thanks again for you help with this.
Mike


mikemio

mikemio
  • Full Members
  • 12 posts

Posted 05 December 2007 - 17:55

Any thoughts on this? Anyone?

I have also found some information that suggests that the "Ignoring disallowed property TARGETDIR" can occur if the user is running with Elevated Privileges and that populating the SecureCustomProperties property will resolve the problem.

I am not sure I understand this because the package works for all other vista users. Or maybe it is not applicable in my case.

The information referred to above can be seen here:
http://community.ins...t=161539&page=2
(bryanwolf entry, bottom of page)

Cheers,
Mike


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 07 December 2007 - 18:20

QUOTE
The drive is not recognized as a "Removable Storage", but rather as a "Hard Disk Drive"
This explains why it's being used as ROOTDRIVE. But that's not cauing the problem.

QUOTE
MSI (s) (40:DC) [09:05:41:093]: Ignoring disallowed property TARGETDIR
This appears to be the problem. Add a property names SecureCustomProperties. As value enter TARGETDIR as a first test. You may need to add more properties (in a semicolon delimited list).

mikemio

mikemio
  • Full Members
  • 12 posts

Posted 10 December 2007 - 05:22

Thanks Stefan. I sent a message the other day to the user asking him to try installing without the user interface (msiexec /i xxx.msi /q). I read somewhere that the problem of values crossing from client to server can be avoided this way. That won't help in real life of course but will show if that is the core problem. I also asked him to try installing from the true Vista Administrator account in case that reveals something.

I will wait to hear the results of those tests. Depending on what comes back, I will try your suggestion and add the TARGETDIR and the other values to the SecureCustomProperties list and have him try that.

If the problem is the lack SecureCustomProperties it still make me ask the question, "why only for this user?". Other Vista users (both admin and non-admin) have installed without problems. Could it be a policy setting that only this user has?

As an aside: Adding values to the SecureCustomProperties list doesn't seem like a practical way to maintain an installation package since, in my case anyway, there are several property names, some of which are GUIDs and some that come from merge modules. I wonder if this is a normal situation of just and omission by the the current installation generator that I am using (VS2005)

In any case, I will report back here with what I find out.

Cheers,
Mike



mikemio

mikemio
  • Full Members
  • 12 posts

Posted 17 December 2007 - 20:15

Just to update this thread, I haven't heard back from the user on these tests. It could be that he gave up on the problem or maybe he is on vacation. Either way he is not responding right now.

If/when I hear back I will post an update here.

Cheers,
Mike