Bobby Habib SharePoint & MOSS Blogging Space

I think one of the most common tasks any new born MOSS environment gets as a christening, is a installation of a i-filter, to allow for adobe .pdf files to be indexed in there MOSS environments. So the likely hood of the adobe pdf ifilter is should be standard for most installation processes. On top of Adobe own pdf ifilter, FOXIT have also developed a ifilter that is truely multi-threaded providing faster crawl times on multi-processor servers, unlike adobe ifilter that is not multithreaded for the time being.

So a bout of Adobe PDF iFilter v FOXIT ifilter came head to head and the link below is worth a peep.

http://blogs.msdn.com/ifilter/archive/2007/11/14/foxit-vs-adobe-pdf-ifilter-32-bit-only.aspx

If you find that a lot of your content within MOSS are pdf's and find that your crawl times are quiet slow, then it could be worth evaluating the FOXIT ifilter http://www.foxitsoftware.com/pdf/ifilter/.

I have had a few people recently ask me questions on what is the "Max Degree of Parrallelism" on a SQL database and when this setting should be changed in a MOSS environment. So I have done a little bit of digging around to try and understand this myself. The following is what Microsoft MSDN interpretation of this setting;

"When SQL Server runs on a computer with more than one microprocessor or CPU, it detects the best degree of parallelism, that is, the number of processors employed to run a single statement, for each parallel plan execution. You can use the max degree of parallelism option to limit the number of processors to use in parallel plan execution. The default value of 0 uses all available processors. Set max degree of parallelism to 1 to suppress parallel plan generation. Set the value to a number greater than 1 (up to a maximum of 64) to restrict the maximum number of processors used by a single query execution. If a value greater than the number of available processors is specified, the actual number of available processors is used. If the computer has only one processor, the max degree of parallelism value is ignored."

The above information is taken from here http://msdn.microsoft.com/en-us/library/ms181007.aspx, so when should we change this? Max Degree Of Parrallelism should be changed from its default value of zero if your hardware is using lets say "HyperThreading, if this is the case then your setting should be set to the number of physical processors available on your SQL Server. If your server is using Cores Technology so for example if I had x4 physical processors with each processor running as a dual core, windows will see this as 8 processors, due to hyperthreading technology, but this should be set to 4 processors. You can also refer to http://support.microsoft.com/kb/322385 SQL Server support in a hyper-threaded environment.

If you are using NUMA hardware (System designers use non-uniform memory access (NUMA) to increase processor speed without increasing the load on the processor bus) then the Max Degree of Parrellelism should be set to the number of physical processors per NUMA. You can reference http://support.microsoft.com/kb/329204 NUMA Support.

The reason to turn off parallelism is typically to improve performance. Especially on 64bit machines there can be cxpacket waits in paralllel plans. However this is completely dependent on the queries and the plans, so it's difficult to make a generalization. If there are no perf bottlenecks I wouldn't change this setting before the perf difference is tested. To get the best setting I still think it's best to measure the waitstats and total number of parallel query plans.

One of the most simplest and effective ways to speed up your portal page loads is to leverage the Object Cache for MOSS, which comes as part of the product Out of the box. This settings can be modified in the SharePoint site : Site Actions > Modify All Site Settings > Object Cache Settings.

So what does this give you?

We all know that MOSS practically stores everything in its SQL database, so this could prove to be expensive from a networking perspective and can put heavy load on the SQL server, so this is where the object cache mechanism can take advantage on objects (Content) that are commonly requested. For example the Navigation control, most pages would have a navigation control embedded into a MOSS page, by storing these common objects to disk, will  reduce the number of server hops required to be hit on the SQL Server decreasing page load time.

Sounds like a great way to speed up MOSS page loads.But when we get out of the arena of Out of the Box controls and jump into the land of customization, then the Object Cache settings can make or break the page load times. Confused?OK we need to dig a little deeper to get my point across.OK, let me give you an example; one of the ways to create a custom navigation control or a site map of your site structure would be to iterate through your sites and build up a control dynamically using something like the PortalSiteMapProvider class that is provided to you in the Microsoft.SharePoint.Publishing assembly.

Sounds about right.

But what happens if you have something like 500+ subsites. I have seen companies having 5000 + subsites, but wait we would probably leveraging the Object Cache, as the PortalMapSiteProvider uses the CacheObject interfaces instead of the actual SPWeb objects.

