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

Changed property on Vista and error 1316 on XP


11 replies to this topic

peterbi

peterbi
  • Full Members
  • 19 posts

Posted 05 June 2008 - 22:02

Hi,

I have posted two questions in InstallShield (http://community.ins...splay.php?f=223) with titles "Error 1316 with log file" and "Why changed properties - log file pasted". But to try my luck better rolleyes.gif I want to see if Stefan (or anybody else) can give me more prompt solution here smile.gif

I am working on a simple installer called DataOnly, it's called because we want it to do monthly based data file updates on a released product (let's call 'Prod'). Prod is a normal product that can be installed with 'administrator' rights, but DataOnly is different in 1) it only can be installed with non-admin or non-privileged user (called 'restricted user') accounts; 2) it only does fresh install, no maintenance or upgrade, whenever someone tries to run the install, it just blindly install the files. We do that because some of our clients set the Prod user accounts without administrator rights, so when they need the monthly updates of the data files with the full version of Prod, they need somebody else (IT, etc.) to help them elevate their rights, and then reduce it. Once we have DataOnly available, those users can update data files without changing their account settings.

I created DataOnly.ism from a copy of Prod.ism, changes include: removing un-needed features/components/CAs, changing product-name/product code/upgrade code/package code, etc. etc., trying to make DataOnly complete unrelated to Prod. BUT, I left the data file components unchanged (with same name/code).

After some more changes to overcome errors appeared during testing installation, DataOnly now can do data updates from a restricted user account on W2K3. What I did is to install Prod first from an account with administrator rights, then install DataOnly from a restricted user account. But when I tried the same thing on XP and Vista, I ran into different problems respectively.

