Do you disable UAC in the enterprise?

DragonNOA1

Supreme [H]ardness
Joined
Aug 15, 2004
Messages
4,301
There are a few applications that are used housewide and need UAC disabled to either work or install correctly. What do you do at your job in regards to UAC? Disable temporarily? Disable permanently? Pressure the vendor to rewrite their app?
 
No, unless required for a testing environment or Application server.

We keep UAC enabled anywhere, where a user will be actively using the machine and browsing the web. Our developers keep it enabled so they can see the problems that the customer may see when running their software.

If it is disabled the machine get labled (UAC disabled) and a background get applied to all profiles that states UAC has been disabled on this machine. So any users that log in immediately know that UAC has been disabled.

Usually it is not a problem.

If there's a problem with the code that requires turning UAC off we either rewrite the code, use Microsoft's application compatibility toolkit, or write it up as a required step in a manual and process the change with full visibility to all who log into that machine.
 
Never disable it, I just turn it down a notch so that it doesn't dim the desktop(Plays havoc with some legacy software)

If you disable it you never get prompted for elevating certain tasks, since most of our users are on basic profiles with no rights we need to be able to prompt or shift+rightclick runas.
 
No UAC on Windows XP. :D

I don't see my workplace ever upgrading to 7 either since lot of our apps require IE6 and very specific (old) versions of Java that probably would not work on 7.

What sucks about XP is the ram limitation though. Would be so nice if we could have like 8 gigs of ram. Heck even 6 would be nice.
 
No UAC on Windows XP. :D

I don't see my workplace ever upgrading to 7 either since lot of our apps require IE6 and very specific (old) versions of Java that probably would not work on 7.

What sucks about XP is the ram limitation though. Would be so nice if we could have like 8 gigs of ram. Heck even 6 would be nice.
XP x64 edition!
 
XP x64 edition!

Heard that has lot of issues so it was never really considered. But yeah it could maybe work. They'll have to look into it eventually. Though I think what will end up happening is all these apps will be moved into citrix on server 2000 or 2003 if we ever do upgrade to 7. We already do have some VMs for certain apps because they require specific versions of Java while other apps require other versions, so they need separate environments. Our whole corporate network is a mess thanks to CGI's crappy coding.
 
UAC is disabled enterprise-wide.

Reasoning? Because that is an absolutely terrible policy unless everyone in the enterprise is running old crappy coded software that doesn't play nice with UAC. Even then, I would be going after the software company to fix their crap before making a change like that for the full enterprise.
 
UAC is enabled. It helps stop malware or at least alerts the user when some abnormally named program tries to run after the user visited a website. It doesn't really help though against things like CryptoWall which exploit Java.
 
I set UAC to Never Notify. However, my users are not members of the built-in Administrators group. If my users had Administrator privileges, I would consider turning it on because they could then install any sort of malware and run it without notification. Since they are just Standard Users, and UAC notifies the user when the Administrator security token is required to continue, UAC won't really help here because it'll require an Administrator login to proceed. If malware actually is able to gain a higher privilege level than the user running level, then something is not patched or actively being scanned...At least this is what I understand about UAC.
 
UAC is enabled for everything. Our policy is to not purchase or allow software that requires standard OS security features to be disabled. If you can't be bothered to bring your software into modern times, we won't be bothered to purchase or use it. It is time to stop doing things the 9x/XP way.

Same goes with vendors who can't make their software work on 64-bit OSes. Stop using 10+ 16-bit year old installers, and stop hard coding paths and maybe your software might just work on 64-bit systems!
 
UAC is enabled for everything. Our policy is to not purchase or allow software that requires standard OS security features to be disabled. If you can't be bothered to bring your software into modern times, we won't be bothered to purchase or use it. It is time to stop doing things the 9x/XP way.

Same goes with vendors who can't make their software work on 64-bit OSes. Stop using 10+ 16-bit year old installers, and stop hard coding paths and maybe your software might just work on 64-bit systems!
Oh, to be able to dictate these terms. Unfortunately, I think you can only get away with that in specific industries where you have choice.

I envy your position, truly. Now, if you'll excuse me, I have to go make an ins claim program that is designed to be single user only ( on windows7/2008 ) work in a remote desktop environment. Yes. Single user only.

Me and this vendor? We're not going to be friends.
 
Oh, to be able to dictate these terms. Unfortunately, I think you can only get away with that in specific industries where you have choice.

I envy your position, truly. Now, if you'll excuse me, I have to go make an ins claim program that is designed to be single user only ( on windows7/2008 ) work in a remote desktop environment. Yes. Single user only.

Me and this vendor? We're not going to be friends.

