Blog: Exchange

When doing maintenance on an Exchange server environment configured with a DAG, one of the things that you have to be aware of is how to temporarily remove one of the servers from the DAG before you disrupt any of the Exchange services (i.e. reboot) so that it doesn't inadvertently cause a failover of your databases or make some databases unavailable. Microsoft wrote a blog post a while back talking about the proper way to place an Exchange server into maintenance mode and it's a bit clunky - 

Fortunately, there's a script readily available that takes care of most of this for you, including failing over the database to another Exchange server if needed. Located in 'Program Files\Microsoft\Exchange\V15\Scripts', take a look at the StartDagServerMaintenance.ps1 and StopDagServerMaintenance.ps1 scripts (and the RedistributeActiveDatabases.ps1 script. Running the script is simple, just pass the server name that you're starting or stopping maintenance on to their respective scripts and let PowerShell take care of the rest! Easy, no? 

Well, sorta. You see, for a few versions now (including Exchange 2013 and Exchange 2016), the StartDagServerMaintenance.ps1 script has a typo in it – specifically the part of the script that actually pauses the node in the cluster. In the parameters, Microsoft has set "$pauseClusterNode" equal to "$false" instead of "$true".   

Left alone like this, the cluster node will never be paused and potentially could cause issues when you reboot, not to mention that when you run the StopDagServerMaintenance.ps1 script, you'll receive a warning that "Call-ClusterExe: cluster.exe did not succeed" meaning it didn't do anything. Just change that parameter to "$true" and you're good to go.


While working with a customer who was searching for a solution to help manage distribution groups, I discovered that Exchange provides a feature called Dynamic Distribution Groups. These groups allow you to set up the distribution group, and then create a rule that references something like an OU or an AD account property to define which users belong to that group.

Here is a link to the TechNet article about Dynamic Distribution Groups:


After installing Windows 10, I decided I wanted to try out the Mail Desktop App.  I added my Exchange  account in the Settings->Accounts-> Add account. After adding my credentials, I got this message:

This caused the Windows 10 lock out policy to be inherited from the policy that is a part of Exchange Activsync, which locks the device after one or three minutes (depending on the policies set up for Activsync).

By removing the Exchange account from the Windows 10 Mail app, it also removed the Activesync enforcement of lockout and hence the lockout times reverted to being controlled by the power manager application.


A user had a full mailbox, so they decided to archive old emails; however, when she would start the Archive process manually (under cleanup tools), it would appear to be working for a few seconds and then finish, but no emails would be transferred. The process would create the entire folder structure, but not place any files in any folder. Since her mailbox was full (i.e. she hit the Exchange storage limits for her mailbox), the Archiving process didn’t have enough space available to successfully move the emails from the mailbox to a local PST. I temporarily disabled the storage limit and she was able to archive a large quantity of her mailbox successfully.


If you want to receive large email attachments (up to 50 Mb) using Exchange, there are several places that need to be checked to make sure large attachments are allowed.

The first place is on the Exchange Server. Within the Exchange server, there are actually a few different places this will need to be set:

  • The first one is a global setting, in the Transport Settings (Organization Configuration/Hub Transport/Global Settings tab/Transport Settings properties/General tab). 
  • The next place you'll need to look is in each receive connector (Server Configuration/Hub Transport/Tranport Server/Receive Connectors/Connector Properties/General tab).  Each connector has its own size limit. 
  • The last place you'll need to check in Exchange is under the recipient's mailbox (Mail Flow Settings tab).

You may also need to make changes in other products (i.e. email filtering) as well. 

  • If you have Barracuda filtering the default limit may already be set to 100 Mb.
  • If your customer has a ZixVPM/ZixGateway, the default limit may be 25 Mb, so it will need to be increased if you need to receive emails larger than that.
  • Finally, check your Firewall and/or Border router for any smtp inspection statements or smtp fixup.  If any of these exist it may prevent large emails (i.e. larger than 20 Mb) from getting through.


