Problem creating new Outlook 2007 Rule on an Exchange 2003 Server

We had a customer who was trying to create a new Outlook Rule using Outlook 2007 connected to their Exchange 2003 server and they kept receiving the message:

“One or more rules cannot be uploaded to Microsoft Exchange and have been deactivated. This could be because some of the parameters are not supported, or there is insufficient space to store all of your rules.”

All manner of attempts to try and fix the problem were in vain. Other users were happily able to create new rules, recreating the specific users Outlook Profile made no difference, using 3rd party software (Outlook Spy) revealed nothing of interest and starting Outlook with additional switches (/cleanclientrules /cleanrules /cleanserverrules) also made no difference.

Looking around on the server for an unrelated issue, I saw many ESE errors (Event ID 467 – Database Corruption) in the Application Event Logs and this led me to dismount the mailstore and repair, defragment and integrity check it (eseutil /p, eseutil /d and isinteg -s servername -fix -test alltests).

Once the eseutil checks were completed, I ran the isinteg command and after the first pass, about 47 errors were noted in the last line of the output. Running isinteg again (to make sure all errors had gone) showed 0 Errors and 0 fixes – whcih is the desired result, so I mounted the store again and contacted our customer.

Our customer then tried to create a new rule and was able to without any problems!

So, if you have scoured the web for solutions to similar problems and you still cannot create a new Outlook rule, check your server Application Event Logs and if required, repair, defragment and integrity check your mailstore as it will most probably fix the problem.

Demon’s (Thus Telecom) Response about their mail server’s being Blacklisted – Do they give a damn?

A customer of ours was having trouble sending us emails recently and the usual reason is that the IP Address of the mail server that was sending the mail to us is blacklisted (our servers check against various blacklists to cut down on spam just like every other good mail server should).

So, after receiving a copy of the email headers from our customer, we checked the sending server’s IP Address 195.173.77.148 and sure enough, on checking on MXToolbox we discovered that they were on 3 blacklists (Lashback / Redhawk and SORBS).

So we asked our customer to get in touch with their ISP (Demon / Thus) and ask them to request that the IP address gets de-listed. That was when the fun started!

After a couple of emails back and forth between us, our customer and Demon (Thus), we received the following response:

—————————————————————————————————————
“It appears that it-eye.co.uk are using SORBS to filter their mail.

There are many blacklists available on the Internet but not all blacklists are created equal. We actively monitor a number of the larger public ones to ensure that we are aware of problems with both our service machines and our customers.

However, it is our opinion that this particular list is a rather aggressive one and sees abuse teams as the enemy rather than an ally.

They also do not appear to provide any evidence for their listings so we will not be submitting any removal requests.

Recipients must understand that if they use such lists, they may very well be losing legitimate mail.

If this is causing you difficulties then there are 2 options available to you:

1. Alter your configuration to send mails directly rather than via our smarthost (if your systems are able to support this).
2. Send your mails to one of the smarthost machines that aren’t presently listed; this is a list of the current machines:

195.173.77.132
195.173.77.133
195.173.77.134
195.173.77.148
195.173.77.149
195.173.77.150

Please note that this is only given as a possible fix for a temporary problem and that you generally should only refer to the smarthosts as ‘post.demon.co.uk’.

—
Network Abuse Team
THUS
a Cable&Wireless Worldwide business”

—————————————————————————————————————
Having picked myself up off the floor, I decided to check out the IP addresses that they listed and guess what, here are the results!

195.173.77.132 – Blacklisted on Backscatterer.org – (badly configured server) plus Lashback & Sorbs
195.173.77.133 – Blacklisted on Lashback & Sorbs
195.173.77.134 – Blacklisted on Backscatterer.org – (badly configured server) plus Lashback & Sorbs
195.173.77.148 – Blacklisted on Lashback, Redhawk & Sorbs
195.173.77.149 – Blacklisted on Lashback & Sorbs
195.173.77.150 – Blacklisted on Backscatterer.org – (badly configured server) plus Lashback & Sorbs

