Jimmie's Sharings : SharePoint

Content Deployment and CEWP Absolute URLs

jimmiet — Tue, 17 Feb 2009 01:15:00 GMT

Content Deployment and CEWP Absolute URLs

The Content Editor Web Part (CEWP) has a Rich Text Editor. This allows non-technical authors to generate custom content using a web part. This is a great feature for team collaboration sites, but some customers also use the CEWP on publishing site pages. Avoiding the discussion of web parts verses field controls in published pages, there are issues using the CEWP to create content on published pages.

The Problem

A Rich Text Editor sounds like a great feature; however, there is a problem with content deployment, described by Andrew Connell. (There is a related problem for sites that can be accessed through multiple AAMs as described by Maxime Bombardier.) The basic problem is the Rich Text Editor forces all URLs to be absolute. If you look at the HTML generated by the above HTML editor, you will see:

As Andrew Connell points out:

If you have a link to http://staging.adventureworkstravel.com/pages/contactus.aspx in a CEWP on a page and then do content deployment to http://www.adventureworkstravel.com, the link will be pointing back to the staging site (which will... or should... be inaccessible).

The absolute URL is not fixed up automatically during content deployment, so the target page will still point to the original URL location, not a location within the target farm. This means the absolute URL must be corrected in the target farm itself. In the preceding example, we want the target farm HTML to be a relative URL that points to locations within the target farm:

Maxime Bombardier’s control adapter strategy can be leveraged. With slight modification, Maxime’s code can be modified to convert absolute URLs to relative URLs, so they effectively point to the appropriate location in the target farm. How do we convert an absolute URL to a relative URL? Looking at the above example, we need to strip out the host portion of the URL; that is, we need to remove “http://moss.litwareinc.com”

The Solution

The difference between the content deployment fix we need, and Maxime’s AAM fix, is what gets stripped. Maxime’s AAM fix strips the AAM host names of the current web application. The content deployment fix needs to strip the AAM host names of the authoring web application, which the target farm does not know. In other words, we need a way to tell the control adapter which host names to strip. The solution is to make the host names configurable. This solution uses the SharePoint Config Store solution developed by Chris O'Brien.

So, the primary difference between this control adapter and Maxime’s control adapter is the GetAlternativeUrls method. This method’s logic is changed to read AAMs from the Config store list, rather than using the object module to get the AAMs from the current web application.

The Code

using COB.SharePoint.Utilities;
using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.Adapters;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;

namespace Litware.SharePoint.WebPartPages.CewpControlAdapter
{
    public class ContentEditorWebPartAdapter : ControlAdapter
    {
        protected override void Render(System.Web.UI.HtmlTextWriter writer)
        {
            StringBuilder sb = new StringBuilder();

            // Allow the CEWP to render itself into a string that we provide
            HtmlTextWriter htw = new HtmlTextWriter(new StringWriter(sb));

            base.Render(htw);
            string output = sb.ToString();

            // Wrap the adatper rendering logic in a try-catch so any error
            // in the adapter won't prevent the CEWP from rendering.
            try
            {
                // Now we post-process the CEWP rendering to convert absolute URLs to relative URLs
                string[] alternativeUrls = GetAlternativeUrls();

                if (alternativeUrls != null)
                {
                    foreach (string replaceableUrl in alternativeUrls)
                    {
                        // Do a simple String.Replace() of the alternativeUrls to generate a relative url
                        searchFor = replaceableUrl;
                        replaceWith = "/";
                        output = output.Replace(searchFor, replaceWith);
                    }
                }
            }
            catch (Exception ex)
            {
                // log exception here
            }

            // Finally, write the rendering to the page
            writer.Write(output);
        }

