Category: Exchange Server

If you work in a place with a lot of remote users and a password policy with expiration set then you need to give your users a way to reset their passwords.  Microsoft ISA / TMG configured with forms based authentication were able to do this out of the box.  The good news is Exchange 2010 and 2013 also have the capability, it just needs to be enabled. Change the following registry entry at your own risk.

Go to the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA and then create the following REG_DWORD value if it doesn’t already exist ChangeExpiredPasswordEnabled. Once created set the DWORD value to 1.

Once you have done that simply recycle the OWA Web Application under IIS or give IIS itself a restart and your users will now be prompted to change their passwords if they are expired instead of having to call the IT helpdesk.

I’ve recently been contracting out to an educational organisation assisting with their BAU work as well as helping them modernising some of their processes and server environment. I was recently given a trouble ticket where I had to troubleshoot slow external mail flow. They have an ancient spam filtering appliance coupled with an Exchange 2013 deployment. My first look was onto the appliance, after checking out the inbound mail queue I could quickly see e-mails sitting there with the following response code;

452 4.3.1 Insufficient system resources

The above response code, which indicates a temporary failure generally means that Exchange is running out of resources and you’ll have the Exchange back-pressure issue where the Transport service will reject message submission because there is not enough free disk space (which is by default 10%). From the information I had their databases sat on another disk with at least 50% free space. Going through the even log I could find no trace of this. Their Mailbox Database servers were also Transport servers so they performed messaging queuing that meant I had another database that should be taken into consideration, which is the Message Queue database. By default it sits in the C:\Program Files\Microsoft\Exchange Server\ directory and is not easily configured to be moved like a standard mailbox database using PowerShell.

As I was unsure of their environment, I quickly navigated to EdgeTransport.exe.config file located under the Bin directory and found the value of QueueDatabasePath pointing to their C drive which had only around 5% free space. I then quickly cleared out some log files that are not required and wrote up a PowerShell script that will run nightly until more space is provisioned on those servers.

Moral of the story is always give your Exchange servers plenty of free space to prevent such issues.

Recently, I was conducting some investigative work around mail delivery for a client.  PowerShell cmdlets for Exchange are awesome and give us as administrators some real power in trying to figure out what is wrong.  Some things in PowerShell though don’t take into account the regional language settings of the machine you’re working on.  One example of this that left me scratching my head a little was when I was running Get-MessageTackingLog. Being in Australia we do our date as dd/mm/yyyy so I had the following command ready to run

Get-MessageTrackingLog -Server SRV-MBX-02 -Start "14/08/2014 08:00:00" 
-End "14/08/2014 15:00:00" -Sender "[email protected]" | 
ConvertTo-Html > "C:\Scripts\MsgTrack.html"

When I ran this I got an error around trying to convert a DateTime, I was sure I had entered the right format (also trying – and .)

Cannot process argument transformation on parameter 'Start'. Cannot convert value "14/08/2014 08:00:00" to type "System
.DateTime". Error: "String was not recognized as a valid DateTime.
    + CategoryInfo          : InvalidData: (:) [Get-MessageTrackingLog], ParameterBindin...mationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-MessageTrackingLog

After a few minutes, I worked out the date needed to be in US Date/Time format of mm/dd/yyy. Swaping around my month and day got the command to work correctly and pipe out what I was after to a html page.

Interestingly, if you copy and paste a command out of the Tracking Log explorer the date and time format in there is based on the regional settings of the computer you are on, but run them through the Exchange Management Shell and you’ll also receive the above date/time error.

I was recently helping out an old work colleague who were having issues with their CRM software and sending bulk emails through their Exchange 2010 server. After around ten minutes they would receive an error message with connection closed gracefully.  They would then have to restart their mail out and need to monitor it for this issue to ensure it didn’t get stuck every ten minutes with this error.

After poking around their receive connectors on their hub transport server I noticed that the particular connector (for their internal applications) they were using had a connection time out of 10 minutes, which would result in us receiving the connection closed gracefully error from our end user application.  The fix for this is to simply increase the ConnectionTimeout value for our Recieve Connector to anything reasonable, for us it is 3 hours. We would do by issuing the following Exchange PowerShell command:

Set-ReceiveConnector "Internal Connector - Synergetic" -ConnectionTimeout 03:00:00 -ConnectionInactivityTimeout 01:00:00

You will want to make sure that your receive connector is protected (i.e. is only set to allow internal networks) as this basically allows anything to stay connected for up to 3 hours so it could be abused.