Public Folder Migration Issues Resolution for KB 977921 With PFDAVAdmin

The Issue

When you migrate from Exchange 2003 to Exchange 2007+ you can run into a number of problems that are due entirely to the differences in how Exchange handled public folders. One of these problems, as explained in KB 977921, is particularly annoying. The problem shows up after the public folders are replicated to an Exchange 2007/2010 server (Exchange 2013 uses a completely new system for Public Folders, and migration to it is completely different so the issue doesn’t really appear for that version of exchange). After replication, you may notice that some or all of the Mail Enabled public folders on your 2003 Public Folder console do not show up as Mail Enabled when looking at them on the Exchange 2007/2010 server.

The Cause

What happens here, which is explained in the KB article itself, is that a Public Folder property that Exchange 2007 and 2010 use to recognize a Mail Enabled public folder is completely missing. Exchange 2003 doesn’t require this property to allow mail enabled public folders, but 2007 and 2010 do, so when the replica gets moved over, the mail enabled public folders basically never get recognized properly on the new servers, so they don’t show up right. The property in question is PR_PF_PROXY_REQUIRED. This property has a Hex ID of 0x671F000B. For Exchange 2007/2010 to be able to recognize a public folder as mail enabled, this property must exist and have a value of 1.

The Solution

To solve this problem, there are a couple possible solutions. One is to mail-disable the mail-enabled public folders and then mail-enable them again. This will, however, mean that email addresses must be reapplied and all other mail properties will need to be recreated. Bill Long has a script that uses this technique to fix the problem available on his Technet blog.

While Bill’s solution is good, if there is still an Exchange 2003 server in the environment still running and holding a replica of the Public Folder databases, or if you install an Exchange 2003 server and replicate the public folders to it, you can fix this problem with a bulk operation done with the PFDAVAdmin Public Folder management tool.¬†

The fix here is to make sure that any public folders that have an email address have the PR_PF_PROXY_REQUIRED attribute added and set to 1. To do this, install PFDAVAdmin and connect to the Exchange 2003 Public Folder Replica of the PF Database. Technet has a good explanation of how to use PFDAVAdmin for general purposes, but I will give you some instructions on how to do this starting from the point after connecting to the Public Folder replica on the Exchange 2003 servers.

Once you are connected to the PF Replica, you will want to click on the Tools menu in PFDAVAdmin, then click on Custom Bulk Operation. This will bring up a window that looks like this:


This will allow you to create a filter that can be used to look up all the mail enabled public folders in the public folder database on the server you connected to. The filter can be a little confusing to figure out, but it basically uses LDAP style syntax and the properties that are available for any public folder to determine which public folders need to be operated on. The best property to use here is the DS:proxyAddresses property, which holds the email addresses for the public folder. If this property doesn’t exist, the folder is not mail enabled. As a result, you can build a filter that only returns mail enabled public folders by entering (&(DS:proxyAddresses=*)) in the Overall Filter box above. This may look like it will return anything, but the public folders that aren’t mail enabled don’t have this property at all, so they cannot be returned with that filter.

Once the Overall Filter is filled in, you can create the bulk operation you want to do. Click the Add button under Operations to bring up a selection window to define what type of operation you want to perform. Select Other Folder Properties and click OK. Under Action, make sure Modify is selected, then click the Property selection box under Properties and select PR_PF_PROXY_REQUIRED:0x671F000B and enter 1 next to Value. Click Add to add the property change to the list of properties that will be modified by the operation. The Folder Properties Op window should look like this:


Once that’s done, Click OK and your operation should be ready to roll. Before clicking OK to start the process, make sure the screen looks like the following:


Now click OK and the operation will start. It will parse through all the public folders, checking for folders with email addresses and applying the appropriate property to them. When the bulk operation completes, you can initiate a replication to Exchange 2007/2010 or just wait for a normal replication to occur. Once replication completes, you will finally be able to see your Mail Enabled Public Folders in the Management tool and manage them the way you are supposed to.


Removing Addresses from an Exchange 2007/2010/2013 Server

