For the past eight months we have been testing our new support portal at https://support.ownwebnow.com and have had a lot of success in making sure support issues do not “fall off the table” as they tend to via email. Going forward, this will be the only way we will provide support, purchasing, cancellations and other account management.

Any mail sent to our previous support aliases will yield this automatic response:

*************************************
This is an automated message
*************************************

The address you sent an email to is not a monitored email address, your reply was destroyed.

Own Web Now Corp only provides support via our support portal at:
https://support.ownwebnow.com

If you have a support request or would like to update a support request please login to our support portal and create/update the support request directly. Doing so allows us to provide you with an SLA, guaranteed support request tracking, escalation and more.

Sincerely,
Own Web Now Corp Support Team
https://support.ownwebnow.com

Check out our blog:
http://www.ownwebnow.com/blog

There are several reasons we chose to eliminate the email support completely:

• We have no tracking of when/if a support request was emailed
• If the message is delayed because the support request was required to address a mail server issue we would get it far too late
• Clients would forget to provide updates
• Clients would keep the message thread going for support requests that were solved and were looking to address other issues
• E-mail is an insecure way of conducting e-commerce
• “Did you get my email?” <that they probably never sent>

There are far more reasons to drop email support but at the end of the day we needed a structured and fixed process of requesting support. At the moment there is only one way to get support, https://support.ownwebnow.com and we stand behind it with our SLA.

Thank you for doing business with us and I hope this change makes your support experience more enjoyable.

4:35 AM EST Update - Network shutdown proceeded as planned. The network recovery process is beginning. Please stand by as all the services are restored. Please be aware that we will not be able to work any Urgent or High priority cases while the maintenance cycle is active. We will resume regular SLA at noon EST. Please keep an eye on the blog as we update it throughout the morning.

10:51 AM EST Update - Powergrid maintenance complete, network maintenance complete, cage “shuffles” complete. Moving on to application layer testing.

1:21 AM EST, The day after update – All services, networks, systems and operations back to normal. We will provide additional details later, we’re also lobbying for a day off

Three times a year Own Web Now Corp conducts a global network maintenance cycle. These maintenance cycles are meant to double-check the equipment, swap out aging infrastructure, improve cable management as execute a disaster recovery procedures. In plain terms, we take the network down at an announced time and work on it during off-peak hours so it doesn’t crash unannounced in the middle of the day.

Our global network maintenance cycle is scheduled for this Sunday, September 23, 2 AM – 5 AM Central (GMT -5).

All networks, all services, all customers will be affected. We will literally be shutting the NOC down and restarting it from scratch.

We will also have a minor ExchangeDefender Policy Engine upgrade during Saturday afternoon, the services should not be affected beyond perhaps a few minutes without control panels while we swap out the switches and nodes.

We are dealing with a fairly significant distributed denial of service attack (DDoS) at the moment and are doing all we can to mitigate the traffic. Please stand by.

Over the past 24 hours we have received a lot of complaints about the non-delivery of email to random recipients from random hosts on the Internet. At this point we have been able to narrow it down to Microsoft Exchange 2003 servers running IMF v2 and Microsoft Exchange 2007 servers also running IMF. In all instances the mail was acknowledged by ExchangeDefender, processed and delivered to the target mail server. In several instances mail disappeared completely. In others only certain recipients “didn’t get” the message.

We cannot stress this strongly enough: Turn OFF any SPAM filtering enabled on your servers, along with any SPF checking, validation or firewall port 25 data inspections. 

The only rules that should be enabled are those described in previous posts dealing with port 25 restrictions.

How come an email was received by one user but not on the other if they were cc’ed?

Frequent question asked today in our support portal. For example, two users in the same organization were receiving an email. Or perhaps a distribution list where a single email address delivers to Outlook/mbox and other relays externally to a Blackberry address. If one gets it and the other doesn’t thats ExchangeDefender’s fault, no?

No. ExchangeDefender does not modify/alter the message body nor does it split the message that is being delivered. The message is delivered in a single direct stream at which point Exchange further processes the message and delivers it to the delivery agent (which further relays the message or forwards it depending on local rules.) Exchange also uses technology called single instance storage, allowing a single message to be stored in the database if it is received for multiple recipients.

So, if a message was received by one user it must have been received by the other. Why can one see it while the other can’t? Turn up message tracking and see. However, we are currently seeing this as an issue related to Outlook Junk Filters and IMF, both of which need to be disabled for reliable mail delivery.

We are extending the maintenance cycle window for July 21, 2007. Our regular maintenance cycle is from 3AM to 7AM EST but due to the number of systems going online this week we are going to have to extend that window until noon EST. We will follow up with full details of the work being done but suffice to say it is significant.

If you are not familiar with our maintenance cycle activities do not worry, they are routine and they happen every week. Generally they are things you would expect – reboots to add more memory, storage, reboot for software patch installation, etc. At times there are other items such as electrical or network maintenance.

This particular weekend involves nearly all of the above plus a significant upgrade to our core infrastructure of ExchangeDefender, offsite backups and virtual servers. We’re bringing online 3 new data centers to top it off so we wanted to give ourselves more time to get everything done right.

You may have had a difficult time reaching us on Wednesday 6/27 and Thursday 6/28.

I have mistakenly redirected my DID to an unmonitored extension at the same time that the PBX was undergoing a software upgrade to Trixbox. This resulted to all incoming calls being routed to an unmonitored extension that didn’t even have a greeting assigned to it. I have been able to track down the voicemails and will be returning calls tomorrow on Friday, 6/29.

All other support mediums (email, web, portal) were working during this time, we did not become aware of the problem until one of our partners let me know. We’re really sorry about the inconvenience this has caused some 40 of our callers, we will match up the caller ID with the customer database and contact you all as soon as possible.

Earlier this morning we identified an issue with our load balancing network and moved to quickly update the firmware and restart the services. This emergency maintenance window has caused delays between 5 and 15 minutes accross our entire network between 10:00 – 10:30 AM EST (13:00  – 13:30 GMT).

This window was not planned and did not affect everyone at the same time. As we applied the load balancer firmware update and cycled the mail currently being processed on that network was temporarily disconnected from the Internet. As soon as the load balancer restarted the normal operation resumed.

While it is unlikely that anyone would have noticed this outage we felt it was important to let you know every time our service is affected.