It's Not What You Think You Know

There's a sense of inertia in the tech industry that becomes more and more concrete as you rise in the levels of IT hierarchy.  The more technical the person you're talking to, the less flexible they are to change - even if it's changing something to the CORRECT setup.  The old adage of "it's always worked for me before; it should work for me now" should NEVER apply to the technical field, considering the changes that occur daily to every area of support.

This applies doubly for those who are calling in for support on an issue - and even moreso for support on a program or service provided by an entirely different company.  No matter how you might have had a service jury-rigged in the past, there's no way to tell whether those settings will still hold.

And most importantly: when it's determined that you're doing something the wrong way, stop asking how to get it to keep working the wrong way!

Me: Thank you for calling [Company Name]; my name is FerroMancer.  May I ask who I'm speaking with?

Cx: This is Cx with [Another Company].

Me: How can I help you, sir?

Cx: We moved our equipment - clients and servers - to another location, and now we're having trouble connecting through your program.

Not a problem, the program needs to be reconfigured to work on the new location.  Of course, the best way to do this is...

Me: If you uninstall and reinstall the client application from the install point on the server, you'll create the proper pathing to get the client working...

Cx: It was working before, and it's not working now - we should be able to change the settings to get it to work.

Strike 1 - When a tech gives you advice on the program he supports, take it.  

Strike 2 - Don't try to get a failing program to start working again if you can replace it with a working program.

Strike 3 - It was working before, and you changed everything.  What worked before won't necessarily work now.  

Me: OK, what do you have for the physical database name?

Cx: It's showing the server route - "\\DD\COMPSERV\COMPSYS.DB"

Me: OK, that's part of the problem; the program connects to the engine on the server first, so the path that's indicated should be the path as if you were already connected to the server.  What drive is the COMPSERV folder located on on the server?

Cx: I have it mapped to "S".  It's always been mapped there.

Me: No; what drive is it on on the server?

Cx: But I'm on the client.

Me: Right, but you're connecting to the engine before you ask about the path.  What drive on the server?

Cx: Let me check...it's on the F drive.

Me: OK, then you want the path to be: "F:\COMPSERV\COMPSYS.DB"

Cx: It's always worked before, with the other path.

Me: It shouldn't have.  It needs the path in relation to the server itself.  Change the path to "F:\COMPSERV\COMPSYS.DB".

Cx: OK....it's not working.

Me: Did it change the path?

Cx: Yeah, now it's showing "DD\F:\COMPSERV\COMPSYS.DB".

Me: Ah...the system does that sometimes.  Windows takes whatever path it has set for a drive and applies it across the board.  We definitely don't want that, it's in the wrong format anyway.  We need to set it to "F:\COMPSERV\COMPSYS.DB"

Cx: But it was working before.

Me: With the way our program works, this is the way it should be set.

Cx: Why was it working with the other info before?

OK, now this is starting to piss me off.  How am I supposed to know how you managed to MacGuyver your system into working in a way it's not supposed to?  I have no idea.  But I'm telling you; THIS is how it should work, THIS is how you should connect, THIS is the protocol you should be using - TAKE the information and USE it!

Me: It might have had something to do with the network setup or the mapped drives, I'm not sure.  These are the correct settings, though.  Now, are the client and the server on the same subnet?

Cx: They're on a different domain.

Me: From you?  OK, but are they on the same subnet?

Cx: They're on a different domain.

Me: What do you mean?

Cx: I'm remoting in to them.

Me: Oh, so you're not in front of them right now.

Cx: Right.

OK, not a big thing, remote connections are a good way for admins to troubleshoot these days.  However...

Cx: Yeah; I have to remote connect to the client computer, and then remote to the server FROM the client I've remoted to.

THAT is just messed up.  Not only are you going to have a horribly slow remote session (and he was), you've got it set up so that your user can get direct server access.

Me: OK, on the server, go to Start, then Programs, then Comp Solutions, then Administration.

Cx: It's not there.

Me: ...are you sure you're not looking on the client workstation's desktop?

Cx: Nope, I'm on the server.

Congratulations.  You seem to have moved your servers around in such a way that you have entirely lost your administrative tools and server components, even though the base files and folders are still there.  You lose at Tech.

This conversation doesn't even get into the 'discussion' that we had about the proper protocol settings, the IP parameters, client access, or any of the other half-dozen problems that we experienced that could have been resolved by 1) listening to me and just trying to reinstall the app from the server and 2) forgetting how he HAD it working and focusing on how it SHOULD work.  Granted, with the loss of server components, he would have had a deeper problem anyway, but we would have found that out after 5 minutes instead of 20.

The moral of the story is: when you call in for support, you're admitting you don't know everything.  Listen to the person that you're getting help from.