Exchange 2010 Outlook Anywhere users receiving prompts when proxied through Exchange 2013

Background

I was working with a customer who had Exchange 2010 & were in the process of migrating to Exchange 2013. As part of their migration process they pointed their Exchange 2010 Outlook Anywhere namespace (let’s call it mail.contoso.com) to Exchange 2013 in DNS. At this point all of their Outlook Anywhere clients should have been connecting to Exchange 2013 & then been proxied to Exchange 2010. While this was somewhat working, they also immediately noticed users were randomly being prompted for credentials, resulting in a negative user experience.

Sometimes the prompts would be when connecting to Public Folders while other times mail or directory connections from Outlook to Exchange.

Resolution

When I was approached with this issue/symptom it sounded familiar. After a search through my OneNote I realized I previously had a discussion with some people I know from Microsoft Support regarding this issue. Turns out this issue was recently addressed via http://support2.microsoft.com/kb/2990117 “Outlook Anywhere users prompted for credentials when they try to connect to Exchange Server 2013”.

This is actually an IIS issue with Server 2008 R2 (the operating system Exchange 2010 was installed on) that’s resolved by a hotfix. After installing the hotfix & rebooting the issue was resolved & their users no longer received the prompts.

 

 

Legacy Public Folder remnants in Exchange 2013 cause “The Microsoft Exchange Administrator has made a change…” prompt

Background

I usually refrain from writing posts on issues where I haven’t been able to fully reproduce them in my lab but enough people seem to be having this issue that it would be good to spread the word should another person find themselves afflicted by it. I’ve seen this issue happen in two different environments & then found out via the forums that several other people have run into it as well.

Issue

I was working with a customer who migrated from Exchange 2007 to Exchange 2013. After decommissioning the 2007 servers, all the Exchange 2013 mailboxes started getting the infamous “The Microsoft Exchange Administrator has made a change that requires you quit and restart Outlook” prompt.

This seemed odd because Exchange 2013 was supposed to all but eliminate those prompts. While it did eliminate the prompts when the RPC Endpoint (Server Name field in Outlook) changed, there are still other scenarios that could result in this prompt (please see reference links at bottom of post for a detailed history). One such thing relates to the Public Folder Hierarchy.

In this customer’s scenario, I determined that the “PublicFolderDatabase” attribute on every Exchange 2013 Mailbox Database was set to a value resembling the screenshot below:

In this case, the decommissioning of Exchange 2007 & its Legacy Public Folders was not done correctly (same issue probably would have occurred if it were 2010). The Public Folder Database was showing up as a deleted object in AD. So the result was that the Outlook clients were trying to access Public Folder information but were reacting in a way that resulted in the frequent prompt to restart Outlook.

The resolution in this case was to drill down to the properties of the Mailbox Database in ADSIEDIT & set the value of “msExchHomePublicMDB” to be blank. Afterwards, a restart of the Information Store Service resolved the issue.

Additional Info

Not long after this issue, I was contacted by a Consultant I know who encountered the exact same issue. After an improperly performed Exchange 2007 migration, the Exchange 2013 mailboxes were getting prompted to restart Outlook. That environment also had Mailbox Databases that were pointed to a deleted object for their default Public Folder Database. Clearing the value & restarting the Information Store Service also resolved their issue.

After hearing this I went online to see if any others were encountering this issue. I found the below two forum posts

Reference A

Reference B

I then tried to reproduce this in my own environment but could not. Manually deleting the Exchange 2007 Server object from AD as well as manually deleting the Public Folder Database object did leave the 2013 Mailbox Databases pointing to the ghosted objects, but I did not receive the prompts. It appears there’s a particular chain of events that causes this issue but even though I could not recreate them in my lab, it certainly seems like people are running into the issue in the wild. If you start receiving these prompts then I suggest looking to make sure your attributes are not also pointed to ghosted objects.

Note: I was also informed that you could leave yourself in this scenario by incorrectly performing a migration from Legacy Public Folders to Modern Public Folders.

During the migration, you run the “Set-Mailbox <PublicFolderMailboxName> –PublicFolder –IsExcludedFromServingHierarchy:$True” command to prevent the Modern Public Folders from serving the Hierarchy requests while you’re moving data over; when you eventually complete the migration you should run “Set-Mailbox <PublicFolderMailboxName> –PublicFolder –IsExcludedFromServingHierarchy:$False” to allow it to serve the Hierarchy requests. If you do not run this command then you may receive the same prompts.

Additional References

http://blogs.msdn.com/b/aljackie/archive/2013/11/14/outlook-and-rpc-end-point-the-microsoft-exchange-administrator-has-made-a-change-that-requires-you-quit-and-restart-outlook.aspx

http://blogs.technet.com/b/exchange/archive/2011/01/24/obviating-outlook-client-restarts-after-mailbox-moves.aspx

http://blogs.technet.com/b/exchange/archive/2012/05/30/rpc-client-access-cross-site-connectivity-changes.aspx

If you loved PFDAVADMIN…..

In 2010 PFDavAdmin is going away but the good new is there is a new tool called ExFolders

http://msexchangeteam.com/archive/2009/12/04/453399.aspx

You can DL here
http://msexchangeteam.com/files/12/attachments/entry453398.aspx

Quote from Ms Exchange Team

“For better or worse, ExFolders still has the same user interface as PFDAVAdmin, so things will look very familiar. However, there are a few changes I want to highlight.

