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

Yet more Bad IT Support Companies!

Following on from my earlier Blog Post about bad IT Support Companies (here) I visited a potential new customer today to look over their IT.  The background information I got from the company was that they had used their existing IT Support Company (a one-man band) for the past 5 years or so and whilst mostly happy with their service, there were some outstanding issues that were being neglected and this was causing some concern to the company.

They had recently installed a ‘server’ and their IT wasn’t running as smoothly as they had anticipated, so wanted to get a 2nd opinion about their setup and my company (IT Eye Ltd) was recommended by a mutual company.

Once I arrived, I had a quick look over their IT and came across 4 PCs and a Netbook.  Asking where the server was, I was directed towards an HP xw6600 Workstation with a label on it suggesting it had come out of a company in New York City (NYC-XXXXXXXXX)!  I then used Remote Desktop to connect to the server and discovered that it was running SBS 2008.  This prompted the question about when the server was purchased and I was told May of 2012.  I then asked how much they had paid for the server and they advised me £2,500.

Okay – so they had a recently installed SBS 2008 server of which Exchange 2007 was now no longer supported by Microsoft because the Mainstream Support had now expired!  That begged the question why SBS 2011 wasn’t installed and to that there wasn’t an answer.  I then looked for a license sticker and couldn’t find one, so that also begged the question if they were actually legal.  This conversation continued to the other workstations and no conclusive evidence was available to suggest that they were even remotely compliant.

Looking at one of the XP workstations I saw that it was running XP pro, so checked to see if it was part of the Domain and saw that it was still configured as a Workgroup.

Data was being shared from the server, so at least the server was being used for something other than a drain on their electricity bill, but data was still being held on the Netbook and the data wasn’t being copied to the server or backed up, so was at risk of being lost.  No evidence of server backup was visible either.

I then asked about emails and found out that they were being hosted externally (1and1) and were being collected via Outlook configured as an SMTP/POP3 account and to allow for shared calendars to be accessed, they had turned to Google Mail.

I then pointed out that their server had Exchange built-in and that they need not pay for mail to be hosted externally or use Google Mail for shared Calendars as they could do everything on their own server.

At this point – I think they had decided that they were not being well looked after by their existing IT Support Company and I left them pondering my findings.  We will wait to hear from them and see how they want to proceed.

Alan

Users Connecting To Exchange 2010 (SBS 2011) Using Outlook 2010 Getting Password Prompts Randomly

I had an email from a customer recently who has an SBS 2011 server (with Exchange 2010) running virtually on an HP Proliant ML350 G6 server (which I had installed for them) and they were reporting that a couple of users were getting password prompts at random times.  This wasn’t affecting all users, so I knew it wasn’t a server-side issue, especially because I installed a trusted 3rd party SSL certificate from www.exchange-certificates.com so asked a few questions and it seemed that this only happened after the machines had been left idle for a while.

My initial thoughts were that there might be some issues with the Network Card having Power Management enabled on it which allowed the PC to turn off power to the NIC to save energy, so I asked my customer to check the NIC settings and sure enough, the Power Management setting to “Allow the computer to turn off this device to save power” was enabled.  After disabling this option, the problem went away and has not returned.

Having had someone ask a similar question on http://www.experts-exchange.com and the solution being the same, I felt it rude not to share this discovery so that others might benefit from this discovery.

To disable this option, click on Start> Run> {type} ncpa.cpl {and press enter}, then right-click on your Wired / Wireless Network Card and choose properties.

On the Network Card Properties, click on the Configure Button (see image below)

then click on the Power Management Tab (see image below)

and make sure that the “Allow the computer to turn off this device to save power” check box is not ticked.

Once you no longer have the computer turning off the power to the network card, it shouldn’t lose connectivity to the server and thus won’t be prompting you for your credentials when you go to use Outlook again.

 

Schedule a Transport Rule to be Enabled or Disabled at a Specific Time of Day / Day of the Week

The Problem:

In Exchange 2003, you could configure Exchange to delay the sending of large attachments until after hours, which was very useful if you have users that don’t think twice before creating an email and attaching dozens of their most recent photographs in the email, then adding 20 or 30+ recipients to the email and hitting send – causing your Exchange server to go into melt-down as it tries its best to push all the emails out as quickly as possible.

So – having upgraded to Exchange 2007 or Exchange 2010 you may have discovered that this options doesn’t exist any more, so you may find from time-to-time that your Internet connection suddenly grinds to a halt and if you dig hard enough, you may find the problem is sitting in your outbound Queues on your Exchange Server.

