Ever been working on a machine that's been locked down and restricted from controlling the printer settings? It can be a real pain to have to log out and log back in as another user to change settings. You can work around these restrictions by combining the RUNAS command with PRINTUI.DLL and the RUNDLL32.
You can get into the inner workings of PRINTUI.DLL to see exactly what you can do with a peek at the help screen:
RUNDLL32 PRINTUI.DLL,PrintUIEntry /?
You can check out Rob Van der Woude's page at http://www.robvanderwoude.com/2kprintcontrol.php for a little more detail on the workings. He also mentions a few VBS files (%windir%\System32\*prn*.vbs) that come with Windows XP that can also help when working with printers. I've seen them, looked through them, played with them, but never tried to use them so I cannot say as to whether or not they would help on a locked down machine. But, I have successfully used RUNAS with the PRINTUI.DLL to work with printers on a locked down machine.
Problems and the occasional solution for technology issues encountered in a the K-12 education environment.
Wednesday, September 23, 2009
Monday, September 14, 2009
Has Google Update got you down?
Anyone out there struggling to save bandwidth? How about trying to keep your machines to a software level standard? I came across this info the other day and I thought that it might help. It lets you utilize Windows Group Policy settings to keep your Google Update in check. You can use them to control scheduling, disable them all together and have better control over the installation.
Sorry for the short post, but it's all pretty self explanatory.
Here's the link to actual documentation
http://www.google.com/support/installer/bin/answer.py?hl=en&answer=146164
Sorry for the short post, but it's all pretty self explanatory.
Here's the link to actual documentation
http://www.google.com/support/installer/bin/answer.py?hl=en&answer=146164
Saturday, September 5, 2009
Ringing the Bells
Recently we found our selves with a few classrooms that were not connected to the main bell system. A classroom full of kids watching the clock like a hawk isn't the best thing in the world. The few precious minutes of class time that is available doesn't need to be wasted clock watching, so they came to us in technology and asked if we could come up with a solution (cheaply). My knee-jerk reaction was, "Get them all alarm clocks." After that passed and I thought about it for a minute, an alarm clock didn't sound like a bad idea. Why not turn the computers in the classrooms into alarm clocks. They're old and slow, but they do keep time and will play sound.
We (in technology) tried to come up with an idea of exactly what we needed. Then we set out across the internet looking for the solution. We needed something that was cheap (free would be best), easy to use, allowed setting multiple alarms, and wrote the alarm settings to some kind of configuration file that we could easily push to the computers. We found a lot of programs, some of the teachers even pitched in with suggestions, but we couldn't find anything that was a good fit.
Then the old reliable "Scheduled Tasks" came to the rescue. It was free (comes with Windows), could be easily programmed with a batch file, could run as many alarms as we wanted, and the batch file was an easy way to set the schedule. For any of you that don't know. There's a way to set scheduled tasks through the command line, just run "SCHTASKS". The built help is great and it takes just a few minutes to figure out what it takes to make the bell ring. Well, it took just a few minutes to figure out that scheduled tasks doesn't include anything to make a sound. That's ok, we're on a Windows box and we still have the trusty "Sound Recorder" program. Now we've got the solution, Scheduled Tasks to watch the clock, Sound Recorder to play the sound, and a single batch file to set it all up.
The batch file we used is pretty simple. Each bell ring gets created by a single command and we just copy that command over and over adjusting the times until we've got all the bell rings covered. The command looks something like this:
SCHTASKS /create /tn BELL_8_00 /tr "sndrec.exe /play C:\Windows\Media\ding.wav /close" /D MON, TUE, WED, THU, FRI /ST 08:00
That command creates a schedule task that's named BELL_8_00, runs at 8:00AM, silently launches Sound Recorder, plays, ding.wav, automatically closes and runs Monday thru Friday. Just rinse and repeat with the times for each bell ring that you need. You can pick any wav file that you know is on the computers. The key to making it play and close cleanly is the "/play" and "/close" switches on the sndrec.exe file.
When it comes time to clean this up, it's much simpler command:
SCHTASKS /delete /tn BELL_8_00 /f
The /f forces the command to run, no prompts, no warning, it just deletes the tasks. Rinse and repeat for each time.
This isn't a perfect solution, there are some draw backs, but it fit our requirements for the time. One problem is that it only allows for on schedule, unless you setup multiple batch files and make sure the teachers get the right ones. It also doesn't account for activity schedules that occur at random times (like pep rallys or school plays). And unless the teacher knows about configuring schedule tasks it doesn't give him/her many configuration options. One solution might be to make a pretty wrapper with AutoIT or VBScript/HTA to allow for customization.
Another idea that I had is a small program that watches for bell ringing commands from another computer so you can change and adjust the schedules in one spot. That way each PC is sitting on the network ready to ring at any minute. I was thinking a small stripped down XMPP client for each PC and a bigger XMPP bot that does the ringing and gets his ring schedule from a GUI that's configured by someone in the office. That's going to be a project for my spare time.
We (in technology) tried to come up with an idea of exactly what we needed. Then we set out across the internet looking for the solution. We needed something that was cheap (free would be best), easy to use, allowed setting multiple alarms, and wrote the alarm settings to some kind of configuration file that we could easily push to the computers. We found a lot of programs, some of the teachers even pitched in with suggestions, but we couldn't find anything that was a good fit.
Then the old reliable "Scheduled Tasks" came to the rescue. It was free (comes with Windows), could be easily programmed with a batch file, could run as many alarms as we wanted, and the batch file was an easy way to set the schedule. For any of you that don't know. There's a way to set scheduled tasks through the command line, just run "SCHTASKS". The built help is great and it takes just a few minutes to figure out what it takes to make the bell ring. Well, it took just a few minutes to figure out that scheduled tasks doesn't include anything to make a sound. That's ok, we're on a Windows box and we still have the trusty "Sound Recorder" program. Now we've got the solution, Scheduled Tasks to watch the clock, Sound Recorder to play the sound, and a single batch file to set it all up.
The batch file we used is pretty simple. Each bell ring gets created by a single command and we just copy that command over and over adjusting the times until we've got all the bell rings covered. The command looks something like this:
SCHTASKS /create /tn BELL_8_00 /tr "sndrec.exe /play C:\Windows\Media\ding.wav /close" /D MON, TUE, WED, THU, FRI /ST 08:00
That command creates a schedule task that's named BELL_8_00, runs at 8:00AM, silently launches Sound Recorder, plays, ding.wav, automatically closes and runs Monday thru Friday. Just rinse and repeat with the times for each bell ring that you need. You can pick any wav file that you know is on the computers. The key to making it play and close cleanly is the "/play" and "/close" switches on the sndrec.exe file.
When it comes time to clean this up, it's much simpler command:
SCHTASKS /delete /tn BELL_8_00 /f
The /f forces the command to run, no prompts, no warning, it just deletes the tasks. Rinse and repeat for each time.
This isn't a perfect solution, there are some draw backs, but it fit our requirements for the time. One problem is that it only allows for on schedule, unless you setup multiple batch files and make sure the teachers get the right ones. It also doesn't account for activity schedules that occur at random times (like pep rallys or school plays). And unless the teacher knows about configuring schedule tasks it doesn't give him/her many configuration options. One solution might be to make a pretty wrapper with AutoIT or VBScript/HTA to allow for customization.
Another idea that I had is a small program that watches for bell ringing commands from another computer so you can change and adjust the schedules in one spot. That way each PC is sitting on the network ready to ring at any minute. I was thinking a small stripped down XMPP client for each PC and a bigger XMPP bot that does the ringing and gets his ring schedule from a GUI that's configured by someone in the office. That's going to be a project for my spare time.
Labels:
bell schedule,
bells,
k12,
scheduled tasks,
schtasks,
sndrec,
sound recorder,
xmpp,
xp
Saturday, August 22, 2009
CD Burning for Power Users in XP
What happens when you've got non-Administrator users (like Power Users) that need to burn CD's under Windows XP? It must be group policy setting, but where? I went over the local group policies with a fine tooth comb and couldn't find the "Allow Non-Admnistrator users to burn CD's" settings. There are a lot of crazy ideas floating around the internet about how to make this work and most of them don't work. But, I did come across 2 (or 3, depending on how you look at it) working solutions.
I actually first encountered this problem some time ago, but the problem recently reappeared. I couldn't find my original notes on how to fix it so I turned to Google, armed with a vague idea of the solution and found the answer within a few minutes. Now I'm making notes for all the world to see and hopefully, this post will be of help to someone else.
The first solution, and seemingly more popular one on the internet, is to use a small application from the makers of the Nero called Nero BurnRights (you can find it here http://www.nero.com/enu/support-nero6-tools-utilities.html ). You can install and configure it by hand if you want, but it's easier to automate it with a script or batch file. There are a few command line switches to help out. The switches I liked were: /silent and/burnrights:all. That sets everyone up to be able to burn and makes the installation silent so it doesn't interrupt anyone while it runs. There's only one catch, you have to be an administrator to run the installer. Otherwise the installer craps out (silently, of course) and it doesn't actually install anything.
Now, I don't have Nero installed on every computer, a lot of them run InfraRecorder. This problem shows up in InfraRecoder as the program launching but not being able to see any available burners. It seemed to be overkill to have to install one application to make another application run so I wanted a better and easier solution. Where's that simple group policy setting or registry key that fixes this problem? Obviously if one group (Administrators) can burn and another group (Power Users) cannot burn then it has to be a fairly simple rights issue. I worked off and on for several days when I stumbled upon the solution in an unlikely place. Over at AppDeploy.com I was looking at some of the configuration settings for the Nero suite ( http://www.appdeploy.com/packages/detail.asp?id=627 ) and I found in the notes section that TheWorkz had answered my questions:
I have found instead of using Nero Burn Rights for user rights to Low Level Device Access in Windows XP, you can use the following registry key/Policy to enable users rights to CD Drives.
Registry Key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"allocatecdroms"="1"
OR
Group Policy
Policy: Local Policy > Security Options
"Devices: Restrict CD-ROM Access to Locally logged-on users only" = Enabled
Registry Key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"allocatecdroms"="1"
OR
Group Policy
Policy: Local Policy > Security Options
"Devices: Restrict CD-ROM Access to Locally logged-on users only" = Enabled
There it was, as simple as that (imho a lot easier that the BurnRights solution listed above). I'd seen that group policy setting before, but my logic had been flawed. I had incorrectly assumed that I needed less restriction instead of more. One might argue that if you apply "Microsoft logic" that it all makes perfect sense. Whatever the case, changing this setting works.
You might be saying, "Come on! Still battling with Windows XP?" This is 2009 and we all know Windows Vista has been out for a while and Windows 7 is right around the corner. But this is practical school tech, and for all practical purposes Windows XP is going to be around for a while in public education. I've got Windows 98 machines still floating around and I know of school systems that have gotten rid of their last Windows 3.11 machines in just the past few years. If it upsets you that your children are using really old computers at school, call any politician that you know and tell them that more money needs to go to technology in education. In this economy they may laugh at you, but once the economy turns around it might help. It can't hurt can it?
Labels:
burnrights,
cd burning,
group policy,
infrarecorder,
nero,
registry,
xp
Monday, August 3, 2009
Practical School Technology
There's an interesting read on Jack Wallen's blog over at TechRepublic about the adoption of open source software in schools. It sparked a lot of discussion, but I guess any time you ask, "Why aren't insert-any-organizations adopting open source?" you're bound to get a lot of discussion.
There were comments from a very diverse group of people. A lot of suggestions were made, some good and some bad. But there were a lot of seemingly good ideas that just are not practical for public education. I thought about replying to some of the comments but I couldn't decide where I wanted to start. So I came up with the idea of starting this blog. A blog about more than just the who/what/when/where/why of adopting open source software in public education, but a blog about lessons learned in dealing with technology and public education, a blog about practical users of technology in education. I invite you guys to join me with comments so we can make this a great place to find ideas for things that work.
Labels:
education,
k12,
open source,
public school,
technology
Subscribe to:
Posts (Atom)