Firefox and the Enterprise Environment

Firefox recently updated to version 5, and sent Firefox 4 to the EOL graveyard.  It plans to do the same with Firefox 6 in 6 weeks, and Firefox 7 6 weeks after that.  Enterprise IT staff are in a tizzy because their internal testing takes that long to figure out whether a piece of software will work for them, and the rapid release schedule completely destroys their system for testing.  See this quote from Mike Kaply's blog by John Walicki to get the idea.

I have 500,000 corporate users on Firefox 3.6. We just completing a test cycle of Firefox 4 on many thousands of internal business web applications. Many hundreds of application owners and their test teams have participated. We gave them several months to ready themselves. We worked with dozens of internal Add-On developers and product teams to prepare their add-ons for Firefox 4. We’re poised to deploy Firefox 4.01 in 3Q when the corporate change freeze lifts. Education programs, documentation updates, communications all are planned. While several of us keep up with Aurora, I can’t expect thousands of app owners to do the same. I applaud the effort to accelerate the pace of Web experience and I expect to chase version releases well into the future. The Firefox 4 EOL is a kick in the stomach. I’m now in the terrible position of choosing to deploy a Firefox 4 release with potentially unpatched vulnerabilities, reset the test cycle for thousands of internal apps to validate Firefox 5 or stay on a patched Firefox 3.6.x. By the time I validate Firefox 5, what guarantee would I have that Firefox 5 won’t go EOL when Firefox 6 is released?

Asa Doltzer responded that he would do the opposite and guarantee that when Firefox 6 is released, 5 will go EOL.

I understand John's (John works for IBM in their IT department) concerns with regards to internal testing and the test version they used being no longer supported by the time they roll it out.  I just think there's an easier solution than trying to force Mozilla back to their earlier versioning scheme. Currently Mozilla puts out 3 to 4 branches for public use. These are:

Full Release: The standard releases you're all familiar with. The most stable release. Currently on version 5.

Beta: A familiar name for a familiar concept.  Pulled from the Aurora branch shortly before being pushed out as the next Full Release.  Currently not available.

Aurora: The perpetual beta branch.  Aurora is pulled from Mozilla Central and is where UX and new feature work takes place.  If something isn't ready that's in Aurora when Beta is set to be branched, it gets disabled and pushed back to the next release. Not the most stable, but not the least.  Currently on version 6.

Mozilla Central (Nightly): Mozilla Central is the trunk of the Firefox dev tree.  Most work gets done on Moz Central, and every night the first build to pass their automated test suite is pushed out as the Nightly release.  Inherently the least stable.  Currently version 7.

Based on this information, my advice to enterprise level IT staff:  Start testing Firefox Aurora, and follow it through until it hits Full Release.  Yes, there will be some changes to Aurora while you're testing it, but all those changes are publicly available on bugzilla, and are fairly easy to collate into a single list for you to keep an eye on.  Watch for changes that have an effect on you or your tests, so that you can time your rollout of Firefox with when it hits Full Release.

VBS to the rescue

Another interesting day at work.  I finished updating our warranty information in our Asset Database pretty quickly, so I had most of the day to do whatever I wanted.  I had heard when I was first hired that we had gotten a new exchange server, and that I would have to go around to everyone's computers, see what PST files they had open, close them, move them to the new server, and re-open them.  Manually.  Bunk that, time to put my title of Master Problem Solver to work.

After a few quick searches online, I had a script that mapped out all PST files on the drives you fed it, and recorded their locations in a logfile.  Good place to start, since I didn't have any experience writing logfiles with VBS, let alone looping over a filesystem.  After tweaking that a little bit I had a script that copied the files it found to a location I fed it (which would later be hardcoded/dynamically generated based on the login name).  Awesome.  After doing some research on opening/closing PST files with VBS (which yielded almost nothing related to it), I decided to simply try and open a .lnk that pointed to a PST file in Outlook.  Fortunately, it was smart and followed the link, so I decided that instead of setting Outlook to open the new file in my script, I would try replacing the old copy with a shortcut to the new one and fool it into re-assigning it.  As you might guess, this didn't work so well.

Outlook was looking for a .pst file, and not a .lnk file (which I was afraid of), so the open PST files now returned an error that it could not be found.  At this point I figured alright, time to take a break and when I come back if I had an epiphany roll with it, and if not work on grabbing the login name for use later.  No such Epiphany, so I moved on to the name.  Searching for these led me to an already completed VB script that read the currently open PST locations from Outlook, determined if they were local or not (if they weren't it skipped them), recorded the locations, closed them, copied the local ones to their \\server\home folder, and re-mapped them in Outlook.  Essentially, it does exactly what I was looking for, and with a few modifications it's able to run just fine and do exactly what I need it to.

Moral of the story:  learn how to search better, because somebody already invented the wheel.  If you're interested in the actual script I'll post it up, just let me know.  I don't have access to it right now (it's at work, I'm not, and VPN access is given out sparingly) otherwise I would throw it up for the world to see now.

MS Access 2007 and VBA

Today was an interesting day at work.  My boss is on a camping trip for today and tomorrow, so I'm the only IT person here, which means I get to answer everyone's stupid questions!  It wasn't that bad, I only had 1 stupid question, and spent the rest of my day helping out a coworker with the Access Database he's building for Project Management.  His first request was for me to come up with a method for Access to automatically schedule a task in Outlook.  Given that I haven't done much VBA  I reluctantly agreed to help, and spent the first hour of my day figuring out how to turn on the Outlook reference in the Access VBA environment.  After that it was all trial and error as I tried and failed and tried and failed to successfully scrape the information I needed out of an Access form.  I finally got it, and about a half hour after I sent the results over to him he comes back wondering why he can't use strings to set the body and subject of his tasks.

I walked him through step by step and worked through it on my copy of his database with him guiding em through what he did.  As soon as we got to the part where he was calling his strings in the NewTask.Subject line, his problem became crystal clear.  He preceded every string call with str, which he should if his strings start with str, which they should if he followed common programming/scripting practices, but he didn't, and as a result they didn't and his code broke because he was calling strings that weren't there.

I thought that would be the end of my troubles with him, but it turns out I was wrong of course.  He returned a third time, asking about why he couldn't assign a task to himself.  This one, like the first one, was actually a problem.  Since I wasn't listed as a user or contact in his database, I never was able to thoroughly test whether or not I could assign a task or not (I used NewTask.Display, which pops up the Outlook dialogue and allows you to adjust any of the imported options before assigning a task.  It also let me cancel before I assigned because I have enough tasks as it is).  Sure enough, you cannot 'assign' yourself a task, outlook has a different dialogue for that.  So now he had a 2 part task for me.  1) find a way to get the logged-in users username and compare to their name in the database, and 2) use the appropriate task dialogue depending on if you're assigning to yourself or not.

Part 1 was fairly easy, I found a chunk of code <a href="http://access.mvps.org/access/api/api0008.htm">here that works beautifully for this</a>, and just made a module for it.  Part 1.5 involved some string functions, because the username scheme we use being first-initial-last-name means that Full names and usernames are totally different.  Conversion to lowercase, grabbing the first character then searching for the position of a [space] and grabbing the characters after that fixed it so they could be compared to one another.  Now to figure out the difference between Assigned task and a regular self-assigned task.  After some playing around it was apparent that the NewTask.Assign call was at fault for converting the tasks to an assigned task, so moving that along with the contact lookup into the If/Then/Else statement solved that problem.

All in all, I'd say today was a rather productive day for me.

Play time

Still playing with the different design options and layouts.  First thing's first: I hid the blogspot bar at the top.  Don't see it? Never knew it was there?  Good, that's the point.  Will be putting AdSense ads up at some point, I don't want them to be obtrusive, but I do want them noticed, so I'm thinking one above posts, and one below.  Thoughts?

Opening Day

And let there be light.  Today is the opening day of the Overclocked Insomniac, a blog about whatever I damn well feel like writing whenever I feel like it, no matter who it offends.  I don't aim to be disrespectful, not ever, but I will not filter what I decide to write about to avoid making someone cross with me.  I also tend to link dump with images I find humorous, so be prepared for those.