Well, aside from the few die-hard students hanging around here, this place is pretty much a ghost of it’s former self.  I spent some of this shift looking into making scripts that run with admin privileges when a user logs out.  It looks like it’s pretty hard to get the scripts to work that way, but I think I may have found an equally good solution:

Since we are planing to initiate a automatic reboot to all the PC’s at a designated time, we can either use the old reboot script or set up a scheduled task to reboot the computer at a certain time during the night.  When the computer reboots, we can then execute a shutdown script (which runs as admin) to delete the profiles on the C drive.

In other news, I spent a couple hours herding chairs to the corners of the building.  Although I was by myself, I still managed to finish the 1st floor and got 5 of the 13 rooms done on the second floor.  Should make it a little less grueling for whoever gets stuck with chair herding tomorrow…

Steve and I decided to hold off on deactivating Zbrush as it would take about 5 minutes to make a call to Pixologic and have them do it vs. the 2-3 hours it would take us to do it manually.

Over and out.

I finally got around to making an automated installer for the Graphire tablets.  This proabably won’t be very useful anymore seeing how it’s almost the end of the quarter.  That being said, the technology is there, should we ever need it.  Plus, doing so has given me more practice into making automated installers, should we ever figure out a way to distribute them on a client-side basis.

In other news, I worked on an automatic logoff script that will delete user profile data saved in c:\documents and settings.  The script works, but I just realized that it runs the script with the current user’s credentials and therefore, will not execute if they don’t have admin rights.  This is a giant pain in the ass instantiated by windows, so we will have to use a runas workaround if we wish to go through with this.  I’m hoping that there may be another method of getting this to work, but runas might be our only option here.

I came in to the office today greeted by a flurry of more computers running out of disk space because of synchronization.  There’s only a few days left of this quarter, but it was preventing students from logging on and causing general mayhem so I decided to take evasive action.  I was still having trouble with my runas scripts properly deleting the C:\WINDOWS\CSC folder so I looked into alternatives.  I found this nifty little program called “psexec” which allows you to execute scripts on remote machines with admin rights (if you’re logged onto the sever machine as an admin).  It has a function to batch execute by reading from a file, but our lookup.txt file has too much information (ip address, mac, etc) so I decided to modify my mass-distribution script to execute a psexec command instead of xcopy.  I had one hell of a time getting the parameters correct, but I finally got it working and pushed out both a script to delete the CSC folder and a script to turn off snychronization.  Now, I only did this on the machines that were currently in Windows, since the script won’t work in Linux.  As a result, there are probably still going to be some complaints of students not being able to log on.  In that event, it’s quite simple to fix the problem now.  If you are logged into either mont-pt1 or mont-pt2, perform the following steps:

If you wish to push out the script to all machines in the building:

1.  Navigate to massDistribute_psexec.vbs and run the script (windows\_Admintools\vbscripts\).

2.  Choose the del_CSC.exe script (del_CSC\sourceFiles\)

3.  the script take about 10 minutes to finish so let it run and review the error log file (in the sourceFiles dir).

4.  Perform similar steps except choose off_snyc.exe to turn off synchronization.

If you wish to fix a single machine:

1.  goto start >run and type ‘cmd’

2.  type the following:

c:

“C:\WINDOWS\psexec\psexec.exe” \\mont-room-compNumber -c “Z:\windows\_Admintools\…the location of the script”

3.  ‘mont-room-compNumber is the computer you wish to copy to and the path to the script is whatever you have the apps drive mounted as (Z:, Y:, etc)

So, with all the students logging on and the file synchronization being on is causing the more popular classrooms to clog up and run out of disk space.  I worked on a simple autoit script to delete the contents of the problem folder (C:\WINDOWS\CSC).  Unfortunately, I ran into some problems with autoit and the script seems to be rather iffy.  basically, I tested it out and it worked, but then Hasan tried it on another computer and it didn’t seem to do anything.  The script del_MCM.exe works pretty much all the time IF the user is logged in as ADMIN.  The other script, runas_del_MCM.exe is SUPPOSED to work if the user isn’t an admin, but that’s where the sketchy part comes in.  Both scripts are located in _Admintools\vbscripts.  I will be looking into making something that works a little better next time around.

On the brighter side, I found the registry keys that enable file synchronization and have created a script to turn them off. They are also in _Admintools\vbscripts.  Run runas_offFileSync.exe to turn off file snycing.

In other news, mont-111-08 has a dead monitor.  I didn’t remove it yet, because I didn’t have one to swap it out with.

