Exchange 2010 – Cannot login after mailbox has been disabled and attached to different AD user account

I was asked to rename an Exchange account (sitting on an Exchange 2010 SP2 server) for a customer today because the surname had changed so to do this tidily, I disabled the Exchange Mailbox, cleaned up the Databases to make the mailbox appear in the Detached Mailboxes folder using the following Exchange Management Shell command:

get-mailboxdatabase | clean-mailboxdatabase

Once that had run, I then deleted the AD user account, created a new AD user account and then Connected the Detached Mailbox to the new AD user account.

All done – I then informed the user of the new login credentials and they then setup their Outlook account accordingly.

It was then that the problem occurred.  They couldn’t login to their account.  They tried OWA and that failed too, saying that the account was disabled!  What the heck?

I tried using OWA and also got Account Disabled and saw the following error message when expanding the error:

Exception type: Microsoft.Exchange.Data.Storage.AccountDisabledException

I checked the AD account and it wasn’t disabled.  Forced an AD Replication and that made no difference.  I disabled the account – replicated AD – enabled the account – replicated AD again and still couldn’t login to OWA.

After a few checks and some head scratching, I re-ran

get-mailboxdatabase | clean-mailboxdatabase

and then was able to login to OWA as the user and they could login to Outlook.

 

SBS 2003 to SBS 2011 Migration – 50Gb of Public Folders to Migrate took a week to migrate!

Having nearly completed yet another SBS 2003 to SBS 2011 Migration after the longest week of my life so far, I was amazed at how slowly the Public Folder Replica Move actually took to push 50Gb of data between the two servers.

Starting the project on a Monday and having the SBS 2011 server built by Monday afternoon (built virtually using Microsoft’s Hyper-V Server on a new HP ProLiant ML350 G6), I started to move the Exchange Mailboxes and then the Public Folder Replicas to the SBS 2011 server.  The network was originally running on a 10/100 Switch but I upgraded it to a Gigabit Switch on the Tuesday morning so that I had the maximum speed available and both servers had Gigabit cards in them.

At the end of the Tuesday, there were still dozens of Public Folders listed in the Public Folder Instances list in the Exchange System Manager, so I checked the SMTP Virtual Server Settings to see if there were any settings configured that might slow the process down and discovered several settings that would restrict the flow of emails.  The initial setting that I noticed was the “Limit session size to (KB):” setting.  This was limited to 40Mb and as some of the emails in the Public Folders were in the region of 30-40Mb in size, the session size was going to severely impact the flow of mail so I changed it to 1024000 (about 1Gb).

The other setting that I changed was the “Connection Timeout” value on the General Tab.  This was set to timeout after 10 minutes, so I increased the timeout to 2 hours, so that this wouldn’t cause any delays either.

I wasn’t unduly concerned at this point about problems with inbound mail and spammers clogging up the system as I had already installed a SAN/UCC SSL certificate (minimum 5 Domain Names) bought from www.exchange-certificates.com and had re-pointed port 25 to the SBS 2011 server.

So having made as many changes to the network and SMTP Virtual Server Settings (also restarting the Simple Mail Transport Service) I created a new Receive Connector on the SBS 2011 server to only receive mail from the IP Address of the SBS 2003 server and set the Maximum Message Size Limit to 50Mb and let the two servers talk to each other.

Sometime overnight on the Saturday after starting the migration, the whole 50Gb of Public Folders had migrated across to the SBS 2011 server and all the Public Folder Instances had disappeared!  A whole 5½ days later.

At one point during the PF Replication, I calculated that it was moving at about 500Mb per hour, so all in all, it was going to take in the region of 100 hours to move the entire database.

So – if you are planning a migration from SBS 2003 to SBS 2011 and you have a large Public Folder Database, don’t expect the migration to complete quickly.  Assuming the worst – a Public Folder Database with 75Gb of data in it, I would expect it to take about a week and a half just to push the data to the new server.

Happy migrating!

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

How To Configure Exchange 2010 To Delay Sending Of Emails With Large Attachments Until Approved By Moderator

Have you ever had a user on your network send out an email with a large attachment (or several large attachments) to a large number of recipients and brought your Exchange Server and Internet Connection to its knees as Exchange tries to send out all the messages with attachments as quickly as possible, flooding your outbound connection?

Well if that sounds familiar, then here is one way around the problem by use of Transport Rules.

With Exchange 2003 – you can make use of the option to delay large emails until after  hours, but this doesn’t exist in Exchange  2010, so you have to come up with an alternative plan to prevent this from happening.

