It’s been my observation that in most organizations administrators use their normal user account for admin tasks. The account is made a member or Domain Admins, DNS Admins, Exchange Admins, or whatever admin group grants the appropriate level of permissions for their role. I would like to make the case for using a separate account for admin tasks.
 
When using a single account for normal user login and admin tasks the first thing that comes to mind is all of the Group Policy settings associated with that account. They could include drive mappings, software installation, scripts, etc. that would apply when you log on to a computer. You wouldn’t want to have all of these apply when you log on an infrastructure server or a Domain Controller.  
 
Another argument is that you will likely be logged in all day. Even the most security conscious person can step away and forget to lock the keyboard. I hate to admit it but I have done this, and when I returned 4 minutes later a co-worked had tinkered with my system as a joke. Danger isn’t always lurking in the next cubical, but there is an undeniable risk.
 
OK you concede, but then I would have to log off my normal user account and log on my admin account every time I need to do something. Not so!  Fortunately in Windows XP there is a feature known as “Run As” that will allow an administrator to log in with a normal user account and, when necessary, execute *.exe or *.msc consoles with their admin account (shift +right click “Run as”). “Run as” was removed in Vista but ShellRunas can be downloaded from Technet Sysinternals.
 
When you need to log into a server remotely using RDP “Run as” isn’t necessary, you merely login with your admin credentials.
 
Returning to the example above, if you walk away from your system and leave a console window open having a separate admin account really doesn’t help. You should only open an admin console (.msc) when needed and close it when finished. The same is true for remote sessions.
 
Keep in mind that if you decide to use a separate account for admin tasks, where ever you place it in your OU structure to make certain it is not receiving unnecessary Group Policies.
 
I hope this information is useful.