The original TFS Deployer attempted to access various restricted resources than effectively required it to run as an administrator user. Since some changes were made in February, Deployer can now be executed under a standard user account with some additional considerations which follow.

Team Foundation Server Permissions

The TFS Deployer service account must be a member of the Team Foundation Valid Users server-level group on the server specified by the TeamFoundationServerUrl config setting and also a member of the Readers project-level group for the Team Projects that Deployer will be monitoring.

If you intend to make use of the Retain Build feature, the Deployer service account will also need the Write To Operational Build Store project-level permission on applicable Team Projects.

PowerShell Execution Policy

TFS Deployer can execute Windows Command Scripts if you really need it to but PowerShell scripts are the preferred option. However, PowerShell is built to be secure-by-default and installs with script-running capabilities disabled. It is left for the user to enable scripts after PowerShell has been installed and can be performed by opening the PowerShell console as an administrator and executing either:

Set-ExecutionPolicy AllSigned ; # or
Set-ExecutionPolicy RemoteSigned

The former choice will require you to sign all your deployment scripts in source control with a certificate trusted by the Deployer. Scott Hanselman has a comprehensive post on his blog describing the signing process. The latter choice will not impose this requirement because files retrieved from source control by Deployer are not marked with a zone identifier.

HTTP Namespace Reservation

TFS Deployer utilises self-hosted WCF over HTTP to subscribe to Build Quality Change events from TFS. This technique relies on the Windows HTTP Server API which requires the Deployer service account to have been granted rights to listen on the portion of the HTTP URL namespace it uses for event notification. By default only local administrators have access to the entire namespace and permissions must be granted using the httpcfg tool (on Windows XP and Server 2003) or the netsh tool (on Vista and Server 2008).

Using the netsh tool, from an administrator command prompt, the following command (as a single line) will grant rights to the appropriate URL for TFS Deployer (assuming you are using the default port number):

netsh http add urlacl url=http://+:8881/BuildStatusChangeEvent user=DOMAIN\TfsDeployerUser

Using the httpcfg tool is more difficult as it requires an ACL string in Security Descriptor Definition Language (SDDL). However, Dominick Baier has created a tool to simplify this process and I can recommend it.

Additional Permissions

All deployment scripts executed by TFS Deployer will be executed under the context of the service account unless the scripts explicitly contain alternate credentials. If the scripts copy files to a network share, configure a web site in IIS, or even upgrade the schema of a SQL database, ensure that the service account also has the minimum privileges to perform those actions too.

Any problems, questions, or suggestions... let me know.

Jon Galloway and Jeff Atwood have been having a debate. Mostly the debate has been about anti-virus software, which is a topic that I have no strong feelings on one way or the other.

However, talking about anti-virus involves talking about security and risks and inevitably the topic of running as an administrator versus a limited user account gets mentioned.

Jon, though, more than just mentions running as a non-administrative user, he labels it as "just about impossible", and the benefits of living in a non-administrator environment is something I do have a strong opinion about.

I am a .NET developer. I develop console applications, windows services, websites, and smart clients. I do it all, not as an Administrator and not as a Power User, but I do it all as a standard user. I've been doing it this way since March 2006 and have never gone back.

I don't cheat either. Microsoft suggests running Visual Studio 2005 with increased privileges to avoid various issues. Bah! It works fine as non-admin. The only programs I run with increased privileges are installation programs... and they don't come along very often.

I'm not just using Visual Studio either. I sync my iPod with iTunes and keep my GPS up to date with TomTom Home. I use all the Office apps and I mount CD and DVD images with Daemon Tools. I write scripts in PowerShell and I test beta software in Virtual PC. I have a local install of SQL Server too.

It isn't just me either. Within six months, the other two developers I work with had joined my non-admin club after I had demonstrated not only how painless it can be but how it helps to ensure the software we develop will work when deployed to our clients' restrictive domain environments. Most of all I demonstrated how to be part of the solution to break the cycle of software that requires administrator privileges.

Ok, so far all these people I've mentioned who are running as non-admin could be considered very capable computer users and aren't the same as most people. Fair enough but how about the other less computer-savvy people I know who have been educated on how to work as a non-admin. People with jobs like call centre operator, machinist, automotive-electrician, and cook.

