This blogpost was designed to be quite different – as next easy-peasy thing, which can be configured in Omnitracker,’cause what can be difficult in configuration of EmailGateway beside writing complicated parsing script?

This integration turned it to be very hard to me. It started last December, when I configured 3 EmailGateway rules for parsing emails and creating/updating Incidents on the basis of parsed data. Two days of testing and voila – everything seemed to work as a dream.

Then it came the time to test it on production env. with ServiceNow. Two first sessions of testing were not so difficult – most of the things were working (not mentioning HTML format of emails sent from ServiceNow), some of the passed data from Omnitracker needed to be added. One additional parsing rule for new test case – but it was fast -30mins devoted for writing parsing script and 'thank you very much-it is working!’.

Unfortunately after these tests we discovered strange thing Omnitracker – it started sending emails to everyone Responsible no matter whether it was related to Maersk or not. It caused a little mess in all of related emailboxes for several hours. The decision was made – you have to test this integration on test env. So I switched off the test email account and all email notification actions in relevant folders.

Well, I had only 3 days to reconfigure the old test server. Blessed, who don’t know everything at once! – then I thought:”hmm, it is only Omnitracker-what can go wrong with this easy Windows app?” Then I discovered that on this strange server there are 30 incoming email rules, 30 outgoing email rules and 15 email notifications in 2 folders including actions after/before transitions in workflow. The question was: how to disable all of them in an easy and fast way in order to avoid mail bomb for everyone? The solution seemed easy – disconfigure email server IP address and leave valid only test email account!!! As I thought I did so…The joy didn’t last long – as next day I discovered several strange things:

• Exchange server was configured in that way that instead of sending emails from Omnitracker, I saw only this error:”Exchange SMTP Error 550 5.7.1 Unable To Relay”
• No incoming emails were received
• EmailQueue in Omnitracker was full, what caused disk full and of course Omnitracker stopped working!

First problem was solved by Exchange admin – he enabled rules so emails to specific email account outside the company could be send as described here:

https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/fix-error-code-550-5-7-1-in-exchange-online

Second problem – it turned out that ServiceNow didn’t send any emails. It was enabled.

Third problem was solved by deleting all emails, restart EmailGateway and in combination with solution one-finally emails were sent.

Then it was time for User Acceptance Tests – having all of the mentioned problems solved I thought, that we won;)

However then, coronovirus affected my country and the result was: closed schools, kindergartens and obligatory home-office. As home-office for me seemed no such a big problem, as I used to work from home once a week and have fast: fibre-optic Internet connection. However when my colleague had bike accident and broke his collarbone, all of the services, which we administered together were under my control + kids at home, whom I had to help with school lessons, teaching how to write and read my younger son. And then that tricky part started!

Belive me, when you had to the same day: fix reconfigured Nagios, solve some strange errors in one Omnitracker (like changing names in one part of app., resulting in not working at all, all frames from two other folders), then disovering that in the second prod server of Omnitracker no emails are parsed for several email accounts (resulting of missing Incidents, RFCs and so on), some OT clients not working because of missing .NET libraries, OT upgrade in meanwhile and of course new problems related with it, fixing SQL queries for complicated report in ActianX, and after work – teaching your kids, sewing protective masks and try to not panic about this surrounding epidemy – it is not such an easy thing.

When this UAT tests failed for the 3rd time, the same day I discovered that half year of my work on the other server was just deleted, because somebody misleaded upgrade of Windows with formatting the main disk (and of course there was no backup), not mentioning vision of reduced salary for my work because of coronovirus crisis. No wonder that this day I said:”I prefer sewing protective masks for hospitals instead of working in IT!”

The reason of failed UAT tests was obvious – failure on main Exchange server. I found out the next day, that almost all email accounts were moved to new server – however the passwords were also changed, without notifying me. The result – not working email accounts in Omnitracker…

However then I discovered other problem – emails seemed to be sent, but actually they weren’t. They got stuck again in EmailQueue-as all of the outgoing email accounts were misconfigured, remember?

This time I used solution offered by my manager- use fakeSMTP server:

https://github.com/rnwood/smtp4dev

I had to install the oldest version, because of 32bit Windows. Then I discovered, that emails were not sent again. It turned out that Omnitracker sends emails with ENVID keyword as described in RFC3461 (who could suspect that I will have to read documentation from the beginning of Internet?!!):

https://tools.ietf.org/html/rfc3461

This time changing Windows registry settings described in „Omnitracker Help”, helped on test server.

Thanks to help from intelligent guy from ServiceNow, we managed to make this integration working on test server.

Next step is : transfer all functionality to prod server and final test on prod server…keep fingers crossed.