In my industry (retail home center/hardware/lumber yard type stores) we could basically pick any generic POS software out there and run it. But there are several designed specifically for the industry that are complete systems with POS/EDI/AP/AR/Payroll/etc.. in one package. And even there we have a lot of choice. A handful of these specialty systems are horrible VB6/batch file/ms access amalgamations, but fortunately all the decent systems are written in modern languages and have no issues running on modern Windows systems.

The one we use currently is 100% .NET and has absolutely zero problems running on any modern version of Windows as a standard user. It even updates itself without requiring elevation.

Unfortunately its not all bunnies and rainbows... Some of our salespeople have to use vendor supplied programs to do quoting/ordering for that vendors products. They are a complete crap shoot... Some of them puke files all over the damn place and because of this require admin access to update. Many of these receive updates constantly as well. So I have a handful of people I have to give local admin access to so they can update these shit softwares without having to bug IT constantly.
 
If you are set on being lazy and not responding to user requests move those machines to new OU's and set a GPO for them, it's like magic in a box.
 
It's on for everyone here. We had it auto accepting for about a day and then realized what was happening and fixed it.
 
Off enterprise wide. I am told it is because our packaging people do not have the manpower to package for a UAC-enabled environment. Not sure what truth there is to that but we as the grunts make do.

I'd be curious to see this survey combined with one asking about Admin Rights in your environment.
 
Off enterprise wide. I am told it is because our packaging people do not have the manpower to package for a UAC-enabled environment. Not sure what truth there is to that but we as the grunts make do.

I'd be curious to see this survey combined with one asking about Admin Rights in your environment.

What about admin rights? Here we have UAC on, no admin for users. If they need something installed, they need my credentials entered. Too many incompetent users just click ok on any kind of install prompt (even if they weren't installing anything....) and then I'm stuck cleaning their malware infested systems.
 
Kills me to say it, but I've gone from an environment where we had to disable UAC on the handful of 7 machines we had rolled out and give a fairly broad range of users Power Users to an environment where not only does UAC need to be universally disabled but all users need admin.

I'd love it if it weren't the case, but there are just industries out there where you're lucky if you have the choice of more than 1-2 software solutions. And when you're at the mercy of janky products made with terribly outdated practices/mindsets... you take the best of what's out there and you grit your teeth and do the best you can to make your environment fit it. Last place, when we were transitioning some users to 7 it totally broke one of the primary software packages that drove the business. Vendor solution was "why would you not give every user admin rights?". They know that when there's little to no competition for them, they don't have to move with the times. For that one, I actually did take the time to figure out which specific registry keys I could alter access for in order to let it at least run properly for Power Users like it did on XP. But that kind of digging just isn't always in the cards, especially with 0 vendor support behind you.
 
Kills me to say it, but I've gone from an environment where we had to disable UAC on the handful of 7 machines we had rolled out and give a fairly broad range of users Power Users to an environment where not only does UAC need to be universally disabled but all users need admin.

I'd love it if it weren't the case, but there are just industries out there where you're lucky if you have the choice of more than 1-2 software solutions. And when you're at the mercy of janky products made with terribly outdated practices/mindsets... you take the best of what's out there and you grit your teeth and do the best you can to make your environment fit it. Last place, when we were transitioning some users to 7 it totally broke one of the primary software packages that drove the business. Vendor solution was "why would you not give every user admin rights?". They know that when there's little to no competition for them, they don't have to move with the times. For that one, I actually did take the time to figure out which specific registry keys I could alter access for in order to let it at least run properly for Power Users like it did on XP. But that kind of digging just isn't always in the cards, especially with 0 vendor support behind you.
I empathize with what you're saying, I've had to do the same countless times over the years. Still, to date, I've been ultimately successful in identifying the necessary permissions and keeping users locked down to normal "limited user" accounts. But it hasn't been easy, and it's a constant game of cat and mouse with the various vendors who insist on making my life interesting with every new release ( which is why I have such a low opinion of software vendors ).
 
Most corporate software vendors are garbage. What sucks is software that requires very specific versions of stuff like Java. That is how it is where I work. It's so bad that we need a VM to run one of the programs because that program requires a different version of Java than another program we use so they can't even be on the same machine. They definitely do require admin rights too but that's pretty much to be expected with crap programs. They typically write their config in c:\windows or other places like that, and not the profile.
 
In reality UAC on Desktops will matter less and less. Many environments already use baseline configurations which are created such that the user can only change them on a per-session basis. Deep Freeze is one example for that where after each restart the baseline configuration is restored regardless of whether the user was an admin or not.

With the rollout of non-persistent VDI this will become even more prevalent. You boot up your thin/zero client, do your work, and when you leave whatever changes you made to the system go poof.
 
Back
Top