This is probably a rare issue, but something I’ve come across in my work. Occasionally an Exchange Administrator may need to remove an Email address domain (The part of the email address that comes after the @ sign). For instance, you may be in a situation where a portion of the users in an Exchange environment are migrated to a Cloud based email solution. This can be a little tricky because even if you remove the email address domain from your list of Accepted Domains in Exchange, the addresses may remain on users’ mailboxes. In this post, I’ll explain the process of removing email domains from an Exchange Server in the proper order.

Step 1 – Remove Address Policies that Use the Domain

Before you can actually remove an accepted domain from Exchange, you have to make sure there are no Address Policies that assign email addresses to users that utilize that accepted domain. In Exchange 2007 and 2010, you can do this by opening EMC (Exchange Management Console) and navigating to Organization Configuration>Hub Transport. Clicking the Address Policies tab will allow you to view the address policies in place. You should then remove any policies that define addresses based on the Email Address Domain you want to remove.

In Exchange 2013, you would open the Exchange Admin Center and navigate to Mail Flow>Email address policies, then modify or remove any policies that include the offending Email Address Domain.

Step 2 – Remove the Domain from the list of Accepted Domains

This step is pretty self-explanatory. In this situation we just remove the domain from the list of accepted domains on the Exchange server. This will tell the Exchange server not to accept emails destined for that domain. This can be done from the same location in EMC for Exchange 2007/2010, and from the Mail Flow system in Exchange 2013 by clicking on Accepted Domains, and then right clicking on the domain you want to remove. Selecting delete will remove that domain.

Step 3 – Remove Email Addresses

This part can be a little tricky. Removing the email address policies won’t necessarily remove the email addresses that users have from their accounts, and if those addresses remain you could still end up having mail go places you don’t want it to. Resolving this issue requires some work with PowerShell in the Exchange Management Shell (EMS).

After the Email Domain is removed, open EMS and run the following command:

get-mailbox | where {$_.emailaddresses -like “*”}

Replace with whatever domain you’ve removed. This will give you a list of all the users that have one or more email addresses attached to their domain that match the domain you’ve removed. If there are none, you’re done. If there are some mailboxes with the domain attached, you’ll want to run the following script to remove them:

$users = get-mailbox | where{$_.emailaddresses -like “*”}
foreach ($user in $users)
$addresses = (get-mailbox $user.alias).emailaddresses
$fixedaddresses = $addresses | where {$_.proxyaddressstring -notlike “*”}
set-mailbox $user.alias -emailaddresses $fixedaddresses

This will reset the email addresses on the account.

Office 365 Hybrid Configuration Failures

This is just a quick post that is meant to help people out who are having some issues with creating a Hybrid Configuration with Office 365 and Exchange 2010 SP3. There are some serious bumps in the road that you can come across when setting this up that may cause you to spend countless hours troubleshooting without any real success. I’ll elaborate on a couple of the problems that I’ve run into here, and follow up with the solution that worked for me with these issues at the end of the post.

AutoDiscover Failures and Free/Busy Issues

One of the things that you may run into after completing is AutoDiscover failures. You’ll know you have this problem when a cloud (or on-prem) user can log into OWA, but cannot set up their mailbox in Outlook or through Activesync. This can also present in an unusual fashion when you attempt to look up cross-premises Calendar information. Cross-premises calendar sharing utilizes the Exchange Federated Sharing features of Exchange, and this in turn utilizes Autodiscover to work properly. If you can’t view calendars in either direction (from On-Prem to Cloud or Cloud to On-Prem), and you get an error that the Free/Busy information couldn’t be read, look into Autodiscover first.

Generally, there isn’t a whole lot you can do to resolve Autodiscover errors, since Autodiscover is something that you have some pretty limited control over. Microsoft Recommends that the record that you publish in your Public DNS, so you shouldn’t have to change your Autodiscover record when introducing a Hybrid configuration. Unfortunately, there isn’t much more you can actually do once the Records are configured.

There is, however, a tool you can use to help you troubleshoot some issues with Autodiscover and Office 365 in a hybrid environment. Since Autodiscover is required for Free/Busy exchange to function, it may actually be possible to resolve your error by using Microsoft’s Free/Busy error troubleshooting tool. It’s available here:

