Unified Logging System (ULS) Logging

ULS logging, when implemented effectively, can provide very useful information for the following audiences.

For developers

As developers, you can take advantage of the trace log when you are developing code. Use trace logs as an extension of your development tools and as another debugging tool, to help you investigate issues. By ensuring that useful information is written to the trace log, many issues that arise in development can be resolved without attaching a debugger. Also, a tester can review trace logs to discover problems that may not be visible in the User Interface (UI), and a tester can use trace logs to verify completion of long-running tasks that may not have any UI associated with the actions.

Another advantage of ULS logging for developers is that problems encountered in the UI or notifications do not need to be displayed in the UI. Instead they can be written to the database for administrators and developers to review and analyze.

For server administrators

For an event log message to be important to the system administrator, it must contain enough information and metadata to allow the system administrator to determine what action is necessary, where the action is needed, and why the action is required. Other useful contextual information that could be included in the event log may be the user who initiated the action.Obviously, server performance and monitoring is very important to success in the enterprise environment, and ULS logging can help administrators fine tune system performance after a deployment.

For support personnel

When a problem occurs that must be solved quickly by using Microsoft Customer Support Services, ULS logs can provide in-depth information about the problem to a support group to enable faster resolution.

New-SPEnterpriseSearchIndexComponent checks the existence of RootDirectory in the wrong server

You want to add a new index component to the search topology, and want to specify a non-default root directory for the index files. For example:

New-SPEnterpriseSearchIndexComponent -SearchTopology $t -SearchServiceInstance $ssi -IndexPartition 1 -RootDirectory “”d:\index4”

The cmdlet might fail with the following error message because it incorrectly checks if the indicated root directory exists on the server the cmdlet is run on:

Cannot bind parameter ‘RootDirectory’ to the target. Exception setting “”RootDirectory””: “”Could not find a part of the path ‘d:\index4’.”

Workaround    You can create the new index component using the following procedure instead:

$host02 = (Get-SPServer”<Name of server>”).Name

$ssa = Get-SPEnterpriseSearchserviceApplication

$t = $ssa.ActiveTopology.Clone()

$ic = (New-Object Microsoft.Office.Server.Search.Administration.Topology.IndexComponent $host02,1);

$ic.RootDirectory =””d:\index4″

$t.AddComponent($ic)”