• ExFolders must be run from an Exchange 2010 server – it cannot be run from a workstation as PFDAVAdmin could. It can connect to Exchange 2010 or Exchange 2007, but not older versions.
• Remove Item-Level Permissions is gone, because there are no item-level permissions in Exchange 2007 or 2010.
• DACL fix functionality is gone. With no WebDAV and no M: drive, non-canonical DACLs should be practically unheard of.
• Permissions export format between PFDAVAdmin and ExFolders are compatible.

There are also a few new features:

• Folder property imports are now supported. You were able to do folder property exports with PFDAVAdmin, but not imports.
• Item property exports are supported – that is, you can export a set of properties from all items in a folder. This feature request has come up again and again for troubleshooting purposes. Item property imports are not supported.
• ExFolders supports the new free/busy permissions that were introduced in Exchange 2007 and Outlook 2007.
• You can now connect to multiple mailbox stores at the same time, so you can run a batch operation against several mailbox stores or all mailboxes in the org if you need to.”

Problem after deleting legacy exchange administrative group

Start ADSI Edit. In the CN=Configuration container, locate the following container:

CN=Services,CN=Microsoft Exchange,CN=ORGANIZATION,CN=Administrative Groups,CN=administrative_group,

Now we were missing the ‘Folder Hierarchies’ folder – All we have to do is recreate it as follows: 
Create the “Folder Hierarchies” under the Exchange Administrative Group 

1. Right click on Exchange Administrative Group 
2. Select New Object 
3. Select msExchPublicFolderTreeContainer for the class and click Next 
4. Enter the following for the value: Folder Hierarchies, click Next 
5. Click Finish 

Create Public Folder Tree Object 

1. Right click CN=Folder Hierarchies -> New Object 
2. Selected msExchPFTree for the class 
3. For the value we entered, “Public Folders” and clicked next 
4. Clicked on the “More Attributes” button, selected msExchPFTreeType and set the 
value to 1. Note: This is very important that this value is set to a value of 1 as 
this tells Exchange that this is a MAPI Tree 
5. Click Ok and then finish 

Populate msExchOwningPFTreeBL attribute object of the PF Stores in the organization 
(Since this attribute is not directly editable, you have to follow the below steps 
to do this for each PF store) 

1. Get properties of the newly created “Public Folders” Tree object in ADSIEdit. 
2. Copy the distinguishedname value to the clipboard and then click cancel. 
3. Navigate to the Storage group that contains the Public Folder Store for this 
server and get properties of the server database. 
4. Locate the msExchOwningPFTree attribute and paste in the value that was copied 
to the clipboard in step 2. Click OK. 
5. Restart the Information Store Service 

Set permissions on the Public Folders

1. Start ADSI Edit. In the CN=Configuration container, locate the following container:

CN=Services,CN=Microsoft Exchange,CN=ORGANIZATION,CN=Administrative Groups,CN=administrative_group,CN=Folder Hierarchies,CN=Public Folders

Note In this container, ORGANIZATION is the name of the Exchange Server organization and administrative_group is the name of your administrative group.

1. Right-click CN=Public Folders, and then click Properties.
2. Click the Security tab.
3. Make sure that the Allow inheritable permissions from parent to propagate to this object check box is selected.
4. Make sure that the Everyone group has the following Allow permissions:

• Create named properties in the information store
• Create public folder
• Create top level public folder

If the Allow inheritable permissions from parent to propagate to this object check box is selected, the Everyone group should already have these permissions. Make sure that the Deny check boxes are not selected.

6. Now try to mount the PF store and see if we can access it fine now. 

http://support.microsoft.com/?id=313866 
http://technet.microsoft.com/en-us/library/cc817865.aspx 
http://social.technet.microsoft.com/Forums/en-US/exchangesvravailabilityandisasterrecovery/thread/35769dc6-1b32-4409-a2c2-38d1de37db01/

Things that frequently get forgotten when migrating

Public Folders are not replicated or moved

To replicate public folders:

Use either PFDAVADMIN or Exchange system manager from 2003

PFDAVADMIN

•  

ESM

• You can set by adding the replication partners on each folder by right click the folder -> properties -> replication tab -> add
• 
• Or by right click the folder -> all tasks -> manage settings -> next -> modify list of replica servers -> -> add servers

To move public folder replicas

• From Exchange Powershell “.\MoveAllReplicas.ps1 -Server <MySourceServer> -NewServer <MyTargetServer>”

Exchange Team Article on the matter http://msexchangeteam.com/archive/2007/07/09/445967.aspx

Address Lists are not upgraded

To upgrade all address lists: (Just the default lists)

set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients
Set-AddressList “All Users” -IncludedRecipients MailboxUsers
Set-AddressList “All Groups” -IncludedRecipients MailGroups
Set-AddressList “All Contacts” -IncludedRecipients MailContacts
Set-AddressList “Public Folders” -RecipientFilter { RecipientType -eq ‘PublicFolder’ }
Set-GlobalAddressList “Default Global Address List” -RecipientFilter {(Alias -ne $null -and (ObjectClass -eq ‘user’ -or ObjectClass -eq ‘contact’ -or ObjectClass -eq ‘msExchSystemMailbox’ -or ObjectClass -eq ‘msExchDynamicDistributionList’ -or ObjectClass -eq ‘group’ -or ObjectClass -eq ‘publicFolder’))}

OAB is not moved or upgraded

• From Powershell: Move-OfflineAddressBook -Identity <OfflineAddressBookIdParameter> -Server <ServerIdParameter>