4

I have custom bootstrappers for SQL Server 2008 R2, .NET Framework 3.5, .NET Framework 4, etc. I am using Visual STudio 2010's Deployment project to deploy a .NET 4 application. I know these are going away.

Is there a way I can specify a bootstrapper to Fail if the user does not have specific Windows Privledges? SQL Server's Setup seems to take care of this on its own, but gives very cryptic error codes and texts that are hard to trace for users. I know that I can set Bypasses for Windows versions, and SqlCheck.exe performs some sort of version check. Would I have to create my own application that checks the user's permissions, and the bootstrapper could check the return code of that, similar to SqlCheck.exe?

Can this be accomplished using the Bootstrapper Manifest Generator, and is the BMG even supported by Visual Studio 2010? Appears to not be supported anymore, but I"m not sure if there's anything specific to VS 2010 / Windows Installer 4.5 http://archive.msdn.microsoft.com/bmg

Stealth Rabbi
  • 10,156
  • 22
  • 100
  • 176

1 Answers1

0

The most you can do with the standard Visual Studio bootstrapper is to check the AdminUser property value. The predefined .NET Framework 4.0 Client Profile prerequisite uses a similar condition. You can find its manifest in this folder:

C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client

This should also be supported by the bootstrapper manifest generator.

But, and this is a big one, on newer Windows versions all users can get Administrator privileges through elevation. So from the installer point of view, any user is seen as an Administrator, even if he's not.

So this approach is pretty much useless on Vista or higher.

You could try creating your own custom EXE bootstrapper which handles prerequisites and checks user privileges. But you will most likely encounter the same problem.

From my experience, the best approach is to let each installer elevate itself if necessary. Most of them have built-in mechanisms for this, especially the ones from Microsoft.

If you encounter problems with this approach, I'm pretty sure they are not caused by privileges. Most likely your prerequisite is not configured correctly (for example an incorrect command line).

Cosmin
  • 21,216
  • 5
  • 45
  • 60
  • It's definitely permissions / privledges issues based on the install logs. Unfortunately, our user base has a wide array of privledges, domains, etc. – Stealth Rabbi Oct 25 '11 at 18:06
  • You mentioned that SQL Server shows errors during install. Does its installation process elevate through an UAC prompt? – Cosmin Oct 25 '11 at 18:25
  • I haven't heard of errors on Vista/Win7. 99% are using XP SP3, so no UAC. – Stealth Rabbi Oct 25 '11 at 18:29
  • Does it work when using "Run as Administrator" option or when launching the install from an elevated command line? Also, is the SQL Server installer launched directly or with a custom command line? – Cosmin Oct 25 '11 at 18:39
  • The user logs in to windows with an account he thinks has the necessary privledges. I don't think they've tried with an elevated command line. SQL Server is installed using a silent command line install as provided by the bootstrapper for SQL 2008, but we are installing SQL 2008 R2. – Stealth Rabbi Oct 26 '11 at 11:46
  • Then the command line is incorrect. If it would be a permissions problem the SQL Server installer should show an Access Denied message. – Cosmin Oct 26 '11 at 12:39
  • This is going beyond my original question. This isn't an across the board failure. The bootstrapper installs for many users, but it's failing for some users that do not have the necessary permissions. I'm trying to check the permissions up front to present a more friendly message than the cryptic error codes presented by the the failing SQL Server silent installer – Stealth Rabbi Oct 26 '11 at 12:49
  • Perhaps I'm misunderstanding the problem. What are the exact messages you are referring to? – Cosmin Oct 26 '11 at 12:54
  • Well, SQL Server dumps cryptic, undocumented exception error codes in the install log. We found that they were a result of the person doing the install not having SeDebugPrivilege, etc. I wanted to add it as a FailIf condition on the bootstrapper for that specific code. I think i'd need to write my own app similiar to SqlCheck.exe that returns a value corresponding to missing privileges, if any. – Stealth Rabbi Oct 28 '11 at 14:48