So – what to do about this?

Half a Solution:

You can create an Exchange Transport Rule to force large emails to be approved (before they are sent out), by a Manager or a Moderator which at least enables the Manager / Moderator to have to Approve the email before they clog up the Exchange Queues but as we are now living in a 24×7 age, if you don’t want to have to approve / reject the emails in the evenings or over the weekend, there is no option in the Transport Rule to schedule the times that the Rule applies!  Quite frustrating, especially over a long weekend.

The Whole Solution:

The answer (well, my answer) to this is to create two Powershell Scripts, two batch files and a two Scheduled Tasks to Enable / Disable the Transport Rule at specific times (Disable after hours on Weekdays / Enable before work starts on Weekdays).

Start by creating a new folder on your Exchange server called Scripts on any drive you like (I will be using E:\scripts in my example).

Then open up Notepad and copy / paste the scripts below (one script per file) and then save the files as DisableTransportRule.ps1 and EnableTransportRule.ps1 in the E:\Scripts folder.

The PowerShell Scripts:

Disable Transport Rule:

# Script to Disable a Transport Rule
Disable-TransportRule “Rule_Name” -confirm:$false

Enable Transport Rule:

# Script to Enable a Transport Rule
Enable-TransportRule “Rule_Name” -confirm:$false

The Batch Files:

Open up Notepad and copy / paste the single line commands below (one command per file) and then save the files as DisableRule.bat and EnableRule.bat in the E:\Scripts folder.

Disable Transport Rule Batch File:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1’; Connect-ExchangeServer -auto; e:\Scripts\DisableTransportRule.ps1”

Enable Transport Rule Batch File:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1’; Connect-ExchangeServer -auto; e:\Scripts\EnableTransportRule.ps1”

Scheduled Tasks:

Open up Server Manager and Expand Configuration> Task Scheduler.  In the Actions Pane, click on Create Task…..

 

On the General Tab, Name the Task according to the rule you want to run e.g., Disable Transport Rule, then Select ‘Run whether user is logged on or not” and “Run with highest privileges”.

On the Triggers Tab, Click on New and Select “Weekly” and enable the days of the week you want the rule to run e.g., Mon to Fri.  Set the time you want the rule to run e.g., 18:00:00 hours and tick the “Enabled” box and click OK.

On the Actions Tab, Click on New and the default option is to Start a Program.  Leave this selected and in the Program/script: window, click on Browse and select ‘e:\scripts\disable.bat’, then in the Start in (optional): box, enter ‘e:\scripts’ and click on OK.

We don’t need to add anything to the Conditions Tab or the Settings Tab, so click OK and then enter the relevant username / password for the account you want to use to run the Scheduled Task as (usually an Administrator account).

Repeat the above for the Enable.bat file.

One last step:

Before these commands will run properly, you need to run the following command in the Exchange Management Shell:

Set-ExecutionPolicy RemoteSigned

This command allows Powershell to interact with the Exchange Management Shell.

Summary:

So – you should now have two Scheduled Tasks that Disable your Transport Rule at a specified time on specific days (mine are Disabled at 18:00:00 hrs Mon – Fri) and another Scheduled Task to Enable the Transport Rule at a specific time one specific days (mine are enabled at 07:30:00 hrs Mon-Fri), so now, after hours and at weekends, you won’t have to approve emails for your Exchange organisation and if someone sends out an email with large attachments to multiple users, there is less impact on the rest of the workforce.

Alan

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!).

Why are there so many bad IT Support companies out there who don’t have the first idea about IT?

Having taken on two new customers with SBS 2003 servers within the last week, the first server was in a very bad way with 58Gb of Exchange logs piled up since the last Exchange full backup in about August 2010 and the SBS 2003 backup hadn’t worked since the 23rd August 2011 (we 1st saw the server on the 15th September).

The SBS backup was configured but fell over the second it tried to start.  After a quick poke about, I edited the selections in the SBS backup job and then re-ran the backup.  This time it worked and started to backup.  It subsequently failed with a corrupt font file in the ClientApps\Outlook 2003 folder (so I replaced the file from the CD) and problems with the Exchange database, so I took the store offline, ran a repair (eseutil /p), defragmentation (eseutil /d) and integrity check (isinteg) and that solved those problems.  The backups are now running to the end and all 58Gb of Exchange logs have been purged from the disk – finally!