        private string[] GetAlternativeUrls()
        {
            string[] alternativeUrls = null;

            try
            {
                alernativeUrls = (string[])HttpContext.Current.Cache["alternativeUrls"];

                if (alternativeUrls == null)
                {
                    string temp = String.Empty;

                    // Get the URLs to be replaced from the config store
                    temp = ConfigStore.GetValue("CEWP Adapter", "AAMs");

                    if (String.IsNullOrEmpty(temp))
                        throw new ArgumentNullException("AAMs config store parameter is null or empty");

                    // Split apart the config parameter using a semicolon separater value
                    char[] separaters = { ';' };
                    alternativeUrls = temp.Split(separaters);

                    // Validate the config value
                    if (alternativeUrls == null || alternativeUrls.Length == 0)
                        throw new ArgumentNullException(
                            "AAMs config store parameter is null or empty after split");

                    for (int i = 0; i < alternativeUrls.Length; i++)
                    {
                        // Ensure the URL is "/" terminated for consitent replacement behavior
                        string replaceableUrl = alternativeUrls[i];
                        if (!string.IsNullOrEmpty(replaceableUrl) && !replaceableUrl.EndsWith("/"))
                            alternativeUrls[i] += "/";
                    }

                    // Sort, and then reverse the array
                    // to put the longest; that is, the most specific
                    // URLs first in the list
                    Array.Sort(alternativeUrls);
                    Array.Reverse(alternativeUrls);

                    // Cache for 5 minutes to allow for a somewhat quick refresh
                    // if the configuration values are changed
                    HttpContext.Current.Cache.Add("alternativeUrls",alternativeUrls, null,
                         DateTime.Now.AddMinutes(5), System.Web.Caching.Cache.NoSlidingExpiration,
                         System.Web.Caching.CacheItemPriority.Normal, null);
                }
            }
            catch (Exception ex)
            {
                // log exception here
            }

            return alternativeUrls;
        }
    }
}

Build the output assembly as strongly named, and then deploy it to the GAC on every WFE. A simple solution package (wsp file) can be created to automate the deployment to all WFEs. Creating a solution package is automatic if you create your project using the Visual Studio 2008 extensions for Windows SharePoint Services 3.0, v1.2.

Browser File

The control adapter is associated with the CEWP through browser file entries. The default browser file, compat.browser, is in the App_Browsers folder of each web application’s virtual directory. We don’t want to update this file; instead, we will create a separate file for our control adapter.

Additional browser files can be added to the same directory; however, additional files will not be recognized by ASP.NET until compat.browser is recompiled. Recompilation is forced by opening compat.browser in a text editor like Notepad, making an innocuous change (e.g., add and then delete a space), and then saving the file.

The customized browser file, litware.browser, is created and placed in the App_Browsers folder of every web application where the control adapter is to be enabled. Without this browser file, the control adapter is not called even though it may be installed in the GAC. The default compat.browser is then updated and saved to force a recompiled of the local application browser files as described in the preceding paragraph.

Looking at the litware.browser code, the entry controlType attribute tells ASP.NET to associate this control adaptor with the CEWP. The adapterType attribute has the control adapter type and assembly. The refID=”Default” attribute tells ASP.NET to apply the adapter to all browser types.

<?xml version="1.0" encoding="utf-8" ?>
<browsers>
<browser refID="Default">
    <controlAdapters>
      <adapter controlType="Microsoft.SharePoint.WebPartPages.ContentEditorWebPart"
               adapterType="Litware.SharePoint.WebPartPages.CewpControlAdapter.ContentEditorWebPartAdapter,
                    Litware.SharePoint.WebPartPages.CewpControlAdapter, Version=1.0.0.0, Culture=neutral,
                    PublicKeyToken=daf6fd1bbe0cfc20" />
    </controlAdapters>
</browser>
</browsers>

Note, App_Browser directory must be updated on every WFE in the target farm.

References

Browser Definition File Schema (browsers Element)
Securing Browser Definition Files

Office Web Service

jimmiet — Fri, 04 Jul 2008 01:46:41 GMT

Office Web Service

The Office Services Web service is used by Office SharePoint Server 2007 as a communication channel between Web servers and application servers. This service uses the following ports:

TCP 56737
TCP/SSL 56738

Access to the web service methods is restricted to the farm administrator group, WSS_ADMIN_WPG. None of the web service methods can be called from user code.

Web Services

Depending on features installed, the Office Server Web Services Web application exposes the following internal Web services, which are not available for calls from custom code:

Friendly Name	Location	Description
Search Web Service	SearchAdmin.asmx	Microsoft Office SharePoint Server 2007 Search Administration Web Service.
Search Application Web Service	/SSP/Search/SearchAdmin.asmx	Microsoft Office SharePoint Server 2007 Search Application Administration Web Service.
Excel Service Soap		/SSP/ExcelCalculationServer/ExcelService.asmx	Microsoft Office SharePoint Server 2007 Excel Services Application Web Service.

The object model automatically short circuits the web services, i.e. invokes the underlying functionality without invoking the web service, when the target server is also the client primarily for performance reasons. Hence, the web services are not used...

On a Basic deployment.
When the administrative action is performed on a WFE that also happens to be the indexer.

Global Web Service (SearchWebService)

Runs in the Office Server Web Services virtual server root application pool, i.e. an application pool that does not belong to any SSP. This GLOBAL application pool runs as NetworkService.

