Forcing a Server’s Active Directory Site

In January 2010 I wrote a blog post Where oh where, did my AD site go…[Alternate title: It’s the DNS, stupid.]. In that blog post I discussed a situation where an incorrect DC locator record could cause a server to report itself as a member of an improper Active Directory site. That can cause a number of issues with Exchange.

I am in the process of migrating that same customer to Exchange 2013 (the prior blog post was written when migrating a particular customer to Exchange 2010).

The first Exchange 2013 server was brought online after the OS was installed. I went through the normal process of installing Exchange 2013 role and feature pre-requisites, installed Ucma 4.0, etc. etc. When it came time to do the first actual step in installing Exchange 2013, PrepareSchema, setup.exe reported that the Schema Master FSMO was not in the same Active Directory site as the computer running setup.


Of course it was. I know this requirement and made certain it was satisfied! The Schema Master FSMO was in the AD site named “10-129-59”. The new server was in the same subnet.

However, when executing “nltest /dsgetsite”, nltest reported that the AD site was “Default-First-Site-Name”. Uh, wow.

I immediately reviewed AD Sites and Services to ensure that AD Subnets and AD Sites were properly configured. Indeed, they were. Next, I reviewed the customer’s DNS, in detail, as described in the above blog post. The DNS was correct.

Finally, with little hope of success, I tried resetting the secure channel to the proper FSMO DC. That succeeded.

So, I rebooted. After the reboot, the secure channel was again reset to a DC in “Default-First-Site-Name”. OK, I tried the same thing again (resetting the secure channel and then rebooting) with no change in behavior.

No need to try a third time. That would meet a classical definition of insanity. 🙂

I spent a limited amount of time investigating the particular reasons for why this should occur. But when it comes down to it, as a consultant, my job is to accomplish this project. So, I went out to find ways to ensure that a particular computer is a member of a particular AD site.

It turns out to be pretty simple. You must set a registry value for this key:


The value is called SiteName and is of type REG_SZ (the name is case sensitive).

In my case, I set SiteName to “10-129-59” and closed regedit.exe (of course you can set this value in many ways – you can use PowerShell, .NET, Win32, reg.exe – whatever you wish to use). Documentation says that restarting the NetLogon service should correct everything, but that is not my experience. After rebooting the server, the computer came up in the proper AD site and I was able to proceed with installing Exchange Server 2013.

Follow me on Twitter: @essentialexch

Exchange Server 2013 Service Pack 1 Released!

Just a quick note…. Exchange Server 2013 Service Pack 1 has been released.

Among other changes, this version of Exchange Server provides support for installation on Windows Server 2012 R2 and provides support for Windows Server 2012 R2 domain controllers.

The blog post announcing the release is here. You can download the release here.

At the same time were releases for two legacy versions of Exchange: Update Rollup 5 for Exchange 2010 Service Pack 3 and Update Rollup 13 for Exchange 2007 Service Pack 3.

The announcement for those releases is here. At the time of this writing, no information is available about the contents of those rollups.

More information coming soon!

Follow me on twitter: @essentialexchange


Exchange Server 2013 Gotchas

Exchange Server 2013 reached RTM a couple of months ago and has since reached General Availability (GA).

In my personal opinion, Exchange 2013 RTM is not ready for prime time. Microsoft made a decision to release all of Wave 15 (Office desktop applications and servers) at the same time; as well as release Windows 8, Windows RT, and Windows Server 2012 at the same time. I think this decision was seriously flawed. It is obvious that the products were not complete at RTM (witness Windows 2012 and Windows 8 having 300 MB of patches between RTM and GA, and Exchange 2013 not supporting any interop with prior versions of Exchange at either RTM or GA). It is easy to conclude that the RTM dates were artificially imposed.

I have prepared a class on Exchange 2013 for one of my clients and part of that class was to discuss the limitations associated with Exchange 2013 RTM when compared to Exchange 2010 SP2. Note that the rest of the class discussed many of the new features and capabilities that have been added to Exchange 2013. So… the story is not all bad.

But as a summary of my opinion, Exchange 2013 RTM is not ready for prime time. Right now, it can only be installed in a green-field environment (that is, an environment where Exchange did not previously exist), so it is a safe bet that the Exchange team agrees with that as well. We can hope that some updates will quickly come out to address some of the current deficiencies.

