Well today was a somewhat eventful day. Even as I type that though I think back to what happened and I find that it really wasn’t _that_ eventful.
**Interesting what seems to be a huge deal only because it took a long time to fix. As I find I am quick to do, let me give you the back story.**
This morning at work I went in to build a ghost item to send out to all the machines in the center. As I was setting it up I was forced to pull a file off of my machine’s hard drive. I found my machine wasn’t listed in the directory and so I searched it out and found it elsewhere. I thought little of it and went about what I was doing (editing batch files and running commands remotely **kinda cool stuff actually**). Next several machines could not find machines to map drives off of. Interesting, but not out-of-place in a cube farm where machines that are supposed to be _exactly_ the same with _exactly_ the same software often act is dissimilar ways. These machines where fixed by placing a secondary WINS server in the settings (yes they run WINS….I know I know). Shortly after that Supervisors stopped being able to print via the printservers. They where not able to see the print server. This cinched the deal for me and I started searching out reasons for the lack of WINS resolution from the Bloomington servers. It was quickly realized that the Bloomington servers had been updated by some of the techs in Bloomington and no one checked to see if they were running correctly. In the meantime I went back and did some work on another script to run to change some settings on all the floor machines. By 12 it was decided that we should change all the settings on the machines to point to our servers for WINS resolution (better than sending all that traffic to Bloomington IMO) so I was called upon to write a script to do this as well. This was accomplished rather quickly, but then the real hassles started in. Afni (or maybe more correctly, the techs in bloomington for afni) like to have all the control in Bloomington, thus they try to give us as little information as possible. Thus I was forced to wait 1 hour for the “official” word on what we were supposed to do, so that I could run the scripts that I had already gotten ready. This was annoying for me because I am used to finding the problem, analyzing it and then moving on the plan of attack (POA) to get it done. I have little patience for waiting to get the word from someone that caused my problems on how to fix it. The one good thing that came from all this was that Shane (who was not the root of all the problems) gave us the lead on helping the Opelika facility out with fixing their version of the problem. This involved little more than giving them my script and telling them to change it, but I think it may have been a big step in a good direction for him and us. Jeremiah and I (well maybe just I) would like more responsibility and maybe this is first step toward that. I feel though that a line I once read applies here… “Your master keeps you on a leash, it may be a long leash, but it is a leash none the less.” No matter how much we end up doing or how much I end up proving we will still be lower class techs than the people in Bloomington. This is the thing that drives me to be better right now, and I think that it is a good enough reason right now and has made me a little more hungry to understand and learn than when I was at Western.