It is used to retrieve low level computer configuration settings before any SSP is created, e.g. system drive info, verify path correctness, the computer's IP Address.

It is also used to create/configure a propagation share. The web method that implements this functionality is special: It impersonates the WindowsIdentity making the request. That identity must be a local admin on the remote server (only local administrators can create/configure shares).

Allowed access: WSS_ADMIN_WPG.

SSP (Application) Web Service (SearchApplicationWebService)

Primarily used for SSP administration of Search configuration.

A web service associated with a specific SSP on a specific server (indexer and/or query server).

Runs as the SSP web service credentials (the credentials that you enter in the SSP creation/details page).

The SSP web service account can read/write from/to the SSP database and the Search database (only the ones that belong to its SSP).

Allowed access: WSS_ADMIN_WPG and the SSP administration application pool identity.

Security

InterServer Communications

Network traffic can be secured with either SSL on port 56738, or with IPSec on either port.

IPSec is an IP level feature, which means all traffic on the configured ports is protected; whereas, SSL is an application level protection mechanism.

IPSec has the advantage of limiting which pairs of servers can communicate, by configuring the IP addresses. This feature can significantly lock down a server farm.

Service Accounts Used

Search service account

It is a db_owner in ALL SSP databases.
It is a db_owner in ALL Search databases.
It has READ ONLY access to all the content in ALL web applications via a policy.
It has read/write access to the propagation share on Query servers.
It has read/write access to the Search registry hive.
It has read/write access to the Search index location.

SSP administration site application pool identity

This account is determined by the web application that you select when you create the SSP.
It has read/write access to the SSP database and the Search database.
This account has full control over the Search service via its COM interfaces.
It has read/write access to the Search registry hive.

Global web service account

This is the GLOBAL application pool account of the Office Server Web Services, i.e. an application pool that does not belong to any SSP.
It is always set to NetworkService.

SSP (Application) web service

The application pool account of an SSP web service (the credentials entered in the SSP creation/details page).
This account has read/write access to the SSP database and to the Search database of an SSP.
This account has full control over the Search service via its COM interfaces.

It has read/write access to the Search registry hive.

My Site Recommendations

jimmiet — Wed, 02 Jul 2008 03:19:00 GMT

My Site Recommendations

The following My Site recommendations are a composite of best practices taken from experiences at Microsoft and other large customers.

Planning

My Sites (even if they are as small as possible and only really used to store a profile picture) complicate backup/recovery, and add complexity and risk to ensuring the availability of the rest of the SSP farm. Large organizations (100K+ employees) should consider putting My Sites into a separate farm.

Very large organizations might consider multiple My Site farms, perhaps regionally located. This minimizes the number of content databases per farm and places the My Sites geographically closer to the site owners. Having fewer content databases per farm eases administrative burdens. Having My Sites hosted closer to site owners reduces the affects of network latency, thereby enhancing their usage experience. Multiple My Site farms can also provide more flexibility in managing the effort and time required to deploy updates and service packs to any given farm.

Always create a dedicated Web Application to host My Sites. This allows leveraging web application policies to define security, facilitates content database management, and enables creation of zones for external access.

Do not customize the My Site site definition. Besides being unsupported, poorly designed customizations can severely impact server performance and unnecessarily consume valuable CPU and memory resources. Any customization should be done through feature stapling, see http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx and http://blogs.msdn.com/cliffgreen/archive/2008/03/13/removing-web-parts-from-the-my-site-web-part-gallery.aspx

Indexing

Install the latest service pack (currently SP1). Be sure to get the latest post service pack hotfixes applied, in particular 21243 (Office QFE). There is an issue where incremental crawls will not pick up all changes on My Sites without the post SP1 hotfix.

Use a separate content source for People Profiles rather than allowing it to default to the Local Office SharePoint Server Sites content source. My Sites full crawls can be time consuming due to the large number of site collections. Creating a separate content source enables independent crawl configuration; such as, the type of crawl and crawl frequency for My Sites.

Provisioning

Remember, a user profile page will exist for all employees following a full Active Directory profile import, even if no My Sites have been created yet. Profile pages allow basic employee information to be exposed in search results.

Allow users to create their own My Site on demand. Do not pre-provision My Sites. Generally, pre-provisioning is a time consuming process potentially taking many days or weeks. It gains little, and costs storage and administrative headaches.

Rolling-out

Make My Sites available to everyone on day 1. This allows for "viral" adoption by early adopters. This will eventually encourage others to create My Sites, thereby getting the momentum rolling.

Send out invitations to a small group of "pilot" users who would be interested in trying out My Sites, based on their role in the organization. The pilot group might contain a few hundred users. This gets a critical mass of My Sites in place quickly.

Try regional roll-outs via "soft launches", which include poster campaigns or brown bag lunch training at selected campuses and offices.

About the 3^rd or 4^th month, promote the My Site feature in a story on the Intranet portal home page.

Around the 6^th month, incorporate the concept of "filling out your profile" into new employee orientation as a specific training exercise. Now essentially all new hires will have a My Site (because they need one to store their profile picture).

Encouraging On-Going Adoption

Encourage high profile "executive blogging" to drive awareness and adoption of My Sites. Blogging topics might include annual business planning, corporate strategy, rumor control, etc. This can demystify blogging by encouraging many participants to make daily posts about what they were doing and what they are thinking about. Note: this implies more frequent incremental crawling to incorporate blog entries into the search index.

Also, consider setting up a "Blogs" scope on the search home page to facilitate blog discovery. This can be accomplished by setting up scope based on the Content Type of blog posts. An example follows:

Note that this scope will pick up Blog Posts no matter where the Blog resides, as long as those a SharePoint Blogs crawled by a SharePoint Content Source.

Consider adding a link on the profile page that allows others to send an email to ask the person to fill out their profile ("peer nagging").

Explore holding a contest or raffle – If you fill out (or update) your profile this month you are eligible to win a prize.

Vanity Site Collection URLs

jimmiet — Sun, 01 Jun 2008 17:05:00 GMT

Vanity Site Collection URLs

A customer recently asked for “vanity” URLs for each of the major departments; HR, Finance, Legal, etc.; so for example, HR would be http://hr.bigcorp, and legal would be http://legal.bigcorp. No problem you say, just create a web application for each department, give the web application default zone the vanity URL, create corresponding DNS entries, and the requirement is fulfilled.

The problem is there are over 30 departments, not to mention foreign subsidiaries, and possibly other “I want my own vanity URL” requests from other corporate groups. Since web applications are heavy resource consumers, each one requiring one IIS web site per zone, basing vanity URLS on web applications would not be feasible.

The traditional out-of-the-box site collection paths did not meet the requirements;

Wildcard inclusion; e.g., http://bigcorp/sites/finance

Explicit inclusion: e.g., http://bigcorp/finance

For both wildcard inclusion and explicit inclusion, the vanity part of the URL is at the end, which is not what was desired.

Host-Named Site Collections

Host-named site collections (what used to be called "scalable hosting mode" in WSS v2) provide exactly the needed capability. Don’t confuse the terms host-named with host headers. They are different concepts. The host-named concept applies to the internal SharePoint virtual path mapping mechanism; whereas host headers apply to IIS web sites independent of SharePoint.

Host-named site collections effectively allow use of an arbitrary URL, which is associated with an existing web application. There can be many host-named sites for a web application. The net result is freedom to have as many vanity URLs as necessary, while limiting the number of web applications. We can have URLs like http://finance.bigcorp, http://finance, http://my.finance, etc.

Host-named sites cannot be created through the UI. You must use stsadm. This should not deter you, since the syntax is simple. The secret is to add the –hhurl parameter to the stsadm createsite command.

Host-Named Site Collections Limitations

As with all good things, there are some limitations and complications. The following blog is an excellent read: http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx. Quoting from this blog:

Host-named site collections short circuit much of the AAM functionality, including the URL remapping functionality. They're always considered to be in the Default zone, and their URL is always the same URL you supplied when creating the site collection. You cannot use host-named site collections with off-box SSL termination, port translation, or host header manipulation scenarios.

This whitepaper is also highly recommended reading. It discusses how to enable SSL, and many other configuration issues:

http://office.microsoft.com/search/redir.aspx?AssetID=AM102157711033

Step-by-Step Example

Assume we want to create a site collection with the vanity URL http://finance.litwareinc.com in the http://extranet.litwareinc.com web application.

Step 1: Open a command prompt as a farm administrator, and then enter this command, being sure to include the –hhurl parameter:

>stsadm -o createsite -url http://finance.litwareinc.com -ownerlogin litwareinc\administrator -owneremail administrator@litwareinc.com -hhurl http://extranet.litwareinc.com -sitetemplate STS#1 -title "Finance Department" -quota DepartmentalSite

Operation completed successfully.

The new site collection appears in the site collection list of the extranet.litwareinc.com web application.

