Powered everything back up after the weekend outage with no problems; testing sending out a file in Lab C. All seems to be OK.
There'll be a campus-wide power outage on Sunday, so I've been unplugging everything in sight. Lab C is completely unplugged; Lab B has a class in it, and the CALL folks will handle shutting it down at the end of their day. All machines in R&D are unplugged, including printers, except my own machine, which I'll do last thing before I leave. The server room is a bit more problematic; here's a list of what I know about:
- Squash: no lab classes need it this afternoon, so I've shut it down through Terminal Services access.
- Chou: can't connect to it, and pinging it results in nothing, so I'm concluding it shut itself down at some point.
- Quince: Got the OK from Michael Joyce to shut it down, so it's off. Was able to log in through Putty, but the details in our documentation are wrong. Note to Greg: update the info.
- Idaho: I'll shut this down via SSH when I've done my backups for the day.
- Casper: doesn't seem to be running; no response to pings.
- Parsnip: I didn't really know anything about this server till I found it in the server room, but it seems to be the reborn Crossroads B -- presumably we don't need a Crossroads B, though, since the teacher stations can now run their own Crossroads? At any rate, nothing seemed to be running on it, so I shut it down.
- Machine handling video surveillance in ETCL: I have no idea what to do about this machine, and there are no instructions, so I'm leaving it running in case there are security implications from shutting it down. The UPS should bring it down gracefully when the time comes.
In the server room itself, I left the UPSes connected to the power; they're supposed to handle outages. Nothing else was plugged in except for a power bar supplying one of the KVMs, and I turned that off. Hope I've done all the right things here; we should really have some documentation on how to power off for outages in the server room.
Eoin reported a recurrent difficulty, which we were able to reproduce, and which seems to be the problem documented by Greg before he went away. RSRV.exe is not starting when users log on (although it's in the All Users startup menu folder), so when you start the Sanako program, you get an RSRV error; a side-effect appears to be that several items in the Sanako interface don't show up (such as the Program source controls). Starting RSRV.exe and restarting the Sanako program seem to solve the problem, so I put a shortcut to RSRV.exe on the All Users desktop, for quick access to a fix when the problem recurs.RV
Not many ELC classes showed up yesterday, so in view of the heat I decided not to boot the student stations. In fact, several were still running in Lab C (C 18 and 21), and 18 was difficult to shut down. I've noticed a problem with the LG StudioWorks monitors: once they go to sleep, it's really hard to wake them up again.
Lab B teacher station was either left frozen overnight, or froze on bootup (I pressed the button and walked away, so I'm not sure whether it was already running or not). A forced reboot seemed to fix it.
I'm booting up both labs first thing every morning because there are classes in both at 8.30, and they seem to be showing up. Today all the Lab B machines booted fine, and the only oddity was in Lab C, where STN 18 was very slow indeed.
Booting up this morning, Lab B 19 went into CheckDisk. It eventually completed the bootup successfully, but this may be a sign of a dying HD. Station 21 booted up at 800 x 600, and when I logged in to change it to 1024 x 768, it seemed to lose all communication with the monitor for a couple of minutes before coming back with a wobbly picture, then settling down. Watch this one in case the monitor is on the way out.
I've done the last troubleshooting/adjustment I'll do before my time off.
1) Server 2003 has draconian default interent security settings that cannot be turned off. Rather, one must uninstall the Windows Component responsible. I did that, and users should not have any site access problems.
2) For some reason RSrv.exe is not automatically starting when a user logs in. This is needed for the Sanako 300 console to function. If it isn't running there will be an error message in the Console "taskbar" (the colourful tabs at the bottom that list the various sources, like Cassette 1 etc.) something to the effect of "RSRV error -42 \\Lab-B-Teacher not responding". If you start RSrv.exe from C:\Prgram Files\Sanako\Shared Components\NetCommPlatform\RSrv.exe and relaunch the console everything should work. My short-term solution was to put a shortcut to RSrv.exe in the Startup folder for All Users. Not elegant or failsafe, but it seems to work.
3) The media directory for teachers to put their own media for distribution is in the All Users tree - I set the folder to be modifiable by everyone. This is needed for collection of student work and sending out files that instructors bring with them.
There may be other problems which I have not yet addressed. Some things have not been fully tested either. For example, the audio card setup for Sanako seems OK, but I haven't had the time to run the complete setup. I also have not tried pushing out URLs via the console or other "push" type browser activities, nor have I fully tested telephone or alternate media sources. That said, CD as source seems fine as does Teacher as source. Feedback welcome...
Dan came in with 4 files on a USB stick that were needed by an instructor for a final exam in just over an hour in Lab C.
In similar situations previously, I recall going to Squash in the server room and copying the files into the appropriate folder in the teachingmaterials tree. I went in to the server room, logged in as admin on Squash, put the usb stick in the usb port on the back of the computer and the OS did not find the device. I burned the files to a CD on my Mac, took the CD to Squash, but could not get the door on the optical drive to open (tried the button on the drive and selecting the optical drive icon in windows and choosing eject disc). We've got to make it possible for an admin to sit in front of squash and copy files from a removable media to the hard drive.
Then I went to the teacher station in Lab C and logged in as UVIC/sarneil. I put the files on the desktop of that machine and tried to share them out from there, but that failed.
I used the network connections shortcut on the desktop of the teacher station to find Squash/teachingmaterials and uploaded the files to the appropriate directory on Squash. I then used Sanako to send them out to a couple of stations, everything seemed fine. I left Dan confirming everything was working.
[At this point the dean's office phoned to say they had forgotten the new password they'd created for their departmental account, so I spent half an hour dealing with that.]
When I returned the instructor, Judy and Eoin were in lab C and when they tried to send the same files out to the students in Sanako (using File button with copy and launch), they would successfully get to only two or three student machines, the rest got error "-2 permission denied" errors. We tried a couple of times and each time only a couple of computers got the file, but not always the same couple of computers.
Eoin moved the class to Lab B and everything worked just fine. I don't know who he logged on as on the teacher station.
Meanwhile, in Lab C, I could see that Dan must have logged me off and anita had logged in. I restarted the computer, logged in again as sarneil and everything worked fine. I then logged off sarneil, logged in as lang02 and tried the same File send, and got access denied errors in the open file dialog box. I was thinking there might be some issue with just logging off versus restarting the computer between users on the teacher station. However, this morning I came in, logged in as sarneil tried the send and got the -2 errors.
The permissions on the files on the server look reasonable to me, though I don't know how to get Windows to tell me who owns the files. I could also see a list of users on Squash which included a bunch of instructors and UVIC/sarneil and the instructor's account but not UVIC/lang02, so that might explain the problems with the lang02 account, but not with the instructor's.
I am not sure whether the problems stem from the way we uploaded the files to the server, or whether that's completely irrelevant. There don't seem to be problems with any of the other files on the server.