Grant or deny?

Local admin privileges — to reinstate or keep locked away?

This has been on my mind a lot lately, mainly because I’ve been thinking about ways to better serve our users at NPCC and make things easier for them.  I know the local admin discussion is not a new one by any stretch, and you can also approach it from either side of the fence.  It really comes down to what you determine to be "acceptable risk."

This is what I’m kicking around in my head right now — what if I made each user a local admin for their respective machine?  Currently, only laptop users and one, maybe two desktop users have local admin rights to their machine. 

The advantages of giving back local admin?
1. Users can install software without having to ask me or wait on me to arrive on the scene.
2. Users can update programs on their own (Yeah I’m talking about you, iTunes) without my approval.
3. Those flash drives that require an extra piece of software before they mount (which I hate) can be used without my being on the scene.  In addition, the end-user can be walked through the process of reassigning drive letters if their flash drive somehow manages to interfere with our standard drive mappings. (boo)
4. Users can install fonts on their own without having to ask me.
5. If a user is done with a program and no longer needs it, they can uninstall it on their own without my help.

Now, the disadvantages and dangers of putting local admin back in the users’ hands?
1. Users can install software without having to ask, regardless of whether this software is legit or not.
2. To guard against the above, I will need to implement a monitoring solution that tracks software installation.  Spiceworks might be a good place to start with that.
3. I’m going to have to create a list of software that it supported by NewPointe IT; I don’t have the resources to support every piece of software that gets installed on a machine.  What happens then, when a user installed "unsupported" software and it wrecks their system?  That will need to be spelled out as well.
4. Any process that runs while the user is logged in will run with local admin privs.  Again, machine monitoring and logging will be a must.

I haven’t made a decision on this yet, but I’m very interested to hear anyone’s argument for or against users running with local admin.  What are you doing in your organization, and what factors led you to that decision?

Crazy Week

Here’s how you know your week is going to contain 50% less sleep … one of your co-workers walks up to you and asks "Hey, did you know there’s a loud beeping noise coming from your server room?"

I should have gone home right then and gotten my jammies and pillow to prepare for the week.

As it turns out, the beeping was exactly what I thought it would be.  Another hard drive had bitten the dust in our would-be file server, PowerEdge 1400 that up to this point had been rock-solid for us.  With dual 1GHz P3 CPUs and 2GB of RAM, it would have made a great file server.  WOULD HAVE … except for that it had somehow managed to eat 3 hard drives before I could even put it into production.  However, this was the last straw.  3 dead hard drives in 2 months is enough to convince me that I don’t want this machine in the lineup anymore.

The plan this week was supposed to be simple.  Copy our file server and EMS Lite data to the PE1400 and bring it online.  After that, install a second array of disks in the PE1800 (where the file server once was), install Ubuntu on it, and begin using it as our VM host.  Why Ubuntu?  Because I’m budget-tight at the moment, and also because the current install of Win 2k3 Standard wasn’t utilizing all 8GB of RAM as well as the 64-bit CPUs that the 1800 now has.

This plan seemed pretty airtight, except I didn’t plan on losing server hardware just before making this transition.  However, the migration needed to proceed, and so I loaded a working RAID5 array (controller and drives) into a newer desktop box, threw Server 2k3 on it, and began the Robocopying all over again.  By now it’s Tuesday, and tonight I’m scheduled to take all the servers down and transition our PE1800 over to Ubuntu so it can be a big bad 64-bit VM host.  However, in the midst of copying file server data, I forgot about EMS Lite.

EMS our current calendaring software, and the only SQL (MSDE) database we have on-site that gets any end-user interaction.  It figures that this tiny-but-critical program would hold things up for about 24 hours while I learn how to successfully migrate the database from one instance to another without breaking things.  HUGE thanks to Jeremy Marx for taking time out of his day to help me through this.  (That’s the power of the CITRT community!)

That 24-hour period was not wasted though … during that time I did some test runs with Ubuntu 64-bit and also got our new file server straightened out.  By 3:30pm Wednesday (yes, it’s Wednesday now) I had been up for about 30 hours, but I was very please just to have conquered the EMS data issue.  I fell asleep around 4pm Wednesday and didn’t wake up until about 8am Thursday morning.

It’s now Thursday night (almost Friday morning) now, and I’m on the last leg of this transition.  All of our VMs are being copied over to another server, and once that’s done, I’ll take the old array out of our PE1800 and install a new array.  That new array will have Kubuntu 8.04 on it, and will server as our new 64-bit VM host.

I’m already starting to wear down a bit (I wouldn’t ever make it as a Bering Sea crabber), but I’m pumped to see this project finally coming to a close.  It took longer than I thought and it cost a few hours of sleep, but I feel like the benefit will be worth the trouble.