Bypassing Anti-Spam on an Exchange 2007/2010 Receive Connector

I was looking at an old Exchange environment that was being used to send bulk mail outs. We noticed every now and again a bunch of e-mails would not be getting sent, trawling through Message Tracking Logs we could see that the messages were failing because of an AGENT FAIL which usually means that there is a transport agent blocking those messages.

The customer still wanted the anti-spam agents enabled so instead we used PowerShell to modify the receive connector to bypass the Spam Filtering by giving the anonymous logon extended right ms-exch-bypass-anti-spam. Use the following PowerShell cmdlet and modify the Receive Connector with the name of your Connector.

Get-ReceiveConnector "Receive Connector" | Add-ADPermission 
-User "NT AuthorityAnonymous Logon" -AccessRights ExtendedRight 
-ExtendedRights ms-exch-bypass-anti-spam

Hope that helps.

Make viewing and sorting Exchange 2013 / 2016 Message Tracking Logs using PowerShell easier with GridView

exchange2010-powershell-logoSo a lot of environments are making the jump to Exchange 2013/2016 away from 2007/2010. From a management point of view the largest change is the move away from a GUI Management option to web-based and PowerShell management. One of the tools missing is the Message Tracking tool, which in a basic form is available on the Web Console but is difficult to use for external mail items so then we move onto PowerShell which gives us what we want but not in the format that is the easiest to understand.

You can use things like FormatList or FormatTable to make things a little prettier but a nicer trick I learned recently was to use Out-GridView which formats things into a new window which we can apply filters to. An example of Get-MessageTrackingLog piped to GridView is below (see the image for the example output)

Get-MessageTrackingLog -ResultSize Unlimited -Start "November 10 2016" -End "November 30 2016" -Recipient "[email protected]" | Out-GridView

Using the GridView we can easily apply filters to further narrow down our search easier.

Adjust resource mailbox calendar permissions on Exchange 2010/2013 using PowerShell

Quick one today.  By default, when creating a room resource mailbox, Exchange will grant default permissions of AvailabilityOnly for any user (default), if you are after people knowing who has booked a room or resource then you can adjust the permissions to Reviewer. The quickest way to do this is via PowerShell, you can use the following cmdlet;

Add-MailboxFolderPermission -Identity MeetingRoom2:\Calendar -user "Staff - All Staff" -AccessRight Reviewer

I am using a group (called Staff – All Staff) in the above that does not have any permissions already applied to that mailbox calendar. If the user or group already has some kind of permission, you will need to use Set-MailboxFolderPermissions instead of Add-MailboxFolderPermissions.

If you have multiple Resource Mailboxes, you can pipe a Get-Mailbox to hit them all at once like so;

$rooms = Get-Mailbox -RecipientTypeDetails RoomMailbox
$rooms | %{Add-MailboxFolderPermission $_":\Calendar" -User "Staff - All Staff" -AccessRights Reviewer}

Hope that helps.

Enable a user to Change their Password if it has Expired using OWA for Exchange 2010 and 2013

OWA Change PasswordIf 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.

Troubleshooting 4.3.1 Insufficient System Resources Error for External Mail Flow on Exchange 2013

EdgeTransport.exe.config QueueDatabasePathI’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.

Setting item level (Calendar, Tasks etc) permissions for Mailboxes and Users with PowerShell for Exchange 2007, 2010 and 2013

Every so often I get a request to allow people to view someone else’s calendar. Usually I just tell that person to go and ask whom ever the calendar belongs to, to give them permission. This isn’t always possible though as on a few occasions where I’ve had to give access because that other person is away.

With mailboxes you can use the management tools to give access rights, but what if I just want to give the, access to a calendar or tasks for example. This is where the exchange PowerShell console comes in. I can give a user Permission to a particular object. So for example I wanted to give user1 permission to edit manager 1’s calendar, I would do the following

Add-MailboxFolderPermission -identity manager1:\Calendar
-user user1 -accessrights Editor

You can use the following on all of the Outlook Exchanged based folders like so replacing <User> with the identity of the mailbox with the object you want to modify the permissions of and <delegate_user> with the username of the person of who you are giving permission to;