If you aren’t experiencing Free/Busy errors, the tool may not be as handy, but I suggest trying to go through it a bit anyway, since it can give you some tips for resolving Autodiscover errors. If you have on-prem users that are having trouble configuring clients with autodiscover, tell the tool you have on-prem users that can’t see free-busy for Cloud users. If you have cloud users that are having trouble, do the opposite. If neither are working, use the other option available in the tool.

What Solved My Problem

Interestingly, it took me about 2 or 3 days of digging before I finally found the solution to my autodiscover and free/busy issues. It turned out that my problems were caused by some information that Microsoft failed to let anyone know about.

When you run the Hybrid Configuration tool, it will make some major changes to each of the CAS and HUB servers that you add as Hybrid Endpoints. However, because the hybrid configuration wizard actually makes these changes remotely and on demand, it does not actually complete the setup for you. Once you complete the Hybrid Configuration Wizard and add *any* CAS or HUB servers as hybrid endpoints (All your CAS and HUB servers should be hybrid endpoints for optimum functionality), *make sure to reboot those servers*. The changes that are made by the Hybrid Configuration wizard *will not* apply fully until the World Wide Web Publishing Services and IIS services are restarted. You can achieve the same goal by running IISRESET on your CAS/HUB servers like I did if you are in a situation where rebooting will create unnecessary downtime, but a full reset is a good idea.

Internal DNS and Exchange Autodiscover

The Issue

By now, anyone who has managed, deployed, or worked with an Exchange 2007 or later environment should be familiar with Autodiscover. If you aren’t yet, I’ll give a short Explanation of what it is and how it works.

Autodiscover is a feature that allows any Mail Client that supports Autodiscover to configure the appropriate server settings for communication so you don’t have to input everything manually. It’s very handy. Unfortunately, you can end up with a lot of headaches related to Autodiscover when you start having to deal with Certificates. The issues you may run into are specifically limited to Exchange Organizations that have a Domain Name that uses a non-public TLD like domain.local, or a public domain name that they don’t actually own and can’t use externally as well. On an unrelated note, this is one of the reasons that Microsoft has started recommending the use of Public domain names for Active Directory domains.

If you have a domain that isn’t publicly useable on your Exchange AD environment, you will run into certificate errors when mail clients use Autodiscover. This becomes particularly problematic when you use Exchange 2013 and try to use HTTPS for Outlook Anywhere. This is because Microsoft is now enforcing certificate validity with Exchange 2013’s Autodiscover features (Note, though, that Outlook Anywhere will be configured to use HTTP only when your Exchange Server certificate is determined to be invalid in Exchange 2013). With Exchange 2007 and 2010, you will get a Certificate error every time you open Outlook. Generally, this error will state that the name on the certificate is not valid.

The Cause

To solve the issue with certificates, you need to configure your environment so it enforces the appropriate action with Autodiscover. By default, Autodiscover will attempt to communicate with a number of URLs based on the Client’s email address (for external users) or domain name (for internal users). It will take the following pattern when checking for Autodiscover services:

1. Autodiscover will attempt to find the Autodiscover configuration XML file at the domain name of the SMTP address used in configuration (because internal domain computers configure themselves automatically by default, this matches the Internal Domain. For example, the first place autodiscover looks is for external addresses. Change with domain.local for what Exchange looks for on Internal clients.

2. If the autodiscover record is not found at, the server will attempt to connect to (replace with domain.local for internal). This is why the typical recommendation for having an A Record for Autodiscover in your DNS that points to the mail server exists. In addition, you would need to have as a SAN on the SSL certificate installed on the Exchange server for it to be valid when attempting to connect to autodiscover using this step.

3. If autodiscover information cannot be found in either of the first two steps, Exchange will attempt to use a Service Locator record in DNS to determine the appropriate location of the configuration files. This record points the Autodiscover service to a specific location for getting the configuration it needs.

Because of the way this works, there is some configuration necessary to get Autodiscover working correctly. This usually involves adding Subject Alternate Names to the SSL certificate you use for your Exchange Server to allow the many host names used to be authenticated with the certificate.

The problem lately, though, is that many Third Party Certificate Authorities that provide SSL certificates are beginning to deny requests for Subject Alternate Names that aren’t publicly available (There are valid security reasons for this that I won’t go in to in this post, but maybe later). As a result, you won’t be able to get a valid SSL certificate that allows domain.local as a SAN. This means that the automated steps Exchange uses for Autodiscover configuration will always fail on an Internal domain with a name that is not publicly accessible or not owned.

The Solution

IMPORTANT NOTE: This particular solution only applies to computers on your network that are *not* added to the domain. Domain-joined computers have a different solution to work with. Please read my article on resetting the Active Directory SCP for resolving Autodiscover issues like this on domain-joined computers.

There are actually two ways to solve the certificate issues, here. The first would be to prevent Outlook from automatically entering a user’s information when they create their profile. This will result in more work for you and your users, so I don’t recommend it. The other solution is to leverage that last step of the Autodiscover configuration search to force it to look at a host name that is listed on the certificate. This is actually fairly simple to do. Follow these steps to configure the Service Locator record in your internal domain.

  1. Open the DNS manager on one of your Domain Controllers.
  2. Expand out the management tree until you can see your Internal Domain’s Forward Lookup Zone. Click on it, and make sure there are no A records for autodiscover.domain.local in the zone.
  3. Once no autodiscover A records exist, right click the Zone name and select Other New Records.
  4. Select Service Location (SRV) from the list.
  5. Enter the settings as shown below:Image
  6. Hit OK to finish adding the record.

Once the SRV record is added to the internal DNS zone, Outlook and other autodiscover clients that attempt to configure themselves with a domain.local SMTP address will work properly without the Certificate errors on all versions of Exchange.

Other Nifty Stuff

There are some additional benefits to utilizing the Service Locator record for Autodiscover rather than an Autodiscover A record, even in your public domain. When you use a SRV record, you can also point public clients to communicate with or, or whatever you have configured your external server name to be. This means you can get away with having a single host name on your SSL certificate, since you wouldn’t need to get autodiscover working. Since most Third Party CAs charge a bit more for SANs than they do for Single Name SSL certs, you can save a bit of money (for this to work, though, you may need to change your Internal and External Web Services URLs in Exchange to match the name you have configured).

Another Problem the SRV record Fixes

There are also some other issues you may run into that are easily fixed by adding a SRV record. One of the most common is the use of multiple Email Domains in a single Exchange Environment. If you have users that are not assigned a Primary or secondary SMTP address that matches the domain name listed on your SSL certificate, you’ll discover that those users and the rest of your users will not be able to share calendar data between their mailboxes. You can fix this by adding an Autodiscover SRV record to the DNS zone that manages the additional mail domains. For example, you have and on the same Exchange Server. can’t see’s calendar. The fix for this is to add the SRV record to the DNS zone and point it to the public host name for’s mail server. Once that’s done the services that operate the calendar sharing functions will be properly configured and both users will be able to share calendars.

Exchange 2010 Relaying – How to use it, how to turn it off

Email Relay is one of the more annoying features of email servers. However, there are times it can be pretty useful. It’s annoying because Spammers love to exploit it, and it’s useful because it can allow you to centralize a lot of email services.

What is Email Relay?

Email relay is, quite simple, a feature that allows one email server to use another email server for sending mail. In a relay setup, one SMTP server is configured to relay all the mail it’s trying to send through another email server when the sending email address is not a part of the second server’s organization. In a relay situation, Server 1 will connect to Server 2 and attempt to send an email using SMTP. However, unlike a normal SMTP session where Server 1 sets the recipient as an email address that “belongs” to Server 2, Server 1 tries to send an email to a recipient in a completely different organization. A successful relay basically means that Server 1 can use Server 2, which accepts email for, to send email to

How is Relay Useful?

Usually, there’s very little, if any, need to use email relay. But there may be situations where you have an application or device that has its own email server solution built in that needs to be able to send email to various recipients. Without the ability to relay, that application or device would need to have wide open access to the Internet in order to send email. This is not always an optimal solution, especially if you already have an email solution in place. It’s simply more secure to have that application or device relay mail through the central email solution.

How is Relay a Pain?

Allowing relay on an email server can cause some major problems, though. The biggest problem is with spammers. Spammers have software that will go to as many public IP addresses as possible, looking for IPs that respond on port 25. If a server responds, the software will attempt to send an email to a recipient by creating a relay session. If the relay session succeeds, that server is tagged as an “Open Relay” and the software will attempt to use that server as a source for loads and loads of Spam. This often results in massive mail queues and the server that is being used to relay mail will often be blacklisted and legitimate mail from that server ends up getting blocked by email systems that use blacklists as a form of spam filtering. In other words, having an open relay can cripple your Email infrastructure in any number of ways.

Relaying with Exchange 2010

By default, Exchange 2010 does not allow relaying. In fact, the last Email server developed by Microsoft that allowed relay by default was Exchange 2003. However, it is possible to configure Exchange 2010 to work as a relay, but you have to be careful with it because you don’t want to turn your Exchange server into an open relay for spammers to use and abuse.

Relaying in Exchange 2010 (and 2007 if you haven’t made the jump to 2010) is accomplished through the use of a simple setting that exists on the Receive Connectors. It’s called Externally Secured Authentication. Unfortunately, MS didn’t do a very good job at explaining what that setting actually does. The setting exists on the Authentication tab of the Receive Connector properties screen in the Exchange Management Console. The image below shows this setting:

The Externally Secured Authentication setting on Receive Connectors basically removes all security blocks and allows complete and total access to that receive connector for any server with an IP address that matches the address range configured in the Network tab on the connector. This means that once that little box is checked, any computer that matches the connector’s IP range can use the Exchange Hub Transport Server as a Relay.

The Externally Secured Authentication setting shuts everything off because it assumes that you are using some other security technique to allow other mail servers to communicate with the connector. So if you have a Unix mail server that has to send mail to your Exchange server, you can secure the communication between the two servers using IPSec or some other technique to prevent snooping and unauthorized access. Exchange assumes that the connection between hosts is secure and therefore allows complete access to all servers that communicate through the connector.

Shutting Down Open Relay in Exchange 2010

If you have Exchange 2010 and discover that your server is an open relay, the cause is usually due to someone having configured Externally Secured Authentication on your Default Receive Connector. The Default Receive Connector in Exchange 2010 is set up to allow communication with¬†all IP addresses. If the Externally Secured Authentication setting is checked on the Default Receive Connector, every IP address is therefore allowed to use your Hub Transport Server to send mail to any recipient. This is not a good thing. Now, it’s possible to have that setting checked on the Default Receive Connector and still close open relay (Alan Hardisty has instructions on his blog here: ) but in general, there is no reason to enable Externally Secured Authentication on a publicly accessible Receive Connector. So just don’t use that setting on Default Receive Connectors

Configuring a Relay Connector in Exchange 2010

So let’s take a for-instance. Let say you have an application that has to send emails to people who aren’t in your organization. You really want to use a Relay connector to do this. Here’s how you set it up in the EMC:

1. Navigate to Server Configuration -> Hub Transport in the EMC.

2. Click New Receive Connector in the Right side pane.

3. When the Wizard pops up, enter a name for the connector (Relay Connector works fine) and click Next

4. The Local Network Settings screen doesn’t have anything you have to worry about for this, so you can click next to go on or change the settings there to meet your needs.

5. The Remote Network Settings section of the wizard is where we actually secure this relay connector. The image below shows the default screen:

By default, you can see that the entire IPv4 range shows up (I have IPv6 disabled on my email server, on yours it may show the whole IPv6 range here as well). Select all entries that show here and click the red X to remove them. Click Add and enter the IP address of the server you want to allow relay to. Click Next, then New to finish the wizard and create the connector.

6. Once the wizard is done and the connector is created, you should see it in the EMC. Right click the new connector and go to the Permissions tab first. Select Anonymous and Exchange servers (You have to do this to allow Externally Secured Authentication to be a valid selection). You can also check whatever other groups you want as well.

7. Click the Authentication tab and select the Externally Secured Authentication box. Remove all other check marks and click Apply. Click apply and the connector will be set up properly to allow Relay.

8. Click the Network tab and make sure that only the servers you want to relay are listed under “Receive mail from remote servers that have these IP addresses.” If you still have the full IP range listed the server will be an Open Relay at this point.

Note that when you do this, all communications between the server that is sending mail to the Relay server will be in clear text. This means that anyone sniffing traffic between the two mail servers can read the emails with ease. This is usually not a big deal on an Internal network, but you’ll want to make sure there actually *is* an external encryption system going between the two servers to secure the transmission of data.