InstallAware

I appologize up front for the long post, however I wanted to provide as much information as possible.

I am testing out InstallAware and I have server software which includes SQL Server 2008 Express and client software. To start with, I've created different installers for the client and server portions. Only the server portion has SQL Server as part of it.

I was able to quickly build an installer for an XP machine with relative ease and I like the product.

I ran into few issues in testing and have a few questions.

1. On Vista. With Always Elevate specified in the Vista UAC Elevation under Summary Information and the Vista User Account Control Elevation checked under Application Requirements I got the following problem when trying to install while logged in as a non-administrator.

With these settings the .exe setup program properly asks me to enter a password for an administrator user account. Once entered, the setup runs. However, if I use the *.msi instead, it simply exits without any warning or reason given after I enter the password for the administrator account.


2. On Vista. Using the above settings, the *.exe installer runs to completion. I set the SQL Server Administrators to be the Current User. However, the logged in user is not given access permissions to the SQL Server 2008. The queries return access denied. I could, however, run the server app when logged in as the adminsitrator I used when I entered the password to elevate the privledges. I could not run the server app using another administrator user account. So only the administrator user used in the elevation could query the database.

Question, does InstallAware put the elevated administrator user in $SQL_COMPUTER_NAME$\\$SQL_USER_NAME$ instead of the invoking user?

Next question, how do I also add the Administrators group to the /SQLSYSADMINACCOUNTS in the command line setup for SQL Server 2008?

I may be using the UAC settings incorrectly as I am not that familar with ramifications of these settings. I have personally avoided using Vista as much as possible, meaning that I test on it and don't otherwise use it.

3. On XP, I had an interesting error. With either the Vista UAC Elevation set to Elevate Administrators Only (highestAvailable) or the Always Elevate (requireAdministrator) I get "The computer atleast requires User Account Control Elevation. Setup cannot continue." I was logged in on an administrator user account. I haven't tested with a non-administrator user account on XP.

In XP, when being logged in on an administrator user account, the Never Elevate (asInvoker) is the only option that will allow the installer to work. However, trying to install with the asInvoker setting on a Vista machine gave an unpleasant experience and failed on dotNet Framework 3.5 install and on Windows Installer 4.5 install unless I used the Run As Administrator.

I was under the impression that the UAC Elevation was ignored on XP installations, at least that is what I understood when reading the help.


Could you please explain the proper use of the Vista UAC Elevation under the Summary Information and the Vista User Account Control Elevation and the Administrator priviledges check boxes under Application Requirements? I am unclear as to how these settings work together. I did read the help and thought I was using them correctly.


What I am looking for is for a consistant install for both XP and Vista. I'd like the invoking user to simply install either the server side or client side or both and run the software, including having access to SQL Server on the local machine, without having to put them through the Vista obstacle course that few of them will understand.

Advice?


Also, one last thing, x64 components for Windows Installer 4.5. The Application Runtimes only show x86 versions.

Hi Chris,

Thank you very much for your detailed post.

1. The InstallAware bootstrapper must at all times be used to start setup. While the actual installation is executed by the Windows Installer engine through the MSI file, in order to make the scripting logic in your MSIcode script work, and also in order to handle the installation of any pre-reqs (such as Windows Installer itself), even when you launch the setup.msi file, it automatically shuts down and launches setup.exe instead, as you have observed on Windows XP. Unfortunately there is a known issue on Vista with UAC enabled, which is that setup.msi does not invoke setup.exe, but just quits. At any rate this is a cosmetic issue (and therefore a low priority issue), since setup.exe must always be used to start setup anyways.

2. With UAC enabled, if you call Run Program, any programs you run will run under the elevated account, and not the original invoker account. What you need is access to the original invoker account, which we call "de-elevation". While with other tools like InstallShield de-elevation can require a lot of custom code and be a total pain, InstallAware makes it very easy: Just use the Run Program As command instead of Run Program, and check the de-elevation check-box. That's all it takes! And any software you run will be run under the invoker account, instead of an elevated account.

3. This behavior is as-designed but can certainly be confusing. The check for UAC elevation in InstallAware does a full check for UAC elevation; meaning it does not just check for full admin rights platform neutrally, it instead actually checks for the presence of UAC and full elevation. If you're running on a platform older than Vista, since UAC is not supported, this check will automatically fail. If your intent is to just check for admin rights platform neutrally, you should just wrap the sophisticated UAC check inside an If...Else...End block which runs only if the OS is Vista or higher, and fall back to regular admin checks on older platforms.

Hopefully that helps iron out your Vista issues. We know exactly what you mean when you say you don't use Vista other than to test for it So hopefully the above information and the de-elevation tricks help save the day for you on Vista.

Vista certainly should have been a whole lot better, and we're keeping fingers crossed for Windows 7 - which, ironically, is not Windows NT 7.0 but Windows NT 6.1 - a tacit admission by Microsoft regarding how hard it is to fix issues brought on by Vista, since it takes them three years to issue a point upgrade for their new OS! Contrast this with Windows 2000 and Windows XP, released just one year apart, with the former being Windows NT 5.0 and the latter being Windows NT 5.1. The clues are all around about Vista's failure, be it by design or by accident.