When Tech Support.... Isn't.
Mar. 17th, 2009 02:16 pmI'm a network consultant. Part of my job is to deal with the third-party vendors so that the client doesn't have to, and so that they can't screw my client by railroading them into "solutions" that the client doesn't need, or that won't fix the problem, but that will cost my client money that they don't need to spend.
These are my tales. Well, one of them.
So, after a migration from Windows 2003 SBS to Windows 2008 SBS (and no, we're not even going to go into THAT), my client's application database would no longer open up. After a bit of troubleshooting, determined that the application was timing out when someone tried to open it up from a workstation, but that the application would open just fine on the host machine. I was pretty sure that the issue didn't have anything to do with the migration, since while the host machine was part of the domain (and had been migrated), it didn't rely on anything on any other workstation or server to run. The shortcut points to the executable on the host machine, the host machine holds the database. Checked to make sure that the Windows Firewall wasn't causing problems (by making sure that the service was disabled on both the hostmachine and the workstation, and once I confirmed that, I called the application support line and got them involved.
Two hours (and two Web-Ex sessions) later, they told me that the problem was that the version of SQL on the host machine needed to be patched, and that the application would likely have to be migrated to a new machine. Which (of course) would cost money, and more money because it would have to be done on an emergency basis.
After their troubleshooting session was over and as they were delivering this information to me, something that they said clicked a relay in my head. I went back and looked. The shortcut that was in place used UNC pathing to point to the shortcut, so "\\hostmachine\sharename\applicationname.exe" Pretty straightforward, right? On a hunch, I mapped a drive on the workstation to the application folder on the hostmachine, created a new shortcut that pointed through the drive mapping, and... Bingo! Application opened up without a hitch. Tested on a few other machines and confirmed the fix.
Called the application support people back and left them a message saying that we'd resolved the issue. And spent the next few minutes amused as hell that they spent two hours on the problem, and then gave me a completely bullsh*t "fix" that they admitted might not work, and used that to try and push for a migration that they would be able to charge my client money for.
These are my tales. Well, one of them.
So, after a migration from Windows 2003 SBS to Windows 2008 SBS (and no, we're not even going to go into THAT), my client's application database would no longer open up. After a bit of troubleshooting, determined that the application was timing out when someone tried to open it up from a workstation, but that the application would open just fine on the host machine. I was pretty sure that the issue didn't have anything to do with the migration, since while the host machine was part of the domain (and had been migrated), it didn't rely on anything on any other workstation or server to run. The shortcut points to the executable on the host machine, the host machine holds the database. Checked to make sure that the Windows Firewall wasn't causing problems (by making sure that the service was disabled on both the hostmachine and the workstation, and once I confirmed that, I called the application support line and got them involved.
Two hours (and two Web-Ex sessions) later, they told me that the problem was that the version of SQL on the host machine needed to be patched, and that the application would likely have to be migrated to a new machine. Which (of course) would cost money, and more money because it would have to be done on an emergency basis.
After their troubleshooting session was over and as they were delivering this information to me, something that they said clicked a relay in my head. I went back and looked. The shortcut that was in place used UNC pathing to point to the shortcut, so "\\hostmachine\sharename\applicationname.exe" Pretty straightforward, right? On a hunch, I mapped a drive on the workstation to the application folder on the hostmachine, created a new shortcut that pointed through the drive mapping, and... Bingo! Application opened up without a hitch. Tested on a few other machines and confirmed the fix.
Called the application support people back and left them a message saying that we'd resolved the issue. And spent the next few minutes amused as hell that they spent two hours on the problem, and then gave me a completely bullsh*t "fix" that they admitted might not work, and used that to try and push for a migration that they would be able to charge my client money for.
no subject
Date: 2009-03-17 08:20 pm (UTC)no subject
Date: 2009-03-17 08:50 pm (UTC)no subject
Date: 2009-03-17 09:46 pm (UTC)no subject
Date: 2009-03-17 10:26 pm (UTC)no subject
Date: 2009-03-17 10:36 pm (UTC)If they ported it, then there'd be a chance, match up system calls and set it up for the filesystem.
Hell, A good chunk of the work has been done before with things such as cygwin
Its late and I've not worked with that sort of thing for a while, but think thats all the major bits.
no subject
Date: 2009-03-18 03:27 am (UTC)no subject
Date: 2009-03-18 03:55 am (UTC)Its 4am, but i'm sure there's more i've wanted to do.
I run cygwin on almost all my windows systems, makes working with files in bulk a hell of a lot easier.
no subject
Date: 2009-03-17 10:37 pm (UTC)no subject
Date: 2009-03-17 09:14 pm (UTC)At least they admitted it might not work. I've had vendors that insist you have to do something like that suggestion before they'll even look at the problem.
Which is something that affects techs on both sides, of course.
no subject
Date: 2009-03-17 09:26 pm (UTC)It's actually a version of SQL for Windows Desktop, and a very old version at that. When they first installed the application, we agreed that I would support the OS and hardware, and that they would provide all support for SQL and the application. They've never upgraded or patched any part of SQL or the application except when we requested an upgrade to the application 6 months ago, and they didn't upgrade or patch the SQL installation that it was running.
Unfortunately, the application was supposed to synchronize with Exchange, and the process that they used to do that caused the SBS to fail to restart until we disabled the synchronization process. I worked with the vendor's support staff for a while to find a resolution, with no luck. That was the first time that they failed to impress me.
They're still pushing my client to upgrade, and I've already told her that they don't impress me with their skills, and that at the very least I'd like some time to put the new SBS through a shakedown before we start making other significant changes to the network. She's onboard with that, but she'd really like to get the synchronization with Exchange working, which they claim that they've fixed. I'm... understandably untrusting of their claims.
no subject
Date: 2009-03-18 01:17 am (UTC)And why do I wonder if Marketing asked this question last year?
no subject
Date: 2009-03-18 01:59 am (UTC)Goldmine?
no subject
Date: 2009-03-18 02:02 am (UTC)Soldier on...