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