Maintaining 20 Windows boxes with no budget
August 11, 2024 4:26 PM
As I spent my entire career immersed in Unix and macOS, the universe has decided I will spend my retirement administrating Windows boxes. In this case it is what amounts to a computer lab for K–12. I’m not even sure what questions I should be asking.
For my own convenience it would be nice if the boxes remained identical with the only differences being OS version related (we’re going to be stuck with both Windows 10 and 11 machines), and maybe the desktop pictures. I would like the kids to store their files on network drives, probably through Google.
I don’t need net nanny software to begin with but I imagine it will become interesting at some point.
I think it’s safe to say that just about every virus in the known universe will arrive at these computers sooner or later. Is Windows Defender enough?
Money is mind-numbingly tight, and anything requiring a subscription is a no go.
I’d love to hear people’s thoughts, particularly if you have run a K-12 computer lab.
For my own convenience it would be nice if the boxes remained identical with the only differences being OS version related (we’re going to be stuck with both Windows 10 and 11 machines), and maybe the desktop pictures. I would like the kids to store their files on network drives, probably through Google.
I don’t need net nanny software to begin with but I imagine it will become interesting at some point.
I think it’s safe to say that just about every virus in the known universe will arrive at these computers sooner or later. Is Windows Defender enough?
Money is mind-numbingly tight, and anything requiring a subscription is a no go.
I’d love to hear people’s thoughts, particularly if you have run a K-12 computer lab.
It’s private. I have total control from the ground up. My plan was to have a common student account with a well-known password (or none if possible) and an administrative account with a private password.
posted by Tell Me No Lies at 4:58 PM on August 11
posted by Tell Me No Lies at 4:58 PM on August 11
Tech Soup works with schools, too. Microsoft hosts content for school educators: training modules (Manage devices used for education; Windows 11; Microsoft 365 and Windows) with an Educator Center overview, IT manager support, a K-12 Education Guide, a K-12 "showcase", etc.
posted by Iris Gambol at 5:02 PM on August 11
posted by Iris Gambol at 5:02 PM on August 11
From a tiny kid perspective no log in is good, but I'd recommend individual log ins for the big kids so you don't have issues.
posted by freethefeet at 5:09 PM on August 11
posted by freethefeet at 5:09 PM on August 11
Will these be Windows “Home” or “Pro” editions? With Pro, you could join them to a simple samba domain controller, perhaps hosted on a small Linux box. With that you could have accounts, saved / cleared home directories, and some scripting control.
posted by nickggully at 5:18 PM on August 11
posted by nickggully at 5:18 PM on August 11
To answer the question no one else has answered yet, Yes, Windows Defender is good enough. Figure out what you have to do to make sure virus signatures are updated at least weekly, and that automatic scans happen (overnight, quick scan daily, full scan weekly).
Also be sure that updates happen regularly. Window patches and updates are usually released on the second Tuesday of the month ("Patch Tuesday"). Updates can happen automatically, but usually require a reboot. Like virus scans, you should be able to find a way to do this automagically.
Good luck!
posted by lhauser at 6:33 PM on August 11
Also be sure that updates happen regularly. Window patches and updates are usually released on the second Tuesday of the month ("Patch Tuesday"). Updates can happen automatically, but usually require a reboot. Like virus scans, you should be able to find a way to do this automagically.
Good luck!
posted by lhauser at 6:33 PM on August 11
Can you really not use Linux on these machines? Because that is the solution 😂.
posted by jabah at 9:13 AM on August 12
posted by jabah at 9:13 AM on August 12
Sorry, I'm training them to be *useful* members of society. :-)
posted by Tell Me No Lies at 9:36 AM on August 12
posted by Tell Me No Lies at 9:36 AM on August 12
I ran a K-6 computer lab for a decade and a bit.
Can you really not use Linux on these machines? Because that is the solution
It's a solution to the Windows licensing problem, which is a pain in the arse for sure, but it's not a solution to the Nobody In A School Knows WTF A Linux Is problem. Despite my being a Linux bigot's Linux bigot, getting anybody to agree even to try running anything but Windows on the school boxes (at least visibly) was something I never achieved. I did deploy a lot of cross-platform free software that would have run just fine on Linux as well, though.
The school had its own server, a nice roomy Supermicro-based box from Acer with 24 cores, redundant hot-swap power supplies and a shedload of RAM and disk. I ran Debian on that, and used KVM on Debian to host a pair of Windows Server domain controllers, one for the admin subnet and one for the curriculum subnet. Those two subnets had physically separate switchgear, wiring and IP address ranges (all that had been set up by the Catholic Education Office before I started working there, at which time the admin and curric domain controllers were also still separate physical computers). I added some routing inside the Debian VM host so that machines on the admin subnet could initiate connections to those on the curric subnet but not the other way around.
We settled on one student login per class up to grade 2, then one per student from grade 3 onwards. Teachers had their own logins, and teachers' user accounts had local admin rights on the Windows boxes (but not domain admin rights! Those were for me, the principal and the bursar). So teachers with the savvy to do so could easily install whatever they wanted to on the boxes in their own classrooms.
I wrote my own software installation and maintenance script that ran whenever a machine got shut down (not when started up, not when restarted) and turned off all the Windows automatic updates. This was nice for my users because they could always just turn a machine on at any time and start using it without lengthy delays while it brought itself up to date. I also wrote my own custom login scripts that would make sure the logged-in user profile was in suitable condition to work in a standard way. One of the things that script did was look for a picture named Wallpaper in the logged-in user's own Pictures folder, or failing that, in the shared Pictures folder for their class) and apply that as the desktop background.
Installing new computers became very easy: write out a standard Windows image that included no application software, only drivers, then tell the machine to shut down and walk away. The updater script would then deal silently with applying all available Windows and application software updates.
Some kind of scripted software standardizer is, I think, the only practical way to maintain a consistent operating environment. Trying to do it all with imaging will just drive you insane. There are various commercial and open-source products that do this. I rolled my own because I'm cheap and, like you, I had sole and total control. Maintaining a script I'd written myself and understood inside out and backwards was much easier for me than trying to bend something else to my will. I also understood full well that regardless of how I chose to run the joint, whoever had my job next would blow that all away and do it their way anyway, so there was no particular virtue in trying to do everything in some "standard" way.
Don't bother with third-party anti-malware suites, they're all more trouble than they're worth at this point. Windows Defender has been plenty good enough since the version that comes bundled with Windows 10. Once you've got your automated update deployment under control, anything that goes seriously wrong with a classroom Windows box can be dealt with by re-imaging it at the first sign of trouble. It's polite to make some effort to preserve pictures, documents and whatnot that have been saved locally before blowing the local installation away.
I disabled Windows roaming profiles because it is simply not practicable to stop people downloading enormous files to their local machines in places that roaming profiles would then attempt to sync via the domain controller, causing horrible logon delays and regular profile sync breakages. My own logon script did most of the useful things that roaming profiles do (setting up preferred printers etc) but with explicit config-file copying and registry tweaks, not broadscale file and folder sync.
Fairly late in the piece, the school jumped on the Google train and all the kids got Google accounts. We ran the same policy with those as for our local Windows accounts: tinies got shared class accounts, grade 3 and up got individual ones. I made no attempt at all to get Google Drive file sync working reliably with these, just gave that up as a bad idea. When people wanted to work with cloudy stuff it happened via the web browsers. This was easy for my users to understand and I think it saved both them and me endless grief. Background file sync is a lovely-sounding idea but in practice it has a lot of failure modes and dealing with those is time-consuming.
I strongly recommend not trying to manage a Windows shop without running at least one domain controller / central file server, because Group Policy really does let you solve multiple classes of problem that are otherwise a complete pain. You can make that a Linux box with Samba on it if you don't want to descend into Windows Server client access licence hell. Make sure it has the hardware and media needed to back it up properly, too.
As an educational institution, organizing volume licensing for Windows will save you money, possibly enough to fund server hardware.
Some kind of standard naming scheme for machines is helpful as well. All mine got names like 2013-02-06-rm12, which I could interpret at a glance: this is the sixth machine from the second batch installed in 2013, and it's in room 12. I printed the machine names on sticky labels and stuck one to the PC case, one to the monitor and one to the keyboard. Everybody knew that I simply wouldn't act on any problem report that didn't include a machine name, and this saved me a lot of time not having to deal with ambiguous notes in my pigeonhole like "the PC in the corner next to the door in my room won't print - signed, illegible".
Speaking of printers: we had one mono laser printer per classroom, two mono laser printers in the lab, and a colour photocopier in the library to which any logged in teacher could send print jobs. Saved a bit of money on printers by getting non-networked types, hooking them up to one designated computer per classroom, and making that computer the classroom's print server. OEM print drivers for networked printers are, in my experience, much more painful to deal with than their USB print drivers and it's pretty easy for users to understand that in order for printing to work, the computer with the sticker on it that says "print server" needs to be turned on.
I'm happy to answer specific questions either in-thread or via memail, email or keybase.
posted by flabdablet at 10:58 AM on August 12
Can you really not use Linux on these machines? Because that is the solution
It's a solution to the Windows licensing problem, which is a pain in the arse for sure, but it's not a solution to the Nobody In A School Knows WTF A Linux Is problem. Despite my being a Linux bigot's Linux bigot, getting anybody to agree even to try running anything but Windows on the school boxes (at least visibly) was something I never achieved. I did deploy a lot of cross-platform free software that would have run just fine on Linux as well, though.
The school had its own server, a nice roomy Supermicro-based box from Acer with 24 cores, redundant hot-swap power supplies and a shedload of RAM and disk. I ran Debian on that, and used KVM on Debian to host a pair of Windows Server domain controllers, one for the admin subnet and one for the curriculum subnet. Those two subnets had physically separate switchgear, wiring and IP address ranges (all that had been set up by the Catholic Education Office before I started working there, at which time the admin and curric domain controllers were also still separate physical computers). I added some routing inside the Debian VM host so that machines on the admin subnet could initiate connections to those on the curric subnet but not the other way around.
We settled on one student login per class up to grade 2, then one per student from grade 3 onwards. Teachers had their own logins, and teachers' user accounts had local admin rights on the Windows boxes (but not domain admin rights! Those were for me, the principal and the bursar). So teachers with the savvy to do so could easily install whatever they wanted to on the boxes in their own classrooms.
I wrote my own software installation and maintenance script that ran whenever a machine got shut down (not when started up, not when restarted) and turned off all the Windows automatic updates. This was nice for my users because they could always just turn a machine on at any time and start using it without lengthy delays while it brought itself up to date. I also wrote my own custom login scripts that would make sure the logged-in user profile was in suitable condition to work in a standard way. One of the things that script did was look for a picture named Wallpaper in the logged-in user's own Pictures folder, or failing that, in the shared Pictures folder for their class) and apply that as the desktop background.
Installing new computers became very easy: write out a standard Windows image that included no application software, only drivers, then tell the machine to shut down and walk away. The updater script would then deal silently with applying all available Windows and application software updates.
Some kind of scripted software standardizer is, I think, the only practical way to maintain a consistent operating environment. Trying to do it all with imaging will just drive you insane. There are various commercial and open-source products that do this. I rolled my own because I'm cheap and, like you, I had sole and total control. Maintaining a script I'd written myself and understood inside out and backwards was much easier for me than trying to bend something else to my will. I also understood full well that regardless of how I chose to run the joint, whoever had my job next would blow that all away and do it their way anyway, so there was no particular virtue in trying to do everything in some "standard" way.
Don't bother with third-party anti-malware suites, they're all more trouble than they're worth at this point. Windows Defender has been plenty good enough since the version that comes bundled with Windows 10. Once you've got your automated update deployment under control, anything that goes seriously wrong with a classroom Windows box can be dealt with by re-imaging it at the first sign of trouble. It's polite to make some effort to preserve pictures, documents and whatnot that have been saved locally before blowing the local installation away.
I disabled Windows roaming profiles because it is simply not practicable to stop people downloading enormous files to their local machines in places that roaming profiles would then attempt to sync via the domain controller, causing horrible logon delays and regular profile sync breakages. My own logon script did most of the useful things that roaming profiles do (setting up preferred printers etc) but with explicit config-file copying and registry tweaks, not broadscale file and folder sync.
Fairly late in the piece, the school jumped on the Google train and all the kids got Google accounts. We ran the same policy with those as for our local Windows accounts: tinies got shared class accounts, grade 3 and up got individual ones. I made no attempt at all to get Google Drive file sync working reliably with these, just gave that up as a bad idea. When people wanted to work with cloudy stuff it happened via the web browsers. This was easy for my users to understand and I think it saved both them and me endless grief. Background file sync is a lovely-sounding idea but in practice it has a lot of failure modes and dealing with those is time-consuming.
I strongly recommend not trying to manage a Windows shop without running at least one domain controller / central file server, because Group Policy really does let you solve multiple classes of problem that are otherwise a complete pain. You can make that a Linux box with Samba on it if you don't want to descend into Windows Server client access licence hell. Make sure it has the hardware and media needed to back it up properly, too.
As an educational institution, organizing volume licensing for Windows will save you money, possibly enough to fund server hardware.
Some kind of standard naming scheme for machines is helpful as well. All mine got names like 2013-02-06-rm12, which I could interpret at a glance: this is the sixth machine from the second batch installed in 2013, and it's in room 12. I printed the machine names on sticky labels and stuck one to the PC case, one to the monitor and one to the keyboard. Everybody knew that I simply wouldn't act on any problem report that didn't include a machine name, and this saved me a lot of time not having to deal with ambiguous notes in my pigeonhole like "the PC in the corner next to the door in my room won't print - signed, illegible".
Speaking of printers: we had one mono laser printer per classroom, two mono laser printers in the lab, and a colour photocopier in the library to which any logged in teacher could send print jobs. Saved a bit of money on printers by getting non-networked types, hooking them up to one designated computer per classroom, and making that computer the classroom's print server. OEM print drivers for networked printers are, in my experience, much more painful to deal with than their USB print drivers and it's pretty easy for users to understand that in order for printing to work, the computer with the sticker on it that says "print server" needs to be turned on.
I'm happy to answer specific questions either in-thread or via memail, email or keybase.
posted by flabdablet at 10:58 AM on August 12
As a general philosophical guideline: K-12 is a pleasantly low-stakes environment for system administrators. You don't get ridiculous uptime expectations, there's typically nothing hugely sensitive stored on most of the machines you're looking after, and most of the staff and most of the kids you'll be working with will treat you with most of the respect you're usually due.
This means that the standard sysadmin instinct - Lock! Everything! Down! - is uncalled for in that environment. You could in fact just put twenty home-grade Windows installations in your lab and leave them to it and enough of them would keep working well enough most of the time to get by. That's exactly how the school I worked for did it before I worked there; I got the job because they'd finally got to the point of wanting more than one PC in each classroom and more uptime than they were achieving unaided.
But as a conscientious sysadmin, you obviously want almost all of your fleet working well enough almost all of the time to maximize their usefulness. One of the keys to that is making them all essentially interchangeable: if possible, keep the number of different kinds of machine small, their specs fairly similar, the software installed on all of them the same, and user-generated files stored somewhere else.
Lock! Everything! Down! is reasonable in a corporate environment where the number of machines is very large and the number of administrators very small, but in a low-stakes small-scale lab where the sysadmin can actually put their actual hands on the physical machines to fix what breaks, it rapidly becomes counterproductive and creates far more busywork than it saves.
If you concentrate on making recovery from breakage fast and easy, then your user's boundless capacity to inflict breakage doesn't matter very much; and if your fleet is known not to be locked down harder than hard, your relationship with your users becomes much more pleasant and much less adversarial. You'll find out what goes wrong quite quickly because you're not giving your users an incentive to try to hide stuff from you for fear of having it taken away, and most of it will end up pretty quick to fix.
Where Lock! It! Down! does make sense in an educational environment is on the central file servers (or in the cloud accounts, if the file server(s) are not on campus). It is definitely worthwhile spending significant amounts of time designing account-based access control schemes that limit the amount of damage that can be done to shared resources either maliciously or by accident, and implementing thorough, frequent and well-tested backup processes for those resources should be given a high priority.
I enjoyed my job as The School IT Guy the most of any I've had, mainly because I did take the opportunity to do most of my hands-on work inside the classrooms while teaching was going on, and came to be seen as somebody on the side of the people whose equipment I was maintaining. If you focus more on how the people you're supporting are using the machines than on the machines themselves, you'll probably be able to achieve much the same dynamic.
posted by flabdablet at 8:24 AM on August 13
This means that the standard sysadmin instinct - Lock! Everything! Down! - is uncalled for in that environment. You could in fact just put twenty home-grade Windows installations in your lab and leave them to it and enough of them would keep working well enough most of the time to get by. That's exactly how the school I worked for did it before I worked there; I got the job because they'd finally got to the point of wanting more than one PC in each classroom and more uptime than they were achieving unaided.
But as a conscientious sysadmin, you obviously want almost all of your fleet working well enough almost all of the time to maximize their usefulness. One of the keys to that is making them all essentially interchangeable: if possible, keep the number of different kinds of machine small, their specs fairly similar, the software installed on all of them the same, and user-generated files stored somewhere else.
Lock! Everything! Down! is reasonable in a corporate environment where the number of machines is very large and the number of administrators very small, but in a low-stakes small-scale lab where the sysadmin can actually put their actual hands on the physical machines to fix what breaks, it rapidly becomes counterproductive and creates far more busywork than it saves.
If you concentrate on making recovery from breakage fast and easy, then your user's boundless capacity to inflict breakage doesn't matter very much; and if your fleet is known not to be locked down harder than hard, your relationship with your users becomes much more pleasant and much less adversarial. You'll find out what goes wrong quite quickly because you're not giving your users an incentive to try to hide stuff from you for fear of having it taken away, and most of it will end up pretty quick to fix.
Where Lock! It! Down! does make sense in an educational environment is on the central file servers (or in the cloud accounts, if the file server(s) are not on campus). It is definitely worthwhile spending significant amounts of time designing account-based access control schemes that limit the amount of damage that can be done to shared resources either maliciously or by accident, and implementing thorough, frequent and well-tested backup processes for those resources should be given a high priority.
I enjoyed my job as The School IT Guy the most of any I've had, mainly because I did take the opportunity to do most of my hands-on work inside the classrooms while teaching was going on, and came to be seen as somebody on the side of the people whose equipment I was maintaining. If you focus more on how the people you're supporting are using the machines than on the machines themselves, you'll probably be able to achieve much the same dynamic.
posted by flabdablet at 8:24 AM on August 13
As I spent my entire career immersed in Unix and macOS
you are going to find all the centralized Windows admin facilities deeply weird. I recommend ignoring all of them to begin with, then picking up what you need to as you go in order to deal with specific issues you encounter. The problems you'll see in a K-12 lab are simply not going to be all that hard to solve, and although implementing the solutions will occasionally expose you to frankly astonishing levels of This Boneheaded Behavior Is By Design, anybody who has dealt with Unix professionally for any length of time will probably find the process of working around those at least somewhat enjoyable.
Just bear in mind that Windows is primarily a fleet OS and does have extensive centralized control facilities, even if it is far more opinionated than Unix about what The Right Thing looks like and those opinions will occasionally make you want to headdesk. Windows contains remarkably few unifyingly good ideas. Everything in it is super-specialized and oriented toward handling One Specific Class Of Issue in ways that frequently interfere with, rather than help, handle other classes of issue. But it's also just massive and that makes up to some extent for its incoherence: there's a lot of shot loaded in that scattergun. If you can find your way past being appalled by awful fundamental design decisions, and commit to just doing stuff The Windows Way to the greatest extent your sanity will tolerate, it does all work. Mostly.
This thread will stay open for a year unless you mark it Resolved, and since the scope of the initial question is so wide, I don't think anybody would object to you coming back to it with more specific followup questions.
posted by flabdablet at 8:44 AM on August 13
you are going to find all the centralized Windows admin facilities deeply weird. I recommend ignoring all of them to begin with, then picking up what you need to as you go in order to deal with specific issues you encounter. The problems you'll see in a K-12 lab are simply not going to be all that hard to solve, and although implementing the solutions will occasionally expose you to frankly astonishing levels of This Boneheaded Behavior Is By Design, anybody who has dealt with Unix professionally for any length of time will probably find the process of working around those at least somewhat enjoyable.
Just bear in mind that Windows is primarily a fleet OS and does have extensive centralized control facilities, even if it is far more opinionated than Unix about what The Right Thing looks like and those opinions will occasionally make you want to headdesk. Windows contains remarkably few unifyingly good ideas. Everything in it is super-specialized and oriented toward handling One Specific Class Of Issue in ways that frequently interfere with, rather than help, handle other classes of issue. But it's also just massive and that makes up to some extent for its incoherence: there's a lot of shot loaded in that scattergun. If you can find your way past being appalled by awful fundamental design decisions, and commit to just doing stuff The Windows Way to the greatest extent your sanity will tolerate, it does all work. Mostly.
This thread will stay open for a year unless you mark it Resolved, and since the scope of the initial question is so wide, I don't think anybody would object to you coming back to it with more specific followup questions.
posted by flabdablet at 8:44 AM on August 13
I was hoping to get a general orientation here, which you have given me and thank you for it.
I've omitted the snowflakes because it's more of a blizzard at the North Pole situation. For example, most of the young kids speak Mayan natively and pidgin Spanish at best. Microsoft, it turns out, does not make a Mayan version of Windows. Fortunately I don't have to create the workflow that is going to make the students comfortable, but I will probably be the person who implements it.
Also all of the machine administration needs to be done in Spanish, which makes every day a shining journey of adventure with Google Translate.
posted by Tell Me No Lies at 4:57 PM on August 13
I've omitted the snowflakes because it's more of a blizzard at the North Pole situation. For example, most of the young kids speak Mayan natively and pidgin Spanish at best. Microsoft, it turns out, does not make a Mayan version of Windows. Fortunately I don't have to create the workflow that is going to make the students comfortable, but I will probably be the person who implements it.
Also all of the machine administration needs to be done in Spanish, which makes every day a shining journey of adventure with Google Translate.
posted by Tell Me No Lies at 4:57 PM on August 13
Co-opt your users. Somewhere in that population there will be kids who are strongly motivated to learn about the machinery for its own sake; those are our future coders and designers and sysadmins and you want them working with you, not against you. Give them things to do and watch them bloom!
Plus, the best way to understand any issue is to explain it to somebody else. Time you spend helping a future sysadmin understand e.g. why student accounts need both private and shared spaces on the school file server is extremely well invested.
Best of luck with the language issues. I hope for your sake that you're better at acquiring new human languages than I've ever been.
posted by flabdablet at 9:58 PM on August 13
Plus, the best way to understand any issue is to explain it to somebody else. Time you spend helping a future sysadmin understand e.g. why student accounts need both private and shared spaces on the school file server is extremely well invested.
Best of luck with the language issues. I hope for your sake that you're better at acquiring new human languages than I've ever been.
posted by flabdablet at 9:58 PM on August 13
There is a K'iche' (Mayan) language pack for Windows.
posted by Harvey Kilobit at 4:44 AM on August 14
posted by Harvey Kilobit at 4:44 AM on August 14
Remove all the CD and floppy disk drives if the computers are old enough to have them, you can always connect one if needed for maintenance. Disable boot from USB (and possibly all USB usage) and put a password on the BIOS. Outside of bad internet usage, booting from or connecting to something else is how kids get access to all sorts of things and give your network viruses (source: was kid who lived in a university lab for a while). If you can put the pc's in metal or wood cages with padlocks then they can't take them apart either, make sure they still get airflow though else it's a fire hazard (you do always still need a fire extinguisher in labs!), these can be expensive but someone local can probably make you some cheaply if you get hold of one example, or you could look for used computer equipment sold cheaply (not many places have labs anymore). You can also secure monitors, keyboard and mice with stuff like https://www.tufnut.com/com-sec-cab/keyboard-lock-mouse-lock/. Camera's would be nice, but it's tricky legally to have them aimed at kids so you probably don't want them.
At a small cheap IT company I worked for there was a well-crafted Windows image, and if someone messed their pc up, as the junior sysadmin I would take their hard drive, connect it with cables and copy the image onto it, re-connect it up and set a few things, sync the users profile again and voila, all good again. User info and data was stored on a safe share location that was backed up daily. I think we used Norton Ghost. We didn't have time to figure out user problems. There are much better ways but this was almost foolproof and the network was not always reliable.
Another cheap thing to do if you have any warranties on the computers is to keep a very careful spreadsheet and know exactly what serial number you used for what and when. Some warranties have limitations like one part per pc per month so if a pc has two problems you use another serial number to keep things running. This can get complex quickly and you only get so many "oops sent the wrong serial number" excuses if you mess up. If the warranties are all expiring soon you can also try stock up on parts.
Printers suck. Try get the simplest best ones you can else you are in a for a struggle. Have clear instructions on how to unclog and add more paper near them.
If the computers will be used outside of supervised classroom hours - make a position called Lab Monitor or something and get some kids to do that for the glory, résumé item, credits or a little money. They can help people with the basics and printer, stop thefts and acts of destruction, and be the guardian of the extra paper (and stop people printing books which will cost you a lot!). You don't want to have to manage them or their roster so try get someone else to do that or get the most senior and capable kid to do it.
Good luck! Almost forgot this - don't let the kids set the windows background or make it reset on reboot so it's easy to fix, else they will change it to naughty images (they almost always pick something beginning with P).
posted by meepmeow at 5:42 PM on August 14
At a small cheap IT company I worked for there was a well-crafted Windows image, and if someone messed their pc up, as the junior sysadmin I would take their hard drive, connect it with cables and copy the image onto it, re-connect it up and set a few things, sync the users profile again and voila, all good again. User info and data was stored on a safe share location that was backed up daily. I think we used Norton Ghost. We didn't have time to figure out user problems. There are much better ways but this was almost foolproof and the network was not always reliable.
Another cheap thing to do if you have any warranties on the computers is to keep a very careful spreadsheet and know exactly what serial number you used for what and when. Some warranties have limitations like one part per pc per month so if a pc has two problems you use another serial number to keep things running. This can get complex quickly and you only get so many "oops sent the wrong serial number" excuses if you mess up. If the warranties are all expiring soon you can also try stock up on parts.
Printers suck. Try get the simplest best ones you can else you are in a for a struggle. Have clear instructions on how to unclog and add more paper near them.
If the computers will be used outside of supervised classroom hours - make a position called Lab Monitor or something and get some kids to do that for the glory, résumé item, credits or a little money. They can help people with the basics and printer, stop thefts and acts of destruction, and be the guardian of the extra paper (and stop people printing books which will cost you a lot!). You don't want to have to manage them or their roster so try get someone else to do that or get the most senior and capable kid to do it.
Good luck! Almost forgot this - don't let the kids set the windows background or make it reset on reboot so it's easy to fix, else they will change it to naughty images (they almost always pick something beginning with P).
posted by meepmeow at 5:42 PM on August 14
There is a K'iche' (Mayan) language pack for Windows.
It looks like that may only be for Windows Office (which would still be great), but unfortunately Yucatán Mayan is the local language.
posted by Tell Me No Lies at 8:47 AM on August 15
It looks like that may only be for Windows Office (which would still be great), but unfortunately Yucatán Mayan is the local language.
posted by Tell Me No Lies at 8:47 AM on August 15
You are not logged in, either login or create an account to post comments
If it's public they likely have an account that they need to use to log in, and it will be the same username/password if they change schools but are in the same district, making security and forgotten passwords both an issue.
It is rather important that you prevent students from installing software, circa 1998 the default teacher password in my county was "chalk". Several teachers did not change theirs.
posted by I paid money to offer this... insight? at 4:48 PM on August 11