The hard drive in my development box died last week, and although I’ll spare you the story of the replacement process, I thought it might be interesting to document the process of rebuilding my dev box, and provide color commentary while I’m at it.

1. Install Windows Vista (Business)
2. Get domain admin (my boss) to log in and connect my machine to the domain
3. Add my domain account as an administrator
4. Log out and log back in as my domain accout (it’s important to do this ASAP or I end up with shortcuts and things in the ‘root’ user account).
5. Adjust Windows settings (via “Programs and Features”) to include the IIS Features required for SQL Reporting services (*). I had to add the “Basic Authentication” to this list, I think, and I changed a few other features while I was in there … this actually required a reboot for some reason (presumably not because I added minesweeper and solitaire).
6. Install Windows PowerShell (in hopes of doing other things faster)
7. Create User Account for Sql Server to use
8. Install SQL Server (before Visual Studio, to avoid SQL Express and the resulting lack of SQL Manager)
9. While waiting for that, slow it down by copying my Projects, Documents, and Pictures folders over from the backup … I need my PowerShell profile and wallpaper before the defaults drive me insane.
10. Change my wallpaper and avatar (that orange flower is actually annoying).
11. Install Notepad++ (and copy userDefineLang.xml from backup for PowerShell scripts)
12. In order to finder Change Explorer settings to:
    1. Show Hidden files and folders
    2. NOT Hide extensions for known file types
    3. Hide protected operating system files (I leave this, because Vista has tons of hidden junction points (for compatability) in my user directory which are very distracting)
    4. Launch folder windows in a separate process (Explorer still crashes sometimes in Vista)

Some side notes:
I’m actually capable of compiling most of my projects (using MSBuild on the command line) without installing SQL Server, and the rest of them require third party controls which I will not install until after Visual Studio is installed. However, having installed SQL Client, Notepad++ and PowerShell I can actually edit, recompile, and run queries via PowerShell … so in an emergency, at this point I can start fixing bugs

Windows Vista, SQL Server, Visual Studio, and MS Office all want me to go online and check for service patches as soon as I install them. Since I feel fairly secure sitting behind my firewall, I don’t bother with this until all of them are installed — Microsoft Update will find and install all of the service packs in one fell swoop.

SQL Server and Visual Studio are the only two apps I install which have installers which are so badly behaved that I don’t even try to install them in my usual sub-folders (C:\Programs\DevTools\ in this case).. SQL Server, for instance, will make a “C:\Program Files\Microsoft SQL Server\” folder no matter what you tell it during install, and nothing I’ve found can convince it to do otherwise, so I might as well install to that location, and not end up with multiple confusing folders (I’ll make junctions in C:\Programs\DevTools\ later to keep myself sane).

More Software (more…)

Ever since Vista came out, users have been trying to find ways to avoid the “Elevation Prompt” when running things which require administrative access. There are lots of obvious solutions, but I’ve found one that’s not so obvious, and I’ve found an easy way to use it with PowerShell. First though, an explanation of what this is, and some of the “obvious” solutions.

UAC overview (feel free to skip this)

User Account Control (UAC) is a mechanism in Vista which finally brings Windows into the world of restricted user accounts that OS X and Unix/Linux have been in for years. Essentially it’s a mechanism which protects certain areas of the operating system from being changed (or even accessed) by users who don’t have administration rights. You can disable UAC completely, but it’s highly unrecommended — it’s basically like making all of your users into “root” level administrators, and it’s obviously overkill if all you want is for your administrator accounts to get prompted less.

There are several things you can do to leave the UAC mechanism in place while reducing the annoyance for users: they are all present as settings in the Local Security Policy snapin (secpol.msc) which controls the behavior of UAC and it’s elevation prompt. You can choose to require explicit login for everyone (a good idea for the family computer if you all share a single account) or to simply “Prompt for consent” for certain administrators, or even to Elevate without prompting which is basically like having all your administrators running as root (this is a logical idea only if you don’t normally log in as an administrator: it lets you have no prompting when you’re running as an administrator). Finally, you can tweak the behavior of the elevation prompt by disabling the “secure desktop,” this doesn’t get rid of the prompts, it just makes them a little less disruptive.

So far, this is all very much like a Mac or Linux system: with the exception that unlike OS X and Linux, Vista doesn’t just run the apps and let them fail with cryptic errors if they need administrative rights: it detects the attempt to access things which require administrative privileges and proactively prompts you to elevate them. Of course, there is another difference: most Windows apps aren’t written with this in mind: they insist on installing into the global “Program Files” folder instead of into the per-user apps folder (C:\Users\Name\AppData\Local\Apps\), and on accessing the registry, etc. This will change with time, but there will always be apps which need administrative access to install, and some which are actually for administering your system and will therefore always require administrative rights.

What about SetUID?

The problem is that the one thing Linux and OS X have that seems missing in Vista is the “setuid” feature: this allows you to specify that specific application always run with the rights of a specific user. The idea is that you control access to the specific file, but you set it to run as an administrator. This way “any” user who can access the app can run it without needing to have access to an administrator account. It allows you to give users access to some administration tools without giving them access to all of them.

It turns out that Vista has a feature like this hidden in the Task Scheduler. It’s not quite the same as setuid, you can’t use it to allow users to run interactive applications as other users, but it will allow you as a member of the administrator group to create tasks that run with “Highest Privileges” (that is: “Elevated”, or “as administrator”) without needing to deal with the elevation prompt each time. This solution is ideal for those tasks which you use repeatedly and which always require admin rights — but probably shouldn’t be used if non-administrators might use your account, and it can be scripted using PowerShell. (more…)