Eileen O'Rourke https://docs.microsoft.com/archive/blogs/eileenor/feed.xml Wed, 17 Apr 2019 04:01:00 GMT en-US hourly 1 Microsoft Exchange Search Indexer fails to create a catalog for databases in Exchange 2010 with the error message Unable to SetProperty FTE_PluginList on catalog https://docs.microsoft.com/archive/blogs/eileenor/microsoft-exchange-search-indexer-fails-to-create-a-catalog-for-databases-in-exchange-2010-with-the-error-message-unable-to-setproperty-fte_pluginlist-on-catalog Thu, 09 Feb 2012 14:06:48 GMT https://blogs.technet.microsoft.com/eileenor/2012/02/09/microsoft-exchange-search-indexer-fails-to-create-a-catalog-for-databases-in-exchange-2010-with-the-error-message-unable-to-setproperty-fte_pluginlist-on-catalog/ I had a very interesting case a while back where the Microsoft Exchange Search Indexer fails to create a catalog for databases in Exchange 2010. Everything appeared to run fine, but when I checked the CatalogData folder, only 6 files were present that were either zero or a couple bytes in size.

I then looked in the Application Event Viewer log and found the following error:

Event ID 104 for Search Indexer

I did some research on Unable to SetProperty FTE_PluginList on catalog. My findings indicated that one of the following could cause this error:

·         Insufficient or missing permissions on the CatalogData folder

·         Databases are on mount points with insufficient disk space

I verified that the default permissions on the CatalogData folder corresponded to the following table:

default permissions on CatalogData folder

I verified that I had plenty of available disk space for the mount points. I was baffled!

I decided to eliminate the mount points completely by moving one of the databases to a local drive. Imagine my surprise when I got the same exact event!

Now I was intrigued and a little annoyed. After doing some debugging, I discovered that this error occurs when Exchange makes a call to MSSearch's COM+ interface to set properties on our catalog; however, MSSearch returns the error -2146762482. This error code resolves to CERT_E_REVOCATION_FAILURE, which means the certificate revocation check process could not continue, in other words the certificate(s) could not be checked. Interesting, very interesting.

I verified that the following registry key on the server was valid:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing

My next step was to look at the configuration on the reverse proxy server. When I checked to see if authentication of commercial certificates was enabled, I discovered that it was not. Once I modified the reverse proxy server to consider all certificates as good and inhibiting revocation status on the certificates that MSSearch uses, the indexing completed on the databases. Now my users were able to experience the robust experience of search.

]]> Outlook synchronization error [80004005-501-4B9-560] with a Microsoft Exchange Server 2010 mailbox https://docs.microsoft.com/archive/blogs/eileenor/outlook-synchronization-error-80004005-501-4b9-560-with-a-microsoft-exchange-server-2010-mailbox Wed, 04 May 2011 07:57:49 GMT https://blogs.technet.microsoft.com/eileenor/2011/05/04/outlook-synchronization-error-80004005-501-4b9-560-with-a-microsoft-exchange-server-2010-mailbox/

I’ve seen a couple of cases where Outlook users get the following error in the \Sync Issues folder:

17:27:28 Synchronizer Version 14.0.4760
17:27:28 Synchronizing Mailbox 'user name'
17:27:28 Synchronizing Hierarchy
17:27:44 Synchronizing Forms
17:27:44 Downloading from server 'server.corp.com'
17:27:45 Error synchronizing folder
17:27:45 [80004005-501-4B9-560]
17:27:45 The client operation failed.
17:27:45 Microsoft Exchange Information Store
17:27:45 For more information on this failure, click the URL below:
17:27:45 https://www.microsoft.com/support/prodredirect/outlook2000_us.asp?err=80004005-501-4b9-560
17:27:45 Done

The following is from a soon to be publicly published article. Many thanks to Charlotte Raymundo and Greg Mansius for writing and editing this article!

Outlook synchronization error [80004005-501-4B9-560] with a Microsoft Exchange Server 2010 mailbox

Symptoms

If you view the \Sync Issues folder in Microsoft Outlook, you find a synchronization log with an entry similar to the following:

17:27:28 Synchronizer Version 14.0.4760
17:27:28 Synchronizing Mailbox 'user name'
17:27:28 Synchronizing Hierarchy
17:27:44 Synchronizing Forms
17:27:44 Downloading from server 'server.corp.com'
17:27:45 Error synchronizing folder
17:27:45 [80004005-501-4B9-560]
17:27:45 The client operation failed.
17:27:45 Microsoft Exchange Information Store
17:27:45 For more information on this failure, click the URL below:
17:27:45 https://www.microsoft.com/support/prodredirect/outlook2000_us.asp?err=80004005-501-4b9-560
17:27:45 Done

Cause

The 4B9 portion of the error code translates to ecNullObject from Store, indicating that the failure occurred because an object that was referenced was null.  This could be due to number of resons including, but not limited to, a permissions issue or because the Outlook client is not able to access the public folder replica.

Resolution

Possible Resolutions:

