This that you describe is extensively supported and documented in windows.
Any given user (or individual process, through the granting of tokens) can be granted or revoked any desired level of granularity of permissions or abilities.
It's used everywhere, by a large number of (competently written) software and software installers.
It's used extensively in XP and Vista (which are all just later generations of NT).
They are well understood by competent sysadmins and programmers on the platform. I find it really sad to hear that this sort of thing is a surprise to anybody, as its just part of the platform that you need to know about to use effectively.
Is it well documented?
Well, this is probably not comprehensive, but a 10-second google search gives me this as the first result. It's from the 2003 server docs, but its the same set of rights in XP and Vista (though Vista may have some new ones).
For anyone who works professionally in this industry on windows system administration, this is not news, this is well known stuff. Yes, there are plenty of incompetent ('hey, my cousin does windows administration in his spare time from high school') administrators out there, but thats not what we're talking about.
There are a number of reasons why I like it better. Some of these may be relevant to you, some not.
1. The ribbon interface. This is such a massive improvement, I'm actually kind of amazed it came from who it did. Dont discount it before you've spent an hour using it. The advantage was obvious within 10-15 minutes using it. All features are at most 2 clicks deep and the vast majority are just 1 click.
2. Sharepoint 2007 integration. Now this wont mean much if you aren't using Sharepoint 2007, but its a better integration story than before.
3. Outlook 2007. This is a nice improvement. Outlook 2003 was nice as well, but if you use exchange, tasks, calendar heavily in Outlook 2003, you'll like the upgrade. The task/calendar integration is very nice. The ability to auto-discovery exchange 2007 servers is nice once you move your exchange up to 2007.
4. Mouse pointer context menus. These are nice, when you select a word, or put your mouse somewhere... and a nice little context menu pops up right next to the pointer with a bunch of formatting or relevant options. Note these are different than the context menus you get with right-click.
5. Fit and Finish. This is hard to put into quantitative elements, but overall the suite is just much more polished, and is a pleasure to work with.
I'm sure others have other reasons to like it, but this is from my point of view.
Is it compelling if you're forking the cash out of your own pocket? Maybe not. But if you're on a subscription or can get it cheaply with your new computers, its worth it.
Right click on the ribbon and select 'Hide the Ribbon'.
The ribbon is now gone, and only comes back when you click on the tab headers, and then goes away again when you've made your selection. Ie, auto-hide behavior.
This way you get the power and ease of use of the ribbons without taking up real-estate.
Well, dont buy into too many of the comments about how it pops up UAC prompts when moving files around within the MyDocuments, or things like this that require no admin privs.
Thats obviously not happening in a normal setup. These are people who are either inadvertently (or maliciously) using an RC or beta version, or have something horribly broken on their machines in the first place, like mangled ACLs on their mydocs.
I think its a bit disingenuous to suggest that dropping to the command line in linux and running a sudo command is something commonly done by non-expert users, but right-clicking on an icon in windows and choosing runas is too complicated for non-expert users.
They're both the exact same use-case.
And also note that UAC behaves just like an automatic-runas (or similar to OSX in the GUI), if you're running as a non-admin user in Vista. It only does the popup 'are you sure' business in vista if you have UAC enabled AND you are running as an admin users. If you run as non-admin with UAC enabled, when you try to do something requiring admin rights, it asks you for an admin account to log into.
Now mind you, one thing MS completely missed (as you said above in one of the grandparents) is the caching of creds. That would be nice.
Besides, RunAs doesn't help as installers aren't run using the user's privileges anyway. They hand off control to the installation service which already runs with Administrator privileges. If you have UAC enabled you will get the same popups whether you run the installer as lambda user or as an admin. Using Runas to run your installer changes nothing.
Thats not how it works. RunAs runs as whatever user account you tell it to. The Installer sevice only does escalation in a very specific set of cases that isnt really relevant to what we're talking about.
This is easy to prove. Use runas to launch an installer and then look at task manager, and see what identity the installer (and the msiexec) is running as.
And as noted above, UAC behaves differently depending on whether you're running as admin or non-admin users.
Well thats true as a wide generality. IF there is an available priv escalation exploit available, then yes. But thats true of every OS. Every OS has had it's share of priv escalations. Every OS closes them as fast as they're found.
However, I'm not sure what this has to do with the effectiveness of UAC.
By contrast, under the Vista model, a malicious program could hop onto your system with limited rights, and then just wait until the inevitable day when the user disabled UAC. Then it can happily write itself to the filesystem, change the registry and install the keystroke logger with Admin rights.
Only if the users is running as admin.
If someone moves to Vista, runs as admin for their daily regular account usage, and then disables UAC, then what do you expect?
The simpler alternative would be to just use a non-admin account for normal work, disable UAC, and use runas/makemeadmin or log out and log in as an admin account for administrative work.
There are a couple ways to get around most of these, though I wish it were easier.
1. There is a setting on XP in the Tools, Folder Options, View, Launch Folder Windows in a separate process. Check this, and now you can do runas on explorer.exe and get a genuinely new shell window, without the IE hack.
2. Use MakeMeAdmin. This effectively adds admin tokens to the process you're launching, but no other processes. So your regular account (rather than an admin) has admin privs, but only in the context of that one process.
Between the two, you can deal with most anything. I do wish it was simpler, but it is doable at least.
I'm not sure if it still exists in Vista, but in XP there is a group called 'Network Configurators'. If regular non-admin users are added to this group, then they can change the wifi settings, the lan network settings, etc.
I've typically setup the AD such that laptop users are members of Network Configurators on the laptops.
Anyway, a piece of info... not sure if it works the same in Vista.
Note that you can do this too on Windows if the app developer allows it (ie, didnt hard-code certain paths like C:\Program Files\TheApp\etc, and doesnt need to install files in the system directories, or modify the system parts of the registry.
I do alot of development, and so have many apps installed like this. Eclipse, Tomcat, SQL Squirrel, FileZilla, WinMerge. All were installed by literally just dropping files into the right places on the drive.
The sad thing is that nearly every business-type app could be configured to work this way, if only the developers made the choice to do so. There are extensive MS articles on how to do this, including even avoiding the need to globally register COM components.
Note that you dont need admin to compile programs or edit source files in Vista either, you just need it to fire up the Visual Studio IDE. The bulk of this is the debugger integration with the IDE, but its not necessary.
You could use one of a million other more lightweight editors, and then compile your.net programs with the free (as in beer) csc.exe C#/.NET compiler. All without running as admin.
What you're experiencing (or hearing others experiencing) is purely a Visual Studio thing, not a windows or even a.net thing. For better or for worse, MS made the choice to have VS2005 require admins, for the sake of more simpler debugger and system integration support. In the prior two versions of VS.net, you could make a few simple changes, and (other than the debugger) could use VS quite fine as non-admin.
You are not prompted when moving files from one of your own folders to another of your own folders.
This doesnt happen on Vista either. Is it possible the ACLs on those folders or files arent what you think they are? If you have modify perms on the source folder and file, and modify perms on the new folder, then you wont be prompted.
So for example, moving files around inside your My Documents will not trigger UAC. Moving files between your MyDocuments and another user's My Documents, or to the Program Files directories, will cause UAC to fire (and rightly so).
You are not prompted when editing your own menus.
This also doesnt happen in Vista. What's probably happening is that you're trying to modify items in the All Users menu. That will fire UAC, and rightly so, as you're modifying effectively a 'system' portion of the file system, to which your account doesnt have modify ACLs.
Of course, linux and OSX have fine-grained mechanisms to grant/revoke permissions for any file, folder, or program. If I wanted to install openoffice as my cousin vinnie, I could do so.
This is also true of windows, and even more so than most unices. Only with OSX 10.5 and things like SELinux do you get finely-grained file & folder ACLs, which have been standard and built into NT since 3.5. Otherwise, you have the much-less-flexible owner/group/world perms.
This is commonly done in Windows in one of two ways:
1. Use RunAs to fire off a new explorer.exe process running in admin mode. Then do as much work as you want, as long as the process is started from that window, its all in admin mode. It's basically almost like firing up a term-serv window into your own machine. MakeMeAdmin is the same thing, but adds the elevated priv tokens to your regular profile for that one process (rather than starting a process in a different user profile).
2. Use RunAs to fire off a new cmd.exe shell running in admin mode. Then do as much work as you want as admin.
Now granted, UAC is sort of a weird hybrid thing, where you run as admin but cant do admin stuff without answering the prompt. But just turn UAC off, work as a non-admin (like a sane person), and use RunAs when you need it.
You dont need admin rights to run a user-space program in NT.
The app developers basically have to be living in the stone age to still be writing apps that need system privs for user-space apps, after install.
And wrt the registry, the vast, vast majority of applications shouldnt ever need to touch the registry at all. The only real exception is COM registration on install, but that is a one-time thing, no different than dropping new binaries in system directories in a Unix system.
In fact, for about the past 5+ years, MS has offered the 'Designed for Windows ' certification program, which gives explicit best-practices on how to write user apps that (among many other things) run correctly under a non-admin account. So they basically publish an exact guide of where things should go, and where you should and should-not be writing data.
Frankly, I'm not sure what else MS could do to improve things.
Not that I necessarily disagree with you in general, but in this specific case, that doesnt make much sense.
You just build the box, put it back in production, and take your time over the next 30 days to work out activation. There's no critical path preventing you from moving the box back into production until after its activated.
The most common usage, in my experience, is troubleshooting unexpected behavior with other people's code. Had to use it a number of times recently with OJB, to figure out why something is happening that shouldnt be.
Focus groups dont design products or enhancements.
Individuals or small groups of professionals in a brainstorm session do so. They then use focus groups to test and evaluate the ideas.
They also use personal feedback from partners, large customers, and PSS (ie, MS support call) statistics. They also do private betas.
Now granted, for your specific example (activation) I doubt if its seen much in the way of focus groups, so your usability and hard core testing is happening in the wild. But for many of their systems and products, they do insane amounts of usability testing and planning. Unfortunately, prior to recent versions of windows, the vast majority of what they were targeting was non-IT folks, so you end up with dumbed down interfaces or systems.
In addition to Darby's response, which works great, you can also just set the swap to a fixed size right after installing windows.
It'll be one contiguous block (or a very small number of large blocks, which is fine for a swap file), and never change.
A swap partition is more elegant, but MS is somewhat caught here by their drive-lettering scheme. The swap partition would have a drive letter, and would probably confuse the heck out of non-technical folks. Then they'd have to hide the partition, and that would just cause more yelling of tech folks, etc etc.
Anyway, you can get all the benefits of a swap partition very easily on windows, its just not the default, unfortunately.
Slashdot Mirror
This that you describe is extensively supported and documented in windows.
Any given user (or individual process, through the granting of tokens) can be granted or revoked any desired level of granularity of permissions or abilities.
It's used everywhere, by a large number of (competently written) software and software installers.
b rary/ab66826b-3230-4d3f-a8df-2491b10473ec1033.mspx ?mfr=true
It's used extensively in XP and Vista (which are all just later generations of NT).
They are well understood by competent sysadmins and programmers on the platform. I find it really sad to hear that this sort of thing is a surprise to anybody, as its just part of the platform that you need to know about to use effectively.
Is it well documented?
Well, this is probably not comprehensive, but a 10-second google search gives me this as the first result. It's from the 2003 server docs, but its the same set of rights in XP and Vista (though Vista may have some new ones).
http://technet2.microsoft.com/WindowsServer/en/li
For anyone who works professionally in this industry on windows system administration, this is not news, this is well known stuff. Yes, there are plenty of incompetent ('hey, my cousin does windows administration in his spare time from high school') administrators out there, but thats not what we're talking about.
There are a number of reasons why I like it better. Some of these may be relevant to you, some not.
... and a nice little context menu pops up right next to the pointer with a bunch of formatting or relevant options. Note these are different than the context menus you get with right-click.
1. The ribbon interface. This is such a massive improvement, I'm actually kind of amazed it came from who it did. Dont discount it before you've spent an hour using it. The advantage was obvious within 10-15 minutes using it. All features are at most 2 clicks deep and the vast majority are just 1 click.
2. Sharepoint 2007 integration. Now this wont mean much if you aren't using Sharepoint 2007, but its a better integration story than before.
3. Outlook 2007. This is a nice improvement. Outlook 2003 was nice as well, but if you use exchange, tasks, calendar heavily in Outlook 2003, you'll like the upgrade. The task/calendar integration is very nice. The ability to auto-discovery exchange 2007 servers is nice once you move your exchange up to 2007.
4. Mouse pointer context menus. These are nice, when you select a word, or put your mouse somewhere
5. Fit and Finish. This is hard to put into quantitative elements, but overall the suite is just much more polished, and is a pleasure to work with.
I'm sure others have other reasons to like it, but this is from my point of view.
Is it compelling if you're forking the cash out of your own pocket? Maybe not. But if you're on a subscription or can get it cheaply with your new computers, its worth it.
Right click on the ribbon and select 'Hide the Ribbon'.
The ribbon is now gone, and only comes back when you click on the tab headers, and then goes away again when you've made your selection. Ie, auto-hide behavior.
This way you get the power and ease of use of the ribbons without taking up real-estate.
Thats not how it works though. If you open a .doc file, then just hit save, and it saves as a .doc file, doesnt try to 'upsell' you or anything.
.doc for a while.
You can also set the default save type, so you dont ever have to use Save As if you only want to work with
And I'm not sure, but there's probably a script or group policy you can use to enforce that default throughout the organization.
Thats actually not how it works.
.doc document, and just hit save, it saves to that same format with no complaints.
.doc and avoid .docx for now, you change the default save, so you dont even have to do Save As every time.
If you open a
And if you want to just work purely in
Easy as pie.
Now mind you, I do remember old versions behaving the way you describe, but I think its been a while since its done that.
Well, dont buy into too many of the comments about how it pops up UAC prompts when moving files around within the MyDocuments, or things like this that require no admin privs.
Thats obviously not happening in a normal setup. These are people who are either inadvertently (or maliciously) using an RC or beta version, or have something horribly broken on their machines in the first place, like mangled ACLs on their mydocs.
I think its a bit disingenuous to suggest that dropping to the command line in linux and running a sudo command is something commonly done by non-expert users, but right-clicking on an icon in windows and choosing runas is too complicated for non-expert users.
They're both the exact same use-case.
And also note that UAC behaves just like an automatic-runas (or similar to OSX in the GUI), if you're running as a non-admin user in Vista. It only does the popup 'are you sure' business in vista if you have UAC enabled AND you are running as an admin users. If you run as non-admin with UAC enabled, when you try to do something requiring admin rights, it asks you for an admin account to log into.
Now mind you, one thing MS completely missed (as you said above in one of the grandparents) is the caching of creds. That would be nice.
Besides, RunAs doesn't help as installers aren't run using the user's privileges anyway. They hand off control to the installation service which already runs with Administrator privileges. If you have UAC enabled you will get the same popups whether you run the installer as lambda user or as an admin. Using Runas to run your installer changes nothing.Thats not how it works. RunAs runs as whatever user account you tell it to. The Installer sevice only does escalation in a very specific set of cases that isnt really relevant to what we're talking about.
This is easy to prove. Use runas to launch an installer and then look at task manager, and see what identity the installer (and the msiexec) is running as.
And as noted above, UAC behaves differently depending on whether you're running as admin or non-admin users.
Well thats true as a wide generality. IF there is an available priv escalation exploit available, then yes. But thats true of every OS. Every OS has had it's share of priv escalations. Every OS closes them as fast as they're found.
However, I'm not sure what this has to do with the effectiveness of UAC.
Only if the users is running as admin.
If someone moves to Vista, runs as admin for their daily regular account usage, and then disables UAC, then what do you expect?
The simpler alternative would be to just use a non-admin account for normal work, disable UAC, and use runas/makemeadmin or log out and log in as an admin account for administrative work.
At least IMO.
Users are prompted for an admin account and password via UAC if they're running as non-admin users.
If they're running as admin users, then UAC uses the secure desktop to ask Yes/No.
So if you want user/pass prompt, rather than yes/no prompt, then dont run as as an account in the local admins group.
There are a couple ways to get around most of these, though I wish it were easier.
1. There is a setting on XP in the Tools, Folder Options, View, Launch Folder Windows in a separate process. Check this, and now you can do runas on explorer.exe and get a genuinely new shell window, without the IE hack.
2. Use MakeMeAdmin. This effectively adds admin tokens to the process you're launching, but no other processes. So your regular account (rather than an admin) has admin privs, but only in the context of that one process.
Between the two, you can deal with most anything. I do wish it was simpler, but it is doable at least.
I'm not sure if it still exists in Vista, but in XP there is a group called 'Network Configurators'. If regular non-admin users are added to this group, then they can change the wifi settings, the lan network settings, etc.
... not sure if it works the same in Vista.
I've typically setup the AD such that laptop users are members of Network Configurators on the laptops.
Anyway, a piece of info
Note that you can do this too on Windows if the app developer allows it (ie, didnt hard-code certain paths like C:\Program Files\TheApp\etc, and doesnt need to install files in the system directories, or modify the system parts of the registry.
I do alot of development, and so have many apps installed like this. Eclipse, Tomcat, SQL Squirrel, FileZilla, WinMerge. All were installed by literally just dropping files into the right places on the drive.
The sad thing is that nearly every business-type app could be configured to work this way, if only the developers made the choice to do so. There are extensive MS articles on how to do this, including even avoiding the need to globally register COM components.
Sure. Google 'disable uac site:microsoft.com'.
r ary/0d75f774-8514-4c9e-ac08-4c21f5c6c2d91033.mspx? mfr=true
The first result is this:
http://technet2.microsoft.com/WindowsVista/en/lib
Scenario 3 describes how to turn UAC off in its couple of modes.
Note that you dont need admin to compile programs or edit source files in Vista either, you just need it to fire up the Visual Studio IDE. The bulk of this is the debugger integration with the IDE, but its not necessary.
.net programs with the free (as in beer) csc.exe C#/.NET compiler. All without running as admin.
.net thing. For better or for worse, MS made the choice to have VS2005 require admins, for the sake of more simpler debugger and system integration support. In the prior two versions of VS.net, you could make a few simple changes, and (other than the debugger) could use VS quite fine as non-admin.
You could use one of a million other more lightweight editors, and then compile your
What you're experiencing (or hearing others experiencing) is purely a Visual Studio thing, not a windows or even a
This doesnt happen on Vista either. Is it possible the ACLs on those folders or files arent what you think they are? If you have modify perms on the source folder and file, and modify perms on the new folder, then you wont be prompted.
So for example, moving files around inside your My Documents will not trigger UAC. Moving files between your MyDocuments and another user's My Documents, or to the Program Files directories, will cause UAC to fire (and rightly so).
You are not prompted when editing your own menus.This also doesnt happen in Vista. What's probably happening is that you're trying to modify items in the All Users menu. That will fire UAC, and rightly so, as you're modifying effectively a 'system' portion of the file system, to which your account doesnt have modify ACLs.
Of course, linux and OSX have fine-grained mechanisms to grant/revoke permissions for any file, folder, or program. If I wanted to install openoffice as my cousin vinnie, I could do so.This is also true of windows, and even more so than most unices. Only with OSX 10.5 and things like SELinux do you get finely-grained file & folder ACLs, which have been standard and built into NT since 3.5. Otherwise, you have the much-less-flexible owner/group/world perms.
Are you using IE to browse an HTTP delivered listing of files? I'm confused as to what IE has to do with file-sharing.
I've used many a NAS and IE never gets involved. Either just map a drive to the NAS, or use \\servername\sharename\ to access files.
Now mind you, I havent tried WebDAV in Vista yet, so maybe that's what you're experiencing?
This is commonly done in Windows in one of two ways:
1. Use RunAs to fire off a new explorer.exe process running in admin mode. Then do as much work as you want, as long as the process is started from that window, its all in admin mode. It's basically almost like firing up a term-serv window into your own machine. MakeMeAdmin is the same thing, but adds the elevated priv tokens to your regular profile for that one process (rather than starting a process in a different user profile).
2. Use RunAs to fire off a new cmd.exe shell running in admin mode. Then do as much work as you want as admin.
Now granted, UAC is sort of a weird hybrid thing, where you run as admin but cant do admin stuff without answering the prompt. But just turn UAC off, work as a non-admin (like a sane person), and use RunAs when you need it.
You dont need admin rights to run a user-space program in NT.
The app developers basically have to be living in the stone age to still be writing apps that need system privs for user-space apps, after install.
And wrt the registry, the vast, vast majority of applications shouldnt ever need to touch the registry at all. The only real exception is COM registration on install, but that is a one-time thing, no different than dropping new binaries in system directories in a Unix system.
In fact, for about the past 5+ years, MS has offered the 'Designed for Windows ' certification program, which gives explicit best-practices on how to write user apps that (among many other things) run correctly under a non-admin account. So they basically publish an exact guide of where things should go, and where you should and should-not be writing data.
Frankly, I'm not sure what else MS could do to improve things.
Not that I necessarily disagree with you in general, but in this specific case, that doesnt make much sense.
You just build the box, put it back in production, and take your time over the next 30 days to work out activation. There's no critical path preventing you from moving the box back into production until after its activated.
The most common usage, in my experience, is troubleshooting unexpected behavior with other people's code. Had to use it a number of times recently with OJB, to figure out why something is happening that shouldnt be.
You can actually do it without the memory store, using the parenthesis built into the calc program.
You just need to change it to scientific mode. From the pull-down menus, click on View, then Scientific.
Then type on the calc:
( (this is a button)
3
[x^y] (this is a button)
2
+
4
[x^y]
2
)
as soon as you hit the closing parenthesis, you get 25.
Now, you dont get the entire string shown and then click 'do' and get a result, it does it as you type it in, like a traditional calculator.
Focus groups dont design products or enhancements.
Individuals or small groups of professionals in a brainstorm session do so. They then use focus groups to test and evaluate the ideas.
They also use personal feedback from partners, large customers, and PSS (ie, MS support call) statistics. They also do private betas.
Now granted, for your specific example (activation) I doubt if its seen much in the way of focus groups, so your usability and hard core testing is happening in the wild. But for many of their systems and products, they do insane amounts of usability testing and planning. Unfortunately, prior to recent versions of windows, the vast majority of what they were targeting was non-IT folks, so you end up with dumbed down interfaces or systems.
In addition to Darby's response, which works great, you can also just set the swap to a fixed size right after installing windows.
It'll be one contiguous block (or a very small number of large blocks, which is fine for a swap file), and never change.
A swap partition is more elegant, but MS is somewhat caught here by their drive-lettering scheme. The swap partition would have a drive letter, and would probably confuse the heck out of non-technical folks. Then they'd have to hide the partition, and that would just cause more yelling of tech folks, etc etc.
Anyway, you can get all the benefits of a swap partition very easily on windows, its just not the default, unfortunately.