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.

Alan

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 (http://www.windows-server-answers.com/microsoft/Windows-Server-SBS/32257468/icw-fail-on-firewall-step.aspx) and it pointed me to check the registry for the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusinessServer\Intranet
the ‘companywebpath’ key showed this value:

IIS://LOCALHOST/W3SVC/4

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 www.exchange-certificates.com 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:

mail.externaldomain.com (or whatever you prefer to use)
autodiscover.externaldomain.com
internalservername.internaldomain.local
internalservername

With SBS 2008 / SBS 2011 you should include the following names:

mail.externaldomain.com (or whatever you prefer to use)
autodiscover.externaldomain.com
internalservername.internaldomain.local
internalservername
sites

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:

http://support.microsoft.com/kb/940881

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.

Extract From Exchange 2010 Understanding Digital Certificates and SSL :

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.

Summary:
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 www.exchange-certificates.com 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 Backscatterer.org, 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:

Install-AntiSpamAgents.ps1

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:

http://technet.microsoft.com/en-us/library/bb201691.aspx

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 Backscatterer.org (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 http://www.mxtoolbox.com/blacklists.aspx 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 http://www.malwarebytes.org 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 http://www.dnsstuff.com (subscription required) or http://www.mxtoolbox.com/diagnostic.aspx (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., mail.yourcompany.com. Also, your mailserver FQDN should also be setup with something like mail.yourcompany.com.  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 http://www.mxtoolbox.com/blacklists.aspx – 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 http://www.senderbase.org/senderbase_queries/rep_lookup.  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 http://www.mxtoolbox.com/spf.aspx – If you do not have a record setup, visit http://old.openspf.org/wizard.html, 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 http://old.openspf.org/wizard.html). An alternative site to the openspf.org site that you can use is http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
• 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 http://www.dnsstuff.com to check this – but you will need a subscription!). As an example, if you send mail out via IP 123.123.123.123 and the Reverse DNS entry setup on this IP address by your ISP is mail.yourcompany.com, mail.yourcompany.com should also resolve in DNS back to the same 123.123.123.123 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.

How to prevent Spoofed Emails in Exchange 2003

Spammers use all type of techniques to get their rubbish through to you and one technique that they use is called spoofing, whereby they forge the sender address and use your own email address, or someone@yourdomainname.com as the sender address.

There are various ways to combat this and in Exchange 2003, you can do the following:

• Setup Sender Filtering to stop inbound emails that are supposedly from your own domain name.
• Setup Tarpitting to slow down spammers who try to determine the email addresses that are sitting on your Exchange server.
• Setup a Sender Policy Framework (SPF) record for your domain.
• Setup Sender ID filtering to check SPF records for inbound email and reject ones that fail.
• Setup Recipient Filtering (won’t solve the spoofing problem, but it is highly recommended to set this up too)

To set these various Anti-Spam techniques up, you should first check that you are using Exchange 2003 Service Pack 2 by opening up Exchange System Manager, expanding Servers, then click onto your server and then right-click on your server and choose properties.

The screen that follows should advise you what Service Pack your Exchange Server is on.  If it does not say Service Pack 2, please visit the following link to download and install it:

http://www.microsoft.com/downloads/details.aspx?FamilyID=535BEF85-3096-45F8-AA43-60F1F58B3C40&displaylang=en

If you are already on Exchange 2003 Service Pack 2, then please review the following articles to setup the various Anti-Spam techniques:

• Sender / Recipient Filtering – http://www.msexchange.org/tutorials/Sender-Recipient-Filtering.html
• Tarpitting – http://support.microsoft.com/kb/842851
• Sender Policy Framework – Visit http://old.openspf.org/wizard.html to create an SPF record for your domain then add the SPF record to your domains DNS records as a Text record with the Wizard results as the detail of the record.  An example SPF record looks similar to the following ; v=spf1 a mx ip4:123.123.123.123 mx:mail.yourdomain.com -all
• Sender ID Filtering – http://www.msexchange.org/tutorials/Configuring-enabling-Sender-ID-filtering-Exchange-2003-SP2.html

Once you have setup the above, you should be free from spoofed emails claiming to come from anyone@yourdomain.com or from your own email address to yourself!

As an alternative to the above, you could simply install some Anti-Spam software and one product that I have been using recently after being recommended it by a Microsoft Exchange MVP is Vamsoft ORF which is currently priced at $239 per server and has drastically reduced the amount of spam that I have been receiving and now my customers who also have Vamsoft, have also seen a dramatic reduction in their spam levels too.  Their website is www.vamsoft.com.

Exchange 2010 Rollup 2 scheduled release

I have just received word on the Grapevine that Rollup 2 for Exchange 2010 is scheduled for release at the end of this week.

This rollup will fix several problems, including a problem that affects users who have been migrated from a previous Exchange server version that are using POP3 to collect their mail – they simply cannot retrieve their emails!

Why are my Outbound Queues Filling up with Mail that we didn’t send?

If your emails are building up on your Exchange 2003 server and you don’t recognise any of the destination address then you have got a problem and need to resolve it.   To work out what your problem is, please double-click into one of the unknown domain name queues, then click on the Find Now button and then double-click into one of the messages that are returned.

Look at the sender of the message.  If the sender is postmaster@yourdomain.com, you are suffering from a Non Delivery Attack.  If the sender is a random user not in your organisation, then you are suffering from an Authenticated Relay attack.

Non Delivery Attack:

To prevent a Non-Delivery Attack, please turn on Recipient Filtering to reject recipients not in your organisation:

http://www.msexchange.org/tutorials/Sender-Recipient-Filtering.html

The reason for this is that you are currently accepting messages for anyone at yourcompany, even made up names.  If the recipient does not exist, your server is sending a Non-Delivery Report back to the sending email address and as spammers usually make up the sender address, the email message will not be able to go anywhere as the domain is invalid.  Some of the email addresses that spammers use will be valid email addresses and thus some Non-Delivery report mail will get sent out to people who did not send an email to you in the first place and they will potentially report you as a spammer.  Mail of this type is known as Backscatter and this can get you Blacklisted.  Please see  http://en.wikipedia.org/wiki/Backscatter_(e-mail) for more details.

If you also turn on Recipient Filtering, your server will reject recipients that are not setup on your server and the sending mail server will be responsible for sending a Non Delivery Report, not your server, thus shifting the problem back onto the spammer – http://www.msexchange.org/tutorials/Sender-Recipient-Filtering.html

Another tool that you can use to slow down spammers is to implement something called Tarpitting which forces a delay into the mail-flow process for anyone sending mail to an invalid address on your server.  This means that anyone targetting your server will spend lots of time waiting for a response from your server, slowing them down – http://support.microsoft.com/kb/842851

Authenticated Relay Attack:

If the sender is not postmaster@yourdomain.com and is some random address, please Open Exchange System Manager and expand Servers> Right-click the Server Name and choose Properties> Select the Diagnostics Logging tab.

In the Services window, select MSExchangeTransport, and in the Categories window increase the logging level for Authentication to maximum.  Once you have done this, keep an eye on your Application Event Logs looking for event ID 1708 and it should soon become apparent which account is being abused.  Once you know which user account is being abused, change the password for that account and then stop and restart the Simple Mail Transfer Protocol Service and then cleanup your queues (The Administrator account is the usual target for spammers).

Cleanup:

A really useful tool to help clear up the queues very quickly is Aquadmcli.exe which can be downloaded from ftp://ftp.microsoft.com/pss/Tools/Exchange%20Support%20Tools/Aqadmcli/aqadmcli.exe

Once downloaded – run from a command prompt and then use the following commands to empty the queue based on the sender address:

delmsg flags=sender,sender=sender@domain.com

To delete ALL messages in your queues, type the following:

delmsg flags=all

A good document to help you cleanup if you don’t like the above idea is – http://www.amset.info/exchange/spam-cleanup.asp

Once you have cleaned up – please return the logging level back to None.