Wednesday, April 27, 2011

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 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, 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

Tuesday, April 26, 2011

Content filtering for public libraries

The issue of content filtering of the Internet has come up yet again. Some libraries are seeking more E-rate funding in the Internet Access categories and are thus looking at CIPA (Children's Internet Protection Act) compliance and "technology protection measures." Others are looking for solutions to problem patrons abusing the library's internet.

Internet filtering is a difficult and contentious issue among librarians. Some feel that filters must NEVER be used for ANYONE in the library. These librarians see the defending the First Amendment access to information as the overriding responsibility of librarians. Filters can interfere with constitutionally protected speech so they cannot even be considered. Other librarians are interested in protecting library patrons from illegal and objectionable materials that may be encountered on the Internet. Schools often block anything that might possibly be considered problematic or objectionable. Unfortunately, this can prevent students from accessing information they need to complete assignments. It can also prevent public library patrons from accessing legal and unobjectionable sites like web email or social networks from school/community libraries.

Many librarians find themselves between the two extremes and are looking for solutions that will help block illegal and objectionable sites while allowing access to the vast majority of Internet content. I think that filters when chosen with care and used judiciously can help and will allow the libraries to comply with CIPA.

Unfortunately for busy librarians, selecting the right filter is going to take some study and trials. TechSoup has some good basic information:
I think you need to start with your library's Internet policy. My colleague Tracy Cook led a workshop at the 2011 MLA/MPLA Annual Conference on Library Internet Policies. It might be helpful to take a look at her notes from the session to help stimulate a discussion with your library's board. You should spell out in your policy just what is considered inappropriate and for whom. CIPA requires you to block web sites that are obscene or contain child pornography for everyone including adults. There are additional requirements for minors.

Internet Safety Policy
The Internet safety policy must address the following issues:

  • Access by minors to inappropriate matter on the Internet and World Wide Web
  • The safety and security of minors when using electronic mail, chat rooms, and other forms of direct electronic communications
  • Unauthorized access including "hacking" and other unlawful activities by minors online
  • Unauthorized disclosure, use, and dissemination of personal information regarding minors
  • Measures designed to restrict minors' access to materials harmful to minors
Once you've defined as a board what you deem "harmful to minors," Internet filters can be used to help restrict access to those materials for minors. But I think you need to be very careful and thoughtful about just what you want to restrict adults from accessing. I would recommend getting a filtering product that allows several different levels of filtering to account for different age groups. That way you can apply filters in an age appropriate manner.

As objectionable as it may be to many community members and library staff, pornography is not necessarily obscene and therefore may be constitutionally protected speech. Web sites depicting racism, sexism or violence are probably also protected by the First Amendment. Blocking these sites with a filter can subject the library to a First Amendment lawsuit. Hence, I repeat my caution to be very judicious about which categories you choose to block for adults and make sure that library staff can disable the filter at the request of an adult library patron. It's a very good idea to get a filter that lets people know that it's blocking a site and gives them the option to have the site unblocked by library staff.

Once you've come up with a draft internet policy, you can start looking at filters to meet your needs. I would certainly want to test filters before I committed my library to buying, installing and using them. This is another good place to bring in your board and/or staff to help. Install each filter you're considering on a computer and then test it for a while. Make sure it blocks sites you want blocked and doesn't block those that should be accessible. You'll probably also want to test how easy it is to turn on and off. If you don't like it, try another. This is something that library staff and patrons are going to have to live with so you want the filter to be something that works for you.

If you're filtering for CIPA compliance, make sure that discussion and approval of your Internet Use Policy is listed on the agenda for your library board meeting. This meeting must be accessible to the public. Also, keep records related to your filter purchase and testing with your E-rate files. If your library is audited for E-rate, auditors may ask to see proof that you're in compliance with CIPA.

It would be great to hear from libraries as to which filters they're using and how satisfied they are with their choices. This is another one of those areas where we can learn a lot from each others experiences.

Wednesday, April 13, 2011

Deep Freeze on Public PCs

You spend a lot of time and money setting up a PC for the public to use. But soon everything is running slow on it, or you keep getting infected warnings from your anti-virus, or you keep getting unwanted pop-ups. What do you do?

Unfortunately, the first thing you have to do is completely wipe the hard drive on the PC and start over again. But this time, before you give the PC to the public, you install Deep Freeze on it.

Deep Freeze is a product that completely rolls back any changes made to a PC every time it reboots. This is good for when a patron makes unwanted changes to the PC, like changing the background, or for when a PC gets infected. It is not so good for when you need to update the PC, because that will be removed too.

Deep Freeze runs in two modes: frozen and thawed. When its frozen, any changes made are removed at the next reboot. When its thawed, you can do your updates and they will stick.

I have been using Deep Freeze for more than a decade and am very impressed with it. I think you should use it too, or a product like it, to keep your public PCs running well.

Windows Steady State has a similar component but Microsoft does not make a version of Steady State for Windows 7. There are other paid products as well such as DriveShield and Centurion Guard, but I haven't used those so cannot comment on them.

  • I purchase the Enterprise version, which means I have a central console from which I can switch all my PCs from frozen to thawed with just a few clicks. This console also allows you to update the Deep Freeze configuration, to startup and shutdown the PCs, send screen messages to the PC, and more.
  • Deep Freeze is also sold in a Standard edition, which installs on a lone PC and is managed only at that PC.
  • When I get a PC configured for the public, the last thing I will do is install Deep Freeze on it. Then I let the public use it only in the frozen mode. When I have to do updates, I wait until the library is closed, boot the PCs in thawed mode, and do all the updates on each PC. Then I freeze the PC again before I let the public use it.
  • Deep Freeze is not a restriction tool. It is a recovery tool. It doesn't stop patrons from doing bad things to your computer, it just allows you to recover easily when they do. You have to use something like Group Policy, or a Local Policy, or Winselect to impose restrictions.
  • Deep Freeze has what is called a "Maintenance Mode" which is simply a configuration feature that will make the PC boot thawed if it is ever on at a certain time. For example, if you always do your updates after you close Tuesdays at 6 PM, you can set the PCs to automatically turn on and thaw themselves every Tuesday at 6 PM and then freeze again at 9 PM.
  • Deep Freeze is not perfect. It does not protect against Master Boot Record infections, but these are rare anymore. I have had a few problems with it, mostly due to a PC getting turned off when it shouldn't during a windows update, but the company has a good fix for this and their tech support has been very helpful when I have called.
If you are having trouble keeping your PCs working, have a look at Deep Freeze to start making that effort less work.

ARP Poisioning

This will be one of a few posts here relating to the presentation I made at the Montana Library Association conference in Billings recently. I told the attendees I would present further details about how to do some of the procedures I discussed, so here is the first one.

One of the most important things a small library should do is to create an environment where the public PCs, the staff PCs, and the hotspot can not see each other. This is because staff PCs are usually used by people who try not to get infected. Public PCs, alas, are not. It is wise to assume that your public PCs are infected by the end of the day. Hopefully, you are using a product like Deep Freeze so that the public PCs will be uninfected again when they reboot.

There are a variety of ways to accomplish this separation between staff and public PCs and many of them are expensive. This is the poor person's technique for disabling communication between staff PCs and public PCs. It is called ARP Poisoning and it is a technique of lying to your PC.

In order for this to work, you must manually assign IP addresses to your PCs. They need to have an IP address that remains constant and DHCP will not do that.

Let's say you have two staff PCs with the following IP addresses:

And you have two public PCs with the following IP addresses:

Create a batch file with the following name: "staffARP.bat"

It should have the following two lines in it.
ARP -s 00-00-00-00-00-00
ARP -s 00-00-00-00-00-00

Then create another batch file called "publicARP.bat". It should have the following two lines.
ARP -s 00-00-00-00-00-00
ARP -s 00-00-00-00-00-00

Now each of the batch files gets put into the respective startup folder of each PC. That is to say the staffARP.bat file gets put into the startup folder on a staff PC and the publicARP.bat files gets put into the startup folder on the public PC.

Then you would reboot a staff and public PC and ping one from the other. The ping should fail indicating that the two cannot communicate.

In your environment, add a line in the batch file for each PC to which you want to block access. Note that the string after the IP address is a bunch of zero's and dashes, not ohs and dashes. Note that the IP addresses above are just samples. Naturally, you would use your own IP addresses.

There ya go, the poor persons blocking between staff and public PCs.

Next week I'll make a few comments about Deep Freeze. It is the product that, IMHO, is the most cost effective money a library can spend to keep its PCs running.