All product based on SharePoint technologies come with a built-in logging engine named Unified Logging System (ULS). It allows the applications and related component (Microsoft or third-parties) to log activity to the Windows application Event Log and/or to a log file on each server running SharePoint.

Log Location

The log files are, by default, located under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS, the file names always start with a prefix consisting in the name of the server they were generated on: <servername>-<output-format>.log.

Depending upon their configuration, some event may also be logged in the Windows Application event log.

Configuration

To change the location of the log files, the following PowerShell script can be used:

[VOID][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[VOID][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")
$SPDiagnosticsService = [Microsoft.SharePoint.Administration.SPDiagnosticsService]::Local
$SPDiagnosticsService.LogLocation = "G:\Logs\"
$SPDiagnosticsService.Update()

To change the number of log files to be maintained, you can set the “LogsToKeep” property:

Beware: as soon as the Update() method is invoked, the log files above the value specified will be deleted!

Note: this correspond to the setting stored in the registry at the following location: HKLM:\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS. You might therefore therefore be tempted to edit it directly but MS discourage to do so and recommended to use the SharePoint API instead.

To list/set the verbosity level of each component, STSADM can be used:

To list all level (including hidden ones): stsadm.exe -o listlogginglevels [-showhidden]

To set the level for a given category: stsadm.exe -o setlogginglevel   [-category < [CategoryName | Manager:CategoryName [;...]] ] {-default | -tracelevel < trace level setting> [-windowslogginglevel] <Windows event log level setting>}

More information:

• http://technet.microsoft.com/en-us/library/cc262191.aspx
• http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spdiagnosticsservice.aspx

Log File Format

The log files expose the following fields:

• Timestamp: Equivalent to the “TimeGenerated” field in the “Application” event Log
• Process: the image name of the process logging its activity followed by its process ID (PID) between parentheses. Interestingly, IIS worker processes may also log their activity, they are therefore logged under w3wp.exe
• TID
• Area: This maps the “Source” field in the “Application” event Log
• Category: this maps the “Category” field in the “Application” event Log
• EventID: A unique internal Event ID
• Level
• Message
• Correlation: may contain a link to the the EventID of another logged event

Exploitation/Analysis

There are multiple ways to analyze ULS logs, such as:

• Using the good old notepad, which is a valid option when your servers are not too busy and if you know when, where and what to look for
• Using the Swiss army knife of log files: MS LogParser, see below for examples.
• Using some interesting CodePlex projects: An extension to the Central Administration web site: http://www.codeplex.com/wssmosslogfilereader or a WinForm-based application (which also makes use of MS LogParser): http://www.codeplex.com/ShrptNinjaToolkit

Some Log Parser Queries applicable to ULS Logs

• Troubleshooting Indexing with ULS Log by Joel Oleson
• ULS Log File Data Mining
• I will also upload my own queries in a near future, so check back this location regularly

More Information

• http://msdn.microsoft.com/en-us/library/aa979590.aspx

And cut!

I was tempted to user something like 2009: IT Odyssey but gave it up in favor of a more modest (?) title: Michael Cimino’s Year of the Dragon, yet another underestimated movie ;)

Besides wishing to all our readers the very best for 2009, I wanted to share some news and comments:

First and to my great surprise and satisfaction, received an email message to inform me I am awarded a 2009 Microsoft Most Valuable Professional (MVP). Naturally, I wish to thanks Microsoft and the community for this award, needless to say that it helps keeping my motivation as high as it could be for sharing my modest knowledge and helping users and IT pro’s through communities.

Second, I was recently informed that a talented colleague of mine, the Exchange/OCS specialist “cum laude” ToninoB was reorienting his professional career in a more “standalone” manner. I am wishing him a lot of success and definitely recommend you to regularly throw an eye at his contributions on http://www.proexchange.be/. PS: Toni, do not forget winter tires with a BMW ;)

Third, we’ll start to share more massively scripting & automation resource on our site. Feel free to browse for them at the following location: http://www.marc-antho-etc.net/scripts.aspx.

finally, at least I hope so :), another “director” will start contributing very soon! Antho, who scored 100 at the 2008 Scripting Games, will bring some extra entertainment over PowerShell and Active Directory administration

And cut!

With the early days of SharePoint, changing user accounts in order to reflect user changes in Active Directory after domain migration, migration or split  was a nightmare.
With WSS2/SPS2003 and assuming you have compiled the excellent SPSUTIL tool , the situation was much better though not perfect (Anthony, the other Windows Director, suffered a lot from this in a previous job actually, who did not?).

With the WSS3/MOSS era, STSADM now comes with the built-in command “–o migrateuser” in order to do the job. So why bother turning this command into PowerShell? Simply because it greatly eases the automation since you can write custom scripts to scan AD, parse XML or CSV and finally update your SharePoint content DB’s accordingly. The code is incredibly simple, just like the command is:

