Public Folder Migration Error

So when I tried to migrate public folders from Exchange 2007 to 2013, I encountered the following error:

Error: Property expression "xxx xxx" isn't valid.

It appears that for some reason, some mail enabled Public Folders had Alias properties with blanks in them. As we all know, blank or spaces are not allowed in Alias field.

The easiest way to fix this is to launch Public Folder Management Console (from mmc.exe, add snap-in), locate all mail enabled public folder and correct the Alias field.

WAAD DirSync - Broken PowerShell

As widely documented, to manually start the Windows Azure Active Directory DirSync (installed as part of the Office 365 deployment), the following PowerShell commands are issued:

Import-Module DirSync
Start-OnlineCoexistenceSync

Sources:
http://blogs.technet.com/b/rmilne/archive/2014/10/01/how-to-run-manual-dirsync-_2f00_-azure-active-directory-sync-updates.aspx

http://technet.microsoft.com/en-us/library/jj151771.aspx

The only trouble is that, when I tried running the PowerShell command "Import-Module DirSync" on my WAAD DirSync server, I get the following error message!

The message says:
Get-Item : Cannot find path 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence' because it does not exist.

The trouble is, the registry does exist, as proven here:

So what I have done to fix it is:

1. Navigate to your WAAD DirSync install path, typically "C:\Program Files\Windows Azure Active Directory Sync\DirSync\"
2. In there, there should be a file named "ImportModules.ps1"
3. Open the file and replace the second line with "$DirSyncInstallPath = "C:\Program Files\Windows Azure Active Directory Sync\"
4. Save the file, and now you can run "Import-Module DirSync" with no problems.

The resultant file should look like the following (ignore the filename in the picture, it should named  ImportModules.ps1):

Exchange 2013 CU6 Beware!

Exchange 2013 CU6 have several bugs at the moment:

1. Exchange Server 2013 databases unexpectedly fail over in a co-existence environment with Exchange Server 2007 - http://support2.microsoft.com/kb/2997209
2. You cannot route ActiveSync traffic to Exchange 2007 mailboxes after you upgrade to Exchange 2013 CU6 - http://support2.microsoft.com/kb/2997847
3. Hybrid deployment's centralized mail transport doesn't work (when you want to route all Internet bound emails - including users located in Office 365 to your on premise Exchange Server 2013) - http://nathennod.blogspot.com.au/2014/10/hybrid-deployment-route-all-emails.html

First 2 problems are currently fixed via an combined interim update "Exchange2013-KB2997209_2997847-x64-en.msp", and the third problem currently only has a workaround. Please contact Microsoft directly for the patch - the support call is free of charge.

Regarding problem one, even though we have migrated everyone across to Exchange 2013, the ExchangeIS keeps crashing at soon as the users logon to their mailbox (not after the mailbox is migrated). This is particularly annoying as you wouldn't know that you have the problem until users actually start accessing their mailbox.

Hybrid Deployment - Route all emails (including Internet bound email from Office 365 users) to On Premise

There will be situation where the client wants to route all emails (including the ones from Office 365 users to the Internet) to on premise Exchange server first, before sending it out. The most common reason is for centralised tracking and quarantining.

To perform this, during HCW, you would pick the option "Enable centralized mail transport" during the HCW wizard, i.e.:

The only problem is that, when an Office 365 user sends an email to any Internet recipient, it would fail with NDR - "5.7.1 Unable to relay". Further examining the NDR, it would seem that the On Prem Exchange Server (in my case - Exchange 2013 CU6) is rejecting the email relay.

The only article I can find that relates to this problem is here (http://community.office365.com/en-us/f/148/t/265897.aspx), but I couldn't find the receive connector named "Inbound from Office 365" on my Exchange 2013. See below:

So apparently, Exchange 2007 HCW creates a new receive connector called "Inbound from Office 365" and Exchange 2013 HCW just reconfigures the "Default Front End servername" receive connector with TLS authentication with Exchange Online Protection, as seen in the following HCW log entry:

[10/06/2014 13:36:21]    INFO : Session=OnPrem Cmdlet=Set-ReceiveConnector -Identity 'ServerName\Default Frontend ServerName' -TLSCertificateName 'CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=USCN=*.company.com, O=Company Name' -TLSDomainCapabilities 'CN=MSIT Machine Auth CA 2, DC=redmond, DC=corp, DC=microsoft, DC=comCN=mail.protection.outlook.com, OU=Forefront Online Protection for Exchange, O=Microsoft, L=Redmond, S=WA, C=US:AcceptCloudServicesMail' START

With Exchange 2013 CU6, it seems like there is a bug that relay is not enabled on the "Default Frontend" receive connector.

According to the Microsoft engineer, it is a bug that has been highlighted to the product group.

So to fix the problem, I just need to issue the command and the problem is fixed:

Get-ReceiveConnector "ServerName\Default Frontend ServerName" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Exchange 2013 Hybrid Configuration Wizard Failing

I couldn't get the Hybrid configuration wizard working. The moment after I sign into Office 365, I get the following error:

HTTP Error 500.19 - Internal Server Error
Absolute physical path "C:\inetpub\custerr\C:\inetpub\custerr" is not allowed in system.webServer/httpErrors section in web.config file. Use relative path instead.

Screenshot here:

Looking up and down the Internet, I could not find any useful clue at all. Out of the whim, I decided to move the mailbox that my admin account is associated with to Exchange 2013 and problem fixed!

Hopefully this is useful for some other poor folks with the same problem.

There are a lot of discussions about Exchange 2013 CU6 causing co-existence and hybrid problems but I do not this has been documented before.

ActiveSync and AdminSIDHolder

This one is an oldie but wanted to write a little bit about it here. Basically, mailboxes with Domain Admin privilege (and some other admin type group memberships) cannot initiate ActiveSync once their mailbox is moved from Exchange 2007 to 2013.

The following log entry is observed in Exchange 2013:

Log Name:      Application
Source:        MSExchange ActiveSync
Date:          6/10/2014 6:27:44 PM
Event ID:      1053
Task Category: Configuration
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Exchange2013Server.company.com
Description:
Exchange ActiveSync doesn't have sufficient permissions to create the "CN=User Name,OU=IT,OU=Administration,DC=company,DC=com" container under Active Directory user "Active Directory operation failed on dc.company.com. This error is not retriable. Additional information: Access is denied.
Active directory response: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
".
Make sure the user has inherited permission granted to domain\Exchange Servers to allow List, Create child, Delete child of object type "msExchangeActiveSyncDevices" and doesn't have any deny permissions that block such operations.

Also, from exRCA:

Attempting the FolderSync command failed.
Exchange ActiveSync returned an HTTP 500 response (Internal Server Error)

There are two ways to fix this, either by passing security on AdminSIDHolder by granting the required ActiveSync permissions on it, or make the changes on every privileged user's (usually domain admin) AD account - but caveat is that the user might make the ActiveSync directory sync within the hour, or AdminSIDHolder will kick in the original settings again.

1. AdminSIDHolder "fix"/bypass - http://daddyr.blogspot.com.au/2013/08/add-acls-to-adminsdholder-for-exchange.html

REM This user permissions
dsacls "CN=AdminSDHolder,CN=System,DC=MYDOMAIN,DC=COM" /G "MYDOMAIN\Exchange Servers:CCDC;msExchActiveSyncDevices"

REM Descendant msExchActiveSyncDevices objects
dsacls "CN=AdminSDHolder,CN=System,DC=MYDOMAIN,DC=COM" /I:S /G "MYDOMAIN\Exchange Servers:LCRPWPRCWD;;msExchActiveSyncDevices"
dsacls "CN=AdminSDHolder,CN=System,DC=MYDOMAIN,DC=COM" /I:S /G "MYDOMAIN\Exchange Servers:CCDC;msExchActiveSyncDevice;msExchActiveSyncDevices"

REM Descendant msExchActiveSyncDevice objects
dsacls "CN=AdminSDHolder,CN=System,DC=MYDOMAIN,DC=COM" /I:S /G "MYDOMAIN\Exchange Servers:LCRPWPRCWD;;msExchActiveSyncDevice"

2. Per user setting - but be quick! Setup ActiveSync within the hour - http://namitguy.blogspot.com.au/2010/09/exchange-2010-activesync-issue-or.html

• Launch ADUC and make sure Advanced View is enabled
• Right-click the user account and go to Properties
• Click the Security tab, then click Advanced
• Check the Include inheritable permission.... checkbox
• OK out of all the dialog boxes
• Sync your device

Sigh - Outlook Anywhere Exchange 2007 not playing nice with Exchange 2013

OK, now it's Outlook Anywhere's turn to go wonky. Users on Ex2007 is reporting that they cannot access Outlook externally.

exRCA returned an error:

RPC Proxy can't be pinged.

Additional Details An unexpected network-level exception was encountered. Exception details: Message: The remote server returned an error: (401) Unauthorized. Type: Microsoft.Exchange.Tools.ExRca.Extensions.MapiTransportException Stack trace: at Microsoft.Exchange.Tools.ExRca.Extensions.MapiRpcTestClient.PingProtocolProxy(String endpointIdentifier) at Microsoft.Exchange.Tools.ExRca.Tests.MapiPingProxyTest.PerformTestReally() Exception details: Message: The remote server returned an error: (401) Unauthorized. Type: System.Net.WebException Stack trace: at System.Net.HttpWebRequest.GetResponse() at RpcPingLib.RpcPing.PingProxy(String internalServerFqdn, String endpoint) at Microsoft.Exchange.Tools.ExRca.Extensions.MapiRpcTestClient.PingProtocolProxy(String endpointIdentifier) Elapsed Time: 280 ms.

To make the long story short, the authentication method for Outlook Anywhere has to be set to NTLM on both Ex2013 and Ex2007. Again, just like the previously mentioned ActiveSync and OWA virtual directory issues, I had to reconfigure Outlook Anywhere.

1. Disable Outlook Anywhere (http://technet.microsoft.com/en-us/library/bb124537(v=exchg.80).aspx)
2. Enable Outlook Anywhere - only performing the step under "To use the Exchange Management Console to enable Outlook Anywhere" (http://technet.microsoft.com/en-us/library/bb123889(v=exchg.80).aspx)

Re configuring Outlook Anywhere will need 15 minutes to take effect. Watch the event viewer for the following entry:

Event Type: Information
Event Source: MSExchange RPC Over HTTP Autoconfig
Event Category: General 
Event ID: 3003
Date: 6/10/2014
Time: 10:50:51 AM
User: N/A
Computer: EXCHANGESERVER
Description:
The Outlook Anywhere authentication settings have been updated.

Old settings: Ntlm
New settings: Basic

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This article provides an extremely friendly insight that I could not find elsewhere:

http://blogs.technet.com/b/rmilne/archive/2014/03/19/exchange-2007-2013-outlook-anywhere-coexistence.aspx

The parts that struck me was:

1. Note the two different authentication settings that are listed.  ClientAuthenticationMethod and IISAuthenticationMethods.   For the detail oriented people out there, you saw that one was plural and the other singular.
2. Client authentication, which is used to allow clients like Outlook 2013 to authenticate with Exchange is properly configured.  The same consistent OA client authentication scheme should be deployed on legacy CAS and CAS 2013. 
3. Internet Information Services (IIS) authentication, which is used to allow Exchange servers to communicate MUST include NTLM auth.

Therefore, I have also additionally set the IISAuthenticationMethods to NTLM as well (it was Basic only for some reason)

Set-OutlookAnywhere -Identity 'ExchangeServer\Rpc (Default Web Site)' -ClientAuthenticationMethod Basic -SSLOffloading $False –ExternalHostName http://webmail.company.com -IISAuthenticationMethods NTLM, Basic

Exchange 2007 OWA not playing nice with Exchange 2013 for redirection

As part of Exchange 2007 & 2013 co-existence, to provide seamless OWA login for both users having mailboxes in either Exchange environment, the typical Microsoft prescribed method of OWA redirection was deployed  - http://blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx

As the customer was using ISA Server 2006, the first thing is to bypass that and change Exchange 2007 OWA into Forms Based Authentication (FBA). It was set to Basic Authentication previously to support ISA 2006 publishing.

Here comes the trouble, after logging in from OWA 2013, the following error message was displayed:

440 Login Timeout

We tried numerous things, including changing the authentication methods in IIS7 for OWA, but none worked.

The only way that we managed to get it working is to re-create the OWA virtual directories following the article (http://support2.microsoft.com/kb/941201). Only trouble is, although all the virtual directories were deleted and recreated successfully, the /OWA virtual directory would not come up! When the PowerShell cmdllet was ran, an obscure error message popped out (sorry I didn't have screenshot), basically saying that is has no access to Active Directory.

Did a few things and none worked (including forceing AD replication "repadmin /syncall"),

More Internet searching came out with this solution  (http://blogs.dirteam.com/blogs/davestork/archive/2010/12/23/fixing-a-broken-owa-2010-virtual-directory.aspx) - but just as I was going to recreate the OWA container, I tried re-running the New-OWAVirtualDirectory cmdlet (not retyping it, just running the command history to repeat the command) and it worked.

I have no idea why only the /OWA virtual directory have this problem (/Exchange, /public/ and /exchweb had no such issue) - but I guess sometime button meshing does make sense.

Oh well, onward we go.

Exchange 2007 ActiveSync not playing nice with co-existence with Exchange 2013

This project that I am working on is giving me one gold nugget after another...  Anyway, so we are trying to setup co-existence between Exchange 2013 and 2007, and we stumbled into this issue.

Exchange 2013 does not seem want to proxy ActiveSync request for users still having mailbox on Exchange 2007. When testing Exchange Connectivity Test (https://testconnectivity.microsoft.com/), the error returned was:

An HTTP 500 response was returned from IIS7.

It seems that it's Exchange 2007 at fault here. The only way to fix it is to recreate the ActiveSync virtual directory on Exchange 2007, using the following PowerShell commands:


Remove-ActiveSyncVirtualDirectory -Identity "EXCHANGEServer\Microsoft-Server-ActiveSync (Default Web Site)" -Confirm:$false


New-ActiveSyncVirtualDirectory -WebsiteName "Default Web Site" -InternalUrl "https://webmail.company.com/Microsoft-Server-ActiveSync" -ExternalAuthenticationMethods Basic -InternalAuthenticationMethods Basic

The Exchange 2007 Microsoft-Server-ActiveSync virtual directory must be corrupted along the way. 

Exchange 2013 - Problems Relocating Log Path

After one of the Exchange 2013 database got dismounted due to insufficient log space, I've done the typical "ESEUTIL /MK" command to move the transaction log files as any self respecting Exchange Administrator would do. After mounting the database, I issued the following PowerShell command to move the log path for that database to a larger drive:

move-databasepath "DatabaseName" -LogFolderPath "G:\BiggerExchangeLogs\"

The PowerShell would start and then awkwardly dump me back to the prompt without any message.

So I did some searching and came up with the following solution:

Dismount-Database –identity "DatabaseName" -verbose

Move-DatabasePath –identity "DatabaseName" –logFolderPath –configurationOnly:$TRUE –verbose

ROBOCOPY /MOVE /XD *Catalog* /XF *.edb

Mount-Database –identity "DatabaseName" –verbose

Dismount-Database –identity "DatabaseName" -verbose

Although the article is to fix another bug in Exchange 2010, it worked perfectly in Exchange 2013 CU6 for this purpose.

Source: http://blogs.technet.com/b/timmcmic/archive/2010/10/04/exchange-2010-move-databasepath-results-in-an-invalidoperationexception-when-mount-points-are-utilized-for-storage.aspx

Fido what?

Nope, this has nothing to do with Fido Dido.


I've been working on this Exchange 2013 Hybrid deployment when I came across this when accessing OWA from IE11/Win8.1.

After I sign on (Exchange 2013 FBA), OWA briefly loads and then crashes with the following error message:

X-OWA-Error: ClientError;exMsg='fidoCallback' is undefined;file=https://owa.company.com/owa/:1
X-OWA-Version: 15.0.995.29
X-FEServer: EXCH-SVR
X-BEServer: null

Scouring the Internet, I could not find any reference to "fidoCallback" relating to OWA, but there were some other suggestions relating to Office 365 OWA crashing in similar fashion (but no reference to fidoCallback):

1. Clearing the cache (d'oh - first thing that anyone would try)
2. Reset IE's security setting to default (under Advanced tab, not Security tab)
3. Try InPrivate browsing
4. Make sure "Enable XMLHTTP Support" is enabled

None of them worked. I thought I was going mad as I got some other people to try it out as well, same Win8.1 and IE11. All of them worked.

Then I came across an article that talked about setting IE as the default browser - http://answers.microsoft.com/en-us/ie/forum/ie11-iewindows8_1/office-365-issues-with-ie11/5fb4f186-fdf1-4cde-ab48-b97987306aa6  (I use Chrome almost exclusively - which can access OWA without a problem) and it worked. Bizarre! To set IE as default, Start > Search > Default Programs > Set your default programs > Internet Explore > Set this program as default. Restarted my computer and voila!

I can't understand why this is happening, and I might ring up Microsoft if this persists. Keep posted!