Haiku #88

I don't really want

All these files. If only I

Could get rid of them ....

Before we do anything else we should probably let you know that the author of today's Lync Server PowerShell haiku is having a little problem keeping focused on his work. After all, yesterday he got a new lawnmower, and the excitement still hasn't died down. Needless to say, yesterday was one of the three best days in his entire life.

Note. Sadly, that's true: getting a new lawnmower did make yesterday one of the three best days of his life. But you want to know something really sad? Last night his wife actually dreamt about lawnmowers. Interesting ….

Now, you might think that getting a new lawnmower – especially one that comes with Personal Pace® self-propel, Bag on Demand, and washout port for easy cleaning – would make yesterday the best day of his life. On the other hand, last summer he did get a new wheelbarrow; that's pretty hard to top. And as if that wasn't enough, 2010 was also the year that the Lync Server team released the Clear-CsDeviceUpdateLog cmdlet. As you might expect, that was, hands-down, the absolute best day of his life.

Note. Did his wife dream about the Clear-CsDeviceUpdateLog cmdlet, too? Good question. We assume she did, but we'll double-check that for you.

So what is it that makes the Clear-CsDeviceUpdateLog cmdlet so exciting? Well, to explain what's so cool about the Clear-CsDeviceUpdateLog cmdlet, let's first talk a little bit about the device update service itself. As you probably know, the device update service provides a way for administrators to deliver firmware updates to all the phones in the organization running Lync Phone edition. In addition to handing out these updates, however, the service also maintains an extensive collection of log files. What kind of log files? Well, among other things, the service keeps both its own audit logs conducted and log files uploaded from client devices such as cell phones. It's pretty cool, because it provides a veritable treasure chest of troubleshooting and diagnostic information.

Note. And, just maybe, the next version of the device update service will include Personal Pace® self-propel, Bag on Demand, and washout port for easy cleaning, too. Keep your fingers, crossed, huh?

The good news is that the device update service maintains an extensive collection of log files. The bad news? The device update service maintains an extensive collection of log files. After all, depending on the amount of device update activity, and depending on the number of client devices used in your organization, your server could soon begin to overflow with collected log files. You need a quick and easy way to periodically get rid of the log files you no longer need.

Hence the Clear-CsDeviceUpdateLog cmdlet. This cmdlet provides a way for you to configure the device update service to automatically reduce the number of log files stored on the server: all you have to do is run the cmdlet and specify the maximum age (in days) of the files that should not be deleted. Any log files older than that maximum age will be removed from the system.

What does that mean? Well, let's assume that today is April 13, 2011. (Which, come to think of it, it is.) Suppose you've configured the device update service to remove all the log files more than 3 days old. You have the following set of files on your server:

At the end of the day (or whenever you've configured the device update service to do its log cleanup pass), you'll be left with the following files on the server:

What happened to all the other files? You got it: they were deleted because they were too old.

Note. For some reason, the author of today's haiku got a shiver up his spine when he typed that sentence about things being disposed of because they were too old.

Just like we said: a quick and easy way to automatically reduce the number of log files stored on the server.

So how do you configure the device update service using the Clear-CsDeviceUpdateLog cmdlet? Here's how:

Clear-CsDeviceUpdateLog -Identity "service:WebServer:atl-cs-001.litwareinc.com" -DaysBack 10

As you can see, there's nothing very complicated about that command: we simply call the cmdlet, taking care to tack on the Identity of the Web server running the device update service and the DaysBack parameter, which tells us how many days log files will be kept on the server. Here we set the DaysBack value to 10, meaning that log files more than 10 days old will be deleted. What if we did want to delete log files more than 3 days old? That's fine; just change the DaysBack parameter value to 3:

Clear-CsDeviceUpdateLog -Identity "service:WebServer:atl-cs-001.litwareinc.com" -DaysBack 3

Note. In case you're wondering, DaysBack can be set to any value between 0 and 30, inclusive.

If want to run this same command against all your Web servers you'll need to do so in somewhat-roundabout fashion:

Get-CsService –WebServer | ForEach-Object {Clear-CsDeviceUpdateLog –Identity $_.Identity –DaysBack 3}

As it turns out, the Clear-CsDeviceUpdateLog cmdlet can't directly accept pipelined input. Therefore, we have to retrieve all the Web servers by using the Get-CsService cmdlet (and the WebServer parameter) and then pipe that collection to the ForEach-Object cmdlet. We then ask ForEach-Object to run the Clear-CsDeviceUpdateLog cmdlet against each Web server in that collection. Like we said, it's a bit of a workaround, but it does work.

And there you have it: the Clear-CsDeviceUpdateLog cmdlet. We'd tell you more except that: 1) there really isn't anything more to tell; and, 2) we need to go around and show our coworkers pictures of our new lawnmower. See you tomorrow.