These are people running Windows XP to send faxes, play games, and surf the Internet, and most of them still type with one finger. Switching to an administrator account for occasional tasks is just a Fast User Switch away or, on domain-connected PCs, using the simple MakeMeAdmin tool.

Vista users get it even easier when an elevation prompt appears asking for an admin password when they need to install software or change a system control panel setting. I just don't understand why people think it is so difficult. And to be clear, there is no hidden magic here, I'm not touching the default ACLs on my file system or registry either.

To come back to where the debate began, my point is that running as a non-admin is not difficult and does not restrict productivity, but it doesn't necessarily help the anti-virus or malware situation either. Some basic tests do show that it helps in some common infection situations, but I'm confident that I would be able to easily write non-admin compatible malware if needed.

So, Jon, feel free to argue about the effectiveness of anti-virus products or how much being a non-admin protects from malware, but don't tell me non-admin is as usable as unplugging your computer. And Jeff, if you're going to suggest non-admin as a good option, at least lead by example.

By the way, I run 64-bit Windows at work and home too, just to reduce the list of compatible software even further.

Some time ago I put together a template for a file that can be interpreted as both a batch command script for cmd.exe and a SQL script for SQL Server Management Studio and sqlcmd.exe. It works really well for enabling someone unfamiliar with SQL Server to deploy database update scripts.

I've been working with PowerShell quite a lot lately and I was wondering if it would be possible to have a file that would be interpreted by both cmd.exe and PowerShell.exe. It turns out that Jay Bazuzi, a developer at Microsoft, has already found an elegant solution. However, upon inspecting the code I became concerned how it would be effected by PowerShell's default setting to disable all scripts and especially disable unsigned scripts from remote sources.

I have since worked with Jay's sample on my home machine and discovered that it effectively bypasses PowerShell's anti-script security by piping the commands to it's interactive mode. As a result, it was relatively trivial to write a batch command script that would enable PowerShell to run all future scripts and modify the user's PowerShell profile to ensure it stays that way.

Thankfully, security in the OS and other applications is making it harder to get a command script on to another computer and get the user to run it but with the capabilities of PowerShell potentially available for malicious use it's just one more reason to not run as an administrator and minimise the damage.

I tried using Rhino.Mocks in production test code for the first time the other day. I downloaded the latest version from Oren Eini's website, unzipped it into source control, and added a reference to my project.

I wrote a quick test utilising the interface mocking features and hit Ctrl+Alt+X to run the test. SecurityException! The message, which I've since forgotten, was complaining that the referenced assembly (ie Rhino.Mocks.dll) could not be loaded.

A quick Google provided the solution, you need to ensure you've unblocked any files you have downloaded from the Internet or a network machine. Now I'm happily mocking away.

The new 2007/2008 financial year has begun and as promised the Australian Taxation Office released the latest version of their e-tax software on July 1st. As I have for the past several years, I downloaded and installed the software and have started entering my income and deductions for the last 12 months.

When the official paperwork arrives, I'll confirm all my figures and submit my tax return electronically and receive my rebate usually within a week, deposited directly to my bank account. Considering the complexity of the income tax system, the software is excellent for non-accountant-types to complete their own tax return.

Unfortunately, e-tax 2007 is still stuck in the obsolete Windows administrator user world. Installation defaults to "c:\etax2007\". It has been over twelve years since Windows 95 was released and the standard was set for software to install into Program Files.

A single e-tax installation on a PC allows multiple people to fill in and submit their tax return, saving their work in progress locally until it is ready to send. However, the software assumes the user is an administrator and writes the *.tax progress file to the installation folder instead of Documents & Settings.

At several stages throughout the questionnaire, summaries and important details are presented to the user with a recommendation to print the information. However, the software always uses the default printer with the default settings, offering no dialogs, and only picking up changes to the default printer after restarting the software.

One of the biggest reasons why e-tax is so great is because the questions are presented in easy to understand language. Whenever more detail is required there are always hyperlinked keywords or a help button leading to a more extension definition with examples. Sadly, it's all useless under Vista because they've stayed with the deprecated WinHelp format for the documentation.

Lastly, for users of Apple computers (and presumably other OSes), the official solution is to use virtualization. I wonder if the purchase price of VMWare or Parallels and a Windows licence can be claimed as a cost of preparing the tax return.

By all appearances e-tax is a full Win32 application, probably written in C++ at first glance, and is expected to continue in that style for the majority of users next financial year too. Perhaps by 2009, they will have moved to a web-based client, which will open the system to non-Windows users but probably introduce other problems along the way.

If you are running Windows Vista and are bothered by "too many" UAC dialogs on a regular basis to the point that you want to turn UAC off, the problem is that you are futzing with your PC instead of doing real work.

The script in my last post for removing old files from the temporary folder is only necessary because so many applications don't clean up after themselves. Hopefully, if the applications you are developing are doing the right thing they will be using in memory streams where ever possible. Only write to disk when absolutely necessary, creating random temporary files in the environment temp folder, not program folders with restricted access to non-admin users:

string myTempFile = System.IO.Path.GetTempFileName();

However, remembering to track and delete these files when you are finished requires more effort and is often ignored, creating the ever growing temp folder problem. There is a lesser known class in the framework that can help you though:

var myTempColl = new System.CodeDom.Compiler.TempFileCollection();
string myTempImageFile = myTempColl.AddExtension("png");

Excuse the C# 3.0 syntax in the last snippet, I hate the redundancy of repeating long type names, especially on the same line. When you have finished using all the temp files you created with the TempFileCollection, you can dispose it explicitly, automatically deleting the files, or if you're really lazy, let the GC take care of it.

myTempColl.Dispose();

Jeff Atwood had some trouble with malware last week. His digging led him to blame a particular website for infesting his system. In a comment on his post, I proposed, based on my experience, that simply running as a non-administrator user instead on his clean unpatched Windows XP SP2 installation should have protected him for the most part.

I'm not suggesting that patching is a low priority but from my (potentially outdated) understanding of malware attack vectors, running as a least privileged user would have gone a long way. I tried to find some good websites to verify my assumptions but didn't have much luck. What follows is my interpretation of the situation, please leave a comment if I have underestimated the capabilities of today's malware.

• Most malware wants to get installed on your PC and survive a reboot: A non-admin user only has privileges to write to "safe" areas of your file system and registry. Malware would be unable to replace commonly used system files. It would be unable to install itself as a driver or service with higher privilege. It would be unable to schedule itself to run when another user logs on. It would be unable to place shortcuts in an area that another user would see in their profile. Lease privilege users cannot install browser plugins. System level root-kits should be unable to hook in and a reboot with a Live CD should be able to see and remove anything evil.
• Most malware wants to provide remote access to your PC: XP SP2 ships with the firewall enabled. Malware would be able to phone home but would be unable to open a port and await incoming connections. Modern broadband routers naturally prevent incoming connections too. The malware would still only be able to give the remote user least privilege access to the system.
• Most malware wants you to give it something: As a non-admin malware would not be able to modify your drivers/etc/hosts file to redirect network traffic. It would be able to spawn many popup windows attempting to sell you something but this would be nothing more than annoying. It could scan your user documents for email addresses but hopefully your contact list is online (eg Gmail) or in Outlook (which warns the user when accessed programmatically). It could log key presses and grab sensitive passwords, which is definitely a concern, but this may be reduced by the "remember my password" features in software.

Jeff's situation was an extreme example of an unprotected system. Personally, I'm using Vista 64-bit which immediately reduces the amount of malware that is actually compatible. I'm also running non-admin with UAC on so anything questionable needs my permission. I have Internet Explorer 7 which displays the Information Bar whenever something wants special permission. Data Execution Prevention and ASLR are on by default to minimise exploitation of buggy system code. I still have Windows Defender and run Ad-Aware occasionally. Every installed application is patched to the latest update. Lastly, I avoid questionable material and have another separate non-admin user account if I really need to try something.

I'm sure I'm not 100% safe, but I don't think that's currently attainable. Any machines I remove malware from for friends get returned with a non-admin account and they only come back to me with more problems after sheepishly admitting they went back to an admin account. I have read that the new hardware-virtualization features in new CPUs (which I have enabled) could allow malicious code, and then there is everything else I haven't heard of.

