April 2015 - Posts

This is my first binary release of anything.

TinyMonitorService is exactly what is sounds like. It is a service that checks only a few characteristics associated with any computer. It checks the processor utilization, the memory utilization, and the diskspace utilization for the computer on which it is installed. Also, it reports on a subset of event logs on that computer.

The event logs that are searched are:

DNS Server
Directory Service
File Replication Service

Errors in the event logs are sent via email to a specified address. The file log-excludeditems.txt allows you to identify specific log entries that should not be sent via email. Obviously, there are a few which are so common, which are completely ignored, that one can wonder why Microsoft made the particular items errors!

TinyMonitorService began as a PowerShell script. However, the overhead associated with PowerShell is fairly high and running it as a service, while possible, is not very practical.

I had a number of clients who needed basic monitoring, but did not own a monitoring solution, and for whatever reason, could not utilize one of the other free solutions available. Initially, it was installed exclusively on Exchange Servers, but after a few enhancements, it became a good-enough solution for most servers.

Why don't I release the source? Quite frankly, I'm not happy with it. I'm somewhat embarrassed by it. The service is written in C#, almost a line-for-line translation of the PowerShell script, plus the things that are necessary to create a Windows service (which came from MSDN). It's pretty damn ugly.

Expand the contents of TinyMonitorService.zip into C:\TinyMonitorService. Then execute the configuration PowerShell script in that folder:

powershell.exe -file TinyMonitorConfig-v2.ps1

After you have done this, create the service as described in ReadMe.txt in that folder.

If you have questions, please email me.

Please follow me at @essentialexch on Twitter.

In January 2010 I wrote a blog post Where oh where, did my AD site go...[Alternate title: It's the DNS, stupid.]. In that blog post I discussed a situation where an incorrect DC locator record could cause a server to report itself as a member of an improper Active Directory site. That can cause a number of issues with Exchange.

I am in the process of migrating that same customer to Exchange 2013 (the prior blog post was written when migrating a particular customer to Exchange 2010).

The first Exchange 2013 server was brought online after the OS was installed. I went through the normal process of installing Exchange 2013 role and feature pre-requisites, installed Ucma 4.0, etc. etc. When it came time to do the first actual step in installing Exchange 2013, PrepareSchema, setup.exe reported that the Schema Master FSMO was not in the same Active Directory site as the computer running setup.


Of course it was. I know this requirement and made certain it was satisfied! The Schema Master FSMO was in the AD site named "10-129-59". The new server was in the same subnet.

However, when executing "nltest /dsgetsite", nltest reported that the AD site was "Default-First-Site-Name". Uh, wow.

I immediately reviewed AD Sites and Services to ensure that AD Subnets and AD Sites were properly configured. Indeed, they were. Next, I reviewed the customer's DNS, in detail, as described in the above blog post. The DNS was correct.

Finally, with little hope of success, I tried resetting the secure channel to the proper FSMO DC. That succeeded.

So, I rebooted. After the reboot, the secure channel was again reset to a DC in "Default-First-Site-Name". OK, I tried the same thing again (resetting the secure channel and then rebooting) with no change in behavior.

No need to try a third time. That would meet a classical definition of insanity. :)

I spent a limited amount of time investigating the particular reasons for why this should occur. But when it comes down to it, as a consultant, my job is to accomplish this project. So, I went out to find ways to ensure that a particular computer is a member of a particular AD site.

It turns out to be pretty simple. You must set a registry value for this key:


The value is called SiteName and is of type REG_SZ (the name is case sensitive).

In my case, I set SiteName to "10-129-59" and closed regedit.exe (of course you can set this value in many ways - you can use PowerShell, .NET, Win32, reg.exe - whatever you wish to use). Documentation says that restarting the NetLogon service should correct everything, but that is not my experience. After rebooting the server, the computer came up in the proper AD site and I was able to proceed with installing Exchange Server 2013.

Follow me on Twitter: @essentialexch