Exchange 2013 CU9 AD versions

MS has released Exchange 2013 CU9. Prepare Active Directory and domains is not required when upgrading from CU7 or CU8.

AD Versions table:

AD Versions in my lab env after installing Exchange 2013 CU9 with /PrepareSchema & /PrepareAD (ADSI Edit):

Schema naming context:

• CN=Schema,CN=Configuration,DC=demo,DC=lan
• Properties CN=ms-Exch-Schema-Version-Pt
• rangeUpper: 15312

Default naming context:

• DC=demo,DC=lan
• Properties CN=Microsoft Exchange System Objects
• objectVersion: 13236

Configuration naming context:

• CN=Configuration,DC=demo,DC=lan
• CN=Services
• CN=Microsoft Exchange
• CN=MailOrg
• Properties CN=MailOrg
• objectVersion: 15965

 

 

Test-OutlookConnectivity fails: Failed to find the probe result for invoke now request

In my Exchange 2013 lab environment (Exchange 2013 CU7 Multi-Role) cmdlet Test-OutlookConnectivity fails:

Test-OutlookConnectivity –ProbeIdentity 'OutlookRpcSelfTestProbe'
WARNING: An unexpected error has occurred and a Watson dump is being generated: Failed to find the probe result for invoke now request id 743eb01ee4f2436fa909a8206c029773 and probe workdefinition id 317. Failed to find the probe result for invoke now request id 743eb01ee4f2436fa909a8206c029773 and probe workdefinition id 317.

Time zone setting on server: (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

After changing server time zone (& server reboot) to: (UTC -08:00) Pacific Time (US & Canada) cmdlet Test-OutlookConnectivity –ProbeIdentity 'OutlookRpcSelfTestProbe' runs successful:

The same warning may appear when running Invoke-Monitoring cmdlet and is also related to this time zone issue. For example: Invoke-MonitoringProbe -Identity OWA\OwaCtpProbe –Server server-name

This issue has been reported to MS. Don’t know when it will be fixed.

Configure Send As permissions when member of Recipient Management

Administrators who are members of the Recipient Management role group have administrative access to create or modify Exchange 2013 recipients within the Exchange 2013 organization.

However, by default, members of Recipient Management are not able to configure Send As permissions on mailbox level.

Solution: New-ManagementRoleAssignment -Role 'Active Directory Permissions' -SecurityGroup 'Recipient Management'

Exchange 2013 Update-MailboxDatabaseCopy with parameter -CatalogOnly fails

You want to only seed the content index catalog for a database copy. Steps according to Update-MailboxDatabaseCopy:

1.    Suspend-MailboxDatabaseCopy database\server

2.    Update-MailboxDatabaseCopy database\server –CatalogOnly

Error after executing Update-MailboxDatabaseCopy database\server –CatalogOnly:

WARNING: Seeding of content index catalog for database 'DB001' failed. Please verify that the Microsoft Search (Exchange) and the Host Controller service for Exchange services are running and try the operation again. Error: There was no endpoint listening at net.tcp://localhost:3863/Management/SeedingAgent-F5A3EDE0-93F6-4126-927B-5026D8E6661D12/Single that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details..

Solution: do not suspend the database when only seeding the content index catalog

Suspend-MailboxDatabaseCopy database\server is only required when seeding a database copy.

Outlook 2010 shows the same display name for different archives

There is an archive name issue with Outlook 2010 where the delegate archive shows the name of the primary mailbox owner:

Solution:

Exchange 2010 SP3 UR2 + Outlook 2010 SP1 or SP2 with Outlook 2010 hotfix package august 2013 (http://support.microsoft.com/kb/2817574/en-us) is required to solve the archive name issue:

1.       Install Outlook 2010 hotfix package

2.       Start Outlook 2010

3.       Outlook 2010 Autodiscover updates Outlook configuration but Outlook still shows the same display name for different archives

4.       Restart Outlook 2010 client

5.       Outlook 2010 shows correct archive names:

Note: this is also an issue with Outlook 2010 and Exchange 2013 CU2 with the same solution. I have not yet been able to test this with Outlook 2013 and Exchange 2013.

Martijn

 

Exchange 2013 CU2 Error: Windows Failover Clustering isn't installed

I installed two Mailbox Servers and created a DAG. No problems adding first server to DAG.

 

However, got an error while adding second server to DAG:

 

A server-side database availability group administrative operation failed. Error The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error: Windows Failover Clustering isn't installed on 'ex2013-server'

I got this error from both EAC and EMS. Actually, Windows Failover Clustering should be automatically installed when adding a DAG member.

Solution:

1. Windows PowerShell: install-windowsfeature failover-clustering
2. Add second DAG member again

Microsoft Exchange Health Manager service does not start automatically

I installed two new Exchange 2013 servers (1x CAS & 1x MBX) with latest CU2 (build 15.0.712.24).

Issue: Microsoft Exchange Health Manager service does not start automatically after reboot.

Event Viewer System log:

Event ID:      7000
Level:         Error
Description:
The Microsoft Exchange Health Manager service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.

Event ID:      7009
Level:         Error
Description:
A timeout was reached (30000 milliseconds) while waiting for the Microsoft Exchange Health Manager service to connect.

No problem manually starting Microsoft Exchange Health Manager service. When you set the service to ‘Automatic (Delayed Start)’ it starts fine after each reboot.

I've posted comments at http://blogs.technet.com/b/exchange/archive/2013/07/29/now-available-updated-release-of-exchange-2013-rtm-cu2.aspx

http://howexchangeworks.com/2013/08/exchange-health-manager-service-wont-start-automatically-after-installing-2013-cu2-v2.html#comment-3391 describes that recreating Health mailboxes may solve this problem. Recreating the Health mailboxes doesn’t fix the problem. Service has not been started after reboot. However, after some time (10-15 minutes) the service starts automatically.

So, this still seems to be an issue because the Exchange Health Manager service has not been started automatically after a reboot (only after 10-15 minutes).