How to Manage Distribution Groups from Office 365 in a Hybrid Environment

Wednesday, November 30, 2016
When on-premises distribution groups are synced to an Office 365 tenant via Azure Active Directory Connect, migrated users who are owners of the distribution group can't manage them in Outlook. Depending on the version of Outlook used, the user will receive an error message that resembles the following:
The action 'Update-DistributionGroupMember', 'Identity.Members', can't be performed on the object '<name>' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

Changes to the public group membership cannot be saved. You do not have sufficient permission to perform this operation on this object.

This happens because Outlook tries to update the same directory where the user's mailbox exists. If the mailbox is in Exchange Online this is the Exchange Online Directory Service (EXODS) directory, which syncs with Azure AD. Since EXODS is read-only in a hybrid environment using AAD Connect, the user receives the error.

The trick workaround is to use the dsquery management interface (formerly known as the Windows Address Book way back in the Windows 95 days) to manage the on-premises group. Users can create a desktop shortcut to the dsquery user interface and use it to update the on-prem distribution groups. Optionally, you can create a GPO that pushes this desktop shortcut out to all domain-joined computers' desktops.

To create the desktop shortcut to the dsquery user interface, follow these steps:

  • Right-click an area on the desktop, point to New, and then click Shortcut.
  • Type the following in the box, and then click Next:
%SYSTEMROOT%\System32\rundll32.exe dsquery,OpenQueryWindow
  • Type a name for the shortcut, such as "Manage Distribution Groups", and then click Finish.
The shortcut allows users to search for the group, and then add and remove users or change the group's description for groups they manage.

Managing a Distribution Group using the dsquery UI

It's important to note that the user's computer must be domain-joined and connected to the network for this to work because the changes are written to an on-prem domain controller. After group changes are made, they will appear in Office 365 after directory synchronization runs. Or, you can force directory synchronization to see the changes immediately.

Read more ...

Fix for Performance Counter Updating Error (Event 106) on Exchange Servers

Tuesday, November 29, 2016
You may see multiple warnings or errors in the Application event log on Exchange servers for event 106, indicating that performance counters could not be updated.

Multiple Event ID 106 - Perf Counter Events
An example event 106 reads,
Log Name:      Application
Source:        MSExchange Common
Date:          11/29/2016 12:24:28 PM
Event ID:      106
Task Category: General
Level:         Warning
Keywords:      Classic
User:          N/A
Performance counter updating error. Counter name is Percentage of Failed Offline GLS Requests in Last Minute, category name is MSExchange Global Locator OfflineGLS Processes. Optional code: 3. Exception: System.InvalidOperationException: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.
   at System.Diagnostics.PerformanceCounter.InitializeImpl()
   at System.Diagnostics.PerformanceCounter.get_RawValue()
   at Microsoft.Exchange.Diagnostics.ExPerformanceCounter.set_RawValue(Int64 value)
The TechNet article, "'Performance counter updating error' after you install an Exchange Server 2013 cumulative update", indicates this is a problem on Exchange 2013 after applying a CU, but I've seen this happen after applying an update rollup, cumulative update, or .NET Framework update on Exchange 2010, Exchange 2013, or Exchange 2016 servers.

I wrote the following PowerShell script to reload the Exchange performance counters. You run it directly on the affected Exchange server from an elevated PowerShell or EMS prompt. The script will reload all the performance counters in the %ExchangeInstallPath%\setup\perf directory.
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Setup
$perfcounters = Get-ChildItem "$env:ExchangeInstallPath\Setup\Perf\" *.xml | Where-Object {!($_.psiscontainer)}
$perfcount = $perfcounters.Count

foreach ($perfcounter in $perfcounters) {
New-PerfCounters -DefinitionFileName $perfcounter.FullName -ErrorAction SilentlyContinue
Write-Progress -Activity "Reloading $perfcount Exchange Performance Counters" -PercentComplete (($i++ / $perfcount) * 100)}
The script may take a few minutes to run and will reload all the Exchange performance counters. Once complete, the event 106 warnings or errors should stop.

Read more ...

Azure AD Connect Adds Support for Windows Server 2016 and SQL 2016