But it still needs to build the cache the first time. If we look at the behavior of the PortalSiteMapProvider class, when we parse the map, a SPWeb object is cached for each node.

If let's say for arguments sake each node consumes about 1mb  per node and our object cache size is only set to 100mb, if we have a large site structure and we come to the 101 node, the oldest object will be removed from the cache to allow for the latest node to be cached. If we had 500 nodes (sub-sites) only the latest 100 nodes will be cached and the remaining 400 nodes would have been stored in the cache and then removed making the object cache completely in-efficient, as the next request will have to rebuild all this again, causing really slow page loads and no benefit of the object cache, as what is now stored in the object cache is useless pile of muck.

We will also fill up unnecessary memory causing w3wp.exe to run inefficiently.  Also we end up with a high number of SPWeb objects being left open waiting for the most reliable [not] .Net Garbage Collector to free up its memory resource, because the objects are not disposed by design and if you are not careful with Verbose logging ramped up, you probably will end up with GB's of ULS logs in MOSS in minutes, eating valuable disk space, depending on your log settings.

So what can we do to improve this, well we have a few choices:

ISSUE: 

After applying Version 2 patch of Portalshield for WSS 3.0, you my see the following error:

• Event ID
  3351 – SQL database login failed. Additional error information from SQL
  Server is included below.    Login failed for user 'NT
  AUTHORITYANONYMOUS LOGON'
  