Resolution 1:  Problems with the Replica

If there are multiple Exchange servers in the environment there could be a possible replication issue with the EFORMS REGISTRY system folder, removing the replica and adding it back has resolved the issue in some cases.

Use the following commands to remove and re-add the replica:

  1. To check which Public Folder Database the Exchange Mailbox is using, run the following cmdlet in Exchange Management Shell:

    get-MailboxDatabase |fl Name, PublicFolderDatabase

    Example:
    Name                        :  MailboxDatabase1
    Public Folder Database:  Public Folder Database 1

    Name                        :  MailboxDatabase2
    Public Folder Database:  Public Folder Database 2 <-- Users on this mailbox database are getting the sync errors

    Name                        :  MailboxDatabase3
    Public Folder Database:  Public Folder Database 1

  2. To get a list of the replicas for the EFORMS REGISTRY run the following cmdlet:

    get-publicfolder -Identity "\NON_IPM_SUBTREE\EFORMS REGISTRY" -Recurse | fl Name,Replicas

    Example:
    Name      : EX:/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)
    Replicas : {Public Folder Database 1}

    Name      : EX:/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)
    Replicas : {Public Folder Database 2}

     

  3. Remove the replica from the database you found in step #1.  This is most easily accomplished using the Public Folder Managment Console from Exchange Management Console (EMC):

    1. In the console tree, click Toolbox.

    2. In the result pane, double-click Public Folder Management Console.

    3. In the console tree of the Public Folder Management Console, expand System Public Folders, and then expand the EFORMS REGISTRY public folder and click on Organizational Forms Library.
    4. In the result pane, click the public folder you want, and then, in the action pane, click Properties.

    5. Use the Replication tab to view the and set the content replication schedule and to specify the databases on which the public folder content will be replicated.

      • Under Replicate content to these public folder databases select a database from the list

      • Click the X to remove it from the replication list.

  4. Re-Add the replica from the database you found in step #1 using the same Public Folder Management Console:

    1. In the console tree, click Toolbox.

    2. In the result pane, double-click Public Folder Management Console.

    3. In the console tree of the Public Folder Management Console, expand System Public Folders, and then expand the EFORMS REGISTRY public folder and click on Organizational Forms Library.

    4. In the result pane, click the public folder you want, and then, in the action pane, click Properties.

    5. Use the Replication tab to view the and set the content replication schedule and to specify the databases on which the public folder content will be replicated.

      • Under Replicate content to these public folder databases click the Add button to open the Select Public Folder Database dialog box.  Use this dialog box to specify which public folder databases this public folder should be replicated to. 

      • Select the public folder database, and then click OK
         

Resolution 2:  Problems with the Permissions

The error can be caused by incorrect permissions on the EFORMS REGISTRY for the Default user.

  1. To check permissions on the EFORMS REGISTRY, run the following cmdlet in the Exchange Management Shell:

    Get-PublicFolderClientPermission “\NON_IPM_SUBTREE\EFORMS REGISTRY” | fl user, accessrights

Example:
User           : Default
AccessRights: {Reviewer}

User           : Anonymous
AccessRights: {None}

  1. In the output, examine the permissions given to the Default user.  They should not be set to None.  The following is a list of accepted permissions for the Default user: 

    - Owner
    - PublishingEditor
    - Editor
    - PublishingAuthor
    - Author
    - NonEditingAuthor
    - Reviewer
    - Contributor
  2. If the Default user has it's permissions set to None, run the following command to set the permissions to Reviewer. 

    Add-PublicFolderClientPermission “\NON_IPM_SUBTREE\EFORMS REGISTRY” -User Default -AccessRights Reviewer

More Information

For more information about the Set-PublicFolder command, visit the following Microsoft Web site:
https://technet.microsoft.com/en-us/library/aa998596.aspx

For more information about the Add-PublicFolderClientPermission command, visit the following Microsoft Web site:
https://technet.microsoft.com/en-us/library/bb124743.aspx

Configure Public Folder Properties
https://technet.microsoft.com/en-us/library/bb691327.aspx

 

]]> Follow Up Question on Named Props https://docs.microsoft.com/archive/blogs/eileenor/follow-up-question-on-named-props Tue, 19 Apr 2011 07:54:29 GMT https://blogs.technet.microsoft.com/eileenor/2011/04/19/follow-up-question-on-named-props/ The other day I had a customer ask if it was possible to determine what the break down was in the NamedProps table for a mailbox store.