Also, 204-21 which was running Fcheck has come back with pure gibberish.  I tried rebooting and got the same junk.  Windows boots just fine, but Linux is toast.  I decided to reimage the Linux-side, but it’s going super slow (60+ hours).  I told Dan to pull a spare hard drive from one of the backroom z600’s if the image doesn’t pull through in a realistic time-frame.

Pretty much sums up the day.

So, I just sat down for my shift when a student walks in stating that “all the computers in 207 are asking for Unreal CD keys.”  “Surely,”  I think to myself “this student must be running unreal from the .exe, not the proper shortcut.”  So, I went up to 207 and check out one of the machines.  “That’s odd, Unreal isn’t registered on this machine.”  Must be a fluke, right?  After fixing it, I ask the students if there are any others that we’ren’t licensed.  They point to the entire right side of the classroom.  I then proceeded to ask them why they didn’t report this to the systems office only to hear that they have on several occasions - including the submission of problem reports.  How did this go by the entire quarter with no one resolving the matter?  This is absolutely unacceptable.  I’m not pointing fingers at anyone, but we REALLY need to work on our communication in the office.  And, if someone doesn’t know how to do the job, they need to ask questions rather than simply leaving the job half-assed and calling it quits.

In other news, I reimaged 209-19 due to a corrupted windows install.  Zarni is going to install trend micro later on.

Also, 209-21 has a bad memory module (3) on the motherboard and will need to be replaced by HP.

I fixed a computer that wouldn’t boot to windows by using the repair console.  It was posting an error “system32\hal.dll” was corrupt.  I did “fixboot c:” and that took care of the problem.

Today I had to clean up some scripts that I worked on earlier.  Based on the discovery that the bridge fix doesn’t work as a student user, I have to ad a runas command to the script.  Now the script executes the delete registry code as steam, which actually works.  Unfortunately, the comp still has to be rebooted after the script is run in order for bridge to work.  Also, started looking into an automated installer for the graphire tablet drivers.  I sent Pixologic another e-mail requesting an update when they get the muliple user bug cleared up with zbrush 3.5.

Tested out the new version of Zbrush on one of the part time comps.  seems to be working just fine (so long as I don’t change logins).  The registration seems a bit wonky, unfortunately.  You have to enter a registry code, which then directs you to a web page where you have to enter the serial for zbrush.  I’m not sure why they made this system more complex than what they had before, but oh well.  The required files are all on the apps server now in a  zbrush 3.5 folder.  Installation simply requires a copy/paste of the 3.5 folder to wherever you want to install it (at least that part is simple).

In other news, Jon gave me a scare when a student reported bridge not working and still wouldn’t work after we removed the FLEX_LM_LICENSE registry entry.  It turns out, the script doesn’t run properly if the user isn’t an admin.  This is a bit unfortunate, because that means we’ll have to log in as steam in order for the script to run properly.  In addition, further testing on some 8400’s revealed that running the script wasn’t enough - the machines had to be rebooted as well before bridge would work.  Kind of a pain in the butt just to remove a simple registry entry.

I contacted Pixologic regarding the upgrade to 3.5.  They sent me an e-mail with all the required information and I will investigate this tomorrow.  My only concern is that the support person that I spoke to informed me that there is currently a bug with 3.5 that prevents it from running under multiple users, much like Unreal.  While we do have the technology to work around this little problem, he assured me that the bug would be fixed in a matter of days.  Even still, I’m not exactly clear on how they will distribute the fix, hopefully in the means of a patch.  If that’s the case, then we shouldn’t have any problems fixing the install.

Well, not a whole lot to report this evening - pretty slow for the most part.  I updated the forum describing how to use procmon for troubleshooting.  Also, handled a couple of problem reports.

After talking with Steve, it occurred to me that I never tried running Bridge with procmon to see what files/keys bridge was modifying when it hangs.  After monitoring Bridge with procmon for a few minutes, both Steve and I were able to conclude that bridge was repeatedly querying 3dmaxserver and shakeserver.  After telling Dan about this, he concluded that it was the LM_LICENSE_FILE registry key that was the problem.  I tried manually deleting the key on one machine and sure enough, Bridge worked just fine.   I have modified the delete lm licence script to completely remove the key rather than just the 3dsmax line.  In addition, I have pushed out the script to all computers and will run as soon as someone logs in.  The bridge and Indesign problem should become a thing of the past as of now.

Side note, I realized that while I was commenting my distribute script, I accidentally commented out a key line that completely broke the script.  I have fixed the problem and it seems to be running just fine now, sigh…

I brought a new hard drive up to Soha’s computer and took the old one’s down to the office for a virus scan.  I also left instructions for what to do when the drive’s are done scanning.

Off to class…