Step 2: Create a DNS entry for this new name, pointing to the http://extranet.litwareinc.com IP address. For local test, make an entry the hosts file.

You can now open a browser and navigate to the site collection.

Step 3: Create a search context for the new site collection, or include it as a starting address within an existing site collection. Start a crawl to include the site contents in the search index.

To test the search, create a simple text document in a shared document library. When the next increment crawl completes, you can then search for the document to verify the search results are using the vanity URL.

The Kerberos Factor

The stsadm site creation command will give a warning if the host web application is using Kerberos authentication (negotiate).

>stsadm -o createsite -url http://finance.litwareinc.com –ownerlogin mossfs\administrator -owneremail administrator

@mossfs.com -hhurl http://dmz.litwareinc.com -sitetemplate STS#1 -title "Finance Department"

WARNING: SharePoint no longer customizes Integrated Authentication security settings. This Web application may be using Kerberos, which can require manual configuration. See http://support.microsoft.c

om/?id=832769 for more information.

Operation completed successfully.

It is necessary to register the vanity URL with Active Directory using setspn.

>setspn -a http/finance.litwareinc.com litwareinc\administrator

In my testing, I stumbled into another complication. Without realizing it at first, I created a site collection in the Intranet zone of a web application, which was configured for Kerberos.

After creating the site collection, adding the DNS (host file) entry, and executing setspn, I got a “This site is under construction” error page every time I tried to browse to the site. I eventually worked-around this by explicitly adding a host header to the IIS web site. I consider this an unsupported solution, and so I recommend extensive testing before applying it to a production scenario.

“Hidden” SSP Timer Jobs

jimmiet — Sun, 20 Apr 2008 17:21:00 GMT

Not all timer jobs are visible in the Central Administration timer job definition page. There are MOSS 2007 timer jobs in the SSP application which don’t appear in the Central Administration page. It makes sense that these jobs are not visible, since there is nothing you can modify or disable. All the same, it would be nice to know what these jobs are, and what their schedules are, in case you want to schedule other potentially conflicting activities.

You can see the names of these SSP jobs by using stsadm enumssptimerjobs command, as in the following console sample (view entire article ...)

How are SSP Associations Changed?

jimmiet — Sun, 20 Apr 2008 00:44:00 GMT

I recently heard a question, “How do you change SSP web application associations through the object model (OM)?” Searching the OM online help didn’t find any results. Any yet theoretically, it must be possible, since you can set the web application SSP association through Central Administration.

Then the thought occurred, why not reverse engineer the Central Administration page to see how it is done? Here are the steps. This technique can be applied to any administration page if you are curious how the product team wrote the code. (view entire article...)

DST and Timer Jobs

jimmiet — Sun, 30 Mar 2008 00:48:00 GMT

Now that daylight savings has arrived in the United States, have you noticed problems with timer jobs not running when expected?

I recently encountered this trying to deploy solution packages using stsadm scripts. In the past, these scripts ran flawlessly. The old solutions were retracted and deleted, the new solution versions added and deployed across all farm servers within a few minutes, and life was good.

Last week I was working with a customer to deploy a new staging farm. We got to the point at which the solution deployment scripts were run. We waited, and waited, and waited. The script was hung at stsadm –o execadmsvcjobs, which was called after executing several stsadm –o deploysolution -name solutionpackage1.wsp -immediate -force –allowGacDeployment statements. What should have happened is the timer jobs to deploy the solution across the farm servers should have executed within about a minute. Instead, over an hour passed. Then suddenly, the jobs ran. What caused this odd behavior, which had never happened before with the same scripts? Was there a farm configuration problem?

Then a thought occurred. The time had changed to daylight savings a week before; moving the clocks ahead one hour. Could there be a connection?

