Haiku #145

  • Article

We can't tell you how

Happy we are to be back.

Import update rules.

 

You know what's great about coming back to work after a three-day weekend? Well, don't feel bad; we couldn't think of anything, either. Let's see, over the three-day weekend we ate things like teriyaki chicken and pork skewers; now that we're back at work we'll be eating … other stuff. Over the three-day weekend we took a long, relaxing walk by the river, and an even longer and more relaxing bike ride through the Valley; now that we're back at work, we'll be … working …. Over the three-day weekend, we – well, never mind. This is way too depressing.

 

On the bright side, however, the next three-day weekend – Labor Day – is now only two months away.

 

Sigh.

 

If there is anything good about being back to work again it's this: the chance to once more talk about Lync Server PowerShell cmdlets. (It's hard to believe, but the subject hardly ever comes up at home.) Today's subject? The Import-CsDeviceUpdate cmdlet.

 

Note to author. Wait until the applause dies down before continuing with today's article.

 

In case you're wondering, Import-CsDeviceUpdate does only one thing, but it's an important thing: the cmdlet is used to import device update rules to Lync Server. What are device update rules, you ask? Well, device update rules represent firmware updates for devices that run Lync 2010 Phone Edition. After these rules have been imported, administrators can test the updates and then, if all goes well, make the updates available to all the relevant devices used in the organization. Which simply means this: device update rules provide a way for you to automatically update all the Lync 2010 devices being used by anyone in your organization.

 

Note. How does that work, you ask? (You guys sure have a lot of questions this morning, don't you?) Well, each time you turn on a Lync device that device contacts Lync Server and checks to see if there are any new updates. In addition to that, devices check for updates every 24 hours after that initial sign-on; that way, if you turn your phone on and never turn it off, you'll still be able to get any new updates.

 

So how do you get hold of all these new device updates and, equally important, how do you copy them to Lync Server? Well, to begin with, the only way to get device updates is to download them from the Microsoft Downloads Center. At this point in time, there are three different sets of device updates available to you:

 

· Microsoft Lync 2010 Phone Edition for Aastra 6721ip and Aastra 6725ip

· Microsoft Lync 2010 Phone Edition for Polycom CX500, Polycom CX600 and Polycom CX3000

· Microsoft Lync 2010 Phone Edition for Polycom CX700 and LG-Nortel IP Phone 8540

 

Before you start downloading these files we should note that these are three different file sets; depending on the devices you use in your organization, that means that you might need to download all three sets of device updates. That's fine, as long as you keep in mind that all three of these downloads have the same file name: UCUpdates.exe. That's not a huge problem, but it does mean that you'll need to keep track of which file is which when it comes time to import to Lync Server the device update rules contained in each file.

 

Note. Why do all the files have the same name? Well, we assume that's because it makes it easier for Import-CsDeviceUpdate to work with those files. On the other hand, UCUpdates.exe is a pretty catchy little name. Maybe we gave all the files the same name simply because we liked the name so much.

 

After you have downloaded all the copies of UCUpdates.exe that you need, your next step is to run those executable files and extract the file UCUpdates.cab to a local folder (for example, C:\Updates) or a shared folder (e.g., \\atl-fs-001\Public\Updates). After you've done that, you can then use Import-CsDeviceUpdate to import the device update rules to one of your Web servers. That's something you can do using a command like this one:

 

Import-CsDeviceUpdate -Identity "service:WebServer:atl-cs-001.litwareinc.com" -Filename C:\Updates\UCUpdates.cab

 

Obviously that command assumes that UCUpdates.cab has been extracted to a folder on the local computer. If the file has been extracted to a shared folder on a remote computer, use a command like this one:

 

Import-CsDeviceUpdate -Identity "service:WebServer:atl-cs-001.litwareinc.com" -FileName \\atl-fs-001\Public\Updates\UCUpdates.cab

 

That's all you need to do. If you now run the Get-CsDeviceUpdateRule cmdlet you'll see a collection of important device update rules ready for you to approve, reset, or restore:

 

Get-CsDeviceUpdateRule

 

But we'll cover those activities in a future haiku.

 

And what are you supposed to do if you have more than one Web server that needs to host these device update rules? Well, obviously, you could simply run Import-CsDeviceUpdate multiple times, each time specifying the Identity of a different Web server. Alternatively, you could run a command like this one, which retrieves a collection of all your Web servers, pipes that collection to the ForEach-Object cmdlet, then has ForEach-Object call Import-CsDeviceUpdate for each server in the collection:

 

Get-CsService -WebServer | ForEach-Object {Import-CsDeviceUpdate -Identity $_.Identity -FileName \\atl-fs-001\Public\Updates\UCUpdates.cab}

 

That's a little bit faster and easier than having to call Import-CsDeviceUpdate multiple times.

 

And that's the exciting tale of the Import-CsDeviceUpdate cmdlet! Have we mentioned how excited we are to be back to work? Now you know why.