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:




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.


Note. Seeing as how you asked, a particle beam weapon " … ionizes hydrogen gas by either stripping an electron off of each hydrogen atom, or by allowing each hydrogen atom to capture an extra electron …. Cyclotron particle accelerators, linear particle accelerators, and synchrotron particle accelerators can accelerate positively charged hydrogen ions until their velocity approaches the speed of light, and each individual ion has a kinetic energy range of 100 MeV to 1000 MeV or more."


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.




Note. This is also our less-than-subtle way of pointing out that it's currently 52 degrees Fahrenheit and raining here in the Seattle area.


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"}


Note. Please consult your physician before trying anything as exciting as our previous command.


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.