A little research brought the problem to light. WSS 3.0 SP1 includes fixes to timer job DST scheduling problems. See 938663 ( http://support.microsoft.com/kb/938663/ ) One-time timer jobs in Windows SharePoint Services 3.0 are delayed by at least one hour when the jobs are scheduled to occur during daylight saving time (DST).

A quick check in Central Administration > Operations > Servers in Farm, showed the installed version number was 12.0.0.4518. It should have been 12.0.0.6219 if SP1 was installed. We installed WSS 3.0 SP1, and the timer job scheduling problem disappeared!

I strongly encourage installation of WSS/MOSS SP1. It fixes many issues, DST just being one example. Taken time to read and following the installation instructions precisely! Remember, you have to update all servers in the farm at once. There is no rolling update, so if you have a multiple server farm with large content databases, plan on doing this over a weekend to avoid disrupting your user community.

User Profile Change Logging

jimmiet — Sat, 29 Mar 2008 23:56:00 GMT

Profile Change Logging

There is a table in the SSP database named UserProfileEventLog. The table maintains a history of user profile property changes. By default, it retains 7 days of history. This table can cause problems in a couple of ways.

First issue: size. This table contains one row per change of a property in a user profile. The row contains the old and new property values, along with associated metadata like the datetime the property was changed. The implication is that the table can grow large. Assume you just configured the profile import and are ready to start the first Active Directory import. Further, assume your organization has 100,000 user accounts, and each account be populated with 12 AD attributes. The full import will result in 100,000 X 12 = 1.2 millions rows being inserted into UserProfileEventLog. To extend the example, assume you also have a BDC import connection populating another 20 properties from your company's HR system. That adds another 2 million rows. There are now 3.2 million rows in the event log table. If each row is 100 bytes (old value, new value, plus metadata), the table is now approximately 300 MB in size.

Second issue: deleting old entries. The change history is kept for a configurable number of days. The concern is how many rows will have to be deleted on a given day? The number of days of history is 7 days be default, but can be set using stsadm.exe -o profilechangelog -title <SSP Name> -daysofhistory <number of days> -generateanniversaries (http://technet.microsoft.com/en-us/library/cc263013.aspx). The critical issue is that MOSS has to remove a full day of history every day to honor the daysofhistory setting. Using the numbers in the preceding paragraph, 7 days after the first full import, MOSS is going to delete 3.2 millions rows of data all at once! What makes this an issue is that this is done with a single SQL statement, something like DELETE FROM UserProfileEventLog WHERE EventId < @MinEventTime. Think of the implications. As a single statement, this will hold locks until all 3.2 million rows are deleted. These locks might prevent other database transactions from completing; but it also means the transaction log (even with simple recovery mode) cannot be truncated, and will therefore grow until at least this DELETE statement completes. I have seen this delete statement run for 4 hours, with the transaction log quadrupling in size.

This is little you can do to avoid this. Although you can adjust the number of days of history, MOSS will eventually try to delete an entire day's history at some point. The deletion is done by an internal timer job buried within the SSP. The job is hard coded to run at 10:00 PM daily. You cannot change this scheduled time.

What are the take-aways?

1. Be prepared for an occasional long running DELETE statement. Ensure you have sufficient transaction log space to accommodate the potential transaction log growth.
2. Don't schedule any other timer jobs or database maintenance for 10:00 PM to minimize possible deadlocks and transaction timeouts.
3. Be careful using stsadm -o profilechangelog to reduce the number of days of history, because the next time 10:00 PM comes, MOSS will try to delete multiple days of history all at once.

SharePoint Database Log File Cancer

jimmiet — Tue, 18 Mar 2008 01:30:00 GMT

SharePoint Database Log File Cancer

The database log files can grow like cancer, consuming large amounts of disk storage and impacting performance if not properly managed. This can be a particular problem for smaller deployments without dedicated DBAs or database experienced local administrators.

The underlying issue is that native SharePoint backups do not backup the log files. Content databases are created with FULL recovery model if the System Model database has the FULL recovery model specified. This results in unbounded log file growth. It is not unusual for log files to grow to several times the size of the data files before someone notices the problem or worse yet, the log file consumes all available space such that the database server no longer responds. (view entire article ... )

ULS Log File Data Mining

jimmiet — Sat, 15 Mar 2008 20:47:00 GMT

ULS Log File Data Mining

Finding meaningful information in SharePoint ULS logs is frustrating. It can be like finding a needle in a hay stack.

Assume you want to find all the Exceptions thrown in the last 72 hours. You go to the LOGS folder (but due to some categories set to verbose logging, coupled with a recurring error) to discover there are 6 GB of log files. Many of the individual log files are so large you cannot open them with Excel or Notepad. What do you do now?

Fortunately, there is a tool available that makes it possible to data mine ULS logs. This tool was originally developed to data mine IIS log files. Over the years it has been enhanced and extended to data mine other log file formats; such as, system event logs, comma separate text files, Network Monitor logs, the registry, even the file system! It is indeed the Swiss Army knife of log file data mining. It is named Log Parser, now in version 2.2. LogParser can slice-and-dice log files in a multitude of ways. It can output the results to text files, SQL Server tables, or charts. It is indeed, a great way to analyze ULS logs! (view entire article ...)