Back in OCS/R2, deploying updates to your clients was a manual process. It usually worked but was not without its challenges (generally permissions-based). You plonked the Update.msp on the SE server or file share (buried somewhere like C:\Program Files\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files\OC\x32\fre\1033 or similar), then went to <pool>\ Filtering Tools \ Client Version Filter\ and added an “Allow and Upgrade” entry with a link to the “OC” folder. (It figured out the “x32\fre\1033” on its own based upon your architecture and language settings – 1033 being US English).
Lync improved upon this by using WSUS to automate the update process.
Theoretically.
So far it doesn’t seem to have eventuated.
UPDATE: May 11 2011 – it’s here!
The Lync side of it works a treat, but Lync isn’t yet showing as an option in WSUS 3.0 SP2:
If you want to set this up in Lync in anticipation of WSUS support’s arrival, just go to the Lync Control Panel \ Clients \ Client Version Policy and update the entry for “OC” to look something like the below.
Rather than revise the Global Policy, I suggest you create a policy with just a User scope and grant it to your guinea pigs. You can test with this and then roll it into full production when it’s working properly, either by granting this policy to all your users, or simply revising the Global one.
Once this has been saved, EVERY client with that policy will be prompted to update when they log in:
Alas, here’s where the wheels currently fall off: Windows Update says there’s nothing to update, and your users are stuck in this embarrassing (for you) groundhog day every time they log in. Hence why you shouldn’t apply this globally until it’s a worker.
I’ll get back to you when it’s good to go.