Updates had not been downloaded / installed on the server and WSUS was installed but had not synced to Microsoft since it was installed.  All very basic, simple maintenance tasks that should be performed by any competent IT company.

Backup Exec was installed – heaven knows why – as it wasn’t being used.  Probably made the IT support guy some money selling software that wasn’t necessary I suppose.

There were various errors showing up in the Event Logs, mainly Disk errors and IP AUTD failed to Initialize (simple registry fix for this).  A quick tweak to the registry and a restart of the DNS Server service and the IP AUTD error went away (see KB956189).  Waiting to run a disk check to clear the disk errors.

This customer apparently lost all their data when their server crashed recently and it took the IT guy 3 weeks to get their data back.  Presumably after this, they would have made sure the backups were working 100% – but this doesn’t seem to be the case.

Symantec Anti-Virus Management Console was installed – but there were no clients using Symantec Anti-Virus.  Symantec Mail Security for Microsoft Exchange was also installed, but the definitions expired in August 2008, so spam filtering wasn’t going to work, but then as they were using POP3 collection for their emails, what good was Symantec Mail Security going to do for them as it can’t scan POP3 collected mail – only SMTP delivered mail!

Turkey, Poland and Spain were very interested in the server and trying on a minute by minute basis to try and breach the Administrator account – so far unsuccessfully, but it probably won’t take them long if nothing is done to stop the attacks.  As soon as we get the go-ahead to start fixing the various issues – we will be bolting the server down and monitoring it for unwanted attention from foreign parts.

Having been shocked by one server in a week, we secured another customer and started to examine their server in detail, installing some monitoring software which picked up a lack of a completed backup by the SBS backup job, or the Backup Exec software that was also installed (but not configured).

On the second server – the SBS backup was configured to run and was happily running, but as soon as the backup had written about 4Gb of data to the external HDD used for the backups, the backup failed!  Guess what – the drive was formatted as FAT32 not NTFS so the backups were doomed from the start.  A quick re-format of the disk and the backup now completes successfully.

I have only scratched the surface of the 2nd server, so anticipate more problems to surface, but I just can’t believe how two different IT Support companies can provide such useless support and actually charge for their services.  It is beyond belief.

So – if you are happy with your current IT Support company then great.  Why not try asking them to recover a file from backup that you have accidentally deleted (moved to your Personal Computer) and see how long it takes them to recover it.

If you want an IT Support company that makes sure that the servers they look after are backing up properly, have Anti-Virus software installed and updated, doesn’t let spam through to the users because of excellent Anti-Spam software, then please give me a call or drop me an email.  I can happily review your existing servers and advise you if your backups are working properly or if something else is going wrong but you are blissfully unaware of it.

Potential for database corruption as a result of installing Exchange 2007 SP3 RU3

The Exchange Product Group was made aware of an issue which may lead to database corruption if you are running Exchange 2007 Service Pack 3 with Update Rollup 3 (Exchange 2007 SP3 RU3). Specifically, the issue was introduced in Exchange 2007 SP3 RU3 by a change in how the database is grown during transaction log replay when new data is written to the database file and there are no available free pages to be consumed.

This issue is of specific concern in two scenarios: 1) when transaction log replay is performed by the Replication Service as part of ensuring the passive database copy is up-to-date and/or 2) when a database is not cleanly shut down and recovery occurs.

For the full details, please read the following blog from the Exchange Team.

http://blogs.technet.com/b/exchange/archive/2011/03/29/potential-for-database-corruption-as-a-result-of-installing-exchange-2007-sp3-ru3.aspx

Constantcontact.com Mail Servers Cannot Send mail to servers using Greylisting!

We have recently started using Constantcontact.com to keep our customers up-to-date with the goings on at our company and have been very happy with the service until today when we looked at the number of invalid email addresses that were being reported. Upon investigation, we even discovered that the emails to our own servers that use Vamsoft ORF for Anti-Spam filtering, with Greylisting configured, was not receiving any of the emails being sent from Constantcontact.com.

For those of you that don’t know what Greylisting is, it is a method used by Anti-Spam software to reject the first send attempt from an email address that the server has not received mail from before. Because most spammers will only try to send a message once, then move on to the next target, they don’t usually come back to try again. As an anti-spam tool, this technique is incredibly effective. If the sending mail server tries to send the message again, then the receiving server using Greylisting will not reject the second connection attempt unless it has other issues with the sender, the sending server or the sender’s IP Address etc.

