I've had two problems recently and I was looking to buy (hopefully) one piece of software to solve them both...

Problem 1 : The mp4 files output by my Sanyo HD camcorder have the video and audio out of sync with one another when I play them in WMP (which I have to do as QuickTime crashes on every 64 bit machine I've tried it on). I wanted something to convert it to .wmv format that could be played by any windows machine with a default install of WMP.

Problem 2 : I needed to get some of my DVD films into a format (and size) that could be played by my Windows Mobile 6 phone. I thought/think I need something to convert .vob files to .wmv format.

I tried a couple of apps that claimed to do 'any to any' conversion and transcoding - no joy. I then came across Prism Video Convertor which also claimed to do the 'any to any' conversion and transcoding. I downloaded an evaluation copy and set to trying it out with the two cases / problems I needed solved.

Problem 1 - not problem, worked just fine !!
Problem 2 - no joy, blank screen when playing the output file :-(

Searched through the support forums and FAQs, again no joy. By this stage I'm thinking it's probably just me being stupid or choosing the wrong settings/codec/encoder or the like (I don't profess to know much about this technology). I'm excited about the application, it's solved my first problem, just show me the second one working and I'm sold (and I'll rave about it to everyone I know..)

Time for the last resort - open their support page and fill in the form for a support case - enter the details, hit submit, bam "No support contract found, please buy a support contract". The product is around $18, a 'Silver' support contract will cost me another $8, not much, but... I don't want to throw away $8 for them not to fix the problem (it's supposed to be a free trial - right), so I shimmy over to their 'Reasonable Service Terms' (their words not mine)..

Incredulous - the wording, the attitude, the sheer abrasiveness of it all. It made me think that they :-

• Are setting my expectation that I'm unlikely to get a resolution
• Are going to refuse point blank if there is even a chance of it not being their software
• Want me to prove (beyond reasonable doubt) that it's their software at fault before they would even consider helping me.
• Don't want to spend more than 10 minutes on a support case
• Don't really want me as a customer

I am all for setting expectations and outlining boundaries/limits but, in my opinion, this is completely the wrong way to do it.
Certainly as someone who is putting in the effort to trial their software, I do not want to have to pay for the privilege especially when I know it may not even do what I want meaning I may not even buy the application.

You can also bet that when they say...

• It also does not guarantee that they will be able to solve all problems. It means only that they will do their best.

...their definition of 'do their best' will be completely different from mine.

A couple of problems I've come across at work with implementing MSCRM. These could be bugs, or may not be, who knows (I don't have the time for a detailed analysis...)

I have a MSCRM 4.0 multi tenant implementation - I 'disabled' the first (and default) tenant and suddenly all reports (for all tenants started working intermittently - often just hanging time after time). The workaround I found was to re-enable the first tenant.

This same action (disabling the first tenant) also seemed to screw around with the default tenant (the tenant it chooses when you just browse to http://crmserver/)  - just choosing one at random - this is not something I have resolved yet.

Hope this helps someone..

There was a restaurant that I frequented with the family on a weekend for lunch. It is well established, having been in business, successfully for many years. We had always been fans of the place but had noticed recently that business seemed to be declining. This struck me as strange, as the food, atmosphere and service were generally excellent.

Unfortunately, this weekend I found out (I think) the reason behind the decline - they have started ignoring customer feedback...

We spent a couple of hours there this past weekend, having two or three courses and a few drinks. Most meals were excellent, however Sarah's was not quite up to scratch. I mentioned this to the waitress and she duly apologised. I then watched her for a few minutes to see what she did with the information  - and I found she did .. nothing - she didn't let anyone else know, she simply went about her normal business. I then watched a similar event (different waitress) happen at another table, again the feedback from the customer went nowhere.

Later when the bill arrived, it was as though there was nothing wrong, I had a genuine complaint / dissatisfaction of their service and they had hardly even acknowledged it. This just made strengthened resolve to make my point / complaint heard.
I made a point of telling the waitress whom I was paying that I was not happy about paying for the meal that was not up to scratch, she called over the manager who very grudgingly discounted the price of that particular meal.

It struck me that their new policy seemed to be for the waitresses to apologise to any customers who complained but to do nothing else, not to inform the kitchen staff, not to offer any discount or similar gesture - basically, blindly ignore it and make it difficult for the customer to get any sort of recompense.
The reason for this approach seemed to be that they would not have to discount the meals / service (and therefore supposedly make more profit .. ??). This got me thinking of some ISPs and utility companies that I know who make complaining such a complex and involved process in the hope that the customer simply gives up.

For the sake of £6.95 (on a £60 odd bill) that restaurant lost :-

• A tip (around the same value as the discounted meal)
• A lot of goodwill from a party of 5 who frequent the place 3 or 4 times a month.
• The custom of a party of 5 who frequent the place 3 or 4 times a month.
• The opportunity to improve their service
• The opportunity to prevent the same thing from happening to other customers.

Doesn't seem like good business sense to me.

For anyone providing businesses or consumers with any kind of product or service - your customers know best, ignore them at your peril.
These are the people buying your stuff, they know what they like about your stuff and what they don't like about it. Their opinion (good or bad !!) is incredibly valuable.
But hey, maybe you're right - maybe you do know better than your customers... 

This is something that is close to my heart..

Not setting correct expectations - I believe this is the downfall of many organizations and individuals. If you set an expectation and do not deliver then you have failed, simple as that. Doing it regularly it gets you a bad name, people are reluctant to work with you and in some cases can get you fired.

I think the reason most people fall into this miss-setting expectations trap is a fear of saying 'no'. It's not that difficult, I have never met (a reasonable) person yet who has baulked at the idea of "I can't do it in that timescale unless we let something else drop". Most people would rather have an accurate expectation than something that agreed to just to appease them and then not delivered upon.

Why am I writing this post - well, this just popped into my mind when I was researching something for work. I wanted some technical information and it was one of those annoying companies who put up barriers to their customers being successful like not providing someone to speak about presales issue to, only providing email support, the type of companies that you know have no dedicated support and are abusing their developers into handling support issues, or have a vastly understaffed team (one overworked, stressed out, on the edge, guy) and are trying to manage the volume effectively...

Anyway, I filled out their web form asking my question, got the (usually) 'Submit' button and found this...

Wow, Help Me Now, now I have very high expectations - well, actually, based on experience I don't, but they are trying to say 'hey, we want to help YOU RIGHT NOW, THIS INSTANCE, NOT TOMORROW, TODAY, THIS MINUTE'.

On submit I get...

Awwww - now I'm sad. Such high hopes I had, for my dedicated cross functional team of support ninjas, waiting with bated breath to solve my problem. Still, maybe they'll call me tomorrow sometime, or whenever the next business day is...

The company I work for (C2C) are hiring.

We are looking for Technical Support Engineers to work in our Reading, UK office.

We'll consider any experience level as long as the individuals show commitment, determination to learn / succeed and have a passion for technology.

You might be right out of school / college, looking for your first step into an IT career, you might be an Exchange expert with many years of experience.
We can promise variety, leading edge technology, in depth technical problems to investigate and input into the product direction.

Want to apply ?, email us at hr@c2c.com

We had a customer issue yesterday that manifested itself as the user getting a HTTP 401 error when trying to connect to a Website (that is part of our Product).

The user was logged into the domain, the virtual directory was set for 'Windows Integrated Authentication' so they should have been able to connect no problem.

After so investigation we opened the IIS logs and found that the substatus code was 2 (HTTP Error 401.2 - Access denied by server configuration). A bit of searching around the Microsoft KB unearthed this article:

Troubleshooting HTTP 401 errors in IIS

Common reasons

• No authentication protocol (including anonymous) is selected in IIS. At least one authentication type must be selected. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

253667 (http://support.microsoft.com/kb/253667/) Error message: HTTP 401.2 - Unauthorized: Logon failed due to server configuration with no authentication

• Only Integrated authentication is enabled, and an older, non-Internet Explorer client browser tries to access the site. This happens because the client browser cannot perform Integrated authentication. To resolve this problem, use one of the following methods:

• Configure IIS to accept Basic authentication. This should only occur over SSL for security purposes.

• Use a client browser that can perform Integrated authentication. Internet Explorer and new versions of Netscape Navigator and Mozilla Firefox can perform Integrated authentication.

• Integrated authentication is through a proxy. This happens because the proxy doesn't maintain the NTLM-authenticated connection and thus sends an anonymous request from the client to the server. Options to resolve this problem are as follows:

• Configure IIS to accept Basic authentication. This should only occur over SSL for security purposes.

• Don't use a proxy.

Turns out our customer was using a Proxy Server - adding the FQDN of our Website component to the proxy exclusions list solved the problem.

At work, we use SupportSuite for support case tracking. This is a real neat product but the support is dreadful.

I was running version 3.0.0.80 and there are a few problems with it, they recently announced version 3.1.40. I set up a testing copy and tried an upgrade - no joy, 404 page after about 0.00065353 nanoseconds, spent ages trying to resolve and / or get an answer out of Kayako but nothing.

I did like the look of the new version and it solved a number of small but annoying issues we were seeing, so I implemented it in parallel (on port 81) to our current system, we had it all configured, ported across all the Knowledgebase data (Import / Export from the app), ported across all the user accounts (manual DB table hacking) and basically got everything ready for the 'big bang' migration.

Anyway I decided the big bang migration should happen this morning (Friday is typically a quiet day) - I had everyone port their own cases across, put links from the old case to the new case and links from the new case to the old case.

Next step was to move the old system to port 8080 and the new system from port 81 to port 80. Here's what happened :-

• Changed the website ports (in IIS) so that the old system uses port 8080 and the new system uses port 80
• Modified the settings (stored in the mySQL database) to ensure the URL was correct (i.e. removed :81 from the end of the URL)
• Cleared the SupportSuite cache
• IISRESET
• Closed all the browser sessions.
• Opened a browser and browsed to the new site - horrible page with no images and bad formatting.
• Ctrl F5 to refresh the browser again - same detail
• Delete all the temporary files from IE followed by another Ctrl F5 - same detail
• Examine the properties of the images that were not loading - they are still pointing to port 81
• Ramp up my sense of urgency as we have now been off air for about 30 minutes.
• Browse the mySQL database and spot a settingcache table - run a SELECT * FROM settingscache WHERE data LIKE '%:81%'
• AH !! find the row with the cached URL - change the URL and UPDATE, on to a winner here...
• Ctrl F5 - gets a message stating that SupportSuite is not found and I should run setup again - !!WHAT!!
• Look at the settingscache table again - AH !! there is a 'hash' field - Stumped !!
• Change the new system back to port 81
• Added a new website on port 80 with a permanent redirect to port 81…
• Opened port 81 through our firewall...
• Fixed !! At last !!!

It seems the settingscache table is built the very first time the web app runs and then is NEVER updated EVER.

It's working now but I hate leaving niggly issues like this (needing both port 80 and 81 to function correctly) - further investigation on Monday, but if this is a real bug then given my experience with Kayako to date I expect the easiest route will be to configure it on another server (ON PORT 80 !!) and then move it across...

So this is blatant plagiarism of The Joel Test...

This is specifically targeted at Technical Support organizations, or anyone providing support for a technical product or service.

1. Do you have a fault / issue tracking application (extra point for providing customers access to it).
2. Do you have a knowledgebase (extra point for providing customers access to it).
3. Do your technical folks have a working, test/demo version of the product.
4. Do you send out support alerts (do you announce bug fixes / patches).
5. Do you have remote access to customer machines.
6. Do you have a published, well known case escalation process.
7. Do you have a published, well known priority / severity level list with an example of each level.
8. Do you get candidates to troubleshoot during the interview.
9. Do you have handsfree headsets, conference phones.
10. Do you have a published SLA (or similar set of customer expectations)
11. Do you have a published, well known and measured SLA with the team(s) you escalate to.
12. Can a support engineer easily determine if a customer has a maintenance agreement or not (if appropriate)

I had also considered adding 'Do you require that every case closed is linked to a KB article' but some people find this a bit extreme. I find it is a great driver for keeping your KB up to date and living, otherwise it ages and becomes obsolete very quickly - there's no point having it if it contains outdate / useless information and your customers are not using it.

This is the forth (and last for the moment) article on Writing Supportable Software, helping all those customers and support engineers work with our software products and troubleshoot them themselves (i.e. going as far as possible down the troubleshoot path before referring it back to you).

You can the first article here...
and the second article here...
and the third article here...

This final article is all about paranoia and the fact that customers (as much as we love them, and need them to pay our salaries) are not to be trusted one little bit...

We've all been there, troubleshooting a problem, ask the customer what parameter X is set to, go off down a whole path of investigation, find nothing, scratch our head, check parameter X for ourselves and find it's set to something different (and the whole problem resolution falls into place).

It's not that customer purposely try to be difficult, simply that they don't know the system / software as well as you do - quickfire questions about the Primary Master Lookup Port and the Lookup Master Access Port get them all confused - they're probably under pressure for their boss to get it fixed, they've tried a whole load of things, the last time they looked it was set to 5465ABBG_Master but in the confusion they forgot they changed it to Lets_Just_Try_This_Option.

They best way to determine what variable / options / configuration your system is using, is to write it out to a trace file, on start up, before a processing run, before you use it (whenever is appropriate - and that means, if it could have been changed between now and last time we wrote it to the log then write it again)

If ever there has been a thing that wastes the time of support people it is working on the assumption that, the value the customer told them it was set to was the actual value that it was set to.

This is the third article on Writing Supportable Software, helping all those customers and support engineers work with our software products and troubleshoot them themselves (i.e. going as far as possible down the troubleshoot path before referring it back to you).

You can the first article here...
and the second article here...

This article is all about identifying when and how you are using external systems and services. Most enterprise application work with external technologies or services, for example the company I work for (C2C) build applications that work with Microsoft Exchange Server, maybe you consume a particular web service or make LDAP calls.
Whilst you can reasonably expect the customer to provide a stable working environment for your system / software, life is not always that rosy. I've worked with Enterprise systems that have been dependant on SQL Server, Exchange, LDAP, Web Services, VoIP gateways and many other systems...

For experience, there is nothing that irks a customer more than a vendor who points the finger blindly at some part of the environment or system infrastructure. As a support guy for a vendor you have to take the pain and go that extra mile to hold the customers hand and demonstrate how / why / where the environment is going wrong.
Developers can make this considerably easier by identifying (in a log file or the like) exactly what services your calling out to - and how long it's taking.

I can't tell you how many times I've been troubleshooting an issue only to eventually end up some service the software was expecting to just work was not just working - but that's only half the battle, when you've found that you then need to demonstrate to the customer that it's the service that is not working (and if it was working then your system would be working also)

A great example of this is customers have some kind of screwed up AD implementation, so we'll make a LDAP call thinking it's going to the local DC but in reality it finding some old dusty DC in Alaska on the end of a Dial Up connection and it will time out. Another would be a system making calls to a SQL server but the machine making the calls cannot connect to the SQL Server, maybe because there is a firewall inbetween (and the SQL network port 1433 ?? is locked down)

So, when writing your code, identify these external service and provide the verbosity in your log files or your application status screen that allow the support engineers to determine which services are failing (and to demonstrate the fact to the customer)

I haven't even touched on how often we find that our systems / software stops working, customer calls and you spend hours troubleshooting only to find that the customer took a service offline, or decommissioned a server, or added a firewall - you get the idea...

This is the second article on Writing Supportable Software, helping all those customers and support engineers work with our software products and troubleshoot them themselves (i.e. going as far as possible down the troubleshoot path before referring it back to you).

You can the first article here...

This article is all about what you do (what you make your software do) when it fails. So, we all know that software has bugs from time to time, one of the keys to making it Supportable is providing a clean option of recovery from any error / bug / crash...

This is all about thinking in manner of two stage commits. So for a two stage commit system you fire off all the individual components of a transaction, they all report back that they completed successfully and then you do the final commit of the whole thing...

Using two stage commits for all the data moving, updating of entities is essential in building supportable software and for general customer satisfaction.

I worked with an application once that wrote (a lot of) data to the file system (tens of gigabytes per process run). The original design was to stage files in the same folder that we stored the data long term and we had no effective way of doing two stage commits - the result was that when a process run failed we left the part processed data files in the long term storage folder along with all the correctly processed data - all the filenames were of a similar format so it was hugely difficult for the customer or support guys to filter out that part processed data and remove it - what's worse is that we would reprocess the unfinished process run, if it failed again then there would be another set of part processed files with the same data in it - etc etc...

The end result of this was lots of spurious, part processed data files on the customers system, taking up hundreds of gigabytes of disk space and we couldn't clear it out.

When I noticed this, I had the dev team change it to a two stage commit process (preventing it happening again) and had to write a trawler application to go back in and clean up the part processed files.

That is just one example, the general idea is to make sure that any failures / back outs / crashes clean up in an intelligent way or that the part processed data is stored / tagged in such a way as to be easily identifiable and 'cleanable' by your support guys or the customer themselves.

At work (C2C) I'm responsible for the development team and the technical support team and it proves to be a surprisingly difficult task maintaining a balance between their respective objectives - the two extremes are :

• Support has little or no contact with development, bug escalations are done in a very formal way and the overall drive is to ensure development are not distracted by support work.
• Support has unhindered access to development, can draw on their expertise / knowledge whenever they like, the overall drive being to have happy customers (via quick and accurate resolutions)

Neither of these work well in a business - with the first you sacrifice customer satisfaction for development productivity and in the second it's the other way around... The key is finding the balance, but it's tough finding that balance, and there is no one answer or simple formula - it depends on many factors where (between the two extremes) you find the balance (product quality, support team knowledge, customer expectations etc)

One thing that helps is getting the development team is to write Supportable Software - this means developing it in such a way that we maximize the troubleshooting efforts that can be carried out before it has to be escalated to the development team. There are a number of facets to this, I had initially planned to cover them in one article but when I started, it became apparent that there was too much for one article and it should probably be split into each key area in it's own article.

The first area (topic for this article) is Tracing / Logging for Maximum Effect

Let's kick right off with an example - consider the following trace file output :

10/10/2006 12:34:56.987 LDAP lookup failed with result = -214756544

Yes it tells you exactly what went wrong. A support engineer reading that can clearly see there is a problem with LDAP but nothing else. So what's his next step ? -  escalate the case to the development team.

Compare that to :

10/10/2006 12:34:56.987 LDAP lookup (' CN=Ken Hughes,DC=c2c,DC=com') to uk.c2c.com failed result = -214756544

A support engineer reading that line can now check :

• The server uk.c2c.com is up and working
• Using LDP run the same query and check the results

Maybe the server was down, maybe the query works if the user is logged as an Administrator but not as the account running the software - there is a whole avenue of additional troubleshooting that the support engineer can investigate simply because the trace file was a little more verbose...

 This is true many different areas :-

• Web Services - don't just say it failed, tell the user what URL was being used - support guy can check out the web server and DNS resolution
• SQL stuff - it's probably apparent which server your going to, but what about tracing out the SPROC your using or the SQL query string itself (especially if it's dynamically generated in code)
• Remoting / DCOM - Why settle for CoCreateInstance failed when you could specify the destination server and the class your trying to create

We could all think of more, but the general idea is - make the tracing sufficiently verbose as to allow engineers to investigate why the error occurred. If your using external or third party services (DNS lookups, LDAP, SQL, Exchange, WebServices, DCOM etc etc) then give the details of where your going to and the parameters your using.

Bear in mind that as a developer, if your tracing out magic numbers or sparse data that only really make sense to you, then when someone sees it in a trace file it's coming straight back to you.... 

I have been looking at how to make improvements (in productivity) in our technical support team recently.
One of the 'tick list' items I always put on job Descriptions (when advertising) is "Must have a logical and methodical approach to troubleshooting technical problems". I went right back to basics and thought about 'how do I define / measure this and what, in fact, is a logical and methodical approach ?'

Heres what I came up with (at a high level) :

Step 1 - Determine who is reporting the problem.
This is gathering the contact information (email, phone, name, company, preferred method of contact etc) of the person reporting the problem to you. It has to be the first step - if the call drops mid way then you need to know who to call back, when troubleshooting you need to know who to communicate the troubleshooting steps / workarounds / resolutions to.

Step 2 - Determine the nature of the problem.
This is gathering the context information - what product is it, what they are trying to achieve, what they are seeing that they believe is incorrect functionality and what they are expecting to see (the users understanding of the problem).

Step 3 - Gather the supporting evidence.
This is where you get log files, screenshots etc. - i.e. the supporting evidence that allows you to troubleshoot in more detail / see exactly what the product was doing at the time of failure. Usually, the best way to do this is to enable whatever logging your software / system has and have the user / customer carry out the steps which result in the (perceived) failure. If it's reproducable then that is half the battle... I also suggest that you ask for screenshots as they are good solid evidence and nothing is lost in the communication "Oh, I get an error message about DCOM or something", or "The screen goes a funny color" - much better to have the a screenshot of the actual message / action that is happening. Of course the problem may be so obvious that you can already reproduce it without the need for support evidence - if so, then great, no need to bother the customer to get the supporting evidence, gather it yourself (ALL your support people have immediate access to a demo/lab system - right !!).

Step 4 - Outline the next actions.
TELL THE USER / CUSTOMER WHAT TO EXPECT NEXT. If you can commit to timescales, even better !! - but at a minimum let them know what the next steps are "As soon as I get the trace file from you, I will review it and get back to you, it is likely to be this afternoon sometime, what is the best number to get you on this afternoon".

This is at a very high level, obviously in a real world scenario the above steps are all interspersed with process steps related to your own systems / infrastructure / policies etc (for example, checking the customer has a valid maintenance contract, opening a ticket in the fault tracking application)

I logged a feature enhancement to allow the KB article RSS feed to include articles from ALL categories.

This was set as a LOW PRIORIY by Kayako, but is a high priority for me - nothing else for it, I had to fix it myself.....
Here's how I added the feature to enter 0 as the category id in the RSS feed url to provide articles from ALL categories.

Edit /modules/knowledgebase/functions_clientkb.php

Change Line 167 from :
if ($key == $kbcategoryid)

To :
if (($key == $kbcategoryid) || ($kbcategoryid == 0))

The url for the feed includes the category id for the artciles you want to see. Enter a category id of 0 to return ALL articles :

http://[your_domain]/rss/index.php?_m=knowledgebase&_a=view&kbcategoryid=0

Link to the post I entered on the Kayako forums

I have been in my current role for almost 12 months now (Technical Director for C2C Systems). During this time I have refocused the support group from being Application Support people to Technical Support people.
So, what does this mean and why did I do it...

Basically, I view Application Support as helping by telling customers what buttons to press to achieve XXX, and Technical Support as understanding the actual technologies involved, so when something doesn't work they know what areas to probe / test / configure.

We have been through a lot of knowledge sharing (within support and with development), improved (immensely) the level and text of log file tracing in our products so that problems do not automatically have to go to the development team for investigation. Now there are more technology / area messages in the log files the support folks can do considerably more troubleshooting of the technology areas to find the issue without involving the development team (letting them focus their energies on coding !!).

My reasoning behind this is two fold. Firstly it means the Support team can now add significantly more value. Secondly it' better for the Support folks, they are typical techies and much prefer solving the issues themselves (if they can), learning more about the product and technologies and ultimately improving customer satisfaction.

Blank entry, simply to list out the categories.