Syncronize IIS servers in a web farm to enable ETags

It’s known that on web Farm using  of eTags under IIS doesn’t work properly unless all servers are synchronized. suggests to
synchronize the ETag values on all the Web servers that are running IIS using Mdutil.exe that should be extracted from Windows CD
suggests to use iiscnfg.vbs script (with the /copy switch) to keep cluster configuration synced up, this keeps the MDETAGCHANGENUMBER synced up too.
Finally I found extended recommendations how to synchronze IIS databases in—IIS-Settings-Replication.aspx
It has customized MetabaseMerge.bat script, that seems the most appropriate for the job.
Alternative solution is described on codeProject Synchronize file date time on multiple IIS servers and fix ETag discrepency

How to disable messages for category based on severity in EnterpriseLibrary logging configuration

Microsoft documentation article Source Schema for the Logging Application Block is very hard to follow,the set of articles is much better

Finally I found Log Event to Listener Routing in Enterprise Library   article, that very clear described available options , how to disable/enable logging

There are three Filters provided out of the box including a LogEnabledFilter which is a very effective way of short-circuiting the processing of all events, if you want logging turned off entirely. There’s also a CategoryFilter and PriorityFilter provided, but it’s easy enough to write your own.

In the example configuration
<add switchValue=”Critical name=”MyCategory”>
<add name=”EventLogTraceListener” />
I can specify switchValue   to Critical to ignore not important messages

The following switchValue settings can be used:

  • Activity Tracing. Allows the Stop, Start, Suspend, Transfer, and Resume events through.
  • All. Allows all events through.
  • Critical. Allows only Critical events through. A critical event is a fatal error or application crash.
  • Error. Allows Critical and Error events through. An Error event is a recoverable error.
  • Information. Allows Critical, Error, Warning, and Information events through. An information event is an informational message.
  • Off. Does not allow any events through.
  • Verbose. Allows Critical, Error, Warning, Information, and Verbose events through. A Verbose event is a debugging trace.
  • Warning. Allows Critical, Error, and Warning events through. A Warning event is a non-critical problem.

The article  Log Event to Listener Routing in Enterprise Library  also describes notProcessed  special source.

  • notProcessed – any event not picked up by the other sources because there was no matching category will be redirected to this source (if any listeners are specified). Note that notProcessed events do not include filtered events (LogFilters) or events that matched a category but weren’t processed due to the switchValue/severity.

Note that most of examples in the Internet do not specify listener element as a child of notProcessed element, but it’s critical to ensure that some categories are not missed completely.
<notProcessed switchValue=”All” name=”Unprocessed Category”>
<add name=”MailListener” />

A StackOverflow answer pointed me to the ShouldLog method of LogWriter and  Walkthrough: Checking Filter Status Before Constructing Log Messages:

If you want to check configuraton settings from the code, see

Consider to create a facade class to the Logging Block as suggested in the answer to pattern for logging using enterprise library

My related previous post: Logging application block-how configure different listeners for different level of message.

Javascript coding style recommendation: in return and throw statements use only simple variables

My collegue told me that placing the opening curly brace at the end of the line  is safer than at the beginning of the new line, because it prevents some hard-to-debug errors, related to Automatic Semicolon Insertion and  pointed me to the article Basic JavaScript Part 6: Automatic Semicolon Insertion. The article has the recommendation
 Trying to outline curly braces at the end of the line can save you some headaches in case a semicolon is forgotten somewhere in the code.
The statement  is misleading and even incorrect(the problem unrelated to forgotten semicolon).
The article has comments of Elijah Manor with link to JavaScript Semicolon Insertion, that properly explains the issue.

An Expression in a return or throw statement should start on the same line as the return or throw token. A postfix ++ or operator should appear on the same line as its operand. A Identifier in a break or continue statement should be on the same line as the break or continue token.

I really prefer C# style of block notation where new block starts  with curly bracket on a new line and apply it to JavaScript code as well.(You need to untick default setting for curly brackets in Visual Studio Tools->Options-Click Text Editor -> JavaScript  -> Formatting and it should be consistent for all development team).
The restriction above can be avoided by the following coding recommendation.
In return and throw statement use only simple variables and keep them on the same line as the statement:

var ret =


       shoeSize: 48

return ret;

   return   //WRONG

 shoeSize: 48