I think I've rambled enough and probably missed many things but I'm interested in reading your thoughts on the matter. If you can recommend a good source for the latest PC security information I'd appreciate that too.

My new home office machine has arrived and I am setting myself up for the most pain possible with my chosen configuration. Firstly I am installing Visual Studio 2005 on Vista Business Edition. Microsoft has only just released a patch for Visual Studio on Vista and it isn't perfect. Add to that running as a restricted user in Vista which introduces more problems. Finally I've chosen the 64-bit edition of Vista which complicates working with Visual Studio and software in general.

Reading the many articles and forum posts about problems with Vista and 64-bit will discourage most people from trying but so far I've found the experience to be quite pleasant. The first road-block is the need for new Vista 64-bit signed hardware drivers but Windows detected everything but the onboard sound and I was able to very easily find drivers on the HP web site for that. Two vital utilities, Daemon Tools and UltraMon, are already available with Vista x64 versions.

Vista has streamlined .zip file handling so I don't need any archiving software and the usual problems with new OS burning software are gone because Vista writes to CD and DVD out of the box. The small problem of burning disc images is solved by the free ISO Recorder, updated for Vista x64. I don't need MakeMeAdmin anymore because Vista's UAC temporary privilege elevation features have solved the problem. And, of course, Microsoft Office works beautifully.

I could rant for hours about the wonders of this new system but there were some issues. I managed to crash Visual Studio while setting the options for the first time but this is an easily avoidable documented issue (thanks Jim). I upgraded SQL Server 2005 to SP2 via Vista's built in AutoUpdate tool so I needed to run the User Provisioning Tool manually afterward to be able to connect. Also, a minor annoyance, Windows x64 has a separate Program Files folder for 32-bit and 64-bit applications and some installers were defaulting to the wrong folder.

I'm keeping a list of issues I encounter with Windows in general and developing with Visual Studio and SQL Server. I'll write about my experiences further on this blog as time passes and as I start pushing the boundaries of compatibility. At this point I have no regrets moving to Vista and 64-bit. I sure don't want to go back to either 32-bit or Windows XP and I'd recommend anyone with similar needs to my own to do the same.

Windows Vista is expected at the end of the year and security enhancements are one of the biggest talking points about Vista at the moment. One enhancement receiving a lot of attention in particular is the idea of running the system under a Limited User Account (LUA) by default.

I've always like the idea of limited permissions for improved security but it has always seemed too hard to achieve when I have tried in the past. Since then, the information, tools, and push to develop LUA-safe software have become much more popular and it is definitely where most systems are heading. Considering this, I have decided to jump onboard and attempt to use my primary Windows XP machine for all my daily tasks with a non-Administrator, non-Power User, Limited User Account.

I have read several forums and blogs discussing many different aspects of using LUAs but ultimately the replies and comments turn into a list of reasons why people don't like running without their beloved admin rights. I would like to try to use this blog to present a consistently optimistic view toward running with a LUA and look at the problems encountered and how to work around them. Maybe this will be useful to others who are interested in putting their Administrator hat aside for a while or maybe for good.

Writing this article I have been running my notebook as a limited user for one week now. I use my notebook from 9 to 5, Monday to Friday at the office and I take my notebook home at night and on weekends and use it almost every waking hour. It is the only computer I use. At the office I am .NET developer, using Visual Studio 2005 and SQL Server 2005 to write enterprise Windows Forms applications. At home I like to play with the latest software and mess around with new hardware. I definitely consider myself a power user and I didn't begin this expecting it to be an easy endeavour.

However, I may have an unfair advantage. I have had my notebook running with an account with admin rights since I bought it six months ago and in that time I have installed and configured all my regular programs the way I like them. I have now simply removed my account from the Administrators group and continued with my existing profile.

Logging in for the first time as a limited user, my first experiences were very good. All my documents and dev projects were still fully accessible and my regular applications (MSN Messenger, Outlook, and Firefox) worked perfectly. To my surprise Visual Studio 2005 and the SQL Server Management Studio worked fine too.

