Haiku #163
Who needs doughnuts when
You have diagnostic logs?
You mean besides us?
Today is Friday, July 29, 2011, a date that will live in infamy. Why? Well, several weeks ago the author of today's haiku was in a fast food restaurant when he saw a poster that read like this:
Come Celebrate National Doughnut Day with Us!
July 30, 2011
Needless to say, that sparked his interest. After all, here was a major holiday – a day devoted to doughnuts, for crying out loud – and he had never even heard of it. As you might expect, the author of today's haiku took a careful look at the poster, and memorized the date of National Doughnut Day: July 30.
Is it possible that the author of today's haiku made a mistake and got the date wrong? No. After all, when it comes to major holidays, people never get the date wrong. The Fourth of July always comes on July 4th. Christmas always comes on December 25th. Easter always comes on the first Sunday following the first full moon following the vernal equinox.
Note. Incidentally, that last part, the one about Easter, is not only true, but the author of today's haiku didn't have to look it up: he actually knows when Easter comes. As it turns out, he's only half as dumb as he looks.
So there.
At any rate, there really is a National Doughnut Day: it was started in 1938 by the Salvation Army in order to serve as both a fund raiser and to honor the Salvation Army volunteers who handed out doughnuts to soldiers on the front lines during World War I. In fact, the only thing wrong with National doughnut Day is this: it doesn't actually fall on July 30th after all. Instead, National Doughnut Day comes on the first Friday in June every year. The fast food restaurant was wrong (!) and, as a result, the author of today's haiku missed National Doughnut Day by nearly two months.
So is today, the day when he discovered the real date for National Doughnut Day, the worst day of his life? Yes, without a doubt.
In case you're wondering, the author of today's haiku was planning to celebrate National Doughnut Day by trying out some of the more … unusual … flavors of doughnuts that, for some reason, have been created. Without doing much research he was able to uncover some … interesting … doughnut flavors, such as:
· Habanero pepper jelly
· Garlic glazed
· Wasabi and seaweed
· Hibiscus
· Pork floss
Pork floss, by the way, is "… a dried meat product that has a light and fluffy texture similar to coarse cotton." And yes, based on that description, a dental floss doughnut would probably be just as good.
Plus you wouldn't have to brush your teeth afterwards!
At any rate, the author of today's haiku is feeling a bit depressed today. And when he's down in the dumps, there's only one thing that can cheer him up: doughnuts. But seeing as how he doesn't actually have any doughnuts today, he decided to talk about the CsDiagnosticConfiguration cmdlets (Get-CsDiagnosticConfiguration, New-CsDiagnosticConfiguration, Remove-CsDiagnosticConfiguration, and Set-CsDiagnosticConfiguration).
As you might have guessed, the CsDiagnosticConfiguration cmdlets are used to manage your diagnostic configuration settings in Microsoft Lync Server. Which leads to one obvious question: what in the world are diagnostic configuration settings? Well, if you enable logging in Lync Server then, by default, any traffic traveling to or from any domain or URI is included in the log files. Makes sense, right?
Right. Unless, of course, it doesn't make sense. After all, in some organizations, that could result in your logs being filled with tons of information that you don't really care about. For example, suppose you're having problems with traffic involving one particular domain. In a case like that, you might want to log only traffic to and from that domain. That way, you can look through the logs and – with any luck –- pinpoint the problem, all without having to weed through information logged from every other domain you communicate with.
That's where the diagnostic configuration settings come in. These settings allow you to specify a list of domains/URIs that will be logged; if such a list exists, then only the information about the traffic flowing to and from the domains shown on that list will end up in the log files.
Well, that should just about wrap things up for – oh, good point: how do you add domains/URIs to a collection of diagnostic configuration settings? Well, as it turns out, to do this you need to create a diagnostic filter for the domain/URI and then add that item to the diagnostic configuration settings. For example, here's how we can add fabrikam.com to the global diagnostic configuration settings:
$x = New-CsDiagnosticsFilter -Fqdn " *. fabrikam.com" -Enabled $True
Set-CsDiagnosticConfiguration -Identity global -Filter $x
As you can see, there's nothing too terribly difficult about this. We start off by using the New-CsDiagnosticsFilter cmdlet to set *.fabrikam.com as the fully qualified domain name of the domain to be included in the log files. (Why *.fabrikam.com? See haiku #114 for details.) In addition, we set the Enabled property to True; otherwise our new filter would exist, but wouldn't actually do anything. And then, finally, we use this command to set the Filter property of the global settings to, well, our new filter:
Set-CsDiagnosticConfiguration -Identity global -Filter $x
That's not too bad, right? Now, what it you want to add a second domain to that filter? Admittedly, the method for doing that is a bit clunky, but it works:
$x = (Get-CsDiagnosticConfiguration -Identity global).Filter
$x.Fqdn.Add("*.contoso.com")
Set-CsDiagnosticConfiguration -Identity global -Filter $x
As you can see, what we need to do here is first use the Get-CsDiagnosticConfiguration cmdlet to create an object reference ($x) to the global settings. Note that we enclose the call to Get-CsDiagnosticConfiguration in parentheses and then tack on .Filter:
$x = (Get-CsDiagnosticConfiguration -Identity global).Filter
Why do we do that? That's easy: that way we can retrieve just the Filter property, which is the only property we care about right now.
After that, we use the Add method to add *.contoso.com to the collection of filters, then use the Set-CsDiagnosticConfiguration cmdlet to write these changes back to Lync Server.
What will that do? That will give us a collection of diagnostic configuration settings that look like this:
Fqdn : {*.fabrikam.com, *.contoso.com}
Uri : {}
Enabled : True
ExcludeRegisterMessages : False
ExcludeConferenceMessages : False
ExcludePresenceNotifications : False
ExcludeSubscriberMessages : False
Incidentally, if you run the command Get-CsDiagnosticConfiguration without any parameters you'll get output that looks like this:
Identity : global
Filter : Fqdn=IList<System.String>;Uri=IList<System.String>;Enabled=
True;ExcludeRegisterMessages=False;
ExcludeConferenceMessages=False;ExcludePresenceNotifications=
False;ExcludeSubscriberMessages=False
LoggingShare :
And yes, that does look like you've had one too many wasabi and seaweed doughnuts, doesn't it?
Note. For those of you who like to keep track of this sort of thing, one wasabi and seaweed doughnut would be one too many.
If you'd like to actually see the domains/URIs that are included in your filter, you need to run this command instead:
Get-CsDiagnosticConfiguration | Select-Object –ExpandProperty Filter
That will give you output like this:
Fqdn : {*.fabrikam.com, *.contoso.com}
Uri : {}
Enabled : True
ExcludeRegisterMessages : False
ExcludeConferenceMessages : False
ExcludePresenceNotifications : False
ExcludeSubscriberMessages : False
And what if you have a whole bunch of domains included in the Fqdn property, and they end up being truncated onscreen like this:
Fqdn : {*.fabrikam.com, *.contoso.com, "*.wing...}
First of all, don't panic. Second of all, run this command:
Get-CsDiagnosticConfiguration | Select-Object –ExpandProperty Filter | Select-Object –ExpandProperty Fqdn
That will show you your list of domains:
*.fabrikam.com
*.contoso.com
*.wingtiptoys.com
*.northwindtraders.com
*.cpandl.com
*.alpineskihouse.com
Etc., etc.
Ah, another good question: How can you enable logging for every domain except contoso.com? Well, the truth is, you can't: the Enabled property enables (or disables) all the domains and URIs included in the Filter. But that's OK. If you don't want to log data for contoso.com then just remove contoso.com from the filter:
$x = (Get-CsDiagnosticConfiguration -Identity global).Filter
$x.Fqdn.Remove("*.contoso.com")
Set-CsDiagnosticConfiguration -Identity global -Filter $x
See? A little clunky, but no doubt you've seen far, far worse, right?
As we've already seen, you can use the Get-CsDiagnosticConfiguration cmdlet to retrieve information about your diagnostic configuration settings. If you so desire, you can also use the New-CsDiagnosticConfiguration cmdlet to create a new collection of settings at the site scope. For example:
$x = New-CsDiagnosticsFilter -Fqdn fabrikam.com -Enabled $True
New-CsDiagnosticConfiguration -Identity site:Redmond -Filter $x
And if you no longer need a separate collection for the Redmond site? Then it's Remove-CsDiagnosticConfiguration to the rescue:
Remove-CsDiagnosticConfiguration -Identity site:Redmond
All in all, not so bad.
That's all we have for today. If any of you out there were also under the delusion that tomorrow would be National Doughnut Day, well, we apologize for being the bearers of bad news. But look on the bright side: July 30th is both Independence Day in the country of Vanuatu and the 592nd anniversary of the First Defenestration of Prague. So, all things considered, it should be a pretty fun weekend anyway.
See you on Monday.