The Standard Model for Small Library IT Management

I help maintain the IT infrastructure at the Missoula Public Library, but I have also been able to work with a number of small libraries across western Montana for more than 15 years now. These small libraries often have 10 to 25 PCs they have to keep running.

The Standard Model is simply my best guess at any given time for how these small library IT environments should be deployed and managed. With this post I am going to describe the Standard Model, hoping this will give small library directors, and their IT help, direction for how to deploy an environment that works.

This is not to say it's the only way to do it. There are many ways. I will simply be describing the model that is working for me. Note that this model is always in flux, particularly so now because of the BTOP deployments and several of my clients have purchased new servers this past year. But equipment, and software, and user needs are always changing so the infrastructure needs to continually adapt.

These comments are written for someone pretty skilled with PCs and small networks. I encourage any librarian who reads this to pass it on to their tech support and to share this with any interested person. Folks with questions should please post them here as comments so that we can all share in the responses. I would also appreciate anyone with alternative techniques to post those as well.

I'll break the environment up into areas of management, because each of these areas are managed differently. The three areas are the staff PCs, the public PCs, and the hotspot. All these comments assume a Microsoft Domain environment. I am currently using Server 2008 or Server 2008R2.

The staff PCs are managed just like any other business user PC. It has to print, run apps, stay uninfected, store documents, etc. There is nothing particularly unusual in supporting staff PCs so I won't take space for that.

The hotspot is not particularly unusual either except that access is available to all. The important features about the hotspot are that, first, no traffic from it should be allowed to any wired PC, and second, bandwidth must be limited so that there is always sufficient bandwidth available for the staff PCs.

Hotspot Tips:

• Librarians want stats. It is how they justify expenditures. A good stat to get from the hotspot is the number of logons to that hotspot. Do this by logging logons at the Access Point and archiving that data on a syslog server. Make this data available to the librarian so she/he can tally up stats daily, weekly, or monthly. I use Mikrotik hardware for APs, firewalls, and routers and will describe how I collect stats from it in a separate post describing the features of the Mikrotik platform.
• Some of my sites do not leave the hotspot on around the clock. The Mikrotik platform has a scheduler that can turn the hotspot on and off as desired.
• Security dictates that hotspot users cannot have access to any of the staff or public PCs so filter packets from hotspot users so that they have access only to the gateway and not to any resources in the building. One possible exception to this is to allow access to a printer on the wired network. I'm not doing this anywhere because the problems with excessive after-hours printing and with troubleshooting user's printing problems make it appear not worth the effort.

The public PC is a beast that even skilled system and network technicians often have trouble with. The trouble is that they do not understand what the library really wants regarding the configuration of the PC or the management of the public side. Furthermore, librarians often have difficulty articulating what they want in sufficient detail. Thus, there is a gap filled in with tech speculation and librarian dissatisfaction.

Public side management guidelines:

• The fundamental problem libraries have is that they invite people with absolutely no inhibitions to come in and use their computers. A patron told one of my directors that they always come to the library to visit a certain web site, because they always get infected when they go there.
• Assume all public PCs are infected as soon as a patron touches it.
• Focus primary efforts on area segregation and PC recovery, rather than restrictive or blocking techniques. Make sure that public PC's cannot communicate with staff PCs to as low a level as possible. I do the blocking at layer 2.
• Library staff typically are not sufficiently skilled to be able to troubleshoot public PC problems, so the tech's job is to configure the PC so as to create as few questions as possible during its use. Even when they are sufficiently skilled, librarians often have many other things they should be working on.
• Automate the environment as much as possible. For example, automate the turning on and then off of the public PCs. This is easily accomplished with most PCs. There are many other tasks that can be automated. Actively look for ways to minimize staff interaction with public PCs. Also minimize staff/patron interaction over computer management issues.

Deep Freeze is a product from faronics.com that I have long held is the best PC management money a library can spend. There are a number of products similar to Deep Freeze but I have only used this product so will only comment its use. The use of Deep Freeze dictates much about how the public side is managed, so its use will be described in some detail.

Deep Freeze is an application that will allow you to roll back any and all changes to the file system on a PC when it is rebooted. It is switched between frozen and thawed with a reboot. If it comes up thawed, you can make changes and have them stick. If it comes up frozen, all changes are removed at the next boot. So as long as a PC stays frozen, it remains unchanged.

Public PC and environment configuration:

• The tech's primary goal regarding the public side is to limit damage, and facilitate recovery. In a previous post about ARP poisoning, I describe a relatively easy technique for disabling communication between groups of PCs sharing a subnet. That is one way to do it, but however it is done, it must be done.
• Easy recovery is accomplished with Deep Freeze.
• Damage is limited through the use of antivirus and antispyware, local and perimeter firewalls, and restrictions on the PCs functionality while in the patron's hands.
• I use F-prot antivirus because it is lean, good enough, and $3.75/PC/year. I also use Spybot anti-spyware, predominately for the host file it provides. There are other ways to get useful host files to block access to unwanted sites (for example mvps.org), but I find Spybot useful.
• Run the Microsoft firewall at each PC and have a firewall at the perimeter device.
• Restrictions are provided via Group Policy at most of my sites, but at some sites without servers I use a product called WinSelect, also from Faronics.
• I allow three kinds of access to a PC to support centralized and remote management: File and print sharing to allow access to the file system, Remote Registry service to allow manipulation of the registry, and Remote Desktop sharing to support Terminal Services.
• Limit patron logons to only those PCs that patrons use. This is can be done easily in Active Directory Users and Computers in User Properties.

As I have mentioned, Deep Freeze determines much about the way the public side is managed, so I will describe in some detail how I use it.

• Deep Freeze has an Enterprise version that allows central management of Deep Freeze clients. All PCs can be changed to frozen or thawed with a few clicks.
• Deep Freeze has what it calls a thawspace. This is a separate drive where patrons can store documents that will survive a reboot. I use this only for short term storage. I run an automated process that will delete thawspace on all patron PCs on a daily basis.
• I use Imagex, the Microsoft product, to create a disk image that will be copied to many PCs. Do not install Deep Freeze as part of this image.
• Once a month, I go in during library closed hours to thaw all the PCs and run Microsoft updates, as well as updates for a number of applications. Much of this process has been automated, but I still spend too much time on updates.
• Never let any patron touch a PC that is not frozen.
• If you need to thaw a public PC during open hours, make sure that its firewall is set to block all incoming connections.
• Do not do any general surfing on any thawed public PC. Access your update sites only.

Finally, the server is a component available to both the public and staff side. A server does three things. It is my platform for remote support. It is where documents are stored. And it is the platform providing a variety services to the LAN.

• I configure the perimeter device to forward port 3389 packets to the server, and I access it via Terminal Services.
• All critical documents are kept at the server in shared folders which are regularly backed up to external drives and removed offsite. Appropriate permissions are also applied to shared folders. I actively deny access by patron side logons to staff shared folders.
• The server is then used to access all the PCs on site via Terminal Services. It runs the Deep Freeze console. It collects updated antivirus signature files to be disseminated on the LAN. It runs the Active Directory tools such as Users & Computers, and Group Policies. It runs various automated processes with the Task Scheduler. And more.

Excuse the length of this document, but there is a lot of material, even when covered superficially. I have posted documents recently on ARP poisoning and on configuring a public PC. I will soon post a document on the Mikrotik platform and another on the 10 suggestions I have for small library security. These should cover all the issues I discussed at the presentation at MLA.

Good luck configuring and maintaining your IT environment. Share these comments as you wish. Post your questions as comments here at the Montana Bibliotechies, or send me an email at jims@missoula.lib.mt.us.