FIM is a complex product. Once a while, I find myself just clueless why something does not work. I have the advantage of having access to the source code and be able to debug. Attaching a debugger isn't a 5-second task and very often the answer is actually in the log. In this blog post, I would talk about how to enable tracing.
Warning: you should always backup your config file before making any change.
Let's start with the easiest - Password Reset Client.
The following is the config file for the client at C:\Program Files\Microsoft Forefront Identity Manager\2010\Password Reset Client Service\PwdMgmtProxy.exe.config.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section
name="resourceManagementClient"
type="Microsoft.ResourceManagement.WebServices.Client.ResourceManagementClientSection, Microsoft.ResourceManagement"/>
</configSections>
<resourceManagementClient
resourceManagementServiceBaseAddress="http://localhost:5725"
timeoutInMilliseconds="60000" />
<appSettings>
<add key="NamedPipeTimeout" value="10000"/>
</appSettings>
<!--
<system.diagnostics>
<sources>
<source name="Microsoft.ResourceManagement" switchValue="Warning">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add initializeData="C:\Logs\PwdMgmtProxy.svclog"
type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ResourceManagementListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
<filter type="" />
</add>
<add initializeData="Application" type="System.Diagnostics.EventLogTraceListener"
name="myEventListener">
<filter type="System.Diagnostics.EventTypeFilter" initializeData="Error" />
</add>
<add type="System.Diagnostics.ConsoleTraceListener" name="myConsoleListener"
traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
<filter type="System.Diagnostics.EventTypeFilter" initializeData="Information" />
</add>
</listeners>
</source>
</sources>
<trace autoflush="true" indentsize="0" />
</system.diagnostics>
-->
</configuration>FIM uses standard .NET Tracing and Instrumenting libraries. I have highlighted a few important things in the config file:
- The entire <system.diagnostics>...<system.diagnostics> is commented out. You will need to un-comment that.
- The managed part of FIM (FIMService / FIMPortal / Pwd Reset Client) shares the same tracing library and all traces are written to a source Microsoft.ResourceManagement. You should not change this part.
- The Warning switch means for all FIM specific traces, only traces of warning level and above will be considered. Notice nothing has been logged so far.
- For those traces that are being considered, they will be passed to each of the listeners:
- The XmlWriterTraceListener will write all the traces to the file C:\Logs\PwdMgmtProxy.svclog.
- The EventLogTraceListener will further filter only trace with Error level and above, and write them to event log.
So to enable tracing for Password Reset Client, you will need to:
- Uncomment <system.diagnostics>...<system.diagnostics>
- Change Warning to Verbose
- If you want everything to be written to event log as well, change Error to Verbose as well
- Create C:\Logs and grant NETWORK SERVICE full access on that folder so the file can be created.
- Restart FIMPasswordReset service
FIMService and FIMPortal are really the same
The FIMService config file already contains inline comment on how to enable tracing. You can follow those steps.
If you want to log everything, you can replace t<system.diagnostics> section with the following. Warning, the trace file gets really huge.
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging" switchValue="ActivityTracing">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add name="ServiceModelMessageLoggingListener">
<filter type="" />
</add>
</listeners>
</source>
<source name="System.ServiceModel" switchValue="Critical,ActivityTracing"
propagateActivity="true">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add name="ServiceModelTraceListener">
<filter type="" />
</add>
</listeners>
</source>
<source name="Microsoft.ResourceManagement" switchValue="Verbose,ActivityTracing">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add name="ServiceModelTraceListener">
<filter type="" />
</add>
</listeners>
</source>
</sources>
<sharedListeners>
<add initializeData="C:\Logs\Microsoft.ResourceManagement.Service_messages.svclog"
type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ServiceModelMessageLoggingListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
<filter type="" />
</add>
<add initializeData="C:\Logs\Microsoft.ResourceManagement.Service_tracelog.svclog"
type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ServiceModelTraceListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
<filter type="" />
</add>
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>For FIMPortal, you need to change the highlighted filename to something else. For example, use:
- ILMPortal.Client_messages.svclog
- ILMPortal.Client_tracelog.svclog
The *_tracelog.svclog contains all the FIM specific traces instrumented by the FIM team (you will spend 99% of your time with this file). On the other hand, *_messages.svclog contains WCF specific traces.
How to Get Rid of the Generic FIMPortal Error Page?
When there is an error in FIMPortal, you will see the follow screen which absolutely contains no useful information at all.
Thomas Vuylsteke has blogged about how to get rid of hat to get a full stack trace which is usually enough for you to troubleshoot FIMPortal issues.
