Lingering entries for long-deleted servers

I might just serve to be the recorder of small details about Exchange Server. Certainly that's how I feel from time to time. In this case, we have lingering entries for long-deleted servers persisting in the system registry. It's the kind of small but irritating bug that should be easy to fix but is often overlooked because of a lack of time and the need to fix other more important bugs. But if you don't highlight this kind of stuff, it will never be fixed. At least, that's the theory.

Another post that's a whinge about something that really should be fixed in Exchange 2013. The kind of detail that is often overlooked but should be cleaned up to improve the fit and finish of the product, just like the irritating event 6002 (which I believe is fixed in an upcoming cumulative update) or the persistent disk space checker. The stuff that testing never turns up because no one ever looks at these kind of things, the minutiae that seems totally unimportant but mounts up when taken as a whole.

In this case, it’s some lingering debris that Exchange 2013 leaves behind when a server is removed from an organization. No error is observed when Setup removes the server and all seems well but someone forgot that Managed Availability is a picky component that insists on keeping a close eye on everything that could cause problems for an Exchange 2013 server, including its companion servers. And the system registry seems like a good place to store information about those servers.

After a server is removed, its reference is kept in the system registry at HKLM\Software\Microsoft\ExchangeServer\V15\ActiveMonitoring\Subjects. If you look at the screen shot, you’ll see mention of a server called ExServer3.contoso.com. I removed this server some months ago, which accounts for the date and time that’s reported alongside its name. I assume that this is the date and time that the now-removed server was last contactable.

You can certainly argue that this is a very small detail and a lingering remnant of a long-departed server is of no great import. I agree that it is a small detail, but small details can rapidly grow if alerts are flagged that draw administrator attention away from more important work.

Managed Availability worries about the server that it can’t contact in the same way that a mother goose worries about a gosling that can’t been seen. All sorts of horrible things might have happened to the server. And where a goose cackles to express its alarm, Managed Availability writes events into its logs and signals errors to SCOM and any other management reporting framework that might care to listen. You rapidly learn to disregard the warnings but they shouldn’t happen and like the boy who cried “wolf”, encouraging people to ignore warnings can lead to complications when real problems occur.

On the surface this looks like an easy problem to fix. It means that Setup has to inform the other servers in an organization when one of their kind has been removed. Or maybe Managed Availability should make that decision itself by running Get-ExchangeServer to discover whether a problematic server still exists in the organization configuration and if not, Managed Availability can remove the bad value from the system registry.

The problem persists in Exchange 2013 CU5. I hope that it is fixed soon but I am not holding my breath. Too many other things might get in the way between the desire to fix and the ability to execute the fix. It’s just what happens when bugs are assessed in the context of very large software products.

 Follow Tony @12Knocksinna

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×