On XP, I got 1316 error (Error 1316. A network error occured while attempting to read from the file X:\Prod.msi), X: is the mapped driving pointing to source media (DataOnly media here. Prod was installed similarly by mapping the media to a drive). My feeling after a bit research is that DataOnly for some reason still refers to Prod by some way. In the log file, there is a line "Package name retrieved from configuration data: 'Prod.msi'" at the beginning of the logging. How could that happen? Is that XP specific behavior (W2K3 didn't show that)? How to avoid or fix it? You can refer to my post in InstallShield with more log file.

On Vista, the installer elevated the restricted user account to have AdminUser and Privileged rights, which make DataOnly validation failed the requirement checking. Again, in the log file, I found
QUOTE
MSI © (80:88) [09:27:15:207]: MSI_LUA: Setting AdminUser property to 1 because this is the client or the user has already permitted elevation
MSI © (80:88) [09:27:15:207]: PROPERTY CHANGE: Adding AdminUser property. Its value is '1'.
MSI © (80:88) [09:27:15:207]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'.
, is this caused by installer itself or by the system configurations? And how to avoid/fix it?

I hope I have made the problems understandable to you guys, and some of you have enough knowledge and experience to save me!

Thanks,
Peter

peterbi

peterbi
  • Full Members
  • 19 posts

Posted 06 June 2008 - 21:05

One thing I forgot: the installer (DataOnly) works fine on W2K3 server.

I created and compared the log files on the 3 systems, here are the lines that are interesting to me - please note the difference of the commandline property AND the package names extracted are different between W2K3 and XP/Vista.

W2K3:
------------------------
MSI © (EC:64) [12:04:02:795]: Command Line: SETUPEXEDIR=Z: CURRENTDIRECTORY=Z:\ CLIENTUILEVEL=0 CLIENTPROCESSID=1516
...
MSI © (EC:64) [12:04:02:795]: Package name extracted from package path: 'DataOnly.msi'


XP:---------------------
MSI © (14:BC) [10:22:34:357]: Command Line: REINSTALL=ALL REINSTALLMODE=vomus IS_MINOR_UPGRADE=1 SETUPEXEDIR=W: CURRENTDIRECTORY=W:\ CLIENTUILEVEL=0 CLIENTPROCESSID=1812
...
MSI © (14:BC) [10:22:34:372]: Package name retrieved from configuration data: 'Prod.msi'

Vista:
--------------------
Command Line: REINSTALL=ALL REINSTALLMODE=vomus IS_MINOR_UPGRADE=1 SETUPEXEDIR=Z: CURRENTDIRECTORY=Z:\ CLIENTUILEVEL=0 CLIENTPROCESSID=2176 ...
MSI © (80:88) [09:27:15:160]: Package name retrieved from configuration data: 'Prod.msi'

VBScab

VBScab
  • Full Members
  • 436 posts

Posted 09 June 2008 - 09:12

It seems to me your XP and Vista machines think the product is already installed and WI is upgrading. Quite why, given that you've changed ProductCode etc, is open to debate. However, it probably doesn't help that your component names and stuff are the same. If it were me, I'd be rebuilding DataOnly.ISM from scratch.
- 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.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 09 June 2008 - 19:06

Command Line: REINSTALL=ALL REINSTALLMODE=vomus IS_MINOR_UPGRADE=1 SETUPEXEDIR=W:
is coming from InstallShield's setup.exe. Does your setup work as intended if you launch the .msi file directly?
Double check the setup.exe settings / compare the setup.ini files.
Open the actual .msi files of Prod and Data and compare the ProductCode to make sure it's different.

peterbi

peterbi
  • Full Members
  • 19 posts

Posted 11 June 2008 - 22:35

Hi VBScab and Stefan,

Thank you both for replying to my posts.

I now figured out he problem. biggrin.gif For XP, it's the system problem (I have been using it for my development testing for long time, there must be something messed up), now I re-imaged it and the 'clean' system works fine.

For Vista, I found this article http://blogs.msdn.co...er-mistake.aspx, and that's the case I had problem with. Now I moved the checking in Execute sequence and it just works fine!

BTW, I am still curious about the setup.exe commandline in the log file, but I looked at setup configurations (IS IDE ->Releases->Default->CD) and didn't see anything about IS_MINOR_UPGRADE, I couldn't find any setup.ini file either. How can I look for where IS_MINOR_UPGRADE is set?


Thanks,
Peter

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 17 June 2008 - 15:47

I believe that setup.exe sets IS_MINOR_UPGRADE if it detects that you are performing a minor update (i.e. same product code with different package code)

peterbi

peterbi
  • Full Members
  • 19 posts

Posted 18 June 2008 - 19:16

What is going on here mad.gif mad.gif !!!

The installation is not working anymore now - it even allows administrator user to run through. I have trie to change the cheking condition with (Privileged Or AdminUser), (Privileged="1" or AdminUser="1"), and so on, it never works.

But what I got from the MSI blog is still holding: even with restricted user account (no admin, no privileged), if I put the checking in UI sequence, it will fail (i.e. consider as AdminUser or Privileged). But now it's not working with the checking CA in Execute Sequence (before LaunchCondition).

I am attaching the log file (with /v"/l*v ..." option, incomplete, but should contain enough info for the issue), it is for the install of an account with 'administrator' rights, which should throw out the error messgae (from NewUMDataOnlyCheckPrivileged CA) and quit the install, but it did go through dry.gif.

We are now ready to roll out the package, please help blink.gif

Again, this is IS2008 with testing on Vista (business).

Thanks
Peter



Attached Files

  • Attached File  log.log   413.32KB   142 downloads


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 23 June 2008 - 09:18

I'M not sure I fully understand your post, but: on Vista the AdminUser and Privileged properties are always true in the UI sequence, because of UAC. You may need to set the MSIUSEREALADMINDETECTION if you don't want to allow elevation.

peterbi

peterbi
  • Full Members
  • 19 posts

Posted 23 June 2008 - 17:39

Hi Stefan,

Sorry for the confustion, my latest post is contexted with the previous ones, and the whole process is not that straightforward cool.gif .

Yes, I knew AdminUser and Privileged properties are always true in UI sequence, so I moved the checking for the properties to Execute sequence. It seemed to work for a while for me (I am not quite sure now since I can never make it work again wink.gif ).

My understanding is that Execute sequence should all be right with the properties, but my testing now indicates that they are never set (to true), even in accounts with 'administrator' rights.

I am suspecting that there could be Vista system itselfe (UAC, policies, etc.) or my installer (.ism file) got wrong somewhere, but I have tried my best and couldn't see any, so I posted the log file to see if you or anyone here can help?


Thanks,
Peter

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 24 June 2008 - 12:04

FVor the tests, please use:
Privileged
instead of:
Privileged="1"

When testing user rights in a custom action it must be "deferred in system context" because non-deferred actions impersonate the (non-admin) user.

peterbi

peterbi
  • Full Members
  • 19 posts

Posted 24 June 2008 - 17:59

Thank you Stefan.

I have tried to use 'Privileged' instead of 'Privileged=1' (and all other possibilities I could think of), not working.

I think not using deferred (system context) CA might be the reason, I will test it later (currently working on something else). The reason I didn't try to use deferred (any kind of context) CA because we really want the checking to be as early as possible, so user can quit the install early enough; deferred CA could be too late for this purpose.


Thanks,
Peter

stevenwaugh

stevenwaugh
  • Full Members
  • 2 posts

Posted 02 November 2008 - 18:57

Hi,

Before installing check whether the files AdventureWorksDW_data.mdf & AdventureWorksDW_log.ldf files resides under C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data path, if yes check whether AdventureWorksDW databases exists in SQL server. If yes drop the database or delete the physical files and try re-installing the database again.


Make sure SYSTEM has full permission on the data directory C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data, if not provide access to SYSTEM.
A banker is someone who lends you an umbrella when the sun is shining, and who asks for it back when it start to rain.
the buy isk blog