At this past district tech meeting (10/12) the director told a story about a neighboring district’s network going down for two-weeks, referring to it as a “career ending” situation that our district will never have to face because of the steps our IT manager has taken to prevent that sort of thing from happening to us. On the surface that statement is certainly something positive to feel good about. But, as I have learned in the past three years in dealing with district IT, the emphasis is on keeping the network secure to a point where actual usage can become problematic.
I managed my site’s small network in my previous assignment so I was well aware of the phenomenon that everyone on the network thinks that they’re an exception to the rules and it tends to be a full-time job just to keep things consistent across the network. Every network needs standards in order to operate, and given the size of my district’s network, managing this one is a very big job indeed. But some of the choices that they have made reveals a way of thinking that is very non-educational.
When I first came to this school and this district in the Fall of 2001, they had just upgraded our computers to Windows 98 [see notes below] and set us up with a Novell network operating system to manage our user logins and access to our student server. The first difficulty that I encountered was the user login model that they had adopted. They decided that every student would have an individual password protected login with their username based on the students’ nine-digit district ID number plus a four-digit year of graduation number. The students’ password would be based on the students six-digit date of birth. Because every student had a unique ID number this ensured that there would be no duplicate network logins across the whole district and it also was designed so that once a student memorized his login name and password it would be valid all the way through the students’ career within the district. Again that model sounded good until one sat down with 40 first graders and attempted to have them type in “345234576.2010” in the user name line and then have them navigate to the password line to type something like “092396.” The first few times we met it took the full 40-minute period just to get them to find the rows of numbers on the keyboard much less get them to type in the correct ones in the correct order. The need for a secure login model was valid but the model did not fit it’s intended users.
Besides an unreasonable login model, there were two other flaws in the design. First was that with this system in which all users, both students and teachers, had virtually the same access rights, a teacher could not easily access their students’ folders or work stored on the server without manually logging in each student individually. As a classroom teacher I would have wanted to have that kind of access to check on my students’ progress but there was no way that I was going to type in the 13-digit username plus 6-digit password 35 times to see what my students are doing. With my small (Apple) network at my previous site, I’d set up the teachers so that when they logged in they had rights to all of their students’ folders plus their own folders. When I met with the district director, IT managers and district technology curriculum person I proposed having more login layers than restricted users and then “god.” It took over a year but eventually they created a single onsite “admin” login that allows that person to view all the folders on the server, but other than myself, with their original design teachers would still be locked out of their students’ folders.
The second flaw was that the username/password model was designed for a district-wide implementation when the actual username/password was only good when one logged into the individual student server at our site. When our students moved to the middle school, if that school had a student server (and/or networked computers) they would have to recreate all of the logins anyway. And as far as passing on the literal student folder from year to year there was neither the space on the server to hold that much data nor was there a protocol to moving students’ work from our server to the server that will “house” them when they attend the next school. In other words, we’d been saddled with a model designed to handle tens of thousands of users when all we were managing was around 900 (including teachers). Instead of “345234576.2010” we could have had “rm4,joe” and if there were two “Joes” in room 4 we could have had “rm4.joeb” and “rm4.joeh.” But somehow the concept of sculpting the network to fit the actual users was beyond the scope of the folks on top.
I was able to get them to compromise and have “generic” logins based on student room numbers without passwords and unlimited number of simultaneous logins so that a whole class could login at the same time. Managing this model meant that at the beginning of the year I create the individual student folders for the kindergarten and first grade students within their room’s login. Grades two through five I had them create their own folders the first time we meet in September. I spent part of a lab session talking about network ediquette and the consequences of being in someone else’s folder without permission and that’s all the security we tend to need. In three years we’ve had single digit incidents of students messing with other students’ work. Then at the end of the year I back everything up to CDs [see note below] and erase all of the student work to make room for the new years stuff. Teachers have their own login to keep their stuff separate from their students but they only have to login as their class once to access all of their student data. This model as affords us to place documents and templates in a common folder for students (and teachers ) to access instead of having to distribute things individually.
The need for securing the network is valid, but they’ve demonstrated a consistent “one size fits all” approach to the problems which tends to make things either unnecessarily hard or reduce the technology’s usability and thus effects teacher buy-in which is crucial for us to get the most bang for our technology buck. When I discussed this with my brother he commented that they must suffer from “shiny tools” syndrome where one confuses the desire to keep ones tools in pristine condition to the point of rendering the tools inaccessible. That about sums it up. And things since then have gotten substantially worse. But that’s a story for another time. JBB
* Windows 98: During my first district level meeting, three years ago, the district director said in front a library full of site coordinators that they were finally ready to roll-out their “district approved” image of Windows 98, then added, “though I’m not sure why you’d want to upgrade from ’95, they’re virtually the same.” This was in the Fall of 2001 and he was wondering why we’d want to “upgrade” from Windows 95?
* CD Burners: I believe we are still not allowed to order any computers with CD burning capabilities. I brought in one of my own computers, also forbidden (see: homecomputers), so that I could do this basic function. More on this in “One Size Does Not Fit All.”