This may be old hat for people that work with Exchange on a regular basis. However, for the occasional Exchange tinkers among us, there is a way to run PowerShell functions that are specifically built for Exchange without having to run the Exchange Management Shell. [more]

  1. Open PowerShell on your workstation
  2. Use the "PSSession" commands to bring up a PowerShell instance that is pointed at the Exchange server:
    • $session = New-PSSession -configurationname Microsoft.Exchange -connectionuri http://<<Exchange server name>>/powershell -credential <<domain name>>\<<Exchange admin account>>
    • Import-PSSession $session
    • NOTE: the account used in the first command must be a member of one of the Exchange administrator groups in AD. Simply having Domain Admin rights is not enough. When the first command is run, a pop-up box will prompt you for the account's password.
  3. You can now run Exchange-specific PowerShell functions!



If you have difficulty scheduling meetings with multiple people outside of your company Exchange environment when you can't see everyone's calendar, take a look at ScheduleOnce.  It provides several scheduling options for organizing meetings with multiple people.  One option is to upload your calendar to Google Calendar, and others can see your availability without seeing any of the details of your appointments.  ScheduleOnce is free to try with a few basic features and more advanced features start at $5/month.


I was recently assigned a task to pull a list of users who use mobile devices for company email. I came across a neat website with several PowerShell commands listed to help generate the list.

There is a command to generate a device count of each type of device used.  There is also a command to generate six different .CSV files that can be used to see a list of users, emails received, type of device, device id, etc.


When Microsoft Exchange sends an e-mail, the message size may change due to the encoding used to package it. Messages with attachments can expand even more, since the only way to send e-mail attachments is to convert them from plain ASCII to MIME or UU-encode the message. Even if an attachment is smaller than the limits set in Exchange, it may not be accepted because its MIME-encoded or UU-encoded size is too big. This happens most often when limits are set for inbound SMTP mail. An incoming MIME-encoded e-mail with attachments can increase in size anywhere from 30% to 40%, depending on how many separate attachments, line breaks, MIME headers or other non-data elements are in the message. The exact size can vary enormously, especially since mail systems all behave a little differently when converting e-mail and attachments to MIME. The same problem exists in reverse, where messages sent from your domain will be constrained by message limit sizes on other hosts. Likewise, mail sent from your domain is going to expand anywhere from 30% to 40% in size when converted. [more]

A third-party program, such as UUDeview (, can help you find out just how much larger a MIME or UU-encoded version of a given file will be. (Note that this tool does not calculate things like message size overhead, but it can still be helpful.) The exact maximum incoming and outgoing message size is going to be up to the e-mail administrator, but should be set with these caveats in mind.

Also, take the time to explain to users that when they send attachments, they need to be mindful that messages will increase in size.


I’ve been working on migrating an Exchange environment to 2010. This process includes an upgrade to the Unified Messaging role of Exchange to 2010 as well. We had purchased a UCC certificate to include all the Subject Alternate Names our Exchange environment would need and I had already applied it to the CAS server successfully. Since this certificate also included the FQDN of our UM server, I added the cert. and assigned the UM service to it so that Exchange could start processing voicemails through 2010 instead of 2007. [more]

After I had moved a couple of mailboxes (including mine) over for testing, I discovered that I could no longer receive voicemail. People were redirected to the Subscriber Attendant instead of my individual mailbox. There were events logged on the UM server saying the following:

Event ID: 1400 Source: MSExchange Unified Messaging
The following UM IP gateways did not respond as expected to a SIP OPTIONS request. Transport = TLS, Address =, Port = 5061, Response Code = 0, Message = This operation has timed out.

After considerable troubleshooting, I ran across a forum posting ( from someone who encountered the same issue and called for a support incident with Microsoft to figure out what was going on. In order for UM to work in a Lync phone system environment, the Subject Name of the certificate installed must be the FQDN of the UM server itself. It won’t work if it’s just included as a Subject Alternate Name; it must be the Subject Name.

I generated a new certificate from our internal CA with the UM server as the SN of the certificate, installed and assigned it to the UM roles (leaving our UCC cert running the remaining roles), and immediately started receiving voicemail notifications.

I found one other blog posting after the fact that backed this claim up even more (