how-to document

So, one of the companies I work with (contracted), emailed me the other week saying they needed help with some specific aspect of their software. I manage their server, not the software on it, so I got a message to them saying that I don't know the software they're talking about and to contact the support personnel for that software, since it's very specific.

They did and word got back to me that the Tech support from that company wanted access to the server to debug the issue. Okay, not a problem. but that was two weeks ago.

Just today, I was told WHAT access the agent needed. Though the information was ambiguous at best, I made my best estimate on what permissions he needed and setup his accounts.

Now the hard part.

Part of the issue they're experiencing (from what I understand) is that they can't seem to install the client software on a few computers and get it to work... This has been a major problem in the past and we've had to overcome many obstacles with this software because it's so specific.

Some of these obstacles include:

Region settings. - if the Operating system that's running the software is set to any region other than "united states" then, when the client verifies the version with the server, the server will reject it as a version mismatch, since the release date of the software is included with the version number stamp sent to the server.

The error emanates from the fact that the US puts the Day Month and Year in a specific order that no one else seems to use... this is a problem because the company that I work for is Canadian, so some of the systems they use are set to Region "Canada (English)", which formats the date wrong (resulting in a mismatch).

UAC - User Account Control doesn't function correctly when giving permissions to the update installer. So updates always fail when run in user-mode. You have to start the application as an Administrator and log in to receive the updates...

Address - For some reason the software always sets the default server address to "localhost" which is obviously false, and it gives an error every time it's launched. This needs to be changed to the IP address of the server.

ADDITIONALLY, when the client connects, it then needs to access the database, which can be an independent address. So when that attempts to connect, and fails, throws another error that the database server is not "localhost" (which then needs to be changed to the correct IP)

ALSO! The Addressing settings are independent by user, so running the software as an administrator, the software will 'forget' the addressing settings when re-run in user-mode, or when run as a different user on the same machine.

We determined all of these flaws the first few times we installed the software, and by "we" I mean, myself and the couple of other guys who WERE employed by the company (now not), and were working on the project... They new the workarounds but now they're no longer working on the project, so everyone turns to the contracted worker.

It doesn't work and I set it up... therefore I must have done something wrong because it's not straight forward to expand the system... Nope. You did something wrong by firing the only workers that knew anything about the system, then you blame everyone else for not having the knowledge.

So! I wrote a very long email, and included pictures (everyone loves pictures!) to send off to the relevant parties that are now on the project... these, must less technical people than the last bunch, are not very skilled and simply don't have the necessary knowledge of the computer systems they use to really do much debugging, and/or trials. if it doesn't work in an obvious way, they're probably not going to get it to work... at least, when it comes to software.

Oh well, now I have to go do some billing...