Category: Exchange 2013

Just ran into this one,

An existing Exchange 2013 CU2 installation was requested to be updated to CU5, nothing special there…

Once trying to run the CU5 setup.exe /PrepareAD , the setup failed with an error:
[02/07/2014 11:57:49.0192] [1] [ERROR] Active Directory operation failed on dc.domain.com. The object 'CN=Default,CN=OWA Mailbox Policies,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com' already exists.
[02/07/2014 11:57:49.0192] [1] [ERROR] The object exists.

Digging in the ExchangeSetup.log file, I’ve tried to identify the cause.

[02/07/2014 11:57:49.0192] [1] [ERROR] The following error was generated when "$error.Clear();
$policyDefault = Get-OwaMailboxPolicy -DomainController $RoleDomainController | where {$_.Identity -eq "Default"};

if($policyDefault -eq $null)
{
New-OwaMailboxPolicy -Name "Default" -DomainController $RoleDomainController
}
" was run:
"Microsoft.Exchange.Data.Directory.ADObjectAlreadyExistsException:
Active Directory operation failed on dc.domain.com. The object 'CN=Default,CN=OWA Mailbox Policies,CN=Exchange,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=domain,DC=com' already exists. ---> System.DirectoryServices.Protocols.DirectoryOperationException:
The object exists.

So I’ve tried to reproduce the test manually using the same command in the setup:
Get-OwaMailboxPolicy -DomainController $RoleDomainController | where {$_.Identity -eq "Default"}
And the result was indeed $null .. which made no sense here… because it does exists, as the error states – the object ‘CN=Default,CN=OWA Mailbox Policies,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com’ already exists.

Then I’ve noticed that the CN was “default” with lower “d” … although the Where-Object and -eq should be case insensitive, the check failed…

So, I’ve modified the value to be “Default” with capital “D”:

Set-OwaMailboxPolicy -Identity default -Name Default

that did the trick 🙂 and the setup.exe /PrepareAD was successful.

ilantz

Hi,

With Exchange 2013 deployments already in place, I’ve wanted to share with you all some “new” behaviors, tips and more to help you prevent headaches and issues 🙂

With regards to two previously posts – Prevent Outlook Anywhere (aka RPC over HTTP) from being automatically configured in Exchange 2007 with autodiscover and also Authentication pop ups and annoyances with Exchange 2007 / 2010 and Outlook Anywhere – this post is some sort of a follow-up.

With Exchange 2013, Outlook Anywhere (aka RPC over HTTP/s) is the default method for Outlook clients connections – that is no more direct RPC connections to the servers for Outlook clients. Exchange 2013 will essentially require you to utilize Autodiscover and Outlook Anywhere to actually get your Outlook client connected. This is the main reason for writing this post. This information will come useful if you are getting ready or already started to deploy Exchange 2013, I’ll try to keep it simple and write this down as a list of things to consider so this will be rather easy to all.

1. If you followed my post about how to prevent Outlook Anywhere from being configured and removed the EXPR outlook provider, start with restoring it. Run the following powershell command to restore it:
   New-OutlookProvider -Name:EXPR
2. If you’re using any additional methods to configure Outlook Clients or Outlook Anywhere like, static XML files, Registry settings or Group Policy settings make sure to revise or even remove them. See also http://support.microsoft.com/kb/2212902
3. Pay attention to publishing guides for Exchange 2013 – see Publishing Exchange Server 2013 using TMG and also Exchange 2013 Client Access Server Configuration
4. When enabling Outlook Anywhere on Exchange 2013 notice the following:
   1. Retain the current External authentication method (Basic,NTLM) your internal authentication method should always be NTLM.
      Get-OutlookAnywhere –Server (hostname) | Set-OutlookAnywhere -InternalHostname "mail.domain.com" -InternalClientAuthenticationMethod Ntlm -InternalClientsRequireSsl $true -ExternalHostname "mail.domain.com" -ExternalClientAuthenticationMethod Basic -ExternalClientsRequireSsl $true -IISAuthenticationMethods NTLM,Basic -ssloffloading:$false
   2. Enable NTLM on the IIS /rpc directory of your Exchange 2007/2010 servers
      Get-OutlookAnywhere | ?{ $_.AdminDisplayVersion -notlike "Version 15.*"} | Set-OutlookAnywhere -IISAuthenticationMethods NTLM,Basic
5. Plan the CertPrincipalName value you will use, that is the certificate Subject Name that your clients will use to populate the msstd:server.domain.com value – both internally and externally (reminding you to see the note above). My personal best practice is to use the same Subject Name on the certificate you will use on your External TMG/UAG/Juniper/F5 reverse proxy and your internal server or servers.
   Once you are aware of this value you can configure your Outlook Provider accordingly (you can refer to this post for more information on the subject).
6. If you installed a wildcard certificate on your Exchange 2013 server – you must perform the following:
   1. Update your EXPR setting – Set-OutlookProvider EXPR -CertPrincipalName msstd:*.company.com
   2. Update your EXCH setting (yes!) – Set-OutlookProvider EXCH -CertPrincipalName msstd:*.company.com
7. Don’t freak out when you see Exchange 2013 “new” server name – it’s value is actually the Mailbox GUID value, and will be unique for all users. This means that – you must use the Autodiscover wizard to configure outlooks from now on, Email, password and click next.
   If you have full mailbox access to a different mailbox – that’s great- just type it’s email address and enter whatever you want for password. (will work only inside the LAN…)
8. Don’t forget to update your Outlook clients – or else they will not connect to Exchange 2013 – see Exchange 2013 System Requirements for the exact information.

That’s it for now, while deployments continue I will update this topic with new “gotchas”.

Hope this helps anyone out there.
Ilantz

Hi,

I’ve just encountered this issue during a LAB for migrating Exchange 2010 to Exchange 2013, migration batches were getting stuck in Syncing, in addition I noticed two annoying warning messages in the application log of the server with Event ID 1009 and Event ID 1013 with source MSExchangeFastSearch

I’ve looked in the migration report using:
Get-MigrationUserStatistics -IncludeReport -Identity ilantz@lab.com | fl
......
4/28/2013 7:44:46 AM [EX2013] The job is currently stalled due to 'Content Indexing' lagging behind on resource 'CiAgeOfLastNotification(Mailbox Database
.....

So, indeed the Content Indexing which was failing and keeping the migration back… nothing special here, Exchange 2010 had this issue as well …
Quick search showed a very odd solution to this…

Quoting http://support.microsoft.com/kb/2807668 – Content Index status of all or most of the mailbox databases in the environment shows “Failed”

This issue may occur if the search platform tries to check its membership in a security group that is named “ContentSubmitters.” This group is not created by the search platform or by Exchange Server 2013 and is therefore not usually present. Although the check usually fails silently, without any consequences, an exception sometimes occurs. This causes the search component to fail.

Wow … well 🙂 .. hope this will be fixed with CU2.. go with Method 1 in the KB, worked like a charm here.

ilantz