Getting back to Constantcontact.com – having contacted their support team, it was determined that their servers only ever send a message the once and if they encounter a server that uses Greylisting, their servers cannot distinguish between an invalid email address rejection message (550 5.1.1 Unknown User Error) and a Temporary Rejection Message (451 4.7.1 Temporary Rejected – Try Again Later), so they fail the send attempt and class this as an invalid email address. They advise that an email will get tried again 16 days later, but most Greylisting software has a timeout of 24 hours, by which time if they haven’t heard back from the sending server, they then temporarily reject the next connection attempt and then start the 24-hour countdown again. With a 16-day retry interval, the mail from Constant Contact will NEVER reach a mail server using Greylisting.

The support team at Constant Contact’s advice was to contact the recipients and request that they Whitelist (expressly allow mail from their mail servers) the Constant Contact IP Addresses. Considering that we had about 150 “Invalid Email Address” rejections out of about 500 messages, we didn’t find the suggestion that we should contact every customer who they couldn’t email to ask them to Whitelist the Constant Contact mail server addresses a very helpful or indeed practical solution.

As an Exchange Administrator – I am reluctant to Whitelist IP Addresses / mail servers as this can open up the receiving server to problems should the sending server that is Whitelisted become infected. As the problem would appear to be an issue with the mail server configuration at Constant Contact not retrying an email, we have decided to look for an alternative provider that can work properly with servers using Greylisting.

If you send out messages using Constant Contact and have plenty of “Invalid Email Addresses” in your mailing list, then you need to think about using a different provider until they change their working practises because the chances are your email addresses are perfectly valid, but you won’t ever be able to send them emails using Constant Contact.

You have been warned.

****** UPDATE *******

Further to the above information, it now appears that Constant Contact can work happily with Greylisting servers, but the bigger problem that they face at the moment is being blacklisted on pretty much all their servers by UCEProtect Level 1.

Exchange 2007 / 2010 Inbound Mail-flow Suddenly Stops – Quick Fix

What is Backpressure?
Backpressure is a new ‘feature’ in Exchange 2007 / 2010 where Exchange actually monitors resources such as Free Disk Space on the disk where the Exchange Message Queue / Message Queue Transaction Logs live and the Memory that the Edgetransport.exe process is using and memory in general used by other processes.

How do I know if my server is suffering from Backpressure?
If one or more items being monitored hits pre-defined limit, then Exchange will stop inbound mail-flow, so usually the first thing that you notice is that all of a sudden, you are not receiving emails from the rest of the world. You will be able to continue to send emails, you just won’t receive and new emails.

Look in your event logs and if Backpressure is being applied, you will see Event ID’s 15006 or 15007 in the logs:

Event log entry for critically low available disk space
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15006
Description: The Microsoft Exchange Transport service is rejecting messages because available disk space is below the configured threshold. Administrative action may be required to free disk space for the service to continue operations.

Event log entry for critically low available memory
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15007
Description: The Microsoft Exchange Transport service is rejecting message submissions because the service continues to consume more memory than the configured threshold. This may require that this service be restarted to continue normal operation.

How do I get mail-flow restored quickly?
For a quick fix, modify the edgetransport.exe.config file (notepad works happily for this) found in c:\program files\microsoft\exchange server\bin (Exchange 2007) or c:\program files\microsoft\exchange server\v14\bin (Exchange 2010)

Search for and change the “EnableResourceMonitoring” from “True” to “False”, save and close the file, then restart the Microsoft Exchange Transport Service.

Okay – so mail-flow has been restored – what to do next?

Once your inbound mail-flow has returned (assuming disk space is an issue, which has been the case every time I have seen Backpressure applied), then tidy up your drives and if you are not backing up your Exchange Server (which will purge the Exchange Log files), then make sure you do!

Once you have tidied up your drives and freed up some disk space, set the “EnableResourceMonitoring” back to “True” in the edgetransport.exe.config file and then restart the Microsoft Exchange Transport service again.

Further reading:
Exchange 2007 – Microsoft Backpressure Article:
http://technet.microsoft.com/en-us/library/bb201658(EXCHG.80).aspx

Exchange 2010 – Microsoft Backpressure Article:
http://technet.microsoft.com/en-us/library/bb201658.aspx

Backing Up Exchange 2010 with Windows Backup:

Backup Exchange 2010 Information Store using Windows Backup

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.