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 172.25.67.84 GET /default.aspx - 443 PROD-AD01\uTester01 58.213.113.254 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 172.25.67.84 GET /_layouts/AccessDenied.aspx Source=https%3A%2F%2Fportal%2Eportal%2Ecom%2Fdefault%2Easpx 443 PROD-AD01\uTester01 58.213.113.254 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 :).

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	Counter	WFE	Index	SQL	Client	Remark
Processor (_Total)	% Processor Time	Y	Y	Y	Y	Not more than 70%
Memory	Available Bytes Pages/Sec	Y	Y	Y	Y
Physical Disk	% Disk Time Avg. Disk Queue Length	Y		Y
Network	Bytes Sent/Sec Bytes Received/Sec Bytes Total/Sec	Y	Y	Y	Y	http://technet.microsoft.com/en-us/library/aa996224.aspx 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 Requests/sec Request Execution Time Requests Succeeded Request Rejected Requests Timed Out Requests Not Found Requests Not Authorized Output Cache Hits Output Cache Misses	Y				Refer to http://msdn.microsoft.com/en-us/library/fxk122b4.aspx 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)