Death rays are fun but

Device update cmdlets

Are even more fun.

No too long ago, the author of today's haiku noticed that one of the rooms in his building, a room he's walked past several times a day for the past year or so, has a big red sign on it that says this:

BEAM DETECTOR RESET CONTROL PANEL

Logically speaking (logic being the haiku author's strong suit), the fact that Microsoft has a beam detector control panel suggests that we also have a beam detector. As you might expect, the author of today's haiku has now become obsessed with figuring out what kind of beam this beam detector is designed to detect. To be honest, he has no idea. Laser beams? Maybe, but he's not sure what we would use laser beams for and why would need to detect them. Particle beams? That sounded plausible at first, but if Microsoft had perfected a particle beam death ray we probably would have heard about that. (After all, someone would be asked us to write the help for Fire-CsParticleBeamDeathRay.) So no, no death ray.

Unless we're just waiting until we've made that death ray Kinect-compatible, of course.

On the other hand, it should be pointed out that the author of today's haiku has yet to hear any warning buzzers, seen any flashing lights, or otherwise been alerted to the fact that the beam detector has actually detected something. That, and a quick glance outside his window, leads him to believe that the thing is probably a sunbeam detector and not a particle beam death ray detector after all.

Sigh.

The truth is, those of us here at Microsoft probably don't have a particle beam death ray, or even a particle beam death ray detector. But hey, no big deal. After all, we do have something way better than a particle beam death ray: we have the – tah-dah! –  CsDeviceUpdateConfiguration cmdlets!

As you might expect, the CsDeviceUpdateConfiguration cmdlets ionize hydrogen gas by either stripping an electron off of each hydrogen atom, or by allowing each hydrogen atom to capture an extra electron. In addition to that, they also help manage Lync Server's device update service. This service provides a way for administrators to distribute firmware updates to devices that run Microsoft Lync 2010 Phone Edition. As they become available, administrators upload a set of device update rules to Lync Server 2010. After the rules have been tested and approved, they can then be applied to the appropriate devices as those devices connect to the system.

In other words, a fast, simple, and effective way to keep your Lync Server-compatible devices up-to-date.

The CsDeviceUpdateConfiguration cmdlets are primarily used for managing the log files that are generated by the device update service. (See? Way more exciting than a particle beam death ray!) For example, the device update configuration settings (which can be configured at either the global scope or the site scope) are used to determine how long the device update log file is kept before it is deleted and replaced by a brand-new log file. By default, this happens every 10 days. Would you prefer to make that every 30 days? Sure; why not:

Set-CsDeviceUpdateConfiguration –Identity site:Redmond –LogCleanUpInterval 30.00:00:00

If you're wondering about the syntax used in that command, the 30 in 30.00:00:00 indicates 30 days; the remaining 00's represent hours, minutes, and seconds, respectively. You say you'd like to keep log files for 6 days, 7 hours, 19 minutes, and 11 seconds? Interesting choice, but, hey, who are we to judge:

Set-CsDeviceUpdateConfiguration –Identity site:Redmond –LogCleanUpInterval 6.07:19:11

You can also set the maximum size of a log file, the amount of time data is held in the cache before that data is actually written to the log file, etc., etc. There's also an option for managing log files types. By default, the device update service can work with the following log types:

·         Watson. Log files automatically generated by a device in the event of a system crash.

·         Config. RoundTable conferencing device profiles created any time you configure a RoundTable device.

·         DiagLog. Self-diagnostic data for RoundTable devices.

·         CELog. Logs for phones running Lync 2010. These logs contain the results of functional tests as well as a record of critical system events.

But let's suppose you buy a new phone that uses a different log file type: Fabrikam, a log file that uses the file extension .fab. Is there a way to add this new log file type (and new file extension) to the device update service? Of course there is:

Set-CsDeviceUpdateConfiguration –Identity site:Redmond –ValidLogFileTypes @{Add="Fabrikam"} –ValidLogFileExtensions @{Add=".fab"}

Admittedly, that's a somewhat-cryptic looking command, but it's actually fairly easy to understand. The syntax @{Add="Fabrikam"} simply tells Set-CsDeviceUpdateConfiguration to add Fabrikam to the list of valid log file types. What if we wanted to add Contoso to the list? That's fine; this command will do that:

Set-CsDeviceUpdateConfiguration –Identity site:Redmond –ValidLogFileTypes @{Add="Contoso"} –ValidLogFileExtensions @{Add=".con"}

And if you want to really impress your friends, try adding both file types at the same time:

Set-CsDeviceUpdateConfiguration –Identity site:Redmond –ValidLogFileTypes @{Add="Fabrikam","Contoso"} –ValidLogFileExtensions @{Add=".fab",".con"}

And what if you change your mind and decide that you don't want Fabrikam to be a valid log file type (nor do you want .fab to be a valid file extension)? No problem; just remove them from this list:

Set-CsDeviceUpdateConfiguration –Identity site:Redmond –ValidLogFileTypes @{Remove="Fabrikam"} –ValidLogFileExtensions @{Remove=".fab"}

Pretty exciting, huh? And, of course, you can always use New-CsDeviceUpdateConfiguration to create new settings at the site scope; you can use Remove-CsDeviceUpdateConfiguration to remove settings configured at the site scope; and you can use Get-CsDeviceUpdateConfiguration to retrieve information about your device update configuration settings. We still think a particle beam death ray would come in handy from time-to-time, but the CsDeviceUpdateConfiguration cmdlets do made a pretty good consolation prize.

See you tomorrow.

If there's one thing you can say about those of us here at the Lync Server PowerShell blog (yes, we know: there probably are lots of things you can say about those of here at the Lync Server PowerShell blog) it's this: we're too dumb to know any better. Which, oddly enough, is actually a good thing.

Or at least that's what we keep telling ourselves.

For example, take the Lync Server PowerShell One of These Things is Not Like the Others challenge. When we started the challenge back in January, we were well aware that – as a recently-released piece of software – there were probably more people who don't use Lync Server than who do use Lync Server. Furthermore, we knew that only a small subset of people who did have the software up and running were using Windows PowerShell to manage that software. Based on that, anyone with even the least bit of intelligence would have said, "It's too early to start having a weekly contest devoted to Lync Server PowerShell."

Fortunately, though, intelligence has nothing to do with those of us here at the Lync Server PowerShell blog. We went ahead and started the weekly challenge anyway, and we were both gratified and surprised to see how many people decided to play along. To all of you who took the time to participate in the weekly challenge, thank you. And to those of you who didn’t participate in the weekly challenge, well, we know who you are. And one of these days, when you least it expect it, there will be a knock on your door ….

Anyway, once again we'd like to thank everyone who participated in the challenge. We'd also like to take a moment and give you the answer to challenge number 20. As you no doubt recall, last week we presented you with the following list of Lync Server PowerShell cmdlets and asked you which of these cmdlets was not like the others:

As it turned out, the final vote was unanimous: everyone opted for New-CsVoiceRegEx. Why? There were actually several reasons. For one thing, it's the only one of the cmdlets that doesn't have an Identity parameter.

As Tom A., David M., and Ramkumar R. all pointed out, New-CsVoiceRegeEx is also the only cmdlet that doesn't make a change to the system. Set-CsVoiceNormalizationRule and Set-CsOutboundTranslationRule both change existing Lync Server objects; New-CsSipResponseCodeTranslationRule creates a brand-new Lync Server object. But New-CsVoiceRegEx merely creates an in-memory-only object that must then be added to an actual Lync Server object (i.e., a voice normalization rule). Did we realize that when we published this challenge? Well, we realize it now ….

So is New-CsVoiceRegex the solution that we had in mind? Actually, it's not: we opted for New-CsSipResponseCodeTranslationRule. Why? Well, the other three cmdlets all deal with regular expressions and voice normalization rules. By contrast, New-CsSipResponseCodeTranslationRule deals with translating SIP response codes and ISDN User Part cause codes. But hey: you say potato, we say  New-CsSipResponseCodeTranslationRule. It's all good, right?

Right.

Thanks again for taking part in the challenge over the past few months. Will there be a replacement challenge sometime in the future? Well, never say never, right? We'll just have to see how things play out. In the meantime, a warning to Tom A.: one of these days, when you least it expect it, there will be a knock on your door. When there is, just hand us the free beer you offered us and we'll promise to go away and never bother you again.

Challenge Home

We figured that this week’s challenge was an easy one, but so far we’ve gotten at least one email from someone saying, “I don’t think this week’s challenge is an easy one at all.” Is it possible that we were wrong about something?

You’re right: that’s totally impossible. But, just in case, here’s a little hint that should help you solve the challenge:

"In the context of metadata and information retrieval, normalization is the process of converting text to a standard form so that the computer can then process the text consistently and use it in the information searching and retrieval process."

No, that really is the hint. And no, it’s not possible that we’re wrong about that.

Or at least we don’t think it’s possible.

Challenge Home

Here’s an article for everyone. Well, everyone who wants to know how to use Windows PowerShell to work with performance counters. In How Do We Love Performance Counters? Let Us Count the Ways, you’ll learn how to retrieve information about and monitor your performance counters.

The examples use Lync Server performance counters (this is the Lync Server PowerShell blog, after all), but you could substitute any performance counters. The number of ways you can use these commands are countless.

http://blogs.technet.com/b/csps/archive/2011/06/02/gpsperfcounters.aspx