Broken tracked links after change of hostname

Hi everybody

We have what seems to be a general issue with customers who are heavy users of SO mailings. I discovered this during a prep for upgrading superoffice to the latest version from 8.0. I have moved a Service installation from emarketing.company.dk to superoffice.company.dk/Service as per best practise described by Margrethe in the presentation from EW 2017. This does however not really mention anything about backward compatibility with old shipments.

Then to prevent loss of images and tracked links, i've made a 301 redirect on the IIS from the old site to redirect all traffic to the new hostname. The good news is that images and attachment links are redirected just fine, so mailings doesn't look crippled in the mail client of the end receiver. All links are dead though, including the unsubscribe links - which is a big bummer!

To demonstrate, i made a shipment before we made the change that was confirmed working, and then one after:

 

Link before hostname change: http://emarketing.company.dk/scripts/customer.fcgi?action=ejLink&key=12024:40050:677048:9a537a524ee441804c7383731c6f31070987f570&sai=9786225

Link after sending the same shipment after the change: http://superoffice.company.dk/Service/scripts/customer.fcgi?action=ejLink&key=12024:40050:677048:9fe4b958188c5787719ef6cf38c195b8b962eda3&sai=9786225

select * from dbo.s_shipment where id = 12024 -- ID of the Shipment

select * from dbo.s_link where id = 40050 -- Id of the link

select * from dbo.person where person_id = 677048 -- Id of the receiver

select * from dbo.?????? where id = '9a537a524ee441804c7383731c6f31070987f570' -- id of what???

12024:40050:677048: and &sai=9786225 is similar in both links, but the long hash-like string differs.

My theory is that the unique part of the link contains information about the original hostname that needs to be verified against the called link, once the receiver clicks it. When SuperOffice tries to regenerate the hash using the changed hostname URL, the hash will not end up being the same, and therefore the link is being rejected.

So what are other customers / partners doing to prevent broken links when upgrading to 8.1+ on premise?

Please ellaborate, and share a fix if you have any :)

thanks!

Hi,

We have this script to replace URL from old to new when you are changing the domain. That should work and we haven't got any complains. Have you tried it?

update crm7.s_message set html_message = replace(html_message,'://oldurl.no','://new.url.no') where html_message like '%://oldurl.no%'
update crm7.ej_message set html_body = replace(html_body,'://oldurl.no','://new.url.no') where html_body like '%://oldurl.no%'
update crm7.ej_message set body = replace(body,'://oldurl.no','://new.url.no') where body like '%://oldurl.no%'
update crm7.reply_template_body set body_html = replace(body_html,'://oldurl.no','://new.url.no') where body_html like '%://oldurl.no%'
update crm7.ejuser set signature = replace(signature,'://oldurl.no','://new.url.no') where signature like '%://oldurl.no%'
update crm7.ejscript set body = replace(body,'://oldurl.no','://new.url.no') where body like '%://oldurl.no%'
update crm7.screen_definition_action set ejscript_body = replace(ejscript_body,'://oldurl.no','://new.url.no') where ejscript_body like '%://oldurl.no%'
update crm7.KB_ENTRY set question = replace(question,'/scripts/customer.exe/getAttachment','/service/scripts/customer.exe/getAttachment') where question like '%/scripts/customer.exe/getAttachment%'
update crm7.KB_ENTRY set answer = replace(answer,'/scripts/customer.exe/getAttachment','/service/scripts/customer.exe/getAttachment') where answer like '%/scripts/customer.exe/getAttachment%'

Av: Martin Pavlas 16. jan 2019

Hi Martin, sure i did, as i wrote, i followed the best practise in Margrethe's presentation on EW 2017 - which included this script.

And as i also wrote, attachments like images are working as they should - but all tracked links are dead anyway - as it seem like it does not recognize the hashed value at the end. Keep in mind that this is links from mailings that was sent out before the change of domain. If i resend the mailing, after doing the changes in the script - it will of course work as it should. So the customer has been informed about this, and that it will only be a problem on legacy mailings. There will be no problem on future mailings due to running this script - it's just really important for all of us to keep in mind that it does not seem to do anything at all with legacy tracked links.

 

This particular customer also does mailings several times a week, so they're "a bit" special, compared to others who maybe only send out once a month and wouldn't even notice broken links in old mailings - which is why you might never had any complaints about it before now. But you can look into it if you'd like, and until then i'll just keep it in mind whenever i need to move a CS to a new domain.

Av: Dennis Aagaard Mortensgaard 18. jan 2019

Hi Dennis,

you are right. Based on your question I did some research and expanded our migration guide on the Move to new server page with this text:

 

Links in eMarketing messages

All the eMarketing messages sent out before the move will contain links pointing to the old site. There are 2 issues with it:

  • When sending out a link, it will have an absolute URL, for example: http://cs.mydomain.com/scripts/customer.fcgi?action=... so if you move Service to another domain or subfolder, that URL will not be available any more.

    To prevent loss of images / attachments in the sent mailings you need to make a redirect on the IIS from the old site to the new hostname. This way images and attachment links are redirected just fine, so mailings don't look crippled in the mail client of the recipient.

  • Second issue is with tracked links. A tracked link (also including the unsubscribe link) contains a hashed string which is based on the Customer Center domain. Even if you set up a redirect to catch old URL's, then it will be executed by Service but it will fail on the hash test.

    A workaround is to leave the Customer Center on the old URL running, at least till the messages with the tracked links become irrelevant.
Av: Martin Pavlas 24. jan 2019

Hi

I've changed the domain name for a customer, leaving the subscribe link in new maillings not working.

Any idea on how to fix this ?

 

https://community.superoffice.com/en/technical/Forum/rooms/topic/superoffice-product-group/customer-service/unsubscribe-link-after-domain-change/

 

Av: Gabriel Wiig 6. mar 2019

Hi Gabriel,

what I've done previously to solve this issue is to create a new site which responds to the old hostname, then create a rewrite rule on that site to rewrite all incoming requests to the old hostname to the new hostname.

You can read more about it here:

https://community.superoffice.com/en/technical/documentation/prepare/security/deploy-securely/setting-up-a-reverse-proxy-on-iis8/

Av: Simen Mostuen Iversen 6. mar 2019

Hi

That is the only solution when changing domain name?

it will not help to run run C:\SuperOffice\Customer Service\bin\upgrade.exe -d <hostname> after this move ?

Alternative can you uninstall service, delete the content of crm7.config and make a new installation/ejtermsetup.exe ?

Av: Gabriel Wiig 6. mar 2019

Ok, it might be that I've misunderstood your request Gabriel.

If you just change the hostname, all the new links should work perfectly, but whenever you send out a newsletter or something that points to the old hostname, then change the hostname - all those links won't work unless you set up a rewrite rule.

Does the subscription link point to the old or new url?

Av: Simen Mostuen Iversen 6. mar 2019

i've just changed the hostname from http://so.customer.no to https://superoffice.customer.no

but the subscribtion/unsubscription links no longer works. these will result in "The system experienced an error. Please try again later." error

Av: Gabriel Wiig 6. mar 2019

Hi

Couple of things here..

The templates where missing from customer service, and then a blank subscription page..

Ended up upgrading the customer, which fixed everything

Av: Gabriel Wiig 15. mar 2019