Monthly Archives: February 2013

Finding a Host in AD by GUID

Windows Server 2003 Users and Computers allowed the specification of managed GUIDs when creating new computer objects. Any clashes in the domain would be displayed and this was my quick go-to method of tracking down duplicate GUIDs (a sometimes painful issue causing PXE boot problems).

This was removed from the default installation of this MMC snap-in on Server 2008. I believe you get it back if you install the WDS role, but I can’t do that on my Windows 7 machine. Instead, we can resort to hand-crafting LDAP queries to find any existing computer objects with our target GUID:


Be careful to get the ordering correct of the GUID correct. The presence of hyphens often means the bytes need to be reordered .

WCF Impersonation Pass-through

I wanted to call another WCF service from within my WCF service (in fact, I was calling the same service but hosted on a different machine). The function itself uses the callers identity to determine its behaviour, but the second call was arriving as the computer account on the remote machine (this is expected when the caller is running as Local System).

I used the advice from this page in order to reuse the caller’s identity.

In particular, I went with the declarative model (mostly since it was easier).

[OperationBehavior(Impersonation = ImpersonationOption.Required)]
public bool PassThroughMethod(string input)
  // Do things with the client's credentials,
  // e.g. call another service.
  return true;

Don’t forget both server code and the client need to be configure to enable impersonation.

using System.Security.Principal;
using System.ServiceModel;

// namespace and class and method setup, etc.

var channel = new ChannelFactory<IService>(
  new WSHttpBinding(),
  new EndpointAddress("http://localhost:8000/Service/service"));
channel.Credentials.Windows.AllowedImpersonationLevel =
return channel.CreateChannel();

Console Logging with Microsoft Enterprise Library

I was having some issues formatting text with the Microsoft Enterprise Library using the .NET ConsoleTraceListener class. After some doing some research, it appears that a formatter for this class cannot be specified, at least, if one is it is ignored. The output of this listener is more akin to something that should be added to the event log and not very useful as feedback to the user, say, when they use a command line application. I didn’t want to use Console.WriteLine since, to me, that would defeat the purpose of having a single logging block and output to the console is a form of logging.

This post on StackExchange came to my rescue implementing a quick and simple custom trace listener to take the message and format it using the specified text formatter. This can then be configured on the endpoint as required during the application’s life-cycle without requiring a recompile.

I simplified it a bit to remove the colour formatting since I didn’t need it, resulting in this:

using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging;
using Microsoft.Practices.EnterpriseLibrary.Logging.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners;
using System;
using System.Diagnostics;

namespace EddPorter.Blog {

  public class ConsoleTraceListener : CustomTraceListener {

    public override void TraceData(TraceEventCache eventCache,
        string source, TraceEventType eventType, int id, object data)
      if (data is LogEntry &amp;&amp; Formatter != null) {
        LogEntry le = (LogEntry)data;
      } else {

    public override void Write(string message) {

    public override void WriteLine(string message) {