This list is by no means exhaustive. And, as always, whether a particular issue is important to your organization requires you to evaluate your environment.


  • Help -> About is gone
  • It's very slow.
  • No S/MIME support
  • No Public Folder support, either for legacy public folders or modern public folders.
  • No distribution list moderation
  • No way to move the reading pane
  • Built-in spell-check is gone. IE 10 provides spell-check natively, but earlier versions of IE do not. A third-party add-in or an alternate browser is required.
  • Other things are gone; don't waste too much time looking for them.

Client Connectivity

  • No BES support
  • …on a related note (and likely the primary reason BES is not yet available), the CDO/MAPI download is not yet available for Exchange 2013.
  • Outlook 2003 is no longer supported.
  • Direct MAPI access to the Exchange server is no longer supported. RPC/HTTP (Outlook Anywhere) is required.
  • Outlook now reports that the server is it connected to is <<guid>>@<<active-directory-domain>>. This is intentional, if misguided.

Installation and Architecture

  • Cannot uninstall individual roles from a server, must uninstall all of Exchange
  • Install is painfully slow
  • The Hub Transport role is gone. There is now a Front End Transport service on CAS servers and Mailbox Transport services on Mailbox servers.
  • The Unified Messaging role is gone. There is a now a Unified Messaging Call Router service on CAS servers and a Unified Messaging service on Mailbox servers.
  • The CAS consists of three pieces: CAFE' (Client Access Front End), which proxies all end-user protocols to the appropriate mailbox server (completing the decoupling of the MAPI endpoint started in Exchange 2010) and handles Outlook Web App; FET (Front End Transport) which proxies SMTP protocols to the mailbox server and is responsible for TLS setup; and Unified Messaging Call Router.
  • After an installation or an upgrade, services not starting is an endemic problem. You will likely need to increase ServicesPipeTimeout on your Exchange servers.
  • Documentation is minimal at best
  • Deployment and sizing guidance is non-existent.
  • Cannot be installed along with Exchange 2007 or Exchange 2010
  • Exchange 2013 Edge server is not available
  • Forefront Protection for Exchange is gone
  • For both Exchange 2010 and Exchange 2013, applying updates can often screw up the winrm configuration. If you get errors in EMS or EAC regarding "The WS-Management service cannot process the request", try this first:

    winrm quickconfig

  • Since you cannot interop with legacy public folders in RTM, if you need an Organizational Forms Library, you must create it yourself. To create an Organizational Forms Library:

    1. Create "Organizational Forms Library" folder under the Eforms Registry:

    New-publicfolder "Organizational Forms Library" -path "\non_ipm_subtree\Eforms Registry"

    2. Set the locale ID for the Org Forms Library:

    Set-PublicFolder "\non_ipm_subtree\Eforms Registry\Organizational Forms Library" -EformsLocaleID EN-US

    It is no longer necessary to set the PR_URL_NAME property.

Exchange Management

  • The Exchange Management Console is gone as is the Exchange Control Panel. They are mainly replaced by the Exchange Administration Center (EAC); which is completely web based.
  • If you are attempting to use EAC with IE 10, you need KB2761465 (released on December 11, 2012).
  • The Exchange Best Practices analyzer is no more.
  • The Exchange Mail Flow Troubleshooter is no more.
  • The Exchange Performance Troubleshooter is no more.
  • The Exchange Routing Log Viewer is no more.
  • The EAC does not provide a preview (or an after-view for that matter) of the PowerShell it executed.
  • Antispam and antimalware is crippled compared to earlier releases

    The E15 AV does not offer a quarantine
    The E15 AS does offer a quarantine (for the administrator, not per-user)

  • Antispam cannot be managed from the Exchange Administration Center; it must be managed using PowerShell in the Exchange Management Shell
  • Kerberos Constrained Delegation (KCD) is not supported for OWA
  • This isn't new, but should be reinforced: DO NOT TURN OFF IPV6. Microsoft does not perform any testing to determine the effects of disabling IPv6. Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. See
  • System Center Data Protection Manager (DPM) version required for backups of Exchange 2013 is SC DPM 2012 SP1

