Background

We use Kayako Support Suite for our support helpdesk over at Bluethunder and while it is an awesome product, and generally considered the best of its kind on the market, it is not without its issues. I have discovered quite a few bugs in the years  we have been using it and have been surprised that they could have existed so long and not been noticed by others as they were real show stoppers, as a result I have come to the conclusion that most other companies using this product must use it in a very simple way and do not use as many of the cool and useful features of this product as we do, this feeling is backed up by the fact that the Kayako community forums are also no help either.

The other BIG issue is Kayako's support, which is frustrating to put it kindly. They regularly give incorrect advise as the support staff do not really know how their own product works which results in your being told something is not possible when it is, or being given a solution which may screw up your whole system and lose emails. I regularly end up having to explain how their product works in order to prove that the advise given is wrong, if you are lucky this will then result in your ticket being escalated to a senior staff member or developer. This is no doubt partly due to the fact that they are an Indian company, and so there are some communication issues as well, which most people have likely experienced these days with so many companies out sourcing their support and customer service to India it is an experience hard to avoid.

As a result I have decided to add this new category to my blog and start posting hints and tips for using Kayako SupportSuite and solving issues.

The BCC Problem

We recently migrated to a new installation of SupportSuite and have had a few issues with things not working how they did before, which is most cases has been down to the mail server. One of these issues was that the automated emails form our control panel were no longer arriving in the ticket system.

Checking the parser log I found the reason:-

"Result: No assigned queues found for mail recipients".

Now the reason for this is actually valid, when the control panel sends out emails to customers it BCC's them us, and when you do this the BCC address is removed by the receiving mail server for privacy as this is the whole point in a BCC, so that the other recipients addresses cannot be seen.

But the odd thing is that it worked fine on the old system, so I opened a ticket with Kayako.

The answer I got from them was that BCC emails will not work as the parser will only look at the TO address and that I must setup a catch-all rule to allow ALL/ANY email into the system.

Clearly I knew their answer was not true and the solution was of course not viable as it would make the whole system unusable and override all our existing settings and rules and allow every bit of spam into the ticket system.

So I sent a test email BCC'd to each system and checked the parser log to see the difference between them both.

What I noticed was on the old system a "X-Rcpt-To: " header was added to the email by the mail server (Mdaemon) which is populated with the final destination address, and obviously the parser was picking this up and putting the email into the correct queue.

On the new system the email had far less headers and did not have any "X-Rcpt-To: ", instead it had a "Delivered-To:" header created by the mail server (HMail) so obviously the parser did not look for this header and thus why it failed.

With a bit of coercion Kayako support finally accepted and agreed with my findings and came to the same conclusion.

The Solution

The best solution would be to use a mail server that creates the "X-Rcpt-To: " header, but this is probably not a satisfactory solution for many, and not for us either.

So the work around is to make sure that the BCC emails are always sent from a specific address and to create a catch-all rule that will accept all emails from that address and put them into the desired queue. Now obviously you need to make sure the address used is not a public address or a common address that is generally targeted by spammers otherwise you will get bucket loads of spam.

The catch all rule looks like this.

/something\@yourdomain\.com/

I have suggested to kayako that they update their parser to look at *ALL* the headers for the queue addresses, which would resolve this issue on any mail servers that create a header for the destination address.

My ADSL router stopped working today (or so I thought) and I wasted an entire day trying to get 2 different routers working only to discover the problem was actually the power adaptor.

The bizarre thing was that the routers actually seemed to be working, they had power and the lights were on, so the power adaptor is the last thing I considered as I would expect the router to not even turn on if the adaptor was screwed. I am  sure that this must have happened to a lot of people who have must have simply assumed the router was screwed and gone out and bought a new one when they didn't need to, so hopefully this may save a few people some money if they read this.

Symptoms

Netgear DG834G v4.
I lost all connection to the router, I could not ping it or access the interface, it was not assigning IP addresses and was effectively useless. When trying to do a factoring reset by holding in the reset button the power light would flash green and red and would not reset.

