RANU - Microsoft's advice

RANU is a new acronym that I have just discovered when installing SQL Server 2005 Express books online.

It stands for Run As Normal User. In other words, another acronym for LUA.

I was digging around looking for advice on this new concept called "User Instances" and this is where I discovered this acronym. Microsoft actually wants developers to RANU rather than as Administrator and has gone to great length to help by introducing this new concept called "User Instances".

On this topic, this is what Microsoft's advice to the development community:

Microsoft strongly recommends NOT running as an administrator because this reduces the amount of damage that can be inflicted by a virus.

This piece of advice can be found on the books online on "Users Instances":

Many Windows users have accounts with administrative privileges. Unfortunately, running as an Administrator makes it easy for malicious software to take over a user's computer. However, malicious software run by non-administrator users cannot make system-wide changes and therefore can do only limited damage.

It seems developers have a very poor idea of how to develop in non-admin account and they can found out the recipe from here.

Many developers thought that they are shackled down as a poor users and they all will tell you that developers need administrative rights. I was in that camp once.

I think they are very confused. No one denies that a developer need administrative rights but that rights are not required for the majority of time. There is a sharp distinction between having administrative access/privilege and running as an administrator. The latter means you have turned off the security infrastructure of Windows. The former means that you operate in LUA or RANU and gain the elevated privilege when you need it.

For example, as Keith said you do not need administrative rights to compile or debug a program. Visual Studio is quite happy RANU. The only time you need Admin rights is if you need to register COM server, restart IIS, etc.

In COM development, you do not need to register a COM component in order to build the client. All you need is their TLB. Similarly in .Net, you can generate the interop assembly manually in the build script for the server, thus avoiding the need to add a reference via the COM tab.

So if I were a developer who still insist on running everything as admin, I respectfully suggest he/she to visit Keith's instruction, give it a go and you will be amazed how little adjustment you have to make. It also sharpens your awareness of security issues when programming.

The benefit is that you can feel the security envelop within your debugger. So if there is any access violation, you will be told immediately.

On the topic of Users Instances, if you follows the example in that article to have a taste of it, rather invisible actually. You may not have user instances facility turned on by default and when you open a connection to the user instance, you will get a System.Data.SqlClient.SqlException saying that

Generating user instances in SQL Server is disabled. Use sp_configure 'user instances enabled' to generate user instances.

This is what you have to do to fix it:

1. Fire up the Sql Server Management Studio Express
2. Press New Query to compose a query
3. Follow the advice in the section for "sp_configure 'user instances enabled'" here.