Apple release iOS 6.1.1 to fix one bug but it doesn’t fix the bug with Exchange

After Apple released iOS 6.1 on the 28th January 2013, numerous people have complained of various issues with 3G connectivity, others have complained about battery life being reduced dramatically and more recently, Exchange servers around the world have been slowing down due to what appears to be a problem with the devices looping when Calendar Appointments are accepted on the iPhone / iPad.

Today Apple has released iOS 6.1.1 (only for the iPhone 4S) which seems to address the 3G issues, but it doesn’t fix the Exchange issues and Microsoft / Apple are working together on the problem to see if it is an Exchange issue or an Apple issue.

So whilst some can upgrade, not everyone can and even those that can upgrade, may well have to upgrade yet again when a new update is released that fixes the Exchange issue.

Exchange Admins all over the world are probably restricting access to their Exchange Servers for those who have upgraded to iOS 6.1 until they delete and re-create their Exchange Accounts and promise not to do anything with Exchange Calendar Appointments (in terms of Accepting / Declining etc). Once they have deleted and added their account back, the Admins may allow them back on the server as this is rumoured to ease the performance issues that the Exchange servers are suffering.

The iOS 6.1.1 release is 968Mb in size, so it isn’t a small download. If you are not suffering from battery / 3G issues, you may as well wait to see if there is a newer release and download that instead.

I for one (with my iPhone 4S), have only just upgraded to iOS 6.1 but won’t be updating to iOS 6.1.1 because I can’t face the hassle of Jailbreaking it all over again and re-install/configuring my Jailbroken apps so recently after Jailbreaking iOS 6.1, only having to do it again when 6.1.2 or 6.2 (or whatever comes next) is released to fix the problem, assuming it lies with Apple and not Microsoft.

Watch this space for more news as and when it becomes available.



SBS 2003 Connect To The Internet Wizard Fails At Firewall Configuration

Today I was working on a problem where an SBS 2003 server was having issues re-running the Connect To The Internet Wizard whereby the Wizard started happily to re-configure the server but then failed at the Firewall configuration.  The server also had ISA Server 2004 installed.

The reason for re-running the wizard was because emails were not flowing properly out of the server and re-running the Internet Connection Wizard was a good place to start troubleshooting.  Because the Wizard was failing, it was a strong possibility that the Firewall / ISA server was causing the issue.

Having examined the ICWLOG.TXT file to see what might be causing the issue (from C:\Program Files\Microsoft Windows Small Business Server\Support) it showed the following errors:

Error 0x80070003 returned from call to Configuring IIS to listen only on the LAN().
Error 0x80070003 returned from call to CStingrayCommit::DoGeneralConfiguration().
Error 0x80070003 returned from call to Doing general configuration().
Error 0x80070003 returned from call to CStingrayCommit::CommitEx().

Doing some digging on the webs for an answer, I checked a few sites but drew a blank, then I found the following site ( and it pointed me to check the registry for the following key:

the ‘companywebpath’ key showed this value:


Opening up IIS Manager, I then checked the IIS Website Identifier Value for the CompanyWeb site (see example image below) :
and saw that it was showing a different value, in this case it was showing ‘448260875’.

Going back to the Registry key, I then changed the ‘companywebpath’ value to 448260875 to mirror the IIS Website Identifier and then closed Regedit.

Upon re-running the Connect To The Internet Wizard again, it completed happily and normal outbound mail-flow resumed.

I am sure that this isn’t the only reason for the wizard failing at the firewall stage, but it is one thing to rule out that isn’t exactly obvious.

Exchange 2007 & 2010 SSL Certificates

Having just installed Exchange 2007, Exchange 2010, SBS 2008 or SBS 2011, you are now probably at the stage of getting Exchange to work properly (Activesync, OWA, Outlook Anywhere and Autodiscover) and are debating whether or not to use the self-issued SSL certificate installed with the version of Exchange you have, or buying a 3rd party SSL certificate.

Well, for me – it is a no-brainer. I ALWAYS buy a 3rd party SSL certificate from because I can buy one, request the certificate, approve the certificate, import it onto the server, enable it for SMTP, POP3, IMAP and IIS and then forget about it for at least 3 years (I always buy one for 3 years minimum) until it is time to renew the certificate.

Once the SSL certificate has been imported and enabled, ALL aspects of Exchange will work (Activesync, OWA, Outlook Anywhere and Autodiscover) and there won’t be any annoying popups in Outlook complaining about certificate issues.

With Exchange 2007 / 2010, the following names should be included in your SSL certificate: (or whatever you prefer to use)

With SBS 2008 / SBS 2011 you should include the following names: (or whatever you prefer to use)

You will also need to setup a new A record in your Domains DNS records (external via your Domains Control Panel, not in your internal DNS records) called Autodiscover and this needs to point to the IP Address of your Exchange / SBS server.  If you can’t do this (and sometimes this is not possible), the alternative it so setup an SRV record and the following MS guide advises you how to achieve this:

With Exchange 2003, a simple single name certificate was all that was required and these were much cheaper than the SAN (Subject Alternative Name) / UCC (Unified Communications Certificate) certificates, but sadly, these sort of certificates won’t work properly with Exchange 2007 or 2010.

Whilst some parts of Exchange 2007 and 2010 can be made to work without a 3rd party SSL certificate by tweaking the settings in Exchange, my personal recommendation is to save yourself the pain of doing so by spending the small amount of money it takes ($60 / £40 per year) and save yourself the hassle of trying to tweak Exchange and get all the settings correct. This can be time consuming (how much is your time worth to your company) and fiddly to say the least and the time spent / cost of fixing Exchange to make it work with the self-issued SSL certificate vs the small cost of buying and installing a SAN / UCC certificate is money well spent in my humble opinion.

Extract from Understanding the Self-Signed Certificate in Exchange 2007 :

Limitations of the Self-Signed Certificate

The following list describes some limitations of the self-signed certificate.

  • Expiration Date: The self-signed certificate is valid for one year from the date of creation in versions of Exchange 2007 that are earlier than Exchange 2007 Service Pack 2 (SP2). Self-signed certificates are valid for five years from the date of creation in Exchange 2007 SP2 or in later versions. When the certificate expires, a new self-signed certificate must be manually generated by using the New-ExchangeCertificate cmdlet.
  • Outlook Anywhere: The self-signed certificate cannot be used with Outlook Anywhere. We recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party if you will be using Outlook Anywhere.
  • Exchange ActiveSync: The self-signed certificate cannot be used to encrypt communications between Microsoft Exchange ActiveSync devices and the Exchange server. We recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party for use with Exchange ActiveSync.
  • Outlook Web Access: Microsoft Outlook Web Access users will receive a prompt informing them that the certificate being used to help secure Outlook Web Access is not trusted. This error occurs because the certificate is not signed by an authority that the client trusts. Users will be able to ignore the prompt and use the self-signed certificate for Outlook Web Access. However, we recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party.

Self-Signed Certificates
When you install Exchange 2010, a self-signed certificate is automatically configured. A self-signed certificate is signed by the application that created it. The subject and the name of the certificate match. The issuer and the subject are defined on the certificate. A self-signed certificate will allow some client protocols to use SSL for their communications. Exchange ActiveSync and Outlook Web App can establish an SSL connection by using a self-signed certificate. Outlook Anywhere won’t work with a self-signed certificate. Self-signed certificates must be manually copied to the trusted root certificate store on the client computer or mobile device. When a client connects to a server over SSL and the server presents a self-signed certificate, the client will be prompted to verify that the certificate was issued by a trusted authority. The client must explicitly trust the issuing authority. If the client confirms the trust, then, SSL communications can continue.

Frequently, small organizations decide not to use a third-party certificate or not to install their own PKI to issue their own certificates. They might make this decision because those solutions are too expensive, because their administrators lack the experience and knowledge to create their own certificate hierarchy, or for both reasons. The cost is minimal and the setup is simple when you use self-signed certificates. However, it’s much more difficult to establish an infrastructure for certificate life-cycle management, renewal, trust management, and revocation when you use self-signed certificates.

So – there you have it. If you want to have Exchange working happily and trouble-free, my best advice is to buy a 3rd party SSL certificate and is about the cheapest place around that you can buy an SSL certificate for Exchange from (even cheaper than GoDaddy and they are pretty cheap already!).

Exchange 2007 / 2010 Queues Filling Up With Postmaster Mail to Invalid Domains

If you have an Exchange 2007 / 2010 Server and you notice that your queues are filling up with mail for domains that do not seem to be going anywhere and no-one internally has emailed those domains, you need to check to see who it is that is sending these emails.

Open up the Exchange Management Console, then click on the Toolbox, Open the Queue Viewer and then double-click onto a queue that is for a domain that you don’t recognise.

If you see as the Sender, then your server is sending out Non-Delivery Reports back to emails that are received at your server for recipients that don’t exist.

To check your server configuration, please open the Exchange Management Shell and type in the following:

get-recipientfilterconfig | ft RecipientValidationEnabled

You will most likely see the result showing as False, meaning that your server is not filtering Recipients on your server.

The problem with this is that if your server accepts all messages, then tries to deliver them, realises that some are destined for email addresses that don’t exist, your server becomes responsible for sending back a Non-Delivery Report. Now suppose that the email is spam and that the spammer has made-up the sender address. Your server will then be sending a Non-Delivery Report back to either an invalid email address, a valid email address for which the recipient had not sent the email in the first place, or worst of all, a honeypot email address (one that has never been advertised but has been hidden for spammers to find) designed to trap spam mail. If an NDR email arrives at a honeypot address, YOUR mail server will end up getting blacklisted on such sites as, causing you problems sending mail to some domains.

How to fix this problem?

Well, if you have an Edge Transport server, simply run the following command in the Exchange Management Shell:

Set-RecipientFilterConfig -RecipientValidationEnabled:$true

This simple command will tell your Exchange server to check the Recipient email address for any inbound email and if the address does not exist on the Exchange Server, it will immediately reject the message, resulting in the sending server becoming responsible for sending a Non-Delivery Report.

If you don’t have an Edge Transport Server – only a Hub Transport Server, you will need to install the Anti-Spam Agents by running the following comand in the Exchange Management Shell:

Exchange 2007:


Then, run the above command also in the Exchange Management Shell:

Set-RecipientFilterConfig -RecipientValidationEnabled:$true

Exchange 2010:

Read the following article for how to install the Anti-Spam agents:

then run the Set-RecipientFilterConfig command.

If you find that you have not got Recipient Filtering enabled and have to Enable it by using the command above, please pay a visit to MXToolbox, enter your Mail Server’s IP Address and see if you are Blacklisted on (or any other blacklist sites for that matter) and request de-listing if you have fixed the problem.

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.

Why Am I Blacklisted?

The most common reason for being blacklisted is because one or more computers on your network has become infected with a mass-mailing virus and is sending out spam.

Check to see which blacklists you are on and also why you are blacklisted by visiting and click on the link under the reason column to find out why.

If you can – lock down your firewall to block all outbound traffic on TCP port 25 from all computers except your mail server. Most spammers will try to use this post to send mail, so blocking the port will stop most spam immediately.

Check your computers with a tool such as Malwarebytes and download / install their free software and run a basic scan after updating the software online. Remove anything that it finds.

Once you have located and removed any infections on your computers, re-visit the blacklist sites and request de-listing. Some will do this immediately and others will wait a short while. Some sites will ask you to pay for express de-listing – this is up to you, but do make sure you are infection free before paying as you will quickly get listed again if you have not resolved the problem.

Problems sending emails to external domains

If you face problems sending out emails, but only to a handful of domains, please run through the following checks / tests and make sure your environment is setup properly:

  • Check your domain on (subscription required) or (free) and see if you have a Reverse DNS pointer setup.  If you do not have one setup – call your Internet Service Provider (ISP) and ask them to set one up to match the Fully Qualified Domain Name (FQDN) that your mail server responds as e.g., Also, your mailserver FQDN should also be setup with something like  Any FQDN ending in .local or .internal or anything that is not a valid Internet Domain Name is not correct and should be changed otherwise you may experience problems sending out emails to some domains.
  • Check that your IP address is not listed on any Blacklists on – If you appear on any blacklists, then you may have problems sending mail to some domains who check against blacklists (not everyone does, but a lot do).  Follow the links on the results page to the particular blacklist site to find out the reason why you are listed (you may have an infected computer sending out spam that you are not aware of) and then deal with the issue before requesting removal from those blacklists (if you don’t deal with the problem, such as an infected computer, you will get removed from the blacklist, but will only re-appear again as more spam is sent out).  Once you know what you are facing, you can resolve the problem.

If you are blacklisted – configure your firewall / router to block all traffic on TCP Port 25 Outbound from all IP addresses apart from your Mail Server.  This should reduce the possibility of an infection from getting you blacklisted further and will help prevent getting listed again once you have cleaned up your network.

  • Check your IP reputation on Senderbase  You will either be Good, Neutral or Poor.  If your reputation is Poor – then you may have problems sending out mail and are most likely appearing on a blacklist or two somewhere.  If you are Neutral, then you may have had a problem in the recent past and are still recovering your reputation.  If you have a Good reputation, you should have no problems sending out emails.
  • Check to see if you have an SPF (Sender Policy Framework) record setup on – If you do not have a record setup, visit, run through the various options carefully and then you should see your SPF record in the final box at the bottom of the screen. Once you have an SPF record, you have to publish this record in your Domains DNS records by adding a TXT record with the SPF record as the data e.g., Type=TXT Record=(output from An alternative site to the site that you can use is
  • Check to make sure that the advertised IP Address in DNS for your primary MX record is the same IP address that you are sending mail from. Ideally – they should be the same for optimal mail-flow although if you are using a 3rd party spam filtering service or have inbound mail on one IP Address and outbound mail on another, this is not going to be possible.

If you do send out mail from a different IP address to the advertised MX record IP Address, please check that the Reverse DNS entry for this IP Address is also configured properly and that it resolves correctly to the same IP address (I use to check this – but you will need a subscription!). As an example, if you send mail out via IP and the Reverse DNS entry setup on this IP address by your ISP is, should also resolve in DNS back to the same IP Address.

Having checked all of the above and made any corrections to your configuration, your mail should be flowing better. If it is not and your house is now in order, you are not listed on any blacklists and you still have problems sending out mail to one or more domains, then it may be that the external domain may be specifically blocking you, (Hotmail are quite good at doing this for no particularly good reason) you will need to contact them to try to resolve the issue.