March 2007

It all started around 2pm on the 29th. One of our developers pointed out that one of our installers didn’t look ‘quite’ right.

A directory which should have simply contained “Product (build).exe” had both that file and one named: “Product (buildE.exe”. “Product (buildE.exe” still had it’s digital signature, where as the one that was properly named didn’t.

Hrm, let’s take a look. Scan the files with Trend Micro’s Office Scan, nothing, scan files with AVG, nothing. Jump on Trend’s website, using house call, still nothing.

Do a quick Google search for Virus software ratings which point to “BitDefender” being the best. Run that and *blam* we have an un-identified Win32/File Injector.

Nice….

These files so happened to be on the same server as all of our software builds, legacy and what not.

Read the rest of this entry »

Story [here]

I was lucky enough to be at a Krogers last night and experience the chaos that ensued when the scanners didn’t work.

Of course I only needed to pick up three things. Easy in and out for some cold medicine, apple juice and bread. That turned into a 30 minute debacle.

The Self checkouts were closed, and apparently there are only 2 cashiers capable of doing math and making change. (On a Friday night at 8p.m.)

Of the few things I purchased 2 rung up wrong and one wasn’t able to ring. Nice…

So the story above explains what happened. Apparently when they updated their recall info so they wouldn’t sell dog food that is tainted, the system got all fubar’d.

They couldn’t cope and had to shut down the stores for many hours. I wondered why at 8p.m. m 24 hour store was shutting down the lights.

It would have been easier I would imagine to just remove the stuff you can’t/shouldn’t sell from the customers reach. That’s how we did it in the good old days.

This is one downside of too much reliance on technology. Some things are just not all that complicated and aren’t technology problems to solve.

I’m glad I’m not the product/project manager for this. A whole bunch of stores closed. How much revenue was lost?

powered by performancing firefox

Not only does Microsoft provide you with a spectacular tool (Tzmove.exe), not to be confused with (Tzmove.exe) that you can distribute to all of your brilliant end users and ask them to run on your behalf.

(This works so well because as we know, end users just love running tools to fix IT problems that really should be addressed at the server level, and of course they fully understand what has to happen and why things are broken. Yes, delegating IT problems down to the user level is always the best move).

The best they could do from an Exchange administrator perspective is this:

- Create a client fix tool.

- Create absolutely the most convoluted way to take that ‘client’ based tool and script it to run on one machine, mailbox after mailbox. (That is in fact what they are doing).

- Exchange security issues as side, this should be fixable at the server level, without pretending to be a MAPI client for crying out loud.

Remember when Microsoft released the Windows NT domain, and promised us Single point of administration? This is not what I had in mind, if I wanted to script client tools to do things in bulk across my organization, we’d still be running DOS.

Yeah this was a real good idea:

“Note Do not confuse the Outlook tool installer package that is named Tzmove.exe with the actual Outlook tool executable file that is also named Tzmove.exe”

When you actually run these tools they can spew error code: 0×80004005

Which apparently can mean about 18 different things, none of which are related. I haven’t written error handling code in some time but even I, as lazy as I am, was more descriptive than that.

We did finally get the tools to run without error, but nothing has changed. We still have dicked up appointments.

I especially like this:

Recurring meetings that are created in Outlook Web Access are not updated by the Exchange Tool

Beh, who uses Outlook Web Access anyway?

Sheesh.