Friday, November 18, 2016
If you're a customer who uses Azure Active Directory Connect, you'll want to know that Microsoft just released version 1.1.343.0, which adds support for Windows Server 2016 and SQL Server 2016 and fixes some bugs.

  • Added support for installing Azure AD Connect on Windows Server 2016 standard or better.
  • Added support for using SQL Server 2016 as the remote database for Azure AD Connect.
  • Added support for managing AD FS 2016 using Azure AD Connect.
Fixed issues:
  • Sometimes, installing Azure AD Connect fails because it is unable to create a local service account whose password meets the level of complexity specified by the organization's password policy.
  • Fixed an issue where join rules are not re-evaluated when an object in the connector space simultaneously becomes out-of-scope for one join rule and become in-scope for another. This can happen if you have two or more join rules whose join conditions are mutually exclusive.
  • Fixed an issue where inbound synchronization rules (from Azure AD) which do not contain join rules are not processed if they have lower precedence values than those containing join rules.

You can download the latest version HERE.

Read more ...

How to Perform HTTP -> HTTPS Redirection in a Single Exchange Server Environment

Tuesday, August 30, 2016
HTTP to HTTPS redirection in Outlook Web App is a user convenience that many admins consider a necessity. It automatically redirects the user's browser to if they enter, or simply Without redirection, the user will get an HTTP 403 Forbidden error page, like the one below.

This happens because the SSL settings on the Default Web Site and all subdirectories are configured to require SSL.

In multi-server environments where load balancers are used, HTTP -> HTTPS redirection is normally performed on the load balancer. Most load balancers, such as KEMP or F5, automatically configure it when you deploy one of their Exchange server templates.

In single Exchange environments without a load balancer, you must configure redirection directly on the server itself. The steps below explain how to do this. I've used this method since Exchange 2007 and it works perfectly 100% of the time. Other methods I've seen on the Internet sometimes cause routing errors.

  • Open Internet Information Services (IIS) Manager on the Exchange 2016 or Exchange client access server and navigate to Sites > Default Web Site.
  • Double-click Error Pages and add a new custom error page for status code 403.4 that responds with a 302 redirect to

  • Special note for Exchange 2016 - The Exchange team did a little number in the web.config file on Exchange servers to "improve performance", but it removes the custom error page behavior. So you'll need to do the following:
    • Open the C:\inetpub\wwwroot\web.config file in Notepad.
    • Remove the following line, and then save and close Notepad:
<remove name="CustomErrorModule" />

Note that this web.config edit will need to be made after every Exchange 2016 CU installation since setup overwrites this file.

That will handle the HTTP 403.4 - Forbidden: SSL is required error behavior in the browser. All that's left is to handle what happens when a user enters

  • Using Notepad, create a web page called default.htm in the C:\inetpub\wwwroot folder of the Exchange 2016 or client access server. Add the following three lines:

<meta http-equiv="REFRESH" content="0;url=/owa">
  • Save and close Notepad, and then test redirection.

Read more ...

How to Change the From Address in OWA

Monday, August 22, 2016
If you have Send-As rights for another mailbox, you may want to send email as that other user from your own mailbox. You may also want to send as an Office 365 Group so that all replies to your message go back to that group.

This is easy enough to do in the Outlook client by clicking the From drop-down box and selecting the appropriate account or entering an email address. It's not quite that intuitive in Outlook Web App (OWA), but it can still be managed.

First, you need to display the From field for the message you are composing in OWA. Click the [...] ellipses button and select Show From:

Next, right-click From the email address and select Remove:

Now type in the email address of the user or Office 365 Group you want to send the email as:

Of course you need to have rights to send as the user for this to work properly, otherwise you will get an NDR saying, "You don't have rights to send as this user."

Note that the sent item will go into your Sent Items folder, not the user's who you are sending as.

Read more ...

Announcing the 9th Annual UC Roundtable at Microsoft Ignite, Atlanta!

Tuesday, August 16, 2016

I'm pleased to announce the 9th Annual UC Roundtable at Microsoft Ignite 2016 in Atlanta!

A one of a kind conference deserves a one of a kind opportunity to network with your peers.

The purpose of the UC Roundtable is to gather Exchange, Office 365, and Skype for Business admins, MCMs, MVPs, Exchange product group members, architects, and experts for a free-flowing discussion about issues, questions, and experiences related to Exchange, Office 365, and Skype for Business. If you work with Exchange, Office 365, or Skype for Business or Lync Server you need to be here!

Wednesday, September 28th from 7:30PM to 11:00PM EDT