Mailboxes and Databases

  • Mailbox sizes MAY appear to increase substantially when moving a mailbox to an Exchange 2013 mailbox server. In Exchange 2010 and before, only select properties of a particular mailbox item were assigned as part of the mailboxes diskspace allocation, causing under-reporting. Now, all item properties for a particular mailbox item are assigned to the mailboxes disk space allocation. However, some items in Exchange 2013 are now compressed which were not before. This can lead to a reduction in reported and allocated diskspace. So, prediction is basically impossible. Just be aware that it may happen.
  • Corrupt PropertyTags during a mailbox move are common. Using (Get-MoveRequestStatistics -IncludeReport <<alias-name>>).Report.Failures you can find the rule or message that is causing the problem and remove it.
  • Changes made to improve Office 365 and hybrid deployments had an unintended consequence (this is my conclusion). When you are performing impersonation (e.g., to open a different user's mailbox via EWS), you should always impersonate using the email address.
  • As a corollary, it is recommended that the account UPN match the primary email address.
  • In a change that you won't know about until you need to know it – MRS Proxy is not enabled by default in Exchange 2013. Use Set-WebServicesVirtualDirectory to enable it.
  • Clean-MailboxDatabase is gone

    Update-StoreMailboxState is designed to replace it
    Requires that you know the guid of the deleted mailbox
    No on-premises cmdlets allow you to find those out!

  • Get-LogonStatistics is non-operational. The cmdlet is still present, but it doesn't work.
  • Exchange 2013 Enterprise Edition supports only 50 mailbox databases instead of the 100 supported in Exchange 2010
  • MRM 1.0 (Messaging Record Management – Managed Folders) is non-operational on Exchange 2013 mailbox servers. The cmdlets are still present, and will affect down-level servers (which you can't use right now), but they don't work with Exchange 2013 servers.
  • Moving mailboxes using the migration wizard in EAC can generate large amounts of log files for the database which hosts the arbitration mailbox. Use New-MoveRequest instead.
  • In a positive change, Office Filter Packs are no longer required. There is a new search technology used in all Wave 15 (Office 2013) products and it knows how to search all the Office file formats. This also includes the PDF format, so a separate iFilter installation for PDF is no longer required.
  • When using Database Availability Groups (DAGs) on Windows Server 2012, you must manually create the Cluster Network Object (CNO) and provision the CNO by assigning permissions to it.
  • While Windows Server 2012 provides support for large sectors (4 KB), Exchange 2013 does not support large sectors. Emulation of large sectors (512 E) is supported provided that all database copies are on 512 E.
  • The above statement is, in general, true. Additional capabilities of Windows Server 2012 are not supported by Exchange Server 2013. This specifically includes but is not limited to Hyper-V Replica.

Good luck!

[Edit at 19:55 on 6-January-2013 to clarify why you may need an organizational forms library and to add the note regarding lack of spell-check in OWA (hat-tips to Ben Winzenz and Tim Robichaux).]

[Edit at 21:24 on 8-January-2013 to fix several grammar and spelling errors. Oops.]


Windows Management Framework 3.0 / PowerShell 3.0 and Exchange

In the last few days, Windows Management Framework 3.0 (WMF 3.0) has begun appearing in Microsoft Update (MU), Windows Update (WU), Windows Software Update Services (WSUS), and on Configuration Manager Software Update Points. This basically means that Microsoft is now suggesting that WMF 3.0 be installed on all of your servers where the update is applicable.

This update is released as KB 2506146 and KB 2506143.


WMF 3.0 includes PowerShell 3.0.

PowerShell 3.0 is a great improvement to PowerShell. No question about it.

However, Exchange 2010 is NOT currently qualified to work with PowerShell 3.0. And, in fact, it doesn't. It will break. PowerShell 3.0 compatibility will come with Exchange 2010 Service Pack 3, due sometime in the first half of calendar year 2013 (word on the street says first quarter).

If you have installed WMF 3.0, you will also find that Exchange Update Rollups will fail to install.

Exchange 2007 is also not qualified to work with PowerShell 3.0. And, as far as I know, never will be.

You absolutely, positively, do not want to install the update on your Exchange servers.

You also do not want to install the update on workstations or utility servers where you have Exchange Management Tools installed.

I have also heard reports that SharePoint 2010 also has problems with the WMF 3.0 release. I can believe it. You should avoid that as well.

Good luck!

P.S. Exchange 2013 does work with WMF 3.0 and in fact, WMF 3.0 is required to install Exchange 2013. If you are one of the rare few running Exchange 2013, you do not need to be concerned about this.


Wave 15 reaches RTM, including Exchange 2013

Wave 15 of Office products reached the Release To Manufacturing (RTM) stage today, October 11, 2012 (10/11/12 – heh).

These products include Exchange Server 2013, Lync Server 2013, SharePoint Server 2013, and Microsoft Office 2013.

Note that RTM, also known as "code-complete", means that development is done on the products and they will now be written to ISOs, DVDs burned, retail boxes built, etc.

This does NOT mean that the releases are currently available. As of today, releases are still only available to TAP and RDP participants.

General Availability (GA) defines the timeframe when the releases will be available to everyone. This is targeted for first quarter calendar-year 2013 for all the Wave 15 products.

However, volume license customers will be able to download these products on the Volume Licensing Service Center (VLSC) by mid-November and the products will be on the VL price lists starting December 1, 2012.

Specifically for Exchange, the build number for the RTM release is 15.0.516.32. Exchange 2013 was code-named E15 throughout its development cycle.

For your information, "Wave 15" refers to the fact that version numbers of all Office product lines have been synchronized. The major version number for all products is "15".

For more information about Exchange, refer to the Exchangae team blog: The New Exchange Reaches RTM!

For more information about the other Office products, refer to the Office blog: Office Reaches RTM.

It is interesting to note that both releases refer to "the New Exchange" and "the new Office" – taking a cue from Apple, I presume; in not tying the announcement to a specific release of the product.


Exchange Server 2013 on Windows Server 2012

Unless you've been living under a rock, you know that the public betas of all the Wave 15 products, including Office, Exchange, Lync, SharePoint, etc. were released earlier this week as "2013" products. These were all released on Monday July 16, 2012. This follows by a couple of weeks the "release previews" of Windows 8 and Windows Server 2012.

You can download the Exchange Server 2013 public beta/preview here.

In the original release, it was not supported to install the Exchange preview on the Server 2012 preview. Today, Microsoft has changed that guidance and now supports installing Exchange Server 2013 on Windows Server 2012.

At this time, it requires a couple of additional manual steps. You can find information about how to install Exchange Server 2013 on Windows Server 2012 here.

We can reasonably expect that this will be cleaned up before RTM.


Office 2010 Filter Pack for Exchange 2007 and Exchange 2010

One of the prerequisites for both Exchange 2007 and Exchange 2010 is to install the “filter packs”. The filter packs are responsible for “filtering” the content of Microsoft Office documents and passing those contents back to the Indexing Service (ok, it’s not called the Indexing Service anymore – it’s Microsoft Search – and Exchange 2010 uses a slightly customized version of Microsoft Search called “Microsoft Search (Exchange)”).

In Exchange 2003 and before, creating a full-text search index was optional – and “expensive”. Beginning with Exchange 2007, it became cheap (due to Exchange’s use of the much improved Microsoft Search engine) and required. All Outlook Web App (Outlook Web Access) searches and all Outlook (online) searches use that index.

So, with the release of Office 2010, Microsoft has also released an update to the filter packs that support Office 2010 (plus a few other document types). The new filter packs can be installed on Exchange 2007 and Exchange 2010 (and it seems likely that they will be required for Exchange 2010 SP1). Filters are built-in for the following formats:

Legacy Office Filter (97-2003; .doc, .ppt, .xls)
Metro Office Filter (2007 and 2010; .docx, .pptx, .xlsx)
Zip Filter
OneNote filter
Visio Filter
Publisher Filter
Open Document Format Filter

You can download the Microsoft Office 2010 Filter Packs here.

However, you may notice that a common file format is missing! PDF. In order to scan and index PDFs, you need to install a filter available from Adobe, the Adobe PDF iFilter 9 for 64-bit platforms. That will work with both Exchange 2007 and Exchange 2010.

Bharat Suneja, an ex-Exchange MVP who is now working for Microsoft, provides additional information about index generation and scanning on his blog Exchangepedia.(He gave you some stuff I didn’t – and I’ve given you some stuff he didn’t. It all works out!) 🙂

Until next time…

If there are things you would like to see written about, please let me know.

Follow me on twitter: @EssentialExch

Exchange 2010 Gotcha – #4

Public Folder Contacts Can’t Replicate

If you have a public folder contact that includes an e-mail address, there is also an e-mail address type field that is associated with every e-mail address.

Note: You cannot see this e-mail address type field by default – but it’s still there. To view it, go to a Contacts folder in Outlook and create a custom view. In that view, add “Full Name”, then select “E-Mail Address Fields” and add “E-Mail Address” and “E-Mail Address Type”. Now, examine the Contacts in the folder using the custom view. You’ll see e-mail address types such as “SMTP” for external Internet contacts, “EX” for internal organization e-mail contacts, “FAX” if you have a fax connector installed, etc.

Now, Exchange 2003 (and perhaps Exchange 2007 – I have not checked in my lab) allowed two differerent e-mail address types to indicate “SMTP”. I believe this to be a hold-over from Outlook 97, although I have no documented proof of that (but in Outlook 97 we had “Internet mode” and “Corporate or Workgroup mode” – so it makes sense). The two different types are “SMTP” and “POP3/INTERNET”.

“POP3/INTERNET” is not valid in Exchange 2010. If you attempt to replicate a public folders to Exchange 2010 that contains this e-mail address type, the replication will abort. Thankfully, you do receive an event log error message that provides SOME clues about this occurring. The error looks like this:

Event Type:      Error
Event Source:    MSExchange Store Driver
Event Category:  (1)
Event ID:        1020
Date:            5/11/2010
Time:            10:00:43 AM
User:            N/A
The store driver couldn't deliver the public folder replication message "Folder Content Backfill Response (" because the following error occurred: Property validation failed. Property = [{00062004-0000-0000-c000-000000000046}:0x8082] Email1AddrType Error = The length of the property is too long. The maximum length is 9 and the length of the value provided is 13... For more information, see Help and Support Center at

What you will have to do is, using Outlook, obtain a list of all the affected contacts as described above, and also using Outlook, change the address type to SMTP.

In Outlook 2010, you can directly edit this field. In Outlook 2007, you will need to open each contact, right click on the e-mail address in the default display, and select Properties. Then, for the Address Type field, click the “Internet” button (this changes the e-mail address type to “SMTP” – the button will now display “Custom”). Then “Save and Close” the updated contact.

In my migrations, I’ve only had a maximum of about 150 of these. If you have thousands, you will probably need to consider writing a webdav application/script to run against the Exchange 2003 server(s).

Until next time…

If there are things you would like to see written about, please let me know.

Follow me on twitter: @EssentialExch

Exchange 2010 Gotcha – #3

The TrustedInstaller – Isn’t.

Generally, when applying patches (whether service packs or hotfixes or rollups), the installation process will automatically acquire all the necessary permissions – if the user executing the process CAN acquire those permissions. This is especially relevant under Server 2008 and Server 2008 R2, where an interactive logged in user has their access token artificially limited, even if UAC is disabled.

However, the Exchange 2010 update installer either drops administrative permissions too early or never acquires all of the permissions that are necessary. When applying update rollups, binaries are updated just fine – but OWA source files are not.

This commonly leads to a patch application that appears successful – but it isn’t. When testing OWA after an update-rollup appliction, a common error is “syntax error in flogon.js at 1, 1.” This is an indication that the patch was NOT installed with administrative permissions.

Reapply the patch with administrative permissions.

Note: I have heard reports that this begins to affect Exchange 2007 AFTER the application of service pack 2, when Exchange 2007 is installed on Windows Server 2008.

This has (at this writing) been seen to affect Exchange 2010 UR1, UR2, and UR3.

To properly ensure that an application of an update-rollup has adequate permissions, do one of the following:

  • Right-click on the patch (filename.msp) and click on “Run as Administrator”
  • Open an elevated command prompt and then start the patch (just enter filename.msp). To open an elevated command prompt, click Start, then enter “cmd” into the search area, right click on the cmd.exe that appears in the results area and click on “Run as Administrator”.
  • Open an elevated PowerShell session and then invoke the patch (enter “ii filename.msp“). The open an elevated PowerShell session, click Start, then enter “PowerShell” into the search area, right click on the “Windows PowerShell” that appears in the results area and click on “Run as Administrator”.

Until next time…

If there are things you would like to see written about, please let me know.

Follow me on twitter: @EssentialExch

Exchange 2010 Gotcha – #2

Incoming e-mail CAN’T come in!

This issue is not exclusive to Exchange 2010 – it also exists in Exchange 2007.

The default receive connector created by the Exchange setup process does not include permissions to include “Anonymous users” on the default server permission group. Microsoft assumes that you will be using their Edge Server product (which isn’t Anonymous, but Authenticated).

Of course, most people (? – at least my customers!) will not be using the Microsft Edge Server product, but some other gateway e-mail product.

Therefore, you will need to set the “Anonymous users” permission on the default server permission group.

Otherwise – incoming Internet e-mail will bounce!

Until next time…

If there are things you would like to see written about, please let me know.

[Edit on April 15, 2010 to spell “Authenticated” correctly.]

Follow me on twitter: @EssentialExch