Haiku #114
The sun is shining,
The birds are singing, all the
Domains are logging.
We have to admit that it was hard to sit down and write today's haiku: for the next 48 hours, all of us here in the Seattle area will be on pins and needles.
Note. And at least some of will literally be on pins and needles. Microsoft really should invest in some new office furniture.
At any rate, sometime in the next 48 hours, the temperature is expected to reach 70 degrees Fahrenheit. To those of you who live in parts of the world where you get real weather (like, say, warmer temperatures in May than you get in January) that might not seem like a very big deal. Here in Seattle, however, it is a very big deal. Back on September 30, 2010 the temperature hit 70 degrees. We went the entire month of October, 2010 without hitting 70 degrees, then for some bizarre reason we hit 70 one last time on November 3, 2010. (And then, a couple weeks later, got hit with a big ice storm that practically caused Thanksgiving to be cancelled.)
And that's it: the last time we saw 70-degree weather was November 3, 2010. How long ago was that? Let's ask Windows PowerShell:
(Get-Date) - (Get-Date "11/3/2010")
Days : 197
Hours : 8
Minutes : 44
Seconds : 5
Milliseconds : 195
Ticks : 170522451955022
TotalDays : 197.363949022016
TotalHours : 4736.73477652839
TotalMinutes : 284204.086591703
TotalSeconds : 17052245.1955022
TotalMilliseconds : 17052245195.5022
Wow: 197 days ago. Or, if you prefer, 17052245195.5022 milliseconds ago. Because a blink of the eye takes about 400 milliseconds, that means that you could have sat around and blinked your eyes over 42 million times since we last had a day where the temperature hit 70 degrees.
And, thanks to the lousy weather, that's the way many of us have spent our time since November 3rd.
Of course, here at the Lync Server PowerShell blog we're doubly excited. After all, not only are we looking at the possibility of having a Spring day that vaguely resembles a Spring day, but today we're also going to talk about the New-CsDiagnosticsFilter cmdlet!
That's what we said: wow.
Note. And yes, we are aware that some people are predicting that the Rapture will occur this Saturday. However, we assume that, here in Seattle, the Rapture would be cancelled due to bad weather anyway.
Besides, seeing as how we work at Microsoft – well, never mind.
So what is a diagnostics filter? We're glad you asked that. (It was either answer a question or sit here and blink 432,000 times while we wait for the temperature to hit 70 degrees.) If you enable logging in Microsoft Lync Server 2010, the default behavior is for Lync Server to include information about traffic travelling to and from any domain or URI in those log files. Is that a bad thing? Not necessarily, no. On the other hand, however, log files have the ability to grow by leaps and bounds: in a larger organization, you can easily generate several gigabytes of log data every day. That means that, if you aren't careful about managing your log files, you could end up running out of disk space on your servers.
Which is typically not a very good idea.
That's where the notion of diagnostic filters comes in. The idea of a diagnostic filter is actually pretty simple: instead of logging information from traffic travelling to or from any domain or URI, you can tell Lync Server that you only want to log traffic involving a specific domain or URI (or a specific set of domains/URIs). For example, suppose you only care about logging traffic involving the fabrikam.com domain. How can you get Lync Server to only log information about fabrikam.com traffic? Like this:
$x = New-CsDiagnosticsFilter -Fqdn "fabrikam.com" -Enabled $True
Set-CsDiagnosticConfiguration -Identity global -Filter $x
What did we do here? Well, in the first command we used the New-CsDiagnosticsFilter cmdlet to create a new diagnostic filter for fabrikam.com; we also used the Enabled parameter to enable this new filter. Notice, too that we stored the resulting value in a variable named $x. Why? Because diagnostic filters can't live on their own: they have to be created and then added to a collection of diagnostic configuration settings (in this case, the global collection). The only way to do that is to create the filter, store that filter in a variable, and then – as shown in command 2 – assign the filter to a diagnostic configuration collection.
The command shown above limits logging to the fabrikam.com domain. Now, what happens if fabrikam.com has a bunch of subdomains: us.fabrikam.com; europe.fabrikam.com; asia.fabrikam.com; etc.? Hey, no problem: just use a wildcard character to specify any domain that ends in fabrikam.com. You know, like this:
$x = New-CsDiagnosticsFilter -Fqdn " *. fabrikam.com" -Enabled $True
Set-CsDiagnosticConfiguration -Identity global -Filter $x
Nice, huh. And if you want to add multiple domains to a filter, well, then add multiple domains to that filter (just separate each domain using a comma):
$x = New-CsDiagnosticsFilter -Fqdn "fabrikam.com","contoso.com","litwareinc.com" -Enabled $True
Set-CsDiagnosticConfiguration -Identity global -Filter $x
That's all there is to it.
Another way to limit the size of your log files is to include one or more of these optional parameters when creating a filter:
· ExcludeConferenceMessages
· ExcludePresenceNotifications
· ExcludeRegisterMessages
What these parameters do is prevent conference messages, presence notifications, and/or registration messages from being included in the log files. Do you really need to keep track of every time someone from another domain logs on or logs off? Then just set ExcludeRegisterMessages to False:
$x = New-CsDiagnosticsFilter -Fqdn "fabrikam.com" -Enabled $True –ExcludeRegisterMessages $False
Set-CsDiagnosticConfiguration -Identity global -Filter $x
Note. If you want to get technical, you don't really need to include any of those optional parameters: by default, all three of them are already set to False. Because of that, you really only have to include ExcludeRegisterMessages if you don’t want to log registration notices:
$x = New-CsDiagnosticsFilter -Fqdn "fabrikam.com" -Enabled $True –ExcludeRegisterMessages $True
Set-CsDiagnosticConfiguration -Identity global -Filter $x
Ah, good question: what do you do if you later change your mind and don’t want to have traffic to or from a given domain logged? Well, as you might have noticed, the only cmdlet in the CsDiagnosticsFilter family is New-CsDiagnosticsFilter; there is no cmdlet for removing filters. (Or for modifying filters.) So does that mean you're out of luck? Hey, it's Lync Server 2010: you're never out of luck! It just means you have to use the CsDiagnosticsConfiguration cmdlets to remove a filter:
$x = (Get-CsDiagnosticConfiguration -Identity global).Filter
$x.Fqdn.Remove("fabrikam.com")
Set-CsDiagnosticConfiguration -Identity global -Filter $x
That's something we'll discuss in more detail when we discuss the CsDiagnosticsConfiguration cmdlets.
In the meantime, it's almost 9:30 AM, and the temperature has already reached a balmy 54 degrees. Just like we said: we are sitting here on pins and needles.
See you tomorrow (assuming that our sunburn isn't so bad that we have to stay home).