• Event ID 1000 - (#50070 "Unable to connect to the database "<database name>" on "<remote SQL server name>")

These error may occur every 5 mins in your event logs.

FIX:

Run the SETSQLACT tool at the command prompt to select the appropriate account:

1. Click Start, Run, type cmd click OK.
2. At the prompt, type the appropriate command below and press ENTER: 

   CD Program FilesNetwork AssociatesMcAfee PortalShieldin (For PortalShield 1.x installations)

   CD Program FilesMcAfeeMcAfee PortalShieldin (For PortalShield 2.x installations)

3. Type the following command and press ENTER: 

   SETSQLACT.EXE 

4. Type the name of the account that has access to the remote database and is a member of the Local Administrators group and press ENTER.

Keep this command session open as it will be used later in this procedure.

Modify the registry:

1. Click Start, Run, type regedit and click OK.
2. Navigate to and select the appropriate registry key below:

   HKEY_LOCAL_MACHINESoftwareNetwork AssociatesMcAfee PortalShield (For PortalShield 1.x installations)

   HKEY_LOCAL_MACHINESoftwareMcAfeeMcAfee PortalShield (For PortalShield 2.x installations)

3. In the right pane, click Edit, New, DWORD value.
4. Name the new DWORD value ODForceImpersonate and set the Value data to 1.
5. Close Regedit.

At the command prompt:

1. Type the command below and press ENTER to restart Microsoft IIS:

    IISRESET 

2. Wait for the prompt stating Internet services successfully restarted, then close the command session.

Restart the PortalShield service:

1. Click Start, Settings, Control Panel, Administrative Tools, Services.
2. Right-click the McAfee PortalShield service and select Restart.
3. Close the Services window.

This fix was initially used to fix the same issue in PortalShield for WSS 2.0, I came across the same problem for PortalShield for WSS 3.0 after applying Version 2 patch and the same fix resolved my issue for MOSS. The fix is listed on the Macfee site but only references PortalShield for WSS 2.0.

Mcafee

How do we get the OWA Web Part to work without prompting you to add user credentials and to autodetect the user without prompting for a password?

Hmmm…Interesting.  

 The best workaround I have seen for this so far is to set up x2 web sites on your OWA server. One web site can be configured with FBA [Forms Basic Authentication] or Basic Authentication [mail.yourcompany.com] which is used for primary OWA use within your organization and the other web site [spmail.yourcompany.com] is configured with Windows Authentication which is used for just SharePoint web part usage.

 Using the windows authentication site [spmail.yourcompany.com] within your web part will automatically log the user onto the OWA server without re-prompting for the password.

Makes sense when you think about it.  

SharePoint 2007 has a caching features built into itself to speed up the performance of site rendering, but does not do content synching or content replication. MOSS 2007 uses ASP.NET 2.0 caching options as well as caching functionality that the Office team designed specifically for MOSS.

The types of caching are:

Type:       Output Caching and Cache Profiles
Cache At: Individual page level
Note:        Includes extending caching using VaryByCustomString
 
Type:       Object Caching
Cache At: Individual Web Part control, field control, and content level
Note:        Includes cross-list query caching and navigation caching
 
Type:       Disk-based Caching for Binary Large Objects
Cache At: Individual binary large object (BLOB) level and caches images, sound, movies, and code
Note:        Supports .gif, .jpg, .js, .css, and other image, sound, and code files that are stored as binary large objects
 

Procedures for Output Caching and Cache Profiles

Pros and Cons of Output Caching
Before choosing to use output caching to improve the performance of page and page-item rendering, consider benefits and drawbacks of a potential output caching implementation. All considerations are not listed in this document, but some benefits you may want to consider include:

Each equivalent class of content (such as page or item within a page) receives faster response, and therefore shorter latency, after it is initially rendered.

Each server uses less CPU time and energy to serve the same page after the initial rendering.

Each data source for the rendered page can scale to serve more Web clients because of the decreased traffic flow that output caching makes possible.

For each page request for which an output cached version of a page is served, the server does not have to:

Make a round trip to the database to fetch the source code for the .aspx page and any .ascx controls on the page.

Reload and re-render the controls.

Requery any data sources that the controls rely on for data.

However, before deciding to implement output caching, you may want to consider the following concerns:

Output caching consumes additional memory. Each version of a page consumes memory on the Web client.

When used with two or more front-end Web servers, output caching may affect consistency. You can configure a cache profile not to check for updates for each request and, for example, instruct it to ignore changes to the version of the Web page in the output cache until 60 seconds after the original page is updated. If you have two front-end Web servers in your topology, and depending on the load balancer used to route the user's request, a reader of site content could see inconsistency if the page is rendered by one server and then a subsequent request is routed to a second server within that 60-second window.

Cache Profiles
Office SharePoint Server 2007 adds a more precise mechanism for customizing output caching than those available natively in ASP.NET 2.0. Office SharePoint Server 2007 includes cache profiles, which are list-style cache settings that you can name and apply to pages, page items, content types, and levels of scale in your site deployment.

By using cache profiles, you can control the level of granularity applied to output caching; allow or disallow site owners and administrators to choose their own cache profiles and apply them flexibly to page layouts; and target output caching at the site collection, site, and page layout levels.

You can organize caching behavior based on a user's access rights to a site. For example, you may have three groups defined: one with full control, one with read and write rights, and one with read-only rights. Output caching renders the page the same way for users with the same rights, so you can use cache profiles to target caching to specific audience groups. In the cache profiles that Office SharePoint Server 2007 delivers by default, the caching system renders the page once per group of user access rights and then caches the resulting HTML stream. The next user with the same access rights gets the stream from the cache.

After you create and deploy a cache profile, any change to the cache profile immediately affects all applicable content on the site. For example, if all document library page layouts in a given site collection are initially cached for 60 seconds, and you increase that duration to 120 seconds, every document library page layout in that site collection is cached for 120 seconds regardless of the number of document library page layouts or sites in the site collection.

You can define a cache profile by using the cache profile stored in a standard Office SharePoint Server 2007 list, and extend it programmatically by using a VaryByCustom handler. If you apply the cache profile to the site and page layout through the user interface, down-level propagation enforces consistency in child sites. Cache policy is secured independently from other Office SharePoint Server 2007 features.

To enable output caching for a site collection
Navigate to the root Web site of the site collection. On the Site Actions menu, click Site Settings.

In the Site Collection Administration section, select Site collection output cache.

To enable output caching for this site collection, select Enable output cache.

Choose a cache profile for anonymous users from the Anonymous Cache Profile list. This profile is applied when anonymous users access a site in this site collection.

Choose a cache profile for authenticated users from the Authenticated Cache Profile list. This profile is applied when authenticated users access a site in this site collection.

Choose Page Output Cache Policy options.

If publishing sites can use a different output cache profile, select Publishing sites can use a different page output cache profile.

If page layouts can use a different output cache profile, select Page layouts can use a different page output cache profile.

If you want to display additional cache information on pages in this site collection, including the date and time that page contents were last rendered, select Enable debug cache information on pages.

Click OK.

To enable output caching for a site
Navigate to the root Web site of the site collection. On the Site Actions menu, click Site Settings.

In the Site Administration section, select Site output cache.

Choose an Anonymous Cache Profile option:

If you want to inherit a cache profile, click Inherit the profile.

If you want to choose a cache profile from those currently available, select Select a page output cache profile.

If you want to apply these settings to all subsites of this root Web site, select Apply these settings to all sub-sites.

Click OK.

To create a new cache profile
Navigate to the root Web site of the site collection. On the Site Actions menu, click Site Settings.

In the Site Collection Administration section, select Site collection cache profiles.

Click New.

Define and create a new cache profile.

Procedures for Object Cache

Microsoft Office SharePoint Server 2007 supports caching of certain page items, such as navigation data and data accessed through cross-list queries. Caching page items is fast and eliminates the need to retrieve field data from the database each time a page is rendered. The caching system caches complete field data for a page, excluding data for any Web Part controls on the page.

Caching for objects in a page can almost always be used. When users have a document checked out, the cache is bypassed.

Configure the object cache
On the Site Actions menu, point to Site Settings, and then click Modify All Site Settings.

Under Site Collection Administration, click Site collection object cache.

In the Object Cache Size section, type a value in the box to specify the amount of memory (in megabytes) that you want the object cache to use.

In the Cross List Query Cache Changes section, select one of the following options:

If your content changes frequently and you want to display the most accurate results possible, select Check the server for changes every time a cross list query runs.

On site collections where the improved performance you get from caching does not compromise the accuracy of the results, select Use the cached result of a cross list query for this many seconds and type the amount of time in seconds to cache the results of the query

In the Cross List Query Results Multiplier section, type a number from 1 through 10 to use as a results multiplier.

Type a larger number if your site collection has unique security permissions applied to many lists and sites. Type a smaller number if your site collection does not have unique permissions on each list or site. A smaller multiplier uses less memory per query.

Click OK.

Flush the object cache
On the Site Actions menu, point to Site Settings, and then click Modify All Site Settings.

Under Site Collection Administration, click Site collection object cache.

In the Object Cache Reset section, do one or more of the following:

To force the current server to flush its object cache, select the Object Cache Flush check box.

Select one or more check boxes. When you click OK, all entries in the object cache are flushed immediately.

If you do not select one more check boxes, the object cache manages the expiration of items based on when they time-out or are changed in the site.

Click OK.

Enabling and Modifying Disk-based Caching

Disk-based caching controls caching for binary large objects (BLOBs) such as image, sound, and video files, as well as code fragments. Disk-based caching is extremely fast and eliminates the need for database round trips. BLOBs are retrieved from the database once and stored on the Web client. Further requests are served from the cache and trimmed based on security.

Disk-based caching is disabled by default. To enable and customize the disk-based cache, you must modify the following statement in the web.config file for the SharePoint Web application mapped to the Internet Information Services (IIS) Web site:

 Copy Code
<BlobCache location="C:lobCache" path=".(gif|jpg|png|css|js)$" maxSize="10" max-age="86400" enabled="false"/>

In the preceding example:

location is the directory where the cached files will be stored

path specifies in the form of a regular expression which files are cached based on the file extension

maxSize is the maximum allowable size of the disk-based cache in gigabytes

max-age specifies the maximum amount of time in seconds that the client browser caches BLOBs downloaded to the client computer. If the downloaded items have not expired since the last download, the same items are not re-requested when the page is requested. The max-age attribute is set by default to 86400 seconds (that is, 24 hours), but it can be set to a time period of 0 or greater.

enabled is a Boolean that disables or enables the cache

Flushing the Disk-based Cache
On the Site Actions menu, point to Site Settings, and then click Modify All Site Settings.

Under Site Collection Administration, click Site collection object cache.

In the Disk Based Cache Reset section, do one or more of the following:

To force the server to reset its disk-based cache, select Force this server to reset its disk based cache.

To force all servers to reset their disk-based caches, select Force all servers in the farm to reset their disk based cache.

If you select one or more of the check boxes, all entries in the disk caches are flushed immediately when you click OK. If you do not select any of the check boxes, the disk caches are left unchanged and item expiration is managed, with items being removed when they are changed in the site or when the disk size is exceeded.

Click OK.

I thought it would be easier having all the different types of caching for MOSS available in one place.

A sharepoint Inter-Farm means that a SharePoint Farm with its own SSP [Shared Service Provider] will share the SSP to other Farms. The other farm will consume the shared SSP, which allows the reduction of duplicate services. Please refer to the following http://technet.microsoft.com/en-us/library/cc262179.aspx

To provide a quick guide you can try the following;

Hey Community,

Just to make you all aware that the Prime Rollup update is now available on request for Premier customers if required now, taking you to build 12.0000.6315.5000 and publicly available in June 2008. This hotfix come in the standard way of a WSS fix [KB Article Number(s): 942489, 952698] and a MOSS fix [KB Article Number(s): 942489, 952704]. There are a lot of fixes within this prime rollup from a publishing perspective [CMS].

Issue:

With regards to applying this build 12.0000.6315.5000 once you have applied the fixes that there is an slight issue starting the "SPAdmin Service". The timeout period for this service is to short and you will get an error in the Event Logs showing an error of  "The service process could not connect to the service controller".

If you try to manually start this service this is not possible. To successfully start the SPAdmin service you have to modify/add two registry values:

1. HKLMSYSTEMCurrentControlSetControl     ->         add/modify DWORD value ServicesPipeTimeout to 60000 (60 seconds) [Make sure the base type is decimal]
2. HKLMSYSTEMCurrentControlSetControl     ->         add/modify STRING value WaitToKillServiceTimeout to 120000 (120 seconds) [Make sure the base type is decimal]
3. Reboot the server
4. Manually start the SPAdmin service using: net start spadmin

I have seen a few blogs recently talking about how to get the correct version of MOSS from your server's in your server farm. Sound easy enough.

What I have seen; are articles telling you to go to the web sites properties of your site collection in IIS and then to select the HTTP Headers tab, here you will see a "Custom HTTP headers" text box which displays a version number of MOSS. GREAT!

or

Go to "Add/Remove Programs" within control panel select "Microsoft Office SharePoint Server 2007" and click "Click here for support information". On the dialog you will see a version number indicating MOSS version. Suppose to be good! 

If you think this is correct then read on!

This method of getting the version number for MOSS is not correct. What you will see in the HTTP header tab in IIS is the build version of MOSS at the time when the Virtual Directory [Web Application] was created, if you patch the server with a Service Pack, Hot Fix or a Roll up Fix, the HTTP header tab is not updated with new build version number on existing sites, which can confuse a lot of people.  If you create a Web Application [Virtual Directory] after you have patched the server you will get the Build Version number of MOSS, at the time the site is created. I bet most SharePoint veterans must have wondered why one HTTP header on there site collections may have been different to another site collection on the same server. It proberbly because you have created both site collections at different times with different patches applied to your farm. I noticed that the "Add/Remove Program" method too did not update.

The correct way to get this information is to open up "Central Admin", click on "Operations" and then click on "Servers in Farm". in this administration page you will see the Database Schema Version in the top of the screen and a list of servers with the version numbers listed in the relevant column against each server in the farm. You can also see the database schema version in "Site Settings", "Modify All Site Settings" in the Site Information section. The other alternative is to look at the MOSS configuration database [SQL Server] of your site collection and open the Versions table, there will be entires in this table with the versions that have been applied to in your farm and the date when the Service Pack, hot Fix or Rollup was applied.

I have listed below the version numbers for MOSS;

MOSS 2007 or WSS 3.0 Hotfix (KB953484 – KB953473 – KB953471)   12.0.0.6317.500

MOSS 2007 or WSS 3.0 Hotfix (KB953138 – KB953137)   12.0.0.6316.500
MOSS 2007 or WSS 3.0 Hotfix (KB952704)                     12.0.0.6315.500

MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB952294)       12.0.0.6314.500 [In SSP admin you will get a new Search Administration option, which brings the Search Server features to MOSS.]
MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB948945)       12.0.0.6303
MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB941274)       12.0.0.6301
MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB941422)       12.0.0.6300
MOSS 2007 or WSS 3.0 SP1                                         12.0.0.6219
MOSS 2007 or WSS 3.0 October public update                12.0.0.6039
MOSS 2007 or WSS 3.0 August 24, 2007 hotfix package  12.0.0.6036
MOSS 2007 or WSS 3.0 RTM                                         12.0.0.4518
MOSS 2007 or WSS 3.0 Beta 2 TR:                                12.0.0.4407
MOSS 2007 or WSS 3.0 Beta 2:                                     12.0.0.4017

Just wanted to make the community aware of a new blog just written by Stefan Gobner (EE Engineer at Microsoft and also a colleague of mine). He explain very well the steps that can be taken by SharePoint Administrators to isolate if a site that contains custom code, which does not properly dispose objects correctly and also how you can isolate components that are leaking these objects.

http://blogs.technet.com/stefan_gossner/archive/2008/05/07/troubleshooting-spsite-spweb-leaks-in-wss-v3-and-moss-2007.aspx 

Keep up the great work Stefan your a living legend.