hi,

newbie(ish) question : I have spent some time packaging an application called SQLBase. I have pretty much learned what I know about MSI & WinInstall LE 2003 from this task. I have a problem however, when I try and deploy the newly created .MSI on a Windows 2000 machine, it doesn't actually completely install the application. It appears in Add/Remove Programs list as installed and also in the Add New Programs list from apps on the network. Only after you actually click the 'Add' button in the Add New Programs contral panel does the application completely install (the \SQLBase folder is copied and all registry entries are set)... why does it not install when I actually log on to the computer? I have read

It works fine in XP Pro, the user logs on and the application gets fully installed. Is this a Win 2K restriction? The application does have user settings, so I assumed it needs a user installation rather than machine one - but it is not an application that can be launched - it's a database engine - so I need for it to install without any user interaction. Are there distinct differences in the way that XP & 2000 handle the group policy deployed apps?

help much appreciated, cheers

baronne
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
What platform did you create this package on? WinXP? Win2k?

You may run into troubles if you package on one platform and deploy to another.

Nate
Answered 06/29/2004 by: nmead
Senior Yellow Belt

Please log in to comment
0
I used Win2K to package it up... one would expect it to work on 2K.. but it doesn't
Answered 06/30/2004 by: baronne
Senior Yellow Belt

Please log in to comment
0
Are there distinct differences in the way that XP & 2000 handle the group policy deployed apps?

baronne,

I have not run into - nor can I think of - any situations where a Win2K machine reacted differently to a GP/AD deployed app than did a WinXP machine (with the exception of, as nmead correctly points out, packages that do not cross OS platforms well).

I would begin by trying to install your package locally on a Win2k machine. If that succeeds, try installing it from your network UNC. If that succeeds as well, then you very well might have something unusual happening that does not have to do with Win2K.

My suspicion is, though, that it does have something to do with how a Win2K machine is reacting to your package. Do your event logs on an affected machine indicate any problem? Can you confirm that this is happening on all your Win2K machines?

One other thing: You mentioned that app is called SQLbase. If SQL is involved, then it is possible the package may be attempting to touch/replace system files that are protected by the Windows File Protection service. If you built the package on Win2K, many of these files are in the path of C:\Winnt\System32 On XP, the path is C:\Windows\System32. After you deploy the package to an XP machine, is there a C:\Winnt path? If so, this might give you a clue as to why it deploys on XP but not Win2K.

If this does turn out to be the case, these files should not be included in a package. Instead, merge modules (.msm) that contain the necessary files should be incorporated into your package.

Craig --<>.
Answered 06/30/2004 by: craig16229
Third Degree Brown Belt

Please log in to comment
0
hi craig, thanks for your reply...
it's been a crazy few days trying to get this thing to work. Fortunately I cracked it this afternoon (otherwise I think I might have started going mental)!! Here's the story :

The "suite" consists of Centura SQLBase 7.6.1 (a database client), Centura Runtime 1.5 and the VISUAL Manufacturing 6.2.8 application. Initially, I was creating a snapshot of each, but when I tried to deploy to Win2K it only stayed in an advertised state. So I found a script.... Advertised Software Launcher Script which I slotted into my login script which actually forced an advertised application to install once the user had logged on. The problem with this was that the application installed itself in the wrong order, so it wouldn't work. I then recreated a new MSI package of the entire "suite" of applications and so it worked!

I really am not sure why this was happening but it's not the nicest of apps to deploy, so I'm glad this method worked!

The weird thing is that when you install the application manually (as in - you run each of the separate .MSI packages), it installs absolutely correctly. I guess the thing to find out is how to change the order of the above mentioned script so it does the applications in the correct order... but for now... I really have had enough!!! [:-]

cheers

Baronne Mouton
Answered 06/30/2004 by: baronne
Senior Yellow Belt

Please log in to comment
0
Windows 2000 does not support install at logon for user deployed apps. This is a limitation that does not exist in Windows XP.

In Windows 2000 the workstations are advertised the app and once triggered will install fully.

In Windows XP you can advertise the app and select "Install at logon" and the app will fully install after the user completes his login.
Answered 06/30/2004 by: MSIMaker
Second Degree Black Belt

Please log in to comment
0
good stuff... I thought there was something up with Win2K - so the script that activates & installs these advertised applications is a winner!

cheers all for your help

baronne mouton
Answered 07/01/2004 by: baronne
Senior Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity