OK, Tech Support Folks, One More Time…

Let's get this right and not have to review this again, ok?  MMmmmmkay?!

When a user (you know, those noobs we call "losers") call or email and offer up something really insightful like this…

"Uhhhh, my AutoCAD ain't working.  It just opens and crashes with some kinda error, or something."

Here's what you need to put back in their face in order to get something useful to begin troubleshooting:

1. What was the EXACT error message?  Get (them to make) a screen capture if they're too stupid to write it down or can't type very well.
2. When did this start happening? (try to get a specific day and time)
3. Did the application work properly before this started happening? (you'd be surprised how many users say they've never launched the application before… ever)
4. What has changed on the computer since the last time it worked? (this is the most painful question, because they ALWAYS… ALWAYS… ALWAYS swear, on the grave of their grandmothers, that nothing was changed.  But after a few minutes of prodding they finally fess up about the new mouse or new software they installed, or that it had a virus warning that same day, and so on)
5. Have ANY other problems been going on with your computer? (this is usually overlooked, but sooooooooooo many times I find the problem isn't with the application, but something else - see my explanation below)

If the users have even a hint of a clue, you can leverage that to pull a few more teeth:

1. Get them to check the Windows event logs

Nearly every time I have had a discussion with an IT "expert" (whatever the **** that is), if they start to bring up something about a strange application error, I ask "what do the event logs show?" - and every time (ok, 99 out of 100 times) they give me a blank look that says "oh, I didn't think to check there."  Yeah.  So much for those certification exams. (*smack!*)

Here's how I would often handle a support call:

• "Hi, this is Dave from Tech Support and I have a ticket you submitted about you not being able to print your LOL Cats to the color laserjet printer in duplex collation stapling mode from a portrait page setup rotated 90 degrees but not landscape.  Can you tell me more about what's going on?"
• (they talk and talk and talk, while I surf the web and doodle on a notepad.  Every so often I will respond with "uh huh… yeah. mmmkay…" and let them blabber some more. When they finally stop:
• "So, when did this start to happen?"
• (more blabbering)
• "And, did this ever work correctly or has it always been a problem?"
• (more blabbering and some explanation about LOL Cats and how her daughter loves them and she dressed up like one for Halloween)
• "Ok, well, I'm going to need you to log off.  Mmmkay?… and now please put on your coat and get your car keys, and I'm going to suggest you drive home and go back to bed now, mmmkaaaay?  I think we can handle it from here.  We'll call you if anything comes up, like peace in the Middle East.  Buuh-bye now!"
• Then I send the ticket back to Tier 1 with a note the says "user says Tier 1 folks rock her world and she really digs [insert name of the 90 year old tier 1 guy]"

Something like that.  Customer satisfaction is always job #1.  Ok, so I promised an example, and here it is:

Example Case

One issue that drove the Tier 1 folks absolutely insane at my previous job was a support request that described the following issue:

User says everytime they click "PRINT" or type "PLOT" in AutoCAD, it implodes" (yep, they wrote it just like that)

The Tier 1 guy would enter the ticket, and send it directly to Tier 2.  That qualified as "basic troubleshooting".  Tier 1 folks at that time were hired from one of those hospitals where they take care of vegetative patients.  They work for very cheap pay and never complain, but they also don't do a lot of preemptive diagnosis or troubleshooting.  Maybe it was all those tubes and wires hooked to their shaved heads?  They usually kicked all requests up to Tier 2, where I worked.  Tier 2 was where they hired geniuses, focused on solving the world's problems and offering compassion for the poor, displaced and brow-beaten users.  We listened to Bach and sipped tea from a fountain.  Ok, that was a bit much, I agree.

I remoted in, and sure enough, I could launch AutoCAD, do some drawing and fancy stuff (I've been known to do a little fancy stuff, at least a few times, ok, so…) then I typed "PLOT" and pressed Enter and KABOOM! the entire session vanished without any error message or warning.  Not much help.  I repeated the process a few more times and it was consistent.  But after digging around, I decided to blow away the user's custom AutoCAD profile and try it, and the PLOT command worked just fine.  Then the user went in and set their profile back up to suit their needs, from scratch (not importing it from a file), and the problem started again.

I immediately looked at the user's custom plot settings.  The profile pointed to a shared folder on the network.  So I looked in the PC3 and PMP files and found that they were pointing to a printer that was moved to a different print server, so the mapping was invalid.  AutoCAD tried to read the remote printer status and had a massive bowel movement.  Kind of like drinking four Starbucks Doppio Espresso's at once and then eating a big Mexican lunch.  Once we recreated the PC3 and PMP files to point to the correct printer everything was fine.  What caused this?

The print server folks (different department) decided to move the printers to a new server, but didn't get the word out to all the remote engineering department coordinators, who's job it was to keep their departmental PC3 files current and notify their users.  Note: a little communication goes a long way.

So, back to the story (because I know you just can't wait): Don't let users run over you with stupid requests.  You have to push back a little and make them explain things better.  You don't tell your doctor "I hurt" and then stare at him, waiting for a diagnosis.  At least I hope you don't.  You try to provide as much detail as possible - because YOUR health is at stake.  Well, make sure your users (ok, ok, "losers") understand that their support requests put them at stake.  That's a little communication that needs to be repeated every now and then.

Mmmmkay?

The Cloud

I was asked by several folks what I thought about "the cloud" and what it means for the future of IT, business, culture, society, and so on.  One reader (Randy, thank you!) asked if I would take a minute to write something on it.  I've been poking at this subject with a stick like a three year old curiously prodding a jelly fish washed ashore.

First: Caveats and Disclaimers:  I don't work with cloud technologies.  I don't have any clients that use what I would call "significant" cloud services.

The closest thing to cloud services I've used is Gmail, Google Docs, Google Calendar, Picasa, Flickr, Facebook, Twitter and Blogger.  Some of these only remotely qualify as a "cloud" service, while others fit the bill pretty well (Gmail and Google Docs, for example).

But what is it?

Wikipedia (everybody's authoritative source, right?  heh heh) defines it as "Cloud computing is Internet-based computing, whereby shared resources, software and information are provided to computers and other devices on-demand, like electricity"

That's better, but it still doesn't make it crystal clear to a lot of people.  This is like many IT terms which those working inside the club have an inate, yet unwritten understanding of.

To me, a cloud service is when you rely on something hosted over the Internet that you would have traditionally relied on from within your own facilities.  E-mail, document management, CRM, timekeeping, HRIS, accounting, finance, contracts, payroll services, benefits management, and so on.  The degree to which "relies" becomes involved is subjective.  Is it "cloud" oriented to share and mark-up engineering drawings within a collaborative web portal?  Or is it "cloud" when the engineering drawing application itself resides on an external web portal along with the drawings?  The answer is "yes".  It's a vague term, but it gets kicked around so much that many are left just nodding as if they get it, when secretly they don't feel very confident about it.  It's not a confident monicker.

But what is it good for?

That's up to you.  What is a truck good for?  To you it helps with shopping and carrying lawn care materials home.  To a business it means resource distribution and logistics management.  To a club it means carrying a team down a country road to meet for important events.  For a football team it carries the mascots and cheerleaders across the field at half-time.

It's a tool.  Just like computers, networks, software, and wires.  They're all tools.  What they are good for is a matter of what you need them for.

Some people may find cloud services of extremely powerful use to them.  Others may find it uninteresting.  Some may want to try it out and see where it fits into their overall needs.  Some will shy away from it citing regulatory or security concerns.  Whatever your view, at least look at some of the services out there and read up.  Learn what you can.  Then decide what you want to do with it.

I'm sorry if I seem non-committal, but I suppose I am.  Probably the mark of a consultant's world.  We always answer tough questions with "well, it depends".  That's a silly cliché, but it's really the most appropriate answer in most cases.  After 25 years working with computers I've learned to treat knee-jerk answers with caution.

Me personally, I don't have much use for Amazon S3, Microsoft's Azure, or SalesForce.com.  But that doesn't mean those may be of enormous importance and benefit to others.  That's why I say "it depends".

What's good?

Cloud services offload your infrastructure management overhead.  This includes facility space, utilities, logistics (scheduling the T-1 guy and the phone guy, etc.), hardware purchasing and provisioning, patch management, updates, support teams and call rotation schedules, heating and cooling impacts, backups and disaster recovery, and so on.  Those are some hefty reasons to consider it.  It's like saying: "Hey Microsoft, I can't really handle my own data center and server admins, so I'd like you to handle it for us"

What's bad?

There really is no outright "bad" here.  There are risks, that's a given.  Loss of Internet connectivity is probably the biggest concern for most businesses.  After that would be security, fault tolerance, disaster recovery response time, support responsiveness, flexibility, costs (real vs perceived) and so on.  But another recent risk that only emerged since the acquisition of Drop.io by Facebook is what happens when the service is acquired by a competing business or just goes out of business?  What garantees do you have?

Like I said: You have to educate yourself on not only what the general state of the art is, but what each player brings to the table, as well as what risks are incurred.  Then you need to carefully weigh those risks and compare the real costs, which can be tricky.  You will find that many of the aspects for cost comparison are the same as doing the business case for virtualizing servers and services.  Even if you have no plans to jump on the cloud services wagon, at least educate yourself and map out why you should or should not recommend it for your business.  The executive team will be most impressed that you took the initiative on your own (hey, a little job security never hurts).

Weekend Thought: Do You Still Like Working in IT?

It's a simple question really.  Assuming you EVER really "liked" working in IT, or even if not in a formal IT environment, that you ever liked working with computers and related "technology".  Do you still?  On average (not just today or yesterday), do you still enjoy working in the field of technology as much now as you ever did in the past?

Me?  Not so much.

Why?  In the 1990's, the party-time of IT, things were driven by the technology itself.  The features, the capabilities, the new places to explore and improve upon, those were everywhere.  It was almost a free-for-all as far as finding problems and working out solutions with the tools at hand.  It felt like building a house or rebuilding an old car.  It was yours to conquer.

Today, it's mostly about cost cutting.  The projects aren't really driven by IT people anymore either.  They're being driven by bean-counters.  People in suits, with MBA's and PMP certifications.  People who can spew ITIL, SOX, SOA, and SDLC mantra all day, but can't write a single line of code or install a software product of any real meaning (server-based is what I'm talking about).

In the late 90's and early 2000's, if you asked most IT SysAdmins "is this product/technology something YOU would have chosen?" they would have said "Yes.  I chose it."  Today, most that I have talked with say "No.  It was chosen by someone else and I don't like it.".  Many feel that the technology they are supporting is outdated or inefficient, but they don't have the authority or backing to pursue an alternative.  Even when a proof of concept shows enough promise towards saving time and effort, most SysAdmins don't have time (or sufficient skill) at presenting an MBA-oriented business case to get it over the hump.  To us, the features save time, do more, and free us to do other things.  To the financial departments it's only a matter of how much it will cost to implement (including training and support), and what will it provide in savings and over how long.  The old ROI issue.  However, today it's less about the "R" (return) and more about the up-front cost.

Do you still go into work (or work from home) on weekends or late weeknights?  Is it by your own choosing because you LIKE what you're doing?  Or is it because you HAVE to do it?   Or do you even work into your personal hours?  Are you as driven by the fascination of what you're working with now as you were five or ten years ago?  Or are you driven more by staying employed and getting a paycheck?  If you could choose the technologies you work with, would they be the same as you are already using?

Another Top 10 Essential IT Skills

Brian Posey posted a blog article on Microsoft TechNet called "IT Skills Development: Top 10 Essential IT Skills" which is pretty good.  I don't necessarily agree with his list, even on a purely pragmatic level, but after reading it I got to thinking about a more realistic "Top 10 List" of my own.  However, there is one VERY IMPORTANT aspect that Brian overlooked:  The skills you need are directly associated with [a] the job role you have now, and [b] the job role you are trying to attain.  Because the IT field has become increasingly specialized, the skills are also becoming more specific to each role.  So I'll try to break it down by general roles

PC Technician

1. Master eating spicy foods and consuming lots of beer or Jaegermeister
2. Know your sports teams and league standings
3. Know country or pop / hip-hop music
4. Know at least ten dirty jokes
5. Jeans, Van's shoes, T-shirts that say "There's no place like 127.0.01"

Software Engineer

1. Master your iPod or Zune, etc. (coders rarely talk, they work alone)
2. Learn the latest buzz terms even if you work with 1990's technology
3. Starbucks for breakfast, lunch and maybe dinner
4. Know your alternative musicians and hep TV shows
5. Jeans, flip-flops, T-shirts that say "void main()…"

Systems Engineer / Architect / Analyst

1. Play fantasy football or be fluent about some Pro sports league
2. Put charts and diagrams on every wall (MSDN PDC charts work great)
3. Buy the latest smartphone (DroidX, iPhone4, etc.) and learn enough secret tips to impress your coworkers while you…
4. Go out to lunch almost every day
5. Dockers, Polo shirts, casual dress shoes, sunglasses on top of head even at night.

Department Manager

1. Stock cabinet with Mylanta, Exedrin and Vitamins
2. Learn to appreciate cold coffee (I'm not talking about iced latte's either)
3. Picture frames with family and fishing trips (the kind you'll never go on again)
4. Dying potted plants
5. Dockers, Dress shirts with rolled sleeves and sloppy tie, stained t-shirt underneath

Project Manager

1. Books about PMP trends
2. Framed PMP certs on walls, desk junk also
3. Stacks of useless papers all over the place
4. An inefficient meeting calendar with no time to do anything besides meetings
5. Similar attire to Department Manager on bad days, more like CTO on good days

CTO

1. Sharp dresser, spend a lot on clothing
2. Drive a nice sports car, keep it clean and shiney also
3. Latest smartphone
4. Laugh at all the CIO, and CxO jokes (and know enough semi-dirty jokes for the after-parties)
5. Dockers or Suit.  Hawaiian shirts on Fridays, if you even come in on Fridays

CIO

1. BMW, Lexus, Infinity or Cadillac SUV with golf clubs sticking out the back
2. Picture frames with grandchildren and platoon photos from back in the miliary
3. Sports memorabilia (autographed baseball gloves, footballs, framed photos, etc.)
4. Business Philosophy books on shelves (with plenty of dust on them)
5. Suits, Suits and more Suits

Ok, so these are all 5's, not 10's.  Eh.

Meeting with Autodesk

So, after my initial “rant”, I got a very quick response from Autodesk.  I already blogged and blabbered about that.  Then I followed up with another post a week ago.  Well, today was our first “meeting” by phone and I must say: I’m feeling very positive.

Our first meeting skimmed our list of basically 10-12 issues and dove into just a few of them in more detail.  Tomorrow we are scheduled to do a part 2 and dive a bit deeper.  The folks on the line were fully invested in the conversation, not just pretending.  I know.  I’ve been on both sides of these conversations for years.  I can smell fakeness in seconds.  They are geniunely interested in finding solutions and I’m saying that without having drank a single drop of kool-aid.

The key items on our list we are working on as of today is basically as follows:

1. User Rights: Making all products work without requiring users to have elevated rights, even during the “first launch” of the product following installation.  This applies most to Inventor 2010 (dating back to version 11 though), which prompts the user to register (or “re-register”) on first launch.
2. Installation/Deployment: Address the admin-image installation approach for easier bundling of multiple products.  Either of two solutions will suffice, but preferrably the first solution can be achieved.  The second would be a “plan B”:
   1. Preferred: Update the “setup.exe” to remain memory-resident until all sub-processes complete their work.
   2. Alternate: Provide detailed documentation on how to replicate the install process using the admin-image components (msi/mst, etc.) and the proper order of installation.
3. Shortcuts: Address the issue of desktop and start menu shortcuts reverting to defaults upon “first launch” of the product.  This mostly applies to AutoCAD Mechanical 2010 (since MDT is going away), but even AutoCAD 2010 does this.
4. Internet: Address the issue of products attempting to initate “backdoor” Internet connections during application launch.  User-initiated is fine, but hidden processes are a major badness.
5. Uninstall: Address the uninstall process to suit item 2 above, as well as doing a more thorough job of removing in-use components.
6. Raster Design: Address Raster Design’s integration with other products with respect to menus and profiles.
7. Updates: Address the methodology and standard for delivering updates.  We also suggested creating a client-side manifest as a centralized inventory of all Autodesk updates for improved management capability.

Tomorrow’s meeting should be a good one, based on how today’s meeting went.  I will keep you posted.

Follow-Up on my Autodesk Rant

Soon after posting my rant about Autodesk products and their relationship with (at least certain) “Enterprise” customers, I received a TON of feedback.  Probably the most since I resuscitated my blog some time ago.  All of the feedback was appreciated (except for the rude comments by a few dickheads and spammers) and were overwhelmingly supportive and in agreement. 

But the most important response, for me, came from Eric Stover at Autodesk.  Not that it contained anything tangibly immediate, but that it even happened.  We had voiced our frustrations with our sales/customer rep for months and were basically placated with pats on the back, a tissue, maybe a lullaby to get us back to sleep.  But this was like someone opening a dungeon door and letting in sunlight for the first time in, well, forever.

As of today, we are scheduled for a phone conference with Eric and his staff with myself and my co-workers next week.  It would have been today, but I had vehicle “issues” and missed work running errands to get it fixed.

I wanted to keep this topic “alive”, so as not to give the impression all is resolved and we can already move on.  That hasn’t happened yet.  But I am (we are) hopeful that our upcoming meeting will be positive and productive.  I think Autodesk understands the value and importance, now more than ever, of keeping their customers happy and interested in their products and services.  The economy is putting a fire under all of the players in this industry, and they’re all stepping up to eat each other’s lunch.  So, if you have a relationship with a particular software vendor and you feel they aren’t stepping up to the plate for your needs, AND if you’re paying for support or maintenance, now is the time to bend some arms.  As you can see, it does get a response if you remain honest and focused.  Don’t let emotion overshadow the crux of what you’re concerns are.  Let the concerns speak for themselves.

Foolish Pride + Unused Vendor Support = Failure

Over the years, working both inside and outside of corporate IT environments, one thing I’ve seen way too much of is foolish pride.  It comes in all shapes, colors and sizes, but one in particular is most dangerous.

If you have a product in your environment which underpins a critical part of your company’s business, hopefully it also has paid support on it as well.  The thought of depending on something which impacts and directs the lives of employees (some or all, doesn’t really matter) without some sort of insurance is just flat-out stupid.  It happens, but mostly because someone above the IT food chain is too stupid or lazy to ask why their oxygen tube isn’t protected.  When the breathing stops, heads roll.  Preventive measures are still in fashion.

But it gets worse.  Oh yes.  This is when you have a product in place which the business depends on, along with paid vendor support (maybe even “maintenance” or “subscription”, whatever), but the staff in charge of insuring that it is working (a) properly, (b) reliably and (c) optimally, feel as if asking the vendor for guidance, even a sanity-check, is an admission of weakness or failure.  This is very common.  It’s also dangerously stupid.

If you are a business executive with any oversight or impact on your company’s IT operations, please ask your IT staff some of the following questions once in a while:

1. How often do you contact the vendor?
2. What kinds of questions do you ask them?
3. How would you rate their response?
4. Did you consult the vendor directly during your planning and deployment phase?
5. Have you ever had to contact them during a crisis?
6. Which employees are privy to these vendor interactions?
7. Are all of the interactions documented and shared?
8. What things have you ever changed as a result of vendor guidance?

If you have never thought to ask these questions, in my opinion, you should be replaced.  You are in the wrong job position.  If you have asked these questions but have either been given dodging answers, non-answers or poor answers, the IT staff should be replaced (or severely beaten in the front parking lot).  The business is your patient.  Don’t let the medical staff off with bullshit answers.

So many IT environments I’ve been in (visiting or otherwise) have staff that feels that they can figure out everything they need to know on their own.  Usually through Google, web forums / discussion groups, and some mix of vendor documentation.  But if you’re paying for vendor support, I will bet your next quarterly statement that you’re paying a significant price for that service.  If you’re not using it, you are telling the vendor:

1. We are dumbass idiots who love handing you money to do nothing
2. Since we have money to throw around, we are asking you to pester us to also buy upgrades and new products.
3. We really don’t care if your product is performing well in our environment.
4. We will never know if our implementation is operating at its best.
5. We will never know if our implementation is safe and reliable (but we keep telling ourselves it is, don’t worry)

You’re putting your job at risk.  You’re putting the company at risk.  You’re putting the jobs of other employees at risk.  You’re being stupid.  Nature doesn’t forgive stupid, it kills and eats it.  Humans love stupid.  They worship and celebrate stupid.  They buy logo merchandize to proclaim they love stupid.  But being stupid is one of the worst crimes of business.  Do yourself, your career, your company and your coworkers a huge yet silent favor and pick up the phone and start talking with your vendors.  Who knows, you might actually learn a thing or two.  You can take credit for it.  Nobody at work needs to know you called.  And even if you admit to it, it’s not a sign of weakness.  It’s an indication of taking initiative.  Something Americans seem to have forgotten about.

Hands On. Eyes On. or Blind

Continuing on a little further regarding Troubleshooting, I realized right afterwards that there are different types of troubleshooting:

• Hands On
• Eyes On
• Blind

Hands On – is pretty self-explanatory.  You get to put your physical hands directly on the machines involved with finding and fixing the problem.

Eyes On – is when you can’t put your hands directly on them, but you can either view the troubleshooting process over the shoulder of another person, or you get a decent amount of diagnostic information 2nd hand to investigate the problem.

Blind – this is when you try to help others over the phone or by chat.  You can’t see or touch the machines involved.  You can’t see diagnostic output.  You’re usually making educated guesses, at best, using limited information either spoken verbally or typed into a chat window.

Obviously, these are gradually degrading degrees of effectiveness.  Hands On is the ideal.  Eyes On is what you have to put up with a lot of the time.  Blind is what you try to invent stories to get away from.  “I hear my dog eating a small animal out back, gotta go!…”

Basic Troubleshooting 101

At 45 years, I’m even more amazed now than ever at just how incapable people are at performing basic troubleshooting.  Getting to the root cause of a problem.  Any problem.  While I’m focusing on “technology” for the moment, this applies to LIFE in general.  Every day I see people start to gather information about a problem, and before they finish listening to the whole story, are already diving in to “fix” the problem.

9 times out of 10 they end up not fixing the problem, but rather, they prolong or intensify it.  This drags the problem on longer.  The negative aspects of this are dangerous.  Wasted time is just the beginning.  If you’re a doctor, someone could die.  If you maintain certain kinds of machinery or systems, people could die.  This is serious shit!  If you’re laughing right now: shut the fuck up and pay attention!

Basic Troubleshooting

1. Gather the facts (not the rhetoric, bullshit story, just the facts)
2. Isolate the scope of the problem (how big, how far spread)
3. Compare with something not-broken
4. Look for patterns

Basic IT Troubleshooting

1. Gather the facts
1. Find out what changed
2. Inspect event logs, file logs
3. Eliminate the obvious (cables, power)
4. When did the problem first occur
5. Did it EVER work correctly
2. Isolate the Scope
1. Is it User-Specific (one user affected, others are not)
2. Is it Machine-Specific (all users affected on same computer)
3. Is it Application-specific (one app, or all apps)
4. Is it device-specific (printer, scanner)
5. Is it resource-specific (a particular shared folder)
3. Compare
1. Before and After log results
2. Verify interfaces (ping, browse)
3. Verify user accounts (enabled, locked, group memberships)
4. Verify security settings
5. What differs from this to another? (user, machine, app, device, etc)
4. Look for Patterns
1. Does it happen consistently
2. Does it happen at particular days, hours, weeks
3. Does it coincide with another process
4. What circumstances cause it to occur

Nearly every time someone contacts me for help with something on their computer (and I’m talking about IT “professionals” here, not family, friends and so on), I ask “what do the event logs show?”, and I get the same answer “I haven’t checked yet.”

Here’s a real world example:  User calls in a support request saying their application is “broken and won’t launch anymore”.  Help Desk technician immediately uninstalls and reinstalls the application.  This process normally takes an hour per machine.  But guess what?  The problem returns.  Did they check to see if another user could run that application under their own login?  Did they check to see if the application works on other computers?

In one case, the problem was a license server not responding, so NONE of the applications on ANY computer were working.  Restarting a service fixed the problem.    In another case, the user’s profile had a corrupt registry key (HKCU) and simply deleting the registry key and subkeys forced the application to rebuild the keys and everything worked fine.  In both cases, the “fix” was completely wrong and wasted an hour of time for everyone and accomplished nothing.  Rushing in to fix a problem without being careful to diagnose it first is dangerous. It’s how space shuttles blow up.  It’s how ships run aground.  It’s how patients die.  We all make mistakes, but a mistake is a deviation from a normal pattern of NOT making mistakes.  If you make mistakes all the time, everytime, you need to find another career.

Finally, if you step back and look at your environment and find that you’re fixing the same kinds of problems a lot, that is almost always a clear indication that there wasn’t enough testing performed early on.  Whether it was picking the wrong products or technologies, or not implementing properly, or not training users to use it effectively, or not telling users it was coming (and when), well, somebody screwed up.

Conclusion

Slow down, at least a little, and be sure to gather everything you can about a problem so you can get your mind around it and solve it effectively.  The time you spend up front will usually save twice that on the other end when you try to solve the problem.

Thinstall Support Moves to VMware

EMC/VMware announced that support services for Thinstall (now called ThinApp) have been moved to the VMware Support group. What's odd is that even with this, there's still no selection item for "ThinApp" in the drop-down list for the online KB search. That means, to me at least, that they've only reassigned the phone and email support channels, but none of the support-related documentation content. A little strange, but not unusual for switchovers like this.