As you may recall from my posting on the Exchange Team blog (https://blogs.technet.com/b/exchange/archive/2010/07/29/3410545.aspx), the maximum number of named properties that can ever be created is 32,767 per database. NamedProps consist of Authenticated Users & Non-Authenticated Users. It doesn't matter if the user is authenticated or not - they all go into the same NamedProps table. So you could have 32k created all by authenticated users, or 32k all created by unauthenticated users, or 10k created by unauthenticated and 22k by authenticated, or whatever... it doesn't matter who created them, the bottom line is that the maximum is 32k rows in that table.

So the question was:

Is there a way to determine how many of the NamedProps are Authenticated Users and how many are Non-Authenticated Users?

The unfortunate answer is no. There is no way to determine how many of the NamedProps are Authenticated Users and how many are Non-Authenticated Users.

The only way that it could possibly be done is if it was captured at the time it is written to the table and there is not tool available to do this. Will there be one in the future? I haven’t heard of any plans for one, but you never know.

 

]]> MSExchange RBAC Error 17 https://docs.microsoft.com/archive/blogs/eileenor/msexchange-rbac-error-17 Tue, 19 Apr 2011 07:35:00 GMT https://blogs.technet.microsoft.com/eileenor/2011/04/19/msexchange-rbac-error-17/ A case I worked on a while back involved an issue where the application log on the Exchange 2010 servers was full of MSExchange RBAC event id 17. This was recorded on all servers, regardless of role.

There are two types of events: one for user accounts and one for machine accounts. The first example below is for the user eileenor and the second is for the machine name ExchangeMailboxA

ID:            17
Level:        Error
Source:     MSExchange RBAC
Message:  (Process w3wp.exe, PID 1234) "RBAC authorization returns Access Denied for contoso.com/Users/ActionAccount. Reason: No role assignments associated with the specified user were found on Domain Controller DC1.contoso.com"

ID:            17
Level:        Error
Source:     MSExchange RBAC
Message:  (Process w3wp.exe, PID 1234) "RBAC authorization returns Access Denied for contoso.com/Servers/Exchange/ExchangeMailboxA. Reason: No role assignments associated with the specified user were found on Domain Controller DC1.contoso.com"

The first one is easy to track down. You just have to figure out what account was trying to do in the Exchange Management Shell and then verify if they have the correct RBAC permissions. More than likely, the account is related to another program that is running an Exchange Management cmdlet or script.

The second one is a little bit trickier to figure out.

Whenever you see the Exchange Server 2010’s machine name in the event. this means that there is some other program or task that is involved. It could be a Scheduled Task running an Exchange 2010 cmdlet or another program, such as monitoring software.

If you are running an Exchange Management cmdlet or script as a scheduled task, make sure they account has valid RBAC permissions to run it. For example, I run CheckDatabaseRedundancy.ps1 as a Scheduled Task on my Mailbox Servers. As you can see in the example below, I run it using the Local System account:

Scheduled Task

 

If you are running another program, such as monitoring software, check the documentation and make any configuration changes needed.

]]> Just what is it with Named Properties quotas? https://docs.microsoft.com/archive/blogs/eileenor/just-what-is-it-with-named-properties-quotas Thu, 24 Mar 2011 11:03:01 GMT https://blogs.technet.microsoft.com/eileenor/2011/03/24/just-what-is-it-with-named-properties-quotas/ Back in July 2010, I posted a blog on Named Props quotas here

(https://msexchangeteam.com/archive/2010/07/29/455687.aspx).

If you've ever dealt with Named Properties, I urge you to check it out.

]]> How to grant a user account mailbox access https://docs.microsoft.com/archive/blogs/eileenor/how-to-grant-a-user-account-mailbox-access Thu, 24 Mar 2011 11:01:09 GMT https://blogs.technet.microsoft.com/eileenor/2011/03/24/how-to-grant-a-user-account-mailbox-access/ A common question I hear is how do I grant a user account full mailbox access to all mailboxes in Microsoft Exchange 2007? This seems like an easy answer, but it is a little tricky.

The easy answer is for existing users. If I want to grant the Trusted User account Full Access to all mailboxes on a specific server, I can use this cmdlet which sets it at the mailbox level:

     Get-Mailbox | Add-MailboxPermission –User “Trusted User” -AccessRights FullAccess

But, that is only for existing users. What about future users? Do I have to re-run this cmdlet every time I add a user? No, you can use this cmdlet which sets it as the database level:

     Get-MailboxDatabase | Add-ADPermission -User "Trusted User" -ExtendedRights ReceiveAs

Did you catch that? The first cmdlet is Mailbox-level and the second on is Mailbox Database-level.

]]> Welcome to Eileen's World https://docs.microsoft.com/archive/blogs/eileenor/welcome-to-eileens-world Tue, 12 Jan 2010 10:37:00 GMT https://blogs.technet.microsoft.com/eileenor/2010/01/12/welcome-to-eileens-world/ My name is Eileen O'Rourke and welcome to my world.

 

The purpose of this blog is to share information and thoughts about Exchange, Exchange Management Pack and possibly anything else that catches my fancy.

 

I have been with Microsoft since April 1991. In that time, I have supported:

 

·         Windows 286/386

·         Windows 3.0

·         Excel

·         Office Setup and Deployment

·         Windows XP

·         Exchange

·         Exchange Management Pack

 

So if you need to troubleshoot a printer driver issue in Windows 286, I can help you with that. Or if you can’t print from Excel (hint: make sure you have a valid TEMP folder).

I hope you will find this blog helpful or at least amusing. 

]]>