Now you don’t get listed on Backscatterer.org unless your servers are badly configured and send out Non-Delivery Reports to spammers, so it is very clear that Demon do not have a clue about configuring mail servers and clearly don’t care that their IP Addresses are blacklisted and are not prepared to do anything about it. Please read the Wikipedia explanation of what Backscatter is.

So – ask yourself – are you going to use Demon as your ISP? I certainly know that they won’t be appearing on my top 1 million ISP’s 🙂

KB883380 Fails To Regenerate IIS Virtual Directories on Exchange 2003 / SBS 2003

I was working on a server yesterday so that I could change the certificate name from http://www.domain.com to mail.domain.com.

After generating a new Certificate Signing Request and submitting it to the certificate authority (www.exchange-certificates.com), I verified the certificate, downloaded it and installed it onto the server in the usual manner and that was when everything went wrong.

I could not browse to the Exchange virtual directory, nor the exchange-oma virtual directory (this was an SBS 2003 server) and Actvesync / RPC over HTTPS was broken too!

So, as this was SBS, I decided to re-run the Connect To The Internet Wizard and let SBS work its magic to reset everthing back to normal. The wizard failed the Firewall section of the Wizard and my virtual directories were vaguely working. Resetting the virtual directories back to the required settings from my Exchange 2003 / Activesync article, this seemed to break IIS further!

So, following method 2 of KB883380, I deleted the IIS virtual directories, ran the Cscript command (adsutil delete ds2mb) and then ran “net stop msexchangesa && net start msexchangesa && net start msexchangeis” to stop and restart the System Attendant and then start it and the Information store (which stops with the System Attendant) and waited for 1 minutes.

After waiting 15 minutes and seeing that the virtual directories had not magically reappeared, I rebooted the server as recommended in the KB article.

So the server woke up again from its reboot and yet still no virtual directories.

What to do?

I then decided to re-install Exchange 2003 Service Pack 2 on the server as this quite often fixes things that are a little broken with Exchange / IIS, so I downloaded the Service Pack and installed it.

Bingo! The virtual Directories were back!!

In addition, I decided to re-key the new certificate just in case that was causing me some issues, so generated a new Certificate Signing Request, re-keyed the certificate and re-installed in onto the server.

I then re-ran the Connect To The Internet Wizard one more time, modified the IIS settings as per my article and then tested Activesync and RPC over HTTPS which was working perfectly.

So, in summary, if your IIS virtual directories do not re-appear after following any method from KB883380 and you have waited for 15 minutes, rebooted the server all to no avail, simply download and re-install Exchange 2003 Service Pack 2 and you should be back up and working again in no time.

Forefront Threat Management Gateway and Activesync – Password Prompt Issues on Windows Phones

Since installing Microsoft Forefront Threat Management Gateway in Front of my Exchange 2010 server, my Windows Mobile Phone has been regularly prompting me to enter my password (I have an HTC HD2). If I hit Cancel instead of entering the password, the phone will continue to sync (of course I could have entered my password, but I felt that it wasn’t necessary).

So – presumably there is a problem with a rule somewhere or a rule missing that is causing this problem.

After my business partner (Mark) had done some digging, he discovered a potential fix for this and emailed me a link. On checking the link, I did some research and there appeared to be a setting in my OWA / Activesync Publishing Rule that when de-selected (it is set by default), seems to happily solve the problem. To change the setting, please do the following:

Open up Forefront TMG Management, Click on “Firewall Policy” in the tree in the left-hand pane and then find your OWA / Activesync rule.

Double-click on your OWA / Activesync Publishing Rule, then click on the Listener Tab, then the Properties Button for the Listener, then click on the Forms Tab, then the Advanced button on the Forms Tab and you will see a Check box call “Apply Session Timeout to Non-Browser Clients”.

Untick this check box, click on OK 3 times, Apply the rule changes and then the Password Prompt on your Windows Mobile phone should have stopped and syncing will resume normally.

As Activesync needs to keep a connection open with the Exchange server, with this setting selected, the connection is dropped and thus the phone thinks it needs to re-authenticate with the server. With the setting not selected, then phone is allowed to keep a connection open with the Exchange server and thus the password prompt doesn’t pop up.