Advertisements
Feeds:
Posts
Comments

Archive for January, 2017


Alert: Exchange Health Set

Alert: Exchange Health Set

Source: pcrs0119 – ActiveSync.Protocol

Path: pcrs0119.PGESCo.com;pcrs0119.PGESCo.com

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 server1.contoso.com, run the following command:

    Get-ServerHealth server1.contoso.com | ?{$_.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 server1.contoso.com, run the following command:

    Invoke-MonitoringProbe ActiveSync\ActiveSyncCTPProbe -Server server1.contoso.com | 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.

Table: https://technet.microsoft.com/en-us/library/ms.exch.scom.activesync(v=exchg.150).aspx#EXP

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.

Ref: https://technet.microsoft.com/en-us/library/ms.exch.scom.activesync(v=exchg.150).aspx

Advertisements

Read Full Post »

EventID: 8319


 

EventID: 8319

This is the error and this is the EVENT NAME

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

Which is the SQL IO Usage event

To know the database name

Go to central admin

First, we must get the database name

 

The database name is

WSS_Logging

 

 Now we need to find which table is taking most of the space inside the WSS logging Database.

You can check from the SQL Server

Login to SQL Server Management Studio -> Select your logging Database (Right Click) -> Reports- > Standard Reports -> Disk Usage by Top Tables

The SQL IO Usage event

We can reduce the retention period of any events (default is 14)

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

 

In my case its SQL IO

Any way if we couldn’t know exactly which identity is causing the problem we can just

Set them all to any number of days

Then log in the SharePoint power shell

Get-SPUsageDefinition

Set-SPUsageDefinition –Identity “Page Requests” -DaysRetained 3

Now I just changed the page Request to 3 days

Alternatively, you can set all the Identities once

By the following command

Get-SPUsageDefinition | Set-SPUsageDefinition -DaysRetained 3

After you are done

Run the two-timer jobs to clean the old data ‘Microsoft SharePoint Foundation Usage Data Import’ and ‘Microsoft SharePoint Foundation Usage Data Processing’.

Go to SharePoint Central Administration -> Monitoring -> Configure Usage and health data collection-> Log Collection Schedule.

Moreover, it will take you to the timer jobs.

 

Read Full Post »

EventID: 8319


 

EventID: 8319

This is the error and this is the EVENT NAME

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

Which is the SQL IO Usage event

To know the database name

Go to central admin

First, we must get the database name

 

The database name is

WSS_Logging

 

 Now we need to find which table is taking most of the space inside the WSS logging Database.

You can check from the SQL Server

Login to SQL Server Management Studio -> Select your logging Database (Right Click) -> Reports- > Standard Reports -> Disk Usage by Top Tables

The SQL IO Usage event

We can reduce the retention period of any events (default is 14)

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

 

In my case its SQL IO

Any way if we couldn’t know exactly which identity is causing the problem we can just

Set them all to any number of days

Then log in the SharePoint power shell

Get-SPUsageDefinition

Set-SPUsageDefinition –Identity “Page Requests” -DaysRetained 3

Now I just changed the page Request to 3 days

Alternatively, you can set all the Identities once

By the following command

Get-SPUsageDefinition | Set-SPUsageDefinition -DaysRetained 3

After you are done

Run the two timer jobs to clean the old data ‘Microsoft SharePoint Foundation Usage Data Import’ and ‘Microsoft SharePoint Foundation Usage Data Processing’.

Go to Sharepoint Central Administration -> Monitoring -> Configure Usage and health data collection-> Log Collection Schedule.

And it will take you to the timer jobs.

 

Read Full Post »


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


ba0cdef8-dc42-4b2c-8d91-ce1586e1d8e4

 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.

Ref:

http://sharepoint.stackexchange.com/questions/125263/application-server-administration-job-failed-for-service-instance-microsoft-offi

Read Full Post »

%d bloggers like this: