When you are a tech, you need to think things through completely before acting. When you are the only tech in the organization, you need to spend a little extra time thinking things through. After all, no one is going to have your back so you have to double-check yourself.
Terminal Services in Windows Server 2008 sounds really nice. I read up on RemoteApps, TS Gateway, Web Access, and even EasyPrint (we use network printers not local, so EasyPrint would be of marginal use for us.) I checked into Active Directory integration. I read about the changes to the Session Broker. I was even aware of the changes in RDP.
Ah, the RDP client. We mainly use Neoware C50s from about three years ago. We're adding HP t5135s now (since HP bought Neoware), but the majority of our thin clients are the old Neowares. These clients run a modified version of Linux with an old version of rdesktop.
The problem? rdesktop is not compatible with the new RDP used in Terminal Server 2008. So for now I am back to Windows Server 2003 for my Terminal Servers. All the cool functionality will have to wait until I can replace my old thin clients.
The kicker to the whole thing is that one of the reasons I went to server-based computing in the first place in order to get longer life out of my clients. I guess you really can't fight progress.
On Tuesday, I discussed the need for monitoring your network. I mentioned Spiceworks, which is a slick program but it didn't scale up enough for me (as of version 2.0). I also mentioned Zenoss which is a great open source app that I'm using to consolidate server logs and monitor server performance. Zenoss is also slick, but it didn't completely scratch my itch.
I know I need to get out of firefighting mode, but a two day introductory course into ITIL has motivated me to actually make some progress. ITIL is a collection of guidelines and best-practices to bring IT departments and business leaders closer together. Using ITIL, the tech guys should only be working on projects that have real value for the organization and the rest of the business should do a better job of letting the tech guys know what's needed. It seems that no one implements the entire ITIL approach. Everyone seems to adapt it to their own needs. A single-person technology department definitely has needs, so we ought to be able to find something useful here, right?
I'm spending this summer working on phase one of our ITIL implementation. This is where we document every piece of hardware and software we own. The theory is that you cannot improve the situation until you know exactly what you have. I thought I had a pretty good handle on what we had until we actually started documenting it. There's a lot of stuff out there that I forgot/never knew about.
All of this information goes into a Change Management Database (CMDB). While I love Zenoss for keeping an eye on my servers and Spiceworks is fine for inventorying a couple hundred PCs, I wanted something different. I found it in the open source application known as GLPI. GLPI is an abbreviation for something in French. For all I know, it is some kind of insult.
Whatever the name means, the actual application is far from insulting. GLPI allows you to keep track of every piece of equipment (including every card, stick of RAM, processor, hard drive, etc. in your PC) and software, tie them together (connecting a monitor and/or printer to a PC), assign them to locations, and assign them to people. It also allows you to store all financial information about the item with the actual item (information like: warranty, value, depreciation, support contracts, and more). Another feature I like is the ability to attach files to an item. I'm attaching PDFs of the user manuals to everything!
GLPI includes a help desk. Tickets can be entered from email or a web form. The tickets are associated with a piece of equipment or software. While looking at the ticket, you can easily bring up the item being referenced. All of the history, financial information, warranty information, and configuration specifications are at your fingertips.
The intial payoff comes from having tickets recorded in a database instead of on hastily written notes stuffed in your pockets. It also comes from having all the information about an item easily available before you begin troubleshooting. But I'm really looking forward to the future day when I can pull out reports showing the history of our computers and use them to quantify new purchases.
There are a few issues we're still working through. First, it is time consuming to get everything in the CMDB the first time. Fortunately, GLPI works with OCS NG Inventory. (OCS is also French, I think.) OCS is a small agent that uploads computer information when a user logs in. This is a huge time saver on getting information into the database. The problem comes with sorting it all out, getting the financial information in place, and verifying that everything is where it is supposed to be. Plus, certain tech items like projectors are not going to be discovered by a software agent.
A second issue I am concerned about is making sure everyone enters their requests into the system. I've taken requests as I've walked down the halls for so long, I'm afraid people will not understand why I'm forcing them to use a web form to enter their requests. I'm going to do my best to explain the reasons and hope that they see this as a win-win situation.
My biggest concern is persistence. It will be really easy to not keep up with the database or not force people to enter tickets in the help desk. The only way we will reap any rewards from this is if we keep at it.
There is a lot more to ITIL than I've covered here. I'm planning on at least one more post about it in the near future. There's also more to the implementation than I've discussed so far. Look for a post on that this weekend.
See if you can relate to this:
1) Show up at work
2) Start to check email
3) Receive calls from people with login issues or computers that won't boot
4) Run around for the morning fixing issues
5) While running around, meet more people with problems
6) Fix these problems on top of the previous problems
7) Get back to desk
8) Start working on project you were working on yesterday
9) Get more calls about more problems
10) Run around fixing problems
11) Meet more people with problems
12) Get home late - meet angry spouse (and you never did finish checking email!)
This is what we technology professionals refer to as a "Bad Thing". It's what I have been trying to overcome. It just felt like it should be possible to stop fire-fighting and start managing the network in a proactive manner. I'm not there yet, but here's what I'm trying to do to improve the situation.
In the past I have recommended Spiceworks. I've tried it and it is a great product. It inventories hardware and software, includes a helpdesk, has some nice reporting features and comes for the low, low price of free. It's easy to set up, doesn't use agents for the inventory and did I mention it is free? I recommend it highly but have stopped using it.
For all it's good points, there were two problems for me. (Mind you, this is v2.0 I am discussing. I have not tried v3.0.) The bigger problem of the two is that Spiceworks was designed to max out at 200 PCs. The school I work for has about 250 computers. Things were starting to bog down. The other problem is that, despite it's $0 dollar price tag, it isn't open source.
I'm not a raving OSS fanboi, but I think public school systems need to support open source products. I'm not ditching our Microsoft Terminal Servers or XP Pro PCs. I just think that where it's possible, we should seek out open source solutions. So while I would have no problem using Spiceworks if it scaled better to our needs, I wasn't too upset to leave it behind in search of OSS products. But which ones?
My next move was to try out Zenoss. Zenoss has both commercial and OSS versions. Of course, I'm running the open source version. Where this product shines for me is in server log centralization. I never had time to check each server's logs for problems. (Kinda like email.) As a result, I generally found out about server problems when someone else noticed it. Now I am able to quickly scan all my servers for issues and deal with the big ones before anyone else notices them.
Zenoss also includes performance monitoring and uptime monitoring. It monitors printer messages too. There's also addons (called ZenPacks) to add additional functionality. It's definitely worth a look.
One word of warning about the Zenoss virtual appliance. It is a great way to try out the product, but it has a very small virtual hard drive. I ran it out of space in a couple months. In trying to resize the disk, I corrupted the whole thing. I ended up creating an Ubuntu server and installing Zenoss from the repositories. Do yourself a favor, don't plan on running a production server on the appliance.
Zenoss wasn't a complete solution for me. Maybe I could write my own ZenPack to meet all of my needs, but I'd heard about something else I wanted to try. I'm going to discuss that on Thursday along with my grand plan for world domination getting out of firefighting mode.
del.icio.us
