How to get public path via email address

You may have issue to find a public folder path that you know the email address of the PF:

Here is the cmdlet you need to find out the path:

1. Set-AdServerSettings -ViewEntireForest $true -PreferredGlobalCatalog gc1.contoso.com

2. Get-PublicFolder cmdlet to find the path via the PF's email address:

Get-MailPublicFolder AccountsPayable@domain.com | Get-PublicFolder

you will see output something like below:

Name                                                        Parent Path
----                                                             -----------
Accounts Payable                                     \Accounting\US\Americas Choice

Missing Autodiscover information in your Exchange Autodiscover XML Response?

We had issue with Outlook anywhere that cannot be configured automatically reported from remote site. When we use Remote Connectivity Analyzer (https://www.testexchangeconnectivity.com/) to test Outlook Autodiscover, all the External URL (items below the <Type>EXPR</Type> lines) was missing.

After carefully checking the output, our EXPR type output is as follow:

Type>expr</Type>
 <Server>exchange.contoso.com</Server>
 <ASUrl>https://exchange.contoso.com/EWS/Exchange.asmx</ASUrl>
 <OOFUrl>https://exchange.contoso.com/EWS/Exchange.asmx</OOFUrl>
 <OABUrl>https://exchange.contoso.com/OAB/83099da3-46bc-49e3-9e35-4353f0f95268/</OABUrl>
 <UMUrl>https://exchange.contoso.com/EWS/UM2007Legacy.asmx</UMUrl>
 <Port>0</Port>
 <DirectoryPort>0</DirectoryPort>
 <ReferralPort>0</ReferralPort>
 <SSL>On</SSL>
 <AuthPackage>Basic</AuthPackage>
 <EwsUrl>https://exchange.contoso.com/EWS/Exchange.asmx</EwsUrl>
 <SharingUrl>https://exchange.contoso.com/EWS/Exchange.asmx</SharingUrl>
 <EcpUrl>https://exchange.contoso.com/ecp/</EcpUrl>
 <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um>
 <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr>
 <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt>
 <EcpUrl-ret>?p=organize/retentionpolicytags.slab&amp;exsvurl=1</EcpUrl-ret>
 <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms>
 </Protocol>
 <Protocol>

and normal output should be as follows:

<Type>EXPR</Type>
 <Server>exchange.contoso.com</Server>
 <ASUrl>https://exchange.contoso.com/EWS/Exchange.asmx</ASUrl>
 <OOFUrl>https://exchange.contoso.com/EWS/Exchange.asmx</OOFUrl>
 <OABUrl>https://exchange.contoso.com/OAB/83099da3-46bc-49e3-9e35-4353f0f95268/</OABUrl>
 <UMUrl>https://exchange.contoso.com/EWS/UM2007Legacy.asmx</UMUrl>
 <Port>0</Port>
 <DirectoryPort>0</DirectoryPort>
 <ReferralPort>0</ReferralPort>
 <SSL>On</SSL>
 <AuthPackage>Basic</AuthPackage>
 <EwsUrl>https://exchange.contoso.com/EWS/Exchange.asmx</EwsUrl>
 <SharingUrl>https://exchange.contoso.com/EWS/Exchange.asmx</SharingUrl>
 <EcpUrl>https://exchange.contoso.com/ecp/</EcpUrl> ;
 <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um>
 <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr>
 <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt>
 <EcpUrl-ret>?p=organize/retentionpolicytags.slab&amp;exsvurl=1</EcpUrl-ret>
 <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms>
 </Protocol>
 <Protocol>

Do you see the difference between ours and normal Type>expr</Type> vs <Type>EXPR</Type>?

lowercase expr vs Uppercase EXPR.

Oups, EXPR is case sensitive here!!!

Check our Exchange configuration

>get-OutlookProvider -id expr |FL

RunspaceId           : a86dfb0a-3f3f-4b39-a264-cd6cd993853d
CertPrincipalName    :
Server               :
TTL                  : 1
OutlookProviderFlags : None
AdminDisplayName     :
ExchangeVersion      : 0.1 (8.0.535.0)
Name                 : expr
DistinguishedName    : CN=expr,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=contoso,CN=Microsoft Exchange,CN=Serv
                       ices,CN=Configuration,DC=contoso,DC=com
Identity             : expr
Guid                 : 57b60bde-e415-4ce2-b618-5a2425a230e7
ObjectCategory       : contoso.com/Configuration/Schema/ms-Exch-Auto-Discover-Config
ObjectClass          : {top, msExchAutoDiscoverConfig}
WhenChanged          : 3/3/2014 2:53:33 AM
WhenCreated          : 3/3/2014 2:41:58 AM
WhenChangedUTC       : 3/3/2014 7:53:33 AM
WhenCreatedUTC       : 3/3/2014 7:41:58 AM

As you can see above it seems some admin created Identity             : expr WhenCreated          : 3/3/2014 2:41:58 AM.

This is the root cause of the issue and the following cmdlet that helped us to fix the issue

Remove-OutlookProvider -Identity expr

New-OutlookProvider -Name EXPR

After that, run the following command to verify and test Outlook Anywhere works fine after that.

 >get-OutlookProvider -id expr |FL

RunspaceId           : 0c0cf3a8-ad17-432c-8b8d-0d6daabe64df
CertPrincipalName    :
Server               :
TTL                  : 1
OutlookProviderFlags : None
AdminDisplayName     :
ExchangeVersion      : 0.1 (8.0.535.0)
Name                 : EXPR
DistinguishedName    : CN=EXPR,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=contoso,CN=Microsoft Exchange,CN=Serv
                       ices,CN=Configuration,DC=randomhouse,DC=com
Identity             : EXPR
Guid                 : 49918614-cafb-4193-9f06-bdb2287c31f1
ObjectCategory       : contoso.com/Configuration/Schema/ms-Exch-Auto-Discover-Config
ObjectClass          : {top, msExchAutoDiscoverConfig}
WhenChanged          : 6/4/2014 2:55:02 PM
WhenCreated          : 6/4/2014 2:45:24 PM
WhenChangedUTC       : 6/4/2014 6:55:02 PM
WhenCreatedUTC       : 6/4/2014 6:45:24 PM

By the way, for those who ran the test and got the following error:

"The EXCH provider section is missing from the Autodiscover response" message and Exchange 2010 Outlook Anywhere (RPC over HTTP) not working

here is the fix for this:

The EXCH provider section is missing from the Autodiscover response"

 

I'm sure, you already checked all Internal / External URL settings

But, have you checked your Mailbox Database settings and see what do you have configured as RPCClientAccessServer? You can do this by running the following cmdlet:

 

Get-MailboxDatabase | fl Server, RPCClientAccessServer

 

If your RPCClientAccessServer is not set or set not exactly as it supposed to be, you can  correct this as illustrated in the following example:

 

Set-MailboxDatabase -Identity "MYMBXDB-1″ -RpcClientAccessServer outlook.contoso.com

 

Note: In this case outlook.contoso.com is a FQDN name of my Network Load balancer

How to use OAB Global Web Distribution in Exchange Server 2010

In Today's post I am going over a nice feature that is not used a lot in most of the customers that I worked with which is the Global web Distribution for OAB.

In the default OAB we will see something like this for the Default Offline Address Book. In a normal situation we would go there and enable the Web-based distribution and add the servers which is totally fine when you have a few servers and you don't change a lot.

However let's think for a moment in environment with lots of sites where all sites have Exchange Servers, or in multi-tenancy environment where several servers are added/removed in a monthly basis. For our environment, once we tried to add new server, it takes forever to get our server list

The automatic solution!

There is a neat solution called GlobalWebDistributionEnabled on each Offline Address Book. What this feature does is that configures automatic any new CAS server to receive the OAB which is great. If you want to do that

 

In order to get the information about any given OAB we can run the following cmdlet:

Get-OfflineAddressBook | Select Name,Version,AddressLists,Global* | fl

Cool, eh? If you want to enable that we just need to run the following cmdlet

Set-OfflineAddressBook –Identity '\Default Offline Address Book' –GlobalWebDistributionEnabled $True

Now if an administrator goes there to try to add something that is going to be the message that you won't able to add the server since you have GlobalWebDistributionEnabled.

Note: The Public folder distribution method is not impacted by this procedure so it's up to you whether you enable or not such feature.

Configure the Autodiscover Service to Use AD Site Affinity

Set-ClientAccessServer -Identity "ServerName" -AutodiscoverSiteScope "Site-A","Site-B","Site-C"

Upgrade Distribution List from Exchange 2003 to Exchange 2010

Issue: We run issue with very strange mail routing. We are still in mixed mode with Exchange 2003 and Exchange 2010. One of users reported email delay happened to a specific DL.

Troubleshooting Steps:

After login to one of the mailboxes who received the email and found out very interesting routing behavior from the message headers:

Message was sent from an internal 3rd application, via port 25's PMTA. The message reached Exchange 2010 hub first, then forwarded to Legacy Exchange 2003 Connectors, then sent back to the Exchange 2010 Hub and back to users' mailbox on Exchange 2010.

The delay happened with some disk issue on one of legacy Exchange 2003 connector servers. First though could be due to the DL that has not be upgraded to Exchange 2010. Spent some time to upgrade all DLs at our Domains that all mailboxes have been upgraded to 2010 for a while. Working with scripts to remove space from alias, incorrect characters from DL alias such as "@", "(" or ")", BTW, here is the cmdlet I used to remove space, @, (, or ):

Get-DistributionGroup -ResultSize unlimited | foreach {$_.alias = $_.alias -replace '\s|,|\.'; $_} | Set-DistributionGroup

for removing space from alias or

Get-DistributionGroup  -ResultSize unlimited | foreach {$_.alias = $_.alias -replace '\s|,|\.' -replace '\(|,|\.' -replace '\)|,|\.' -replace  '\@|,|\.'; $_} | Set-DistributionGroup

Then run force upgrade of the DLs:

Get-DistributionGroup –ResultSize Unlimited | Set-DistributionGroup –ForceUpgrade

After that, you may still get some issue with some of DLs that you may have to manually upgrade.

All of DLs have been upgraded and the issue still existing.

After digging, and found out one of the Legacy Exchange 2003 Connector servers were running out of space. fixed the issue, reboot all Ex2003 connector servers and Exchange 2010 hub servers. Delay issue has been resolved, however, the strange email routing issue still existing.

Get-DistributionGroup   |FL printed output to file and focused on print out of the DL we had the issue.

Finally I found the settings of the DL was specified with the legacy Exchange 2003 server that we had issue as expansion server. After removed the expansion server, The strange routing issue has been resolved.

Here is the cmdlet I used to change all possible DLs that may have such settings:

Get-DistributionGroup –ResultSize Unlimited | Set-DistributionGroup -ExpansionServer $Null

Keyword: DistributionGroup upgrade, Exchange 2003 connector, Routing issue, Expansion Server of DL.