The plan here is to setup a Transport Rule to send a message to the Administrator asking them to Approve or Reject the message containing the large attachment before Exchange starts to try and send the message(s) out, crippling your connection.

Open up Exchange System Manager and navigate to Organization Transport> Hub Transport> Transport Rules:

Once there, click on the New Transport Rule Wizard, give the new Rule a name and a Description to help you understand what the Rule does then click Next:

Select “From Users that are Inside or Outside The Organization”:

Then select “Sent to users that are inside or outside the organization, or partners”:

You then need to change the selection in Step 2 from Sent to users that are ‘Inside the organization’ to Outside the Organization:

Click OK.  The scroll down to the bottom of the list in Step 1 and select “When the size of any attachment is greater than or equal to limit”:

Once selected, click on the ‘0 B (0 bytes)’ in Step 2 and set the message size that you want to trigger the rule:

In the example above, I have set the size to 4Mb (4,096 Kb). Click OK after setting the size and then click on Next.

We now get to choose the Action to operate when the Criteria chosen is met and the action here is to forward the message to addresses for moderation:

Click on addresses in Step 2 and select your internal Recipient who is to receive the message to Accept / Reject:

Then click on the Add button to select the Internal Recipient:

Once you have selected the relevant recipient, click OK:

Then click on Next and add any Exceptions (if you wish) and click on Next:

We now see the completed rule:

Click on New to create the Rule.  Once completed, click on Finish to complete the Wizard:

You should now see the new Rule in the Transport Rules:

When the Rule is Triggered by an internal user sending a message with an attachment greater than 4Mb, the message will be forwarded to the chosen account for approval.  If approved, then the message will be sent out.  If rejected, the sender will receive a message advising that the message was not able to be sent and the Moderator can add a note as to why if they wish.

If you prefer doing things via the command line (Exchange Management Console), then you can use the following command to achieve the same result:

New-TransportRule -Name ‘Transport Rule Name‘ -Comments ‘Transport Rule Comment To Describe What It Does.‘ -Priority ‘0’ -Enabled $true -FromScope ‘InOrganization’ -SentToScope ‘NotInOrganization’ -AttachmentSizeOver ‘4 MB (4,194,304 bytes)’ -ModerateMessageByUser ’emailaddress@domain.co.uk’ -ModerateMessageByManager $false

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.

Windows Small Business Server 2011 Standard and Premium Add-on Released to Manufacturing

Today Microsoft announced that the next version of Small Business Server (2011) will be released to manufacturing. Early January will see the Volume Licensing versions released and from mid January, trial versions will be downloadable from the Microsoft Website.

Designed and priced for small businesses with up to 75 users, Windows Small Business Server 2011 Standard delivers enterprise-class server technology in an affordable, all-in-one solution. Windows Small Business Server 2011 Standard not only helps to protect, access, and manage your information from virtually anywhere, but also allows your business to be more productive by providing:
• A great way to manage email with the powerful new Microsoft® Exchange Server 2010 SP1. Securely access and manage your communications—e-mail, voice mail, instant messaging, and more—from virtually any platform, Web-browser, or device.
• A powerful collaboration suite with Microsoft SharePoint® Foundation Services 2010. Enable your employees to access and share your business documents with exciting features and capabilities that help you collaborate securely online—no matter where you are.
• A rich platform to run your business applications. SBS 2011 Standard allows you to take advantage of the vast library of applications compatible with Windows Server 2008R2 technologies.
• A simple installation/migration path to limit your downtime. SBS 2011 Standard has been designed to simplify the experience of upgrading or installing a new server.
If you have limited IT resources but still need to run a large number of applications, you should consider using the Windows Small Business Server 2011 Premium Add On to complement your SBS 2011 Standard deployment. Because the Premium Add-on includes SQL Server 2008 R2 for Small Businesses, it offers a dedicated, highly effective data management solution to run those applications that require a centralized database and shared information among users. Also with the Premium Add-on you have access to technologies like Hyper-V or Remote Desktop Services that Windows Server 2008 R2 Standard provides.

Exchange 2010 Service Pack 1 Released

Microsoft has just released Exchange 2010 Service Pack 1 today and you can download the update from the following link:
http://www.microsoft.com/downloads/details.aspx?FamilyID=50b32685-4356-49cc-8b37-d9c9d4ea3f5b&displaylang=en

More details to follow shortly.

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.