Truth. However, there are also political and training issues. 1) We haven't, as a company (nor within IT) figured out how to make our standard apps work under under non-admin accounts. This will take time and resources to figure out, and then further time and resources to figure out how to "productionise" the application of these settings and apply them across the domain, including two offices overseas.
2) A large portion of our users are engineers who have a rabid aversion to the idea that they can't be admins on their own boxes. I'm in the (multi-year!) process of simply trying to convince engineering managers that none of the staff need two NICs in their boxes - one for the production LAN and one for the test/dev LAN. 3) The overseas offices are also politically resistant to this idea. While I agree that the load would be lessened, and we'd have a much better managed and more secure environment, this is not a trivial effort, and at times I despair. But, I persist, and have it as a goal to work toward this fiscal year. The first step is to get signoff by company management, in the form of an actual policy - something of which there are no good examples. There are practices and recommendations regarding IT, but very little in the way of a real IT policy that has been agreed to by management. Kurt On Wed, Jul 8, 2009 at 07:52, Jonathan Link<[email protected]> wrote: > After taking local admin rights away from users my plate is less full. > YMMV. > > On Wed, Jul 8, 2009 at 10:47 AM, Kurt Buff <[email protected]> wrote: >> >> Yes, unfortunately, all our users are admins. It sucks, but I use it >> to my advantage when I can. >> >> The reason we've not done a GP is because we haven't had the luxury of >> studying to understand them. Our plates always seem to be full with >> other things. >> >> On Tue, Jul 7, 2009 at 19:04, Ken Schaefer<[email protected]> wrote: >> > Are all your users admins? Otherwise, how is that logon script going to >> > update HKLM? >> > >> > Machine-based startup script would be better idea, no? >> > >> > Cheers >> > Ken >> > >> > ________________________________________ >> > From: Kurt Buff [[email protected]] >> > Sent: Wednesday, 8 July 2009 2:41 AM >> > To: NT System Admin Issues >> > Subject: Re: New IE zero day exploit in the wild >> > >> > I'm just pushing out the .reg file in the login script: >> > >> > regedit /s \\fileserver\public\patches\videokillbits.reg >> > >> > The file was easy to create, in a capable editor (not notepad or >> > wordpad) that allows metacharacter search and replace, such as '\n' >> > for CRLF and '\t' for tab. I used the ancient, no-longer-supported >> > PFE32. I really should switch to VIM, I suppose. >> > >> > On Tue, Jul 7, 2009 at 08:40, Eric >> > Wittersheim<[email protected]> wrote: >> >> I'm pushing out the .reg via GP. So far so good. >> >> >> >> On Tue, Jul 7, 2009 at 10:38 AM, David Lum <[email protected]> wrote: >> >>> >> >>> The “Microsoft fix-it” is an MSI that I am pushing via SMS and is >> >>> pushing >> >>> fine (so far just a few test cases have it, but no issues). Beats >> >>> trying to >> >>> push out a .REG or something… >> >>> >> >>> >> >>> >> >>> David Lum // SYSTEMS ENGINEER >> >>> NORTHWEST EVALUATION ASSOCIATION >> >>> (Desk) 971.222.1025 // (Cell) 503.267.9764 >> >>> >> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> > >> > >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