I am very satisfied with the LUA support in most Microsoft programs so far and I expect most problems will usually be due to bad third-party software. However, Microsoft Backup is an interesting one, as a limited user I don't have access to all my system files so I cannot perform a complete backup. Windows defines a security group called Backup Operators to solve this problem but I am not sure whether adding my normal account to this group would be a good idea. I guess it depends on whether this group only grants access to special file backup APIs or if it grants all access to any file operation. I think I will just login as a special backup user for performing my backups and avoid any potential problems.

Using a notebook PC means that I have a plethora of OEM applications running to "support" all the non-standard features. The power management software is the first of the bad third-party software to fail under an LUA. It simply doesn't run and as a result when my I unplug my notebook and it switches to battery power, the software isn't there to auto-adjust the LCD brightness and other power-saving options. I don't use battery power often so for now I run the power management software as Administrator whenever I need it but I will have to look into this further and maybe start hassling Acer to fix it.

My RSS aggregator, Omea Reader, refused to start, citing an error about class registration or some such thing. A quick search on the newsgroups suggested clicking the Omea "Clip and Edit" toolbar button in Internet Explorer and sure enough the software has worked fine ever since. Also, Nero Burning Rom denied access to my DVD writer, but having encountered this before I logged in as Administrator, ran the NeroBurnRights.exe tool (hiding in the Nero folder), added my account to the Nero group, and that problem was solved too.

Another minor annoyance was the inability to use one of my favourite shortcuts - double-clicking the clock in the system tray to see a quick calendar. As a limited user I cannot change the system time so that dialog is unavailable and I now resort to using my Outlook calendar (which is normally running anyway).

A very handy tool that I must recommend for LUAs is MakeMeAdmin from Aaron Margosis. This tool uses some neat batch file tricks to temporarily promote your current account to an Administrator for certain programs. The benefit of this over RunAs is that with MakeMeAdmin you still maintain your profile, user folders, and environment. I use this tool for installing new programs and for occasionally starting or stopping a service.

So far I am very happy working as a limited user (Luser) and I expect I won't be changing back to Administrator again. I am even becoming more organised with new files that I create or download because I don't have permission to dump them all in the root of my second partition anymore. I will try to keep you up to date with my progress as my LUA experience continues.

I often get the feeling that I am the only person who has setup Windows 2K/XP computers with limited-access users. Does everyone out there really configure every user as an Administrator? The majority of application software and games available today suggest this is true.

Microsoft published a document entitled "Designed for Windows XP Application Specification" about three years ago. I can only assume that nobody has read it or any of the other related publications or API documentation. On page 37 of this document is Section 3.0, "Data and Settings Management". Here it quite clearly explains where applications need to save user related data and how. The days of Windows 3.1 are over. We have a Program Files folder with security permissions denying write access to non-Administrators. This has been the situation since Windows 2000 (maybe Windows NT 4.0 also?). Yet too many programs attempt to store user configuration information in the same folder as the executable itself.

On my home PC, I have a user account for myself and a user account for my girlfriend, Libby. Libby's account is a limited user account and this breaks a lot of software. She can't use WinAmp without modified permissions on the application's install folder. Also, we each end up inheriting the configuration changes made by the other. Many games that Libby likes to play (including the new and fantastic Yourself Fitness!) have problems too. These games try to store game progress data in the game's install folder. As a result Libby has to start from the beginning everytime unless I change the default permissions.

As the administrator it is necessary for me to install any software that Libby requests. If I am happy it isn't something harmful that she has downloaded I go ahead. Unfortunately it seems that a lot of software won't install to multiple users either. It is not just that the setup program simply didn't put the shortcuts in the All Users start menu. If I create the appropriate shortcuts, the software still won't run under a non-privileged account.

I guess the problem is a combination of ignorance, failure to test restricted user scenarios, and simply considering the problem insignificant. WinAmp has been around for a long time. Version 5 was released not too long ago. However, discussions regarding multi-user support in WinAmp on the WinAmp developer forums have been dismissed as not important.

Everywhere we look today, the focus is on security but if even the most secure and stable software won't work for users other than administrators, what is the point?