Alert: Exchange Health Set

Alert: Exchange Health Set

Alert: Exchange Health Set

Source: pcrs0119 – ActiveSync.Protocol


Last modified by: System

Last modified time: 1/17/2017 8:28:50 AM Alert description: ActiveSync is failing on Mailbox server server name.

Incident start time: 1/17/2017 5:28:35 AM


Last failed result:

Failing Component – EAS

Failure Reason – Unknown Reason: QuotaExceeded


Exception: System.Net.WebException: Error occurred:


Invoke-MonitoringProbe -Identity:”ActiveSync.Protocol\ActiveSyncDeepTestProbe” -Server:servername | fl

  1. Open the Exchange Management Shell, and run the following command to retrieve the details of the health set that issued the alert:
  2. Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}

    For example, to retrieve the ActiveSync health set details about, run the following command:

    Get-ServerHealth | ?{$_.HealthSetName -eq "ActiveSync"}

  3. Review the command output to determine which monitor reported the error. The AlertValue value for the monitor that issued the alert will be Unhealthy.
  4. Rerun the associated probe for the monitor that’s in an unhealthy state. Refer to the table in the Explanation section to find the associated probe. To do this, run the following command:
  5. Invoke-MonitoringProbe <health set name>\<probe name> -Server <server name> | Format-List

    For example, assume that the failing monitor is ActiveSyncCTPMonitor. The probe associated with that monitor is ActiveSyncCTPProbe. To run this probe on, run the following command:

    Invoke-MonitoringProbe ActiveSync\ActiveSyncCTPProbe -Server | Format-List

  6. In the command output, review the “Result” section of the probe. If the value is succeeded, the issue was a transient error, and it no longer exists. Otherwise, refer to the recovery steps outlined in the following sections.


Troubleshooting ActiveSync Health Set

The command didn’t work and you have the failure message then

ActiveSyncDeepTestMonitor and ActiveSyncSelfTestMonitor Recovery Actions

This monitor alert is typically issued on Mailbox servers. To perform recovery actions, follow these steps:

  1. Start IIS Manager, and then connect to the server that is reporting the issue. Click Application Pools, and then recycle the ActiveSync application pool that’s named MSExchangeSyncAppPool.
  2. Rerun the associated probe as shown in step 2c in the Verifying the issue section.
  3. If the issue still exists, recycle the entire IIS service by using the IISReset utility.
  4. Rerun the associated probe as shown in step 2c in the Verifying the issue section.



EventID: 8319

EventID: 8319

This is the error and this is the EVENT NAME

Table SqlIoData_Partition27 has 443957248 bytes that have exceeded the max bytes 442857142

Continue reading

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstanceEvent ID 6482

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance

Event ID 6482

When I view the event logs on the Web Server I see several errors with the Event ID 6482:

Locate the following GUID


 Managed to fix this error by following these steps:

  1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
  2. Navigate to the cache folder In Windows Server 2008, the configuration cache is in the following location: Drive:\ProgramData\Microsoft\SharePoint\Config
    1. C:\ProgramData\Microsoft\SharePoint\Config
    2. In my case it will be
    3. C:\ProgramData\Microsoft\SharePoint\Config\925cd5c7-994f-438a-a5da-a8c179e0e85e\ba0cdef8-dc42-4b2c-8d91-ce1586e1d8e4.xml

      So I will delete all XML under the (C:\ProgramData\Microsoft\SharePoint\Config\925cd5c7-994f-438a-a5da-a8c179e0e85e )folder

      Note: never delete the .ini File

  3. Locate the GUID folder that has the file “Cache.ini” (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)

  1. Back up the Cache.ini file (and the other xml files)
  2. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt. Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  3. Double-click the Cache.ini file
  4. On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
  5. Start the Windows SharePoint Services Timer service

Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.

Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.