BizTalk Server tips and tricks for Administrators: Trying to annoy Tord – Moving an Event Source to a Different/Custom Windows Event Log

Probably this was one of the most talked-about and funny tips, and I completely forgot to publish it in my blog, despite the resources being already available for download and reference in the session slides that you can find here.

If you are familiar with the BizTalk Innovation Day or BizTalk Summit, you will all remember that at some point, my dear friend Tord Glad Nordahl complained in his session about BizTalk Developers writing unnecessary information in the Application Event Log, and because they do not use the Event Viewer. You can also check his post and his point of view about this topic: BizTalk developers + Event log = angry admins.

My goal here is not to criticize those who use the event viewer, or if there is a better way to accomplish this task (monitor/logging BizTalk application errors)… but I partially have to agree with Tord and say that… you shouldn’t write custom application errors, warnings, or information in the Application Event Log.

Many times, BizTalk developers like to write information that will help them track and debug their orchestrations, like:

• Message received.
• Message successfully transformed.
• Message sent to an external system.

And for that, they normally use the following code:

System.Diagnostics.EventLog.WriteEntry("AnnoyingTord",
               "Just an update Tord! Message successfully Transformed");

The problem with using this code is that by default, this information is being logged in the Application Event Log. You need to realize that the Application Event Log holds almost all the important information related to different aspects in BizTalk – SQL, IIS, BizTalk infrastructure, and runtime problems – it is one of the main places that admins use to monitor “applications” installed in your server/machine. And these are the information that is extremely important for BizTalk Administrator in order to monitor the well-being of the platform and to diagnose problems, and you don’t want to infest this event log with irrelevant and unnecessary information at the point to be almost impossible to find real problems – instead, you, or in this case, the admins, should keep it clean.

So I told – “I partially have to agree…” – because I think that this is unnecessary information that is being logged in the Application Event Log that doesn’t provide any additional information to BizTalk Administrators, but… instead, you can use a custom event log for logging that unnecessary information that doesn’t provide any additional information to BizTalk Administrators and in this case, I really don’t care if you are using the Event Viewer to log BizTalk application errors or tracking or debugging information (despite I don’t agree on this last part).

So you can use Event Viewer as long as you do not use the Application Event Log to write custom errors.

Building the Sample

In this sample, you will find a simple orchestration that will receive any XML message and will log some traditional tracking information that developers normally do in their orchestrations… I call this trying to annoy Tord Glad Nordahl (my friend and one of the best BizTalk administrators that I know):

What does the Admin normally do?

When facing this type of development, BizTalk Administrators normally ask the developers to change their code, not write in the application log, or to disable this type of logging/tracking. Code that is already deployed in all the environments.

However, change is hard – Getting others to change can be impossible or a big challenge – Developers will try to find a thousand excuses for explaining why such information is important!

What should the Admin do?

My advice:

• Let the developer be happy by writing in the Event Viewer
• But take back the control of your environment by easily creating or using PowerShell

With this script, you can easily move an Event Source to a different or to a Custom Windows Event Log:

foreach ($LogSource in $LogSources) {
    Remove-EventLog -Source $LogSource
} 
 
$logFileExists = Get-EventLog -list | Where-Object {$_.logdisplayname -eq $LogName}
if (! $logFileExists) {
    $LogSources | %{
        New-EventLog -LogName $LogName -Source $_
    } 
 
    # Compose Key:
    $LogPath = 'HKLM:\SYSTEM\CurrentControlSet\services\eventlog\'+$LogName;
    if(Test-Path $LogPath)
    {
        $acl = Get-Acl $LogPath
        $GpOrUsers | %{
            $ace = New-Object System.Security.AccessControl.RegistryAccessRule $_,'WriteKey, ReadKey','allow'
            $acl.AddAccessRule($ace)
            #Set-Acl $LogPath $acl
        }
    }else{Write-Error "Cannot acesss log $LogName"}
}
else {
    $LogSources | %{
        New-EventLog -LogName $LogName -Source $_
    }
}

This way, you as an admin can take back the control of your environment and fix the blunders (or foolishness) of the developers – if you are a BizTalk developer, don’t be offended, please, I’m also a BizTalk Developer.

Again, if you are a developer and you, for some reason, want to write “tracking” or error information in the Event Viewer, then you should start to optimize your code to write by default to a custom event log. You can use, for example, a similar code:

string logName = "MyCustomEventLog";
string logName = "MyProjectLogSource";

if (!System.Diagnostics.EventLog.SourceExists(logName))
{
   System.Diagnostics.EventLog.CreateEventSource(projectName, logName);
}
System.Diagnostics.EventLog.WriteEntry(projectName, genericString.ToString(), logType);

Download

THESE SAMPLES AND POWERSHELL ARE PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

You can download this BizTalk Server sample solution and PowerShell script from GitHub here:

Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son. 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira