Friday, August 14, 2015

Exchange 2013 built-in anti-malware: MS Filtering Engine Update process was unsuccessful in contacting the Primary Update Path

Issue: Exchange 2013 cannot download anti-malware updates

Event Viewer error:
MS Filtering Engine Update process was unsuccessful in contacting the Primary Update Path. Update Path:

·        Source: FIPFS
·        ID: 6027
·        User: Network Service

Exchange 2013 server:

·        The Exchange 2013 server has Internet access and can access path:
·        Exchange installed on D: drive
·        Exchange 2013 CU9 (Multi-Role) on Windows 2012 R2

“If the above will not resolve your issue check that "NT AUTHROITY\Network Service" has full access for the folder Program Files\Microsoft\Exchange\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin, in case you have installed Exchange in different drive, you need to add "NT AUTHROITY\Network Service" on the drive itself.”

My ‘solution’:

·        Browse with File Explorer to D:\Program Files\Microsoft\Exchange\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin
·        When accessing FIP-FS directory (and some other subdirectories) File Explorer displays a dialog box that prompts you with the following: You don’t currently have permission to access this folder. Click Continue to permanently get access to this folder.
·        After clicking Continue you are able to browse directory contents
·        NTFS security permissions on D:\Program Files\Microsoft\Exchange\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin show NETWORK SERVICE with appropriate permissions

After performing these steps anti-malware updates are being downloaded.
Event Viewer:

MS Filtering Engine Update process performed a successful scan engine update.
Scan Engine: Microsoft
Update Path:
·        Source: FIPFS
·        ID: 6033
·        User: Network Service


Wednesday, June 17, 2015

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

Tuesday, June 9, 2015

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.

Tuesday, May 26, 2015

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'

Thursday, May 21, 2015

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.

Monday, September 9, 2013

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:


Exchange 2010 SP3 UR2 + Outlook 2010 SP1 or SP2 with Outlook 2010 hotfix package august 2013 ( 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.



Monday, August 19, 2013

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.

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