BizTalk Server Tips and Tricks: Moving Event Source from Application Log into a different event log with PowerShell

|  Posted: September 12, 2017  |  Categories: BizTalk Server

Continuing the season topic: “BizTalk Server Tips and Tricks” I have to say this is one of my favorites, I simply love this tip…

If you followed the old BizTalk Innovation Day’s events, that lead to the current Integrate event in London, you may remember my dear friend Tord Glad Nordahl complaining every year in his sessions about Developers writing unnecessary information Application Log. Well, I partially agree with him, I agree in the first part: you shouldn’t write custom application errors, warnings of information in the Application Log!

Moving Event Source: moving source logs to another event log

You need to realize that Application Event Log holds almost all the important information related to different aspects of BizTalk – SQL, IIS, BizTalk infrastructure and runtime problems – it is one of the main places that admins use to monitor “applications” installed on their server. This is the information that is extremely important for BizTalk Administrator in order to monitor the well-being of the platform and to diagnose problems. For that reason you don’t want to immerse the Application 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.

Instead of using the Application Log, you can use a custom log for logging your custom application (integration) errors, warnings or information., So, in this way, I really don’t care if you are using the Event Viewer to log additional information’s about your integration processes.

What the Administrator does normally in these circumstances?

They tend to ask (argue) to the developer team to change their code, that already is deployed in several (or all) the environments, for not to write in the Application log this unnecessary information…

… they tend to receive the following response, “this information is critical for us to have visibility and track the processes (feeling surprised but I have heard enough times this statement), debugging and troubleshooting and so on”.

It’s basically a stupid and unnecessary battle where I can say that no one will be defeated or victorious.

What should the Administrator do?

Changing people’s behavior is hard, but I’m not saying that you should not try. You should, but getting others to change can be impossible, or a big challenge, it will definitely take time… especially developers who will try to find a thousand excuses for explaining why such information is important.

My advice for them take back the control of your environment by easily creating or using PowerShell (let the developer by happy by writing in the Event Viewer)

With this simple script, you can easily move an Event Source to a different 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 $_

}

}

Moving Event Source: custom source logs

This way, you as an admin can take back the control of your environment and fix the developers madness.

The full script can be found and download here: BizTalk DevOps: Moving Event Source To a Different/Custom Windows Event Log

Stay tuned for new tips and tricks!

Author: Sandro Pereira

Sandro Pereira is an Azure MVP and works as an Integration 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.

One Platform Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

ServiceBus360

Azure Composite Application

Learn more

Start manage and monitor your Azure Services in minutes

One Platform - Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

One Platform - Operations, Monitoring and Analytics Software
ServiceBus360

Azure Composite Application

Learn more

Start manage and monitor your Azure Services in minutes

Back to Top