Changed property on Vista and error 1316 on XP
Posted 05 June 2008 - 22:02
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 I want to see if Stefan (or anybody else) can give me more prompt solution here
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'. |
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
Posted 06 June 2008 - 21:05
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'
Posted 09 June 2008 - 09:12
- 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.
Posted 09 June 2008 - 19:06
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.
Stefan Krüger
InstallSite.org twitter facebook
Posted 11 June 2008 - 22:35
Thank you both for replying to my posts.
I now figured out he problem. 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
Posted 17 June 2008 - 15:47
Stefan Krüger
InstallSite.org twitter facebook
Posted 18 June 2008 - 19:16
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 .
We are now ready to roll out the package, please help
Again, this is IS2008 with testing on Vista (business).
Thanks
Peter
Attached Files
Posted 23 June 2008 - 09:18
Stefan Krüger
InstallSite.org twitter facebook
Posted 23 June 2008 - 17:39
Sorry for the confustion, my latest post is contexted with the previous ones, and the whole process is not that straightforward .
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 ).
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
Posted 24 June 2008 - 12:04
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.
Stefan Krüger
InstallSite.org twitter facebook
Posted 24 June 2008 - 17:59
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
Posted 02 November 2008 - 18:57
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.
the buy isk blog