How to disable Managed Availability in Exchange 2013

I’ve finally started exploring the new Exchange 2013 lately (together with¬†Windows Server¬†2012) ūüôā Having done a fresh lab installation (running on vitual machine using Vmware ESXi 5.1, assigned Dual-Core i3 + 5GB RAM) I noticed that the complete response of Win 2012 Server¬†significantly slowed-down after Exchange installation was completed. I was aware that Exchange 2013 is hungry for RAM but I was not able to provide more memory at that moment. There were no apparent errors in Application/System log. All was running fine but server just seemed to be¬†out of breath.

You probably know that starting with Exchange 2013 Microsoft introduced new built-in monitoring feature “Managed Availability”.¬†Managed Availability will¬†undoubtedly be a welcomed improvement for production environment but if you want to run Exchange 2013 on a low-power server then this will probably consume some extra resources since as stated here “Every second on every Exchange 2013 server, Managed Availability polls and analyzes hundreds of health metrics”. You can see yourself with MessageTracking how many health test messages flow among monitoring mailboxes in Exchange 2013.

In addition to this, by default Exchange 2013 collects logs and performance data (<Exchange Install Drive>\Microsoft\Exchange Server\V15\Logging\Diagnostics\DailyPerformanceLogs) that are required by Microsoft in case you need to open a technical case. Those Perf data take up quite a lot of disk space as well.

Since I rather prefer having good response from my Exchange server I decided to disable those extra features.

Managed Availability is provided by Exchange Health Manager Service (MSExchangeHMHost.exe). Just stop and configure the Startup type to Manual/Disabled.

8-7-2013 13-43-02

I also disabled scheduled task that collects Performace Logs. Open location \Microsoft\Windows\PLA in Task Scheduler and disable taks ExchangeDiagnosticsDailyPerformanceLog & ExchangeDiagnosticsPerformanceLog.

8-7-2013 12-54-36

I can¬†confirm that after above actions my Exchange server¬†runs really nice and server’s response is excellent even on a low-power server.

Event ID: 10033 – A folder is being scoped by a search which no longer exists

Hi everyone!

Thanks to Filip’s & Zbynek’s invitation I also have the privilege to be part of this excellent FICILITY.net blog. So here we go. This is my first post ūüôā

If you happen to have an Application log on your Mailbox server full of eventIDs 10033, Source: “MSExchangeIS Mailbox Store” with the following information:

EventID: 10033

A folder is being scoped by a search which no longer exists. This may result in failures or errors when attempting to update the folder contents. If this message continues to persist for this mailbox, moving the mailbox to a different database may resolve the issue.

As instructed this issue can probably be resolved by moving the affected mailbox to a different mailbox database but I’ve found out that you can fix this issue by using cmdlet “New-MailboxRepairRequest” on affected mailbox.

New-MailboxRepairRequest -Mailbox [mailbox name] -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView

After that you’ll see that mailbox-repair request was created. Also check Application log on mailbox server where mailbox is homed for event with ID 10047:

Mailbox level online integrity check for request 7cef315f-60d7-4b8d-995f-32c22c68f4de started:Database=OPEXDAG1-MB1

Mailbox=DF49FD31-D429-423A-BECB-3594C19255FE

Flags=Detect, Fix

Tasks=SearchFolder, View, AggregateCount, ProvisionedFid

After a while you should see EventID 10062 that corruptions were detected & fixed:

Corruptions detected during online integrity check for request 7cef315f-60d7-4b8d-995f-32c22c68f4de

Mailbox:DF49FD31-D429-423A-BECB-3594C19255FE (MAILBOX NAME)

Database:OPEXDAG1-MB1

Corruption        Is Fixed        FID        Property        Resolution

“Folder Backlinks”, Yes, “1-38645 (Synkronointiongelmia1)”, 0x67870102, “Remove unfound folder(s) from the backlink list”

“Folder Backlinks”, Yes, “1-38649 (Ristiriidat)”, 0x67870102, “Remove unfound folder(s) from the backlink list”

“Folder Backlinks”, Yes, “1-3864D (Paikallisia virheit√§)”, 0x67870102, “Remove unfound folder(s) from the backlink list”

“Folder Backlinks”, Yes, “1-38651 (Palvelinvirheit√§)”, 0x67870102, “Remove unfound folder(s) from the backlink list”

“Folder Backlinks”, Yes, “1-12829678 (Digium)”, 0x67870102, “Remove unfound folder(s) from the backlink list”

….

 And when Repair-request is completed you will find EventID 10048:

 Online integrity check for request 7cef315f-60d7-4b8d-995f-32c22c68f4de completed successfully.

 After that original EventID 10033 disappeared