A big special thank you to my friends at F5 who will be hosting the event for the fifth year in a row! Those of you who have attended previous UC Rountables know that they put on a great event.

Please RSVP to for event details and location. I will email you the details via EventBrite.

Help spread the word on Twitter and I hope you can join me!


Also, I'm pleased to say that I will be presenting two sessions at Microsoft Ignite this year:
We will take questions from the audience and give advice from the voice of independent experience. I hope you can join me for these sessions. Check out the MyIgnite tool and schedule builder at

Read more ...

New Set-AutodiscoverSCP v2 script is on the TechNet Gallery

Friday, July 22, 2016
I just published version 2.0 of my Set-Autodiscover.ps1 script to the TechNet Gallery. This is a complete rewrite of the old script and includes the following new features:
  • Made setting the new values easier by cloning an existing server
  • Now also configures Outlook Anywhere and all Exchange virtual directory internal and external URLs
  • Revised verbiage and use *-ClientAccessService cmdlets for Exchange 2016
  • Added -Verbose output to display the values we're configuring
  • Improved overall display output
These changes are intended to make the script more powerful and easier to use.

How many times have you installed a new Exchange 2010-2016 server only to hear users complain about a security pop-up in Outlook referencing the new server?

This happens because Exchange setup uses the FQDN of the server as the service connection point (SCP) that Outlook clients use for autodiscover requests (for example, https://exch03.contoso.local/autodiscover/autodiscover.xml). This new SCP is configured in Active Directory when the Front-End Client Access role is installed during setup. In most load balanced environments the valid SCP should be something like Outlook will prompt users with a security warning because the self-signed Exchange certificate installed by setup is not trusted. If the new server is Internet-facing, ActiveSync clients can also get security warnings on their mobile device.

Read Exchange Active Directory Deployment Site for more information about this behavior.

I wrote a script, Set-AutodiscoverSCP.ps1 (available on the TechNet Gallery), that automatically updates the SCP, Outlook Anywhere FQDNs, and all the virtual directory internal/external URLs for the server your specify to match the values currently configured on another server you specify as soon as the new server is detected in AD. It continually polls Active Directory until it finds the new SCP value and sets the new values. A progress bar indicates that the script is polling AD.

The script is intended to run on another Exchange server in the org running the same version of Exchange as the new server. This is because Exchange 2010 cannot update SCP values for Exchange 2013 or 2016, and vice versa. You can also have the script target a particular domain controller. This is useful when the new server you are installing is in a different AD site.

The syntax for Set-AutodiscoverSCP.ps1 is:
Set-AutodiscoverSCP.ps1 [-Server] <String> [-ServerToClone] <String> [[-DomainController] <String>] [<CommonParameters>]
Two examples of usage:
PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01
Example #1 continually queries the current configuration domain controller until it finds an SCP for server EXCH02 and then sets it to match the SCP of EXCH01. It also configures Outlook Anywhere and the internal/external virtual directory URLs to match those found on EXCH01.

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01 -DomainController dc03
Example #2 is almost the same as the command in the previous example, except it continually queries DC03 for the SCP record and configures it on that domain controller. This is useful when configuring a new Exchange server in a different Active Directory site.

The script is designed to be run during installation. Normally, you would run this script from an existing Exchange server of the same version while the new server is being installed.

You can also run the script directly from the server that is being installed. This is useful when you're installing the first Exchange 2013/2016 server in a 2010 environment. You can start running the script on the new server when the Client Access Front End Service is being installed. The caveat is that setup restarts IIS and web services several times during setup, causing the script to possibly stall during configuration of the virtual directories. If that happens, simply CTRL-C to quit the script and run it again.

I've included error handling for the following conditions:

  1. The script notifies you what version of Exchange is running the script and warns you to make sure the new server is running the same version. Note that Exchange 2013/2016 servers can update each other. This warning really only applies to Exchange 2010 and Exchange 2013/2016 coexistence. 
  2. The script checks that the server, server to clone, and the domain controller (if specified) are pingable. If the servers cannot be pinged, the script will terminate.
  3. If a domain controller is specified, it validates that the DC specified is actually a domain controller

Set-AutodiscoverSCP.ps1 is a useful addition to your Exchange toolbox. Please let me know if you have any questions or feature requests. I'll update the script again on the TechNet Gallery as needed.

Read more ...