First, load the assemblies as usual:
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")

Then get a farm object:
$spFarm = [Microsoft.SharePoint.Administration.SPfarm]::Local

And finally use the
$spFarm.MigrateUserAccount("OLDDOMAIN\OLDUSERNAME", "NEWDOMAIN\NEWUSERNAME", $False)

The first parameter being the original domain name and user name
The second parameter is the new domain name\user name
And the third is Boolean indicating sidhistory on the new user should be used or not.

Keep in mind that while this code will modify the “Account” attribute of a user through the farm, it will not change the “Name” attribute. %If you wish to change this name and you’re lucky enough to operate MOSS, you can rely on the profile import process (see my previous post for some Powershell automation), if, on the other hand, you run WSS3, you’ll have to go through extra code that does some iterations in all your sites and modify the contents of the list named “User Information List” in each of them. The Powershell to update the list would look like:
$spUser = $spWeb.SiteUsers["NEWDOMAIN\NEWUSERNAME"]
$spUser.Name = "NEW USER DISPLAY NAME"
$spUser.Update()

A good movie match for this post could be Face/Off directed by John Woo, the "unofficial inventor" of slow motion.

And cut!

Sometimes AD is not the preferred source for profiles information. Sometimes you feel like BDC is really a pain to configure. Sometime a colleague of yours comes with a plain CSV file which contains the perfect information in order to update your MOSS user profile information… Time for Jason to recover his identity ;)

First, let’s load the necessary assemblies:
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.Administration")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.UserProfiles")

Then instantiate the server context and the profile manager
$spSSP = [Microsoft.Office.Server.ServerContext]::GetContext(“MySSPName”)
$spUserManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($spSSP)

Note: if you have no clue about the name of the SSP, you can check in the Central Admin web site or retrieve it from an existing web application bound to it.

Now that you have a Profile manager ready, you have to create a Profile object for each profile you wish to update. Since the code would eventually fails if no profile exists, you can also test if it exists first:
$spUserManager.UserExists("THREADSTONE\jbourne")
If it result returns “True”, you can go further, if not, you can skip that user or instead, create a new profile by executing:
$spUserManager.CreateUserProfile("THREADSTONE\jbourne ")

Then instantiate a profile object for that user:
$spUserProfile = $spUserManager.GetUserProfile("THREADSTONE\jbourne ")

And populate one or more properties:
$spUserProfile["Department"].Value = "Secret Services"

If you’re clueless about the list of properties you can update, simple retrieve them with the following command:
$spUserManager.Properties|SELECT displayName,Name

Once you’re done, save the changes using the commit method (and not update()!):
$spUserProfile.Commit()

And cut!

Greets to W. N. who inspired this post ;)

A customer experienced a tricky SharePoint issue in his high-security environment.
This problem was not really related to SharePoint directly but rather to IIS, Active Directory and windows authentication in general.

But before giving out the explanation, some troubleshooting steps!
Since SharePoint did not give any clue except the usual “Unspecified error” so-called friendly message and because the issue only occurred in production, not in test (as usually!), I could not afford to disable friendly error messages the now well-known way:
1. On each WFE, backup the web.config of each web site implemented by SharePoint (except central admin and SSP of course) then edit it
2. Look for “CallStack” and replace the value False with True
3. Then look for “CustomErrors”. And set the mode to “off”
4. Save File and provoke the problem again

Instead, I could put my hands on the IIS logs, which were hopefully configured to W3C Extended with all fields enabled and start analyzing them (LogParser is your friend!).
Very strangely enough, the user could manage to be authenticated but then an internal server error occurred (HTTP 500). This error was linked to the Win32 status 0xc0000413 translated in hex, which was actually totally unknown to me. Platform SDK could shine a light on this by reporting this error as STATUS_AUTHENTICATION_FIREWALL_FAILED. Needless to say that there is no firewall running on the production boxes so what was this application firewall then?
I starting thinking about what could, at Windows-security level, impact cross-forest authentication but AFTER real authentication occurred and bingo, I found the culprit: The AD feature brought by Windows Server 2003 and named “Selective authentication”, which allows administrator to authorize or deny in a fine-grained manner security principals from other forests trusted by the forest where the server is running.
Solution was therefore simple: edit the computer account of each WFE in AD, go to the “Security” tab then grant “Allow to authenticate” to the “Domain Users” groups from the remote forest's domain.

Conclusions: even if you’re not allowed to authenticate, you get authenticated first and then everything fails with a dirty Internal Server Error if you use this security feature to protect IIS…

Talking about forests, I suggest you watch an older movie directed by John Boorman called the Emerald forest. Really worth it, for those, like me, who can stand Boorman’s style

Talking about “Selective authentication”, feel free to read Technet for additional information: http://technet.microsoft.com/en-us/library/cc738653.aspx

And cut!

PS: Thanks to Dirk T for reminding me the name of that feature!