Add-MailboxFolderPermission &lt;User&gt;:\Calendar -User &lt;delegate_user&gt; -AccessRights Editor
Add-MailboxFolderPermission &lt;User&gt;:\Tasks -User &lt;delegate_user&gt; -AccessRights None
Add-MailboxFolderPermission &lt;User&gt;:\Inbox -User &lt;delegate_user&gt; -AccessRights None
Add-MailboxFolderPermission &lt;User&gt;:\Contacts -User &lt;delegate_user&gt; -AccessRights None
Add-MailboxFolderPermission &lt;User&gt;:\Notes -User &lt;delegate_user&gt; -AccessRights None
Add-MailboxFolderPermission &lt;User&gt;:\Journal -User &lt;delegate_user&gt; -AccessRights None

You can also quickly check who has access to an object (like a calendar) by using the following cmdlet, again replacing <user> with the identity of the mailbox;

get-mailboxfolderpermission -identity &lt;user&gt;:\Calendar

Hope that helps someone.

Getting Folder Sizes and number of items in a Mailbox for a particular user on Microsoft Exchange using PowerShell

Recently one of our high-end users was going over their mailbox limit. In helping them to cut down I like to let them know what folders are using up the most of their quota (generally it is their sent items folder, but sometimes not). Executing the below PowerShell command in an Exchange Administration Shell gave me a nice ordered list (see output below) of folders in their mailbox along with an associated size and number of items.

Get-MailboxFolderStatistics -Identity <username> | Sort-Object FolderSize 
-Descending | FT folderpath, foldersize, ItemsinFolder -autosize

After executing the above PowerShell you’ll get an output similar to the below

FolderPath                    FolderSize                  ItemsInFolder
----------                    ----------                  -------------
/Inbox                        32.89 MB (34,486,717 bytes)           158
/Carbon Copies                16.9 MB (17,725,567 bytes)            168
/Sent Items                   685.3 KB (701,797 bytes)               14
/Deleted Items                554.4 KB (567,723 bytes)              189
/Calendar                     27.6 KB (28,267 bytes)                  7
/Contacts                     1.492 KB (1,528 bytes)                  4
/Drafts                       138 B (138 bytes)                       1
/Sync Issues/Local Failures   0 B (0 bytes)                           0
/Sync Issues/Conflicts        0 B (0 bytes)                           0
/Sync Issues                  0 B (0 bytes)                           0
/Sync Issues/Server Failures  0 B (0 bytes)                           0

From this I can could then give to the user so they could clear out their mailbox. Hope that helps someone out.

Get-MessageTackingLog cmdlet for Exchange 2010 Returns Cannot process argument transformation on parameter ‘Start’. Cannot convert value to type “System.DateTime” because String was not recognized as a valid DateTime.

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.

Connection closed gracefully error when sending bulk or large quantity of e-mails in an Exchange 2007/2010 environment

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.

Fixing KDC Authentication Problems when upgrading your domain and forest functional level from 2003 to 2008 R2

We recently upgraded our Domain and Forest Functional Level from 2003 to 2008 R2, after a day or so I started having problems connecting to a number of 2008 R2 Hyper-V Virtual Machines. When attempting to connect I would receive the following error:
An Authentication Error Has Occurred. The Encryption Type Requested Is not supported by the KDC
At around the same time we also had one of our Exchange 2010 Transport Servers stop servicing clients, when I attempted to open the Exchange management console on the local server console ended with a HTTP server error status 500 and “Kerberos” authentication failed. So I decided to take a look through the event viewer to see what was up.

As part of Exchange there is an Active Directory Topology Service which will scan your environment for Active Directory Servers every 15 minutes or so, all of the exchange services rely on this service (if you ever have to restart all exchange services, simply restart the AD Topology Service). In the application event log I noticed the following error message:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=xxxx). Topology discovery failed, error 0×80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message))….
There were also issues with the Exchange STORE service with the following two events:
Process STORE.EXE (PID=xxxx). All Global Catalog Servers in forest DC=xxx,DC=xx,DC=xx are not responding.
Process STORE.EXE (PID=xxxx). All Domain Controller Servers in use are not responding

The rather simple resolution to all this trouble is simply to restart the KERBEROS DISTRIBUTION KEY or KDC service on all Domain controllers. While simply restarting the Service will solve the problem, you’re probably better off just doing a proper restart after upgrading your functional levels, only from 2003 to 2008 / 2008 R2.