Thursday, June 18, 2009

SharePoint 2007 SP2 Resources

I might be involve in a SP2 deployment. Guess I better get myself ready for it. Following are stuff that I need to crunch through first:


Announcement of MOSS 2007 SP2 and WSSv3 SP2


Immediate Issue after deploying SP2

Step to re-enter license key -


April Cumulative Update (CU) (with timeline diagram of update schedule)


Updates Resource Center @ SharePoint Server TechCenter


Deploy software updates for Office SharePoint Server 2007


How the upgrade process works

These article explains In-place and Gradual upgrade approches

WSSv3 -
MOSS 2007 -

Running VPCs with different date/time

I have plenty of VPC images that were built on trial version for testing and demo purpose. So when these images lives longer than it’s trial period, you’ll need to trick it by changing the host machine’s time. That’s no good since it’ll affect your applications on the host machine.


There’s a quick method to either disable the time synchronization between the VPC and the host machine, or  hardcode a specific date/time for the VPC. Both can be done via modification on the vmc file.

1. Disable the time synchronization:


Under the following mouse configuration:
<allow type="boolean">true</allow>

Add this:
<enabled type="boolean">false</enabled>

2. Set the desired date/time:

You have to find the time_bytes value inside the .vmc file, which looks like this one:

<time_bytes type="bytes">27003200110001201008</time_bytes>

After finding it, set the desired date/time value according to the following specification:
Digits 1 - 2 contain the seconds value.
Digits 5 - 6 contain the minutes value.
Digits 9 - 10 contain the hours value.
Digits 15 - 16 contain the day value.
Digits 17 - 18 contain the month value.
Digits 19 - 20 contain the year value.

In the above example, the date/time value is 11:32:27, 20/10/2008

After making the above 2 changes, save the .vmc file, and the guest operating system will start in the same date/time that you set in the time_bytes value.



Unable to browse sharepoint from within the server itself

If you ever have problem browsing your SharePoint portal from within the WFEs itself, and running on Windows Server 2003 SP1 or above, it could be due to a loopback check security. I noticed that this does not happen to site that does not use host header (e.g. does not happen to http://servername:port, but happen to

Take a look at By modifying some registry, you can either exclude your specific URL from this security check, or disable the feature. The following is a direct copy from the KB article for reference.

Method 1: Specify host names

Note We recommend that you use this method. To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:


3. Right-click MSV1_0, point to New, and then click Multi-String Value.

4. Type BackConnectionHostNames, and then press ENTER.

5. Right-click BackConnectionHostNames, and then click Modify.

6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.

7. Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check

Follow these steps:

  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:


3. Right-click Lsa, point to New, and then click DWORD Value.

4. Type DisableLoopbackCheck, and then press ENTER.

5. Right-click DisableLoopbackCheck, and then click Modify.

6. In the Value data box, type 1, and then click OK.

7. Quit Registry Editor, and then restart your computer.

Resources on Configuring SharePoint Form Authentication

Here’s some of the best resource for setting up form based authentication.


From the SharePoint Team Blog (Configuring Multiple Authentication Providers for SharePoint 2007):


From the TechNet (Configure forms-based authentication for WSSv3):


From Andrew Connell’s blog (very detailed step by step):

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)