Wednesday, November 9, 2016

What is a Scoped Send Connector?

After so many years of being available, the Scoped property of Send Connectors is still confuses some Exchange administrators, or simply goes by unnoticed.

So what exactly is a Scoped Send Connector? Simply put, when we configure a send connector as scoped, we are stating that only Exchange 2007/2010 Hub Transport or Exchange 2013/2016 Mailbox servers in the same Active Directory (AD) site as the send connector can use it. If this option is not selected, then the connector can be used by any Exchange server in any AD site in the same Exchange organization.

But what is the point of this option if we need to specify the Source Servers for the send connector? Doesn’t this option stipulate which Exchange servers can use the connector?! Well, not exactly...

The source servers for a send connector determine the destination Exchange server for mail that needs to be routed through the send connector. The send connector scope controls the visibility of the connector within the Exchange organization.

Once again, send connectors are by default visible to all the Exchange servers in the entire AD forest, and are used in routing decisions. However, we can limit a send connector’s scope so that it is only visible to other Exchange servers in the same AD site. The send connector is invisible to Exchange servers in other AD sites, and is not used in their routing decisions. A send connector that is restricted in this way is said to be scoped.

To configure scoped send connectors in the EAC (assuming Exchange 2013/2016), we select Scoped send connector in the Address space section of the new send connector wizard, or on the Scoping tab in the properties of existing send connectors (as previously shown).
When using the Exchange Management Shell, we use the IsScopedConnector parameter on the New-SendConnector and Set-SendConnector cmdlets.

Tuesday, November 1, 2016

Cannot expand the folder. The set of folders cannot be opened.

The other day a user was having problems accessing a meeting room’s mailbox in Outlook. Whenever she tried to expand its folder list, she would get the following error:

Cannot expand the folder. The set of folders cannot be opened. Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance.


First thing I tried was to remove and re-add the permissions, but to no vail:
Remove-MailboxPermission meeting.room@domain.com -User Linda -AccessRights FullAccess -InheritanceType All

Add-MailboxPermission meeting.room@domain.com -User Linda -AccessRights FullAccess -InheritanceType All


Second thing I tried was removing the permissions once again, but this time re-adding them without auto mapping:
Add-MailboxPermission meeting.room@domain.com -User Linda -AccessRights FullAccess -InheritanceType All –AutoMapping:$False

Then I manually added the mailbox via Account Settings. This seemed to have worked as the user could now expand the folders! However, when I closed and reopened Outlook the issue came back...


Third thing I tried was to use OWA to access the mailbox and everything worked fine! OK, seems to be a problem with Outlook itself. However, after creating a new profile, the issue was still there...
So, I decided to also give same access to a couple of other users and they all had the same problem (independently if they were in Online or Cached mode).

Time for some digging! Since this issue was all about Outlook, the first place I decided to look was in the RPC Client Access logs (or RCA logs), located by default at C:\Program Files\Microsoft\Exchange Server\V15\Logging\RPC Client Access


In these logs I found the following entry (multiple times) in the Failures column for the user:
RopHandler: Logon: [RopExecutionException] Couldn't find a mailbox for MailboxId: Dn[/o=EXCHANGE/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Meeting Room] in the current forest. The client should attempt to re-discover it.. Error code = UnknownUser (0x000003EB) -> [ObjectNotFoundException] The Active Directory user wasn't found.


Next, I used the Get-Mailbox and Get-ADUser cmdlets to search for the Distinguished Name of “/o=EXCHANGE/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Meeting Room” but couldn’t find it anywhere. There were a couple of X500 addresses for this mailbox, but none with this exact DN.

This meeting room was created years ago on Exchange 2010 and migrated to 2013. Like many other resource mailboxes in this particular environment, their naming convention is just awful and inconsistence, which made me think that I wouldn’t be surprised if somehow someone changed/deleted something they shouldn’t have...

Once I added a X500 address to this room with a value of “/o=EXCHANGE/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Meeting Room” the issue got fixed!