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

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

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.

Update Rollup 1 for Exchange Server 2007 Service Pack 3 released today

Today Microsoft released Update Rollup 1 for Exchange 2007 Service Pack 3 (after I just installed SP3 on an SBS 2008 box today!). Thanks Microsoft – perfect timing (LOL).

This update can be downloaded from the following link:

How To Close An Open Relay In Exchange 2007 / 2010

If you have an Exchange 2007 or Exchange 2010 server and you discover that you are an Open Relay, there is a very simple command that you can run from the Exchange Management Shell to close this down.

The command is:

Get-ReceiveConnector “YourReceiveConnectorName” | Remove-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

Replace “YourReceiveConnector” with the name of your Receive Connector and then run the command.

To test if you are an open relay, you can visit MXToolbox or Mailradar.

If you want to check to see if you are allowing “ms-Exch-SMTP-Accept-Any-Recipient” on any Receive Connector for Anonymous Users, run the following command from the Exchange Management Shell:

Get-ReceiveConnector | Get-ADPermission | where {($_.ExtendedRights -like “*SMTP-Accept-Any-Recipient*”)} | where {$_.User -like ‘*anonymous*’} | ft identity,user,extendedrights

08/04/2014 Update – If you still have a problem after modifying your receive connector(s) accordingly, please make sure you or someone else hasn’t installed the SMTP Service on the Exchange Server.  I was emailed about such a problem with an Exchange 2010 server the other day and the having stopped ALL of the Exchange Services the server was STILL an Open Relay.  With a quick NETSTAT command to see what was listening on port 25, I soon discovered the SMTP service was present and enabled.  Having disabled the service and restarting all the Exchange Services, the Open Relay problem disappeared immediately.

Exchange 2007 Service Pack 3 Released

Microsoft released Exchange 2007 Service Pack 3 today and this can be downloaded from the following link:

http://www.microsoft.com/downloads/details.aspx?FamilyID=1687160b-634a-43cb-a65a-f355cff0afa6&displaylang=en

Overview
Microsoft Exchange Server 2007 Service Pack 3 (SP3) has been designed specifically to meet the challenges facing our customers and to help address the needs of all the different businesses and organizations utilizing our Exchange Server 2007 enterprise messaging system.

Exchange Server 2007 SP3 is a mission-critical communications tool that enables employees to be more productive and access their information anywhere and anytime while providing a messaging system that enables rich, efficient access to e-mail, calendar items, voice mail, and contacts.

For administrators, Exchange Server 2007 SP3 provides further flexibility with the addition of Windows Server 2008 R2 support for server roles and Windows 7 support for the Exchange management tools. These additions, along with enhancements for the advanced protection options against e-mail security threats, such as spam and viruses and the tools which help manage internal compliance and high availability needs provide Exchange administrators with the tools they need to manage their Exchange 2007 environments efficiently.

Clean installations of Exchange 2007 SP3 on a new server are possible by using this download in the same manner as you would install Exchange 2007 RTM, Exchange 2007 SP1 or Exchange 2007 SP2.

> New Deployment Options
> Windows Server 2008 R2 Support
Exchange Server 2007 SP3 supports all Exchange 2007 roles on the Windows Server 2008 R2 operating system.

Exchange 2007 SP3 provides support only for a new installation of Exchange on Windows Server 2008 R2. Exchange 2007 SP3 is not supported in an upgrade scenario on Windows Server 2008 R2. For example, Exchange 2007 SP3 does not support the following installation scenarios:

A new Exchange 2007 SP3 installation on a Windows Server 2008 R2-based computer that has been upgraded from Windows Server 2008

Upgrading Exchange 2007 SP2 to Exchange 2007 SP3 on a Windows Server 2008 R2-based computer that has been upgraded from Windows Server 2008

Upgrading the operating system from Windows Server 2008 to Windows Server 2008 R2 on a computer that has Exchange 2007 SP3 installed

For more information about the installation prerequisites for installing Exchange 2007 SP3 on a Windows Server 2008 R2-based computer, see How to Install Exchange 2007 SP1 and SP2 Prerequisites on Windows Server 2008 or Windows Vista. For more information about the supported operating systems for Exchange 2007 SP3, see Exchange 2007 System Requirements.

> Windows 7 Support
Exchange 2007 SP3 supports the installation of the Exchange 2007 management tools on a computer that is running Windows 7. Additionally, Exchange 2007 SP3 provides support for the installation of the Exchange 2007 Management Tools together with the Exchange Server 2010 Management Tools on the same Windows 7-based computer.

Exchange 2007 SP3 provides support only for a new installation of the Exchange Management Tools on Windows 7. Exchange 2007 SP3 is not supported in an upgrade scenario on Windows 7. For example, Exchange 2007 SP3 does not support the following installation scenarios:

A new Exchange 2007 SP3 installation on a Windows 7-based computer that has been upgraded from Windows Vista

Upgrading Exchange 2007 SP2 to Exchange 2007 SP3 on a Windows 7-based computer that has been upgraded from Windows Vista

Upgrading the operating system from Windows Vista to Windows 7 with Exchange 2007 on a computer that has Exchange 2007 SP3 installed

For more information about how to install the Exchange 2007 management tools, see How to Install the Exchange 2007 Management Tools.

> Improved Password Reset Functionality
Exchange 2007 SP3 introduces password reset functionality for Internet Information Services (IIS) 7. For more information, see How to Enable the Exchange 2007 SP3 Password Reset Tool.

> Updated Search Functionality
Exchange 2007 SP3 includes updates to the Exchange Search (MSSearch) component. MSSearch provides support for creating full text indexes for Exchange stores. Exchange 2007 SP3 updates the MSSearch binary files to MSSearch 3.1.

> Schema Changes
Exchange 2007 SP3 includes Active Directory schema changes for certain Unified Messaging (UM) mailbox attributes. For more information, see Active Directory Schema Changes (SP3).

> Support for Right-to-Left Disclaimer Text
Exchange 2007 SP3 includes support for Right-to-Left text in e-mail message disclaimers in a right-to-left language, such as Arabic. In earlier versions of Exchange, when you use a transport rule to create a disclaimer in a right-to-left language on an Exchange 2007 Hub Transport server, the text appears incorrectly when you view it from Outlook 2007.

Exchange 2007 SP3 adds functionality to the transport rule setting to fully support right-to-left text in disclaimers.

Prevent Spam Mail From Your Own Domain in Exchange 2007

One of the biggest bug-bears with spam is the spam that comes from (or supposedly comes from) random_username@yourdomain.com or even your_username@yourdomain.com. This is known as spoofed mail and is a common technique that spammers use to try to get mail past Anti-Spam software.

From the Anti-Spam logs on my own server in the last 24-hours, I have received 1,974 emails (out of 17,432 in total) where the sender domain matched the recipient domain. This is about 11.3% of all mail that hit my server, so it is a relatively large problem. Factor that up to a year’s worth of mail and you get 720,510 a year.

To prevent this from happening, you simply need to remove a specific permission that allows anonymous senders to use your internal domain names in the Mail From section of an email. If anyone tries to do this (anonymous users only) they will receive a “550 5.7.1 Client does not have permissions to send as this sender” message.

The syntax to remove the permission should be entered as follows in the Exchange Management Console:

Get-ReceiveConnector “My Internet Receive Connector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

(You need to change the “My Internet Receive Connector” part in the above syntax)

Having run this command successfully, test using Telnet to your mail server from an external computer and see what happens if you try to send mail as one of your internal domain names. You should receive the 550 5.7.1 Message.

N.B. To put the permission back (in case you need to), please run the following:
Get-ReceiveConnector “My Internet Receive Connector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Add-ADPermission

If you have internal photocopiers and other hardware that needs to relay via your Exchange 2007 server and you cannot configure them with a username / password, then removing the above permissions will prevent you from relaying and will cause you problems.

Activesync Working But Only For Some Users On Exchange 2007 / 2010

There are some issues with Activesync for both Exchange 2007 and Exchange 2010 users whereby some users can connect their Mobile Devices (Windows Mobile Phones / iPhones / Motorola Droid etc) quite happily and Activesync pushes mail to the devices, but other users cannot connect and cannot sync anything at all.

There appear to be plenty of potential solutions for this problem around if you search the web, but the solution to the majority of these problems can be solved quite simply.

If you open up Active Directory Users and Computers and locate one of your users that is not working, Double-Click into the account and click on the Security Tab (if this is not visible, Click on View> Advanced Features from the Menu at the top of the screen then navigate back to your user). Once on the security tab, click on the Advanced Button and make sure that the ‘Include Inheritable Permissions From This Object’s Parent’ is ticked. Click OK twice to close the user account.

Once the box is ticked, you should then be able to connect up your Mobile Device to your Exchange Server and receive your mail like the rest of your users.

This particular problem seems to only affect migrated users and not users that were setup on the server post migration.

You may also find that if you use an account that has Admin privileges, and you Check the ‘Include Inheritable Permissions From This Object’s Parent’ check box, that it works for a while, and then stops working again about an hour or so later.

The reason this happens is because Active Directory uses something called the AdminSDHolder to define what permissions the default protected security groups receive. Whilst you can change the inherited permissions, a process called SDPROP will run, by default every 60 minutes on the domain controller that holds the PDCe role. It will check the ACL of the protected groups and reset their inherited permissions and the users within the groups, with what has been defined by the AdminSDHolder object.

Microsoft’s recommendation and best practice is that if you are a domain administrator that you have 2 accounts. One for your everyday user which is restricted in the same way that every other user is and a second for your administration role.

The built in groups that are affected with Windows 2008 are:
Account Operators
Administrators
Backup Operators
Domain Admins
Domain Controllers
Enterprise Admins
Print Operators
Read-only Domain Controllers
Replicator
Schema Admins
Server Operators

The built in users that are affected with Windows 2008 are:
Administrator
Krbtgt

Many thanks to Glen Knight aka Demazter for the section about AdminSDHolder.

The following blog shows a way to get around the issue if you want to maintain Activesync with an Administrator Account (use at your own risk):
http://retrohack.com/enable-activesync-outlook-anywhere-exchange-2010/

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.