Friday, February 13, 2009

Cause of Audience Targeting Error Log

The following error was logged on the MOSS WFE servers intermittently without any pattern in the sense of frequency. It happens once in a blue moon.

Event Type: Error Event Source: Office SharePoint Server Event Category: Office Server General Event ID: 7888 Date: 2/11/2009 Time: 5:56:21 PM User: N/A Computer: MOSSPROD01 Description: A runtime exception was detected. Details follow. Message: Thread was being aborted. Techinal Details: System.Threading.ThreadAbortException: Thread was being aborted. at Microsoft.Office.Server.WebControls.AudienceLoader.UpdateAudienceRunTimeCheckHashs(Boolean loadAudiences, Boolean loadMemberships, Boolean loadSharePointGroups) at Microsoft.Office.Server.WebControls.AudienceLoader.EnsureCurrentUserAudienceIDs(Boolean loadAudiences, Boolean loadMemberships, Boolean loadSharePointGroups) at Microsoft.Office.Server.Audience.AudienceManager.IsCurrentUserInAudienceOf(AudienceLoader audienceLoader, String audienceTextRepresentation, Boolean showUntargetedAudience)

There were other logs with similar detail, all has something to do with Audience methods throwing errors. A check on the SharePoint log files provided a little bit of clue, but nothing that lights the bulb. Here's the snippet of the error logged under the category of User Profiles in MOSS log:

GetUserAudienceIDs::GetUserAudienceIDs() failed in SharePoint Group membership resolution (Exception Message : Accessor is invalid. StackTrace at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex) at Microsoft.SharePoint.SPGlobal.HandleUnauthorizedAccessException(UnauthorizedAccessException ex) at Microsoft.SharePoint.Library.SPRequest.GetGroupsDataAsSafeArray(String bstrUrl, UInt32 dwGroupsScope, String bstrValue, UInt32 dwValue, UInt32& pdwColCount, UInt32& pdwRowCount, Object& pvarDataSet) at Microsoft.SharePoint.SPGroupCollection.InitGroups(Boolean fCustomUsers, String[] strNames, Int32[] groupIds) at Microsoft.SharePoint.SPGroupCollection.InitGroups() at Microsoft.SharePoint.SPGroupCollection.Undirty() at Microsoft.SharePoint.SPBaseCollection.System.Collections.IEnumerable.GetEnumerator() at Microsoft.Office.Server.Audience.AudienceManager.GetUserAudienceIDs(String accountName, SPWeb web, Boolean loadAudiences, Boolean loadSharePointGroups, Boolean loadMemberships). No SharePoint Group IDs will be returned.

Then I moved on to the IIS log files, and found that at the time of the error, a user is accessing the homepage. Immediately after that homepage request, several lines of log shows the user was being redirected to the /layouts/AccessDenied.aspx page. This pattern can be seen in several other occasions as well in other copy of the IIS log files.

2008-12-17 07:36:24 W3SVC45547621 GET /default.aspx - 443 PROD-AD01\uTester01 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727) 302 0 0 2008-12-17 07:36:27 W3SVC45547621 GET /_layouts/AccessDenied.aspx Source=https%3A%2F%2Fportal%2Eportal%2Ecom%2Fdefault%2Easpx 443 PROD-AD01\uTester01 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727) 200 0 0

After further investigation and testing, I found that the homepage is the only page that the portal has audience targeting configured. Several testing and monitoring was conducted and the conclusion is that this error will always be thrown whenever an unauthorized user attempts to load a MOSS page that has audience targeting configured. Since the error was thrown when the method IsCurrentUserInAudienceOf is invoked, this indicates that somehow MOSS will still perform audience checking even though the user doesn't have the privilege to access the portal.

I have not found any workaround to remove the error. If you found any without suppressing the logs from central admin do let me know :).

Friday, February 6, 2009

Performance Counters to trace for troubleshooting performance issue

I've been involve in some performance testing for a typical MOSS implementation lately. Although I have done these test many times on different projects, but I find that each performance test is unique, depending on the test objective, environment, the test subject (portal pages and components). Still, one thing that remain quite consistent is the performance counter to monitor. The following performance counter were used for the most recent performance test. I've included additional ASP.NET Application cache counters, as I want to verify whether the MOSS cache profile is working properly.

Counter Object







Processor (_Total)

% Processor Time





Not more than 70%


Available Bytes






Physical Disk

% Disk Time

Avg. Disk Queue Length




Bytes Sent/Sec

Bytes Received/Sec

Bytes Total/Sec





Bytes Total/Sec for 1000mbps NIC should not go over 70MB/s

Bytes Total/Sec for 100mbps NIC should not go over 7MB/s

ASP.NET Applications

Request Total


Request Execution Time

Requests Succeeded

Request Rejected

Requests Timed Out

Requests Not Found

Requests Not Authorized

Output Cache Hits

Output Cache Misses


Refer to for description of ASP.NET performance counters.

I will include the SQL server performance counters later, as I do not have the information now (it was determined by my SQL-expert colleague)