Netgear DG834 v2.

Everything was working on this one, DCHP was assigning IP's, I could access the interface, I could reset and do everything, however it would not connect to the internet. The Internet light would go green for a few seconds and the router status would show it as connected for those few seconds, then the light would flash orange and the status would show disconnected.

I had some vague recollection of an adaptor issue in the past causing something similar to the latter, but sadly I have no other adaptors in the office with the same voltage output, so my only option was indeed to go out and buy a new router. So I bought a top of the range Netgear dual band 8.11b/g/n QOS router for £99 from pc world. which allows you to give priority to certain services/ports or mach addresses, which is great if you use VOIP as we do which generally requires you to not be doing any other up/downloading at the same time, but using this it will give priority to my VOIP phone.

I Got it back to the office, and then used the new adaptor (same voltage) to test the other 2 routers, and they both worked perfectly.

I am rather kicking myself now as when I originally went home to find my spare router I threw out 3 old sky broadband routers at the same time as they are useless, but I bet they probably had suitable adaptors as I believe they are made by Netgear and I also remembered I have a whole box of old adaptors in the garage that I have been refusing to throw away in case I need them one day LOL.

There is a wordpress plugin for GetSatisfaction but is flaky and unreliable and hard to get working, you have to install pear and XML library's, it is a pain, but there is no need to go through all this, inserting the widget into your site is easy peasy. As so many people seem to be having trouble with the plugin I thought I would post this.

Just open up the header.php for your theme (e.g. <wordpress home>\wp-content\themes\<theme name>\header.php).

Or you may be able to do it from your WP Admin from Appearance -> Editor -> select theme -> select header.php

But this did not work for me as hitting the UPDATE button did not actually save anything.

And right after the body tag insert the widget code. Boom your done.

<body id="<?php echo strtolower(date('M'));?>" <?php body_class();?>> 

<script type="text/javascript" charset="utf-8">

  var is_ssl = ("https:" == document.location.protocol);

  var asset_host = is_ssl ? "https://s3.amazonaws.com/getsatisfaction.com/" : "http://s3.amazonaws.com/getsatisfaction.com/";

  document.write(unescape("%3Cscript src='" + asset_host + "javascripts/feedback-v2.js' type='text/javascript'%3E%3C/script%3E"));

</script> 

<script type="text/javascript" charset="utf-8">

  var feedback_widget_options = {}; 

  feedback_widget_options.display = "overlay";

  feedback_widget_options.company = "acme";

  feedback_widget_options.placement = "left";

  feedback_widget_options.color = "#222";

  feedback_widget_options.style = "idea"; 

  var feedback_widget = new GSFN.feedback_widget(feedback_widget_options);

</script>

I have recently been deploying a few wordpress sites, and I have to say that while I am not really a fan of PHP I love Wordpress. I always thought it was just a blogging tool, but it is so much more, a web site builder, a CMS, an online store, you name it Wordpress can do it, and if it can't there is a plug-in to make it do what you want.

One thing you will find after installing on IIS is that the permalinks do not work, and if you Google this problem you will find all kinds of complex solutions from creating custom 404 error handlers to using URL rewriters like ISAPI Rewrite and changing code in the core files. But guess what, you don't need any of this, the solution is in fact really simple.

On the permalinks page, choose the "custom" option and simply create your desired permalink and DO NOT put a trailing slash, e.g.

/index.php/%year%/%monthnum%/%postname%

Yep that's it, nothing else required. I have tested this on IIS 6 and IIS 7 with Wordpress 3.0 and 3.0.1, whether earlier versions of Wordpress will work I do not know so don't ask.

The only thing you should need url rewriting for is if you want to remove the index.php from the url and make it even more search engine friendly. If you do need these features with IIS 6 hen use ISAPI REWRITE or APE both of which support Apache Mod_rewrite rules, with IIS 7 Wordpress will generate the required rules for the built in url rewriter and you just paste them into your web.config, so nothing else required.

As you may remember from my previous post, I had issues with Microsoft Access Data Sources not working after upgrading from CF8 to CF9. The reason being that CF9 decided to install the ODBC service on a different port.

Well after upgrading cfmldeveloper to CF9.0.1 I had the same problem, users started to report MSAccess DSN's were not working, except this time the service was running fine and on the correct port. This was a real head scratcher, and as is often the case with my issues they are fairly unique/unusual and so there often is nothing on google and even my fellow cfgurus cannot help me.

After further investigation I discovered that existing MSAccess DSN's were actually still working, it was only new DSN's that did not work, giving the following error.

[Macromedia][SequeLink JDBC Driver]TCP/IP error, connection refused. 

So I then went into the ColdFusion Administrator to take a look at the DSN's and was unable to do so, getting this error.

The ColdFusion ODBC Server service is not running or has not been installed. 
You may also use the "MS Access with Unicode" driver to connect to MS Access datasources

As you can imagine this was a bit confusing as the service was indeed running otherwise the old DSN's would not be working.

So I had a look in the <cfusion root>/lib/neo-datasources.xml (this is where the DSN's are stored) and found the cause, The CFADMIN was using the wrong port to connect to the ODBC service and for creating DSN's, it was again using 20000 instead of 19999 which result in the following JDBC URL.

<var name='url'><string>jdbc:sequelink:msaccess://localhost:20000;serverDatasource=dofficers</string></var> 

Now bear in mind that I am creating DSN's via the HELM control panel via my API, which is the only reason that was even possible, as obviously it was not possible to add a new MSACCESS DSN via the CFADMIN for the same reason.

So this again seemed like a trivial solution, just change the port again right? So as I know the setting had to be in one of the neo XML files I simply did a search for "20000" thinking this would give me what I want, but no, I came up empty and have now spent almost a month trying to resolve this.

So I viewed the source in the cfadmin for the msaccess.cfm page, and there I could see a hidden form field that contained the port number. My next step was to decrypt the CFADMIN and try and find out where the port came from. This also turned out to be a less than simple task as none of the decrypt tools would work for me. It was then suggested to me by fellow cfguru Mark Kruger that I needed to get a copy of the CFADMIN from ColdFusion 6 as the encryption had changed since then, and these tools had not since been updated.

I eventually got the files I needed and worked out that the port number came from the service factory, so again I was confused as I was sure the service factory settings came form the neo xml files? Well this is where I feel like a dumbass, I just got confirmation from Mike Nimer (who actually wrote some of the cfadmin) that I should be looking in the neo xml files, so I searched the files again and this time I got a hit in the neo-drivers.xml. So it was there all along, god knows how I missed it last time, maybe windows search screwed up or maybe I typed 2000 instead of 20000 several time sin a row LOL. Anyway the solution was indeed as easy as I had first thought, just open up the neo-drivers.xml and find the following.

<var name='port'><string>20000</string></var>

and simply change the port to 19999, then restart CF and everything should be good.

So why am I having these issues every time I update CF? I think it is because of the fact that when you install a new version of CF it leaves the previous version intact and simply disables the services (or should do at least). And in my case the cf installer is seeing the previous CF version and thinks it is still active and thinks there will be a conflict on the ODBC service port, so is changing it. Obviously in both cases it did not do it properly, the first time it only change the service port and not the service factory settings, the second time round it did the opposite.

Now I know some people will just say and did say  "why didn't you just use the Microsoft Access with Unicode" driver instead, and yes this would be a workaround as this driver does not rely on the ODBC service so is better anyway. But Unfortunately the HELM control panel we use only supports the regular MSACCESS DSN, so I needed to get this working again or no-one could use MSACCESS.
And yes we all know that people shouldn't use MSACCESS for production web sites, but they do.