Managing Agent Groups

Create an Agent Group

• To create an agent group

To create a new Response Group agent group, use the New-CsRgsAgentGroup cmdlet. This command uses the AgentsByUri parameter to add individual users to the agent group:

New-CsRgsAgentGroup -Parent service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk Group" -AgentsByUri "sip:kenmyer@litwareinc.com","sip:pilarackerman@litwareinc.com"

By comparison, this command uses the DistributionGroupAddress parameter to add all the members of the helpdesk@litwareinc.com distribution group to the agent group:

New-CsRgsAgentGroup -Parent service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk Group" -DistributionGroupAddress "helpdesk@litwareinc.com"

Change Agent Group Settings or Members

• To change agent group settings or membership

To change a Response Group agent group you must first use the Get-CsRgsAgentGroup cmdlet to retrieve an object reference to the agent group to be changed. After making your changes in memory, use the Set-CsRgsAgentGroup cmdlet to write those changes to Lync Server.

These commands change the routing method for an agent group:

$x = Get-CsRgsAgentGroup -Identity service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk"

$x.RoutingMethod = "RoundRobin"

Set-CsRgsAgentGroup -Instance $x

This set of commands changes the distribution address for an agent group:

$x = Get-CsRgsAgentGroup -Identity service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk"

$x.DistributionGroupAddress = "helpdesk@litwareinc.com"

Set-CsRgsAgentGroup -Instance $x

The following commands add a new agent to an agent group:

$x = Get-CsRgsAgentGroup -Identity service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk"

$x.AgentsByUri.Add("sip:kenmyer@litwareinc.com")

Set-CsRgsAgentGroup -Instance $x

And these commands remove an agent from an agent group:

$x = Get-CsRgsAgentGroup -Identity service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk"

$x.AgentsByUri.Remove("sip:kenmyer@litwareinc.com")

Set-CsRgsAgentGroup -Instance $x

Delete an Agent Group

• To delete an agent group

To remove a Response Group agent group, use the Remove-CsRgsAgentGroup cmdlet:

Get-CsRgsAgentGroup -Identity service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk" | Remove-CsRgsAgentGroup

This command deletes all the agent groups currently configured for use in your organization:

Get-CsRgsAgentGroup | Remove-CsRgsAgentGroup

For more information

• Haiku #12: The CsRgsAgentGroup Cmdlets

Managing Response Group Queues

Create a Response Group Queue

• To create a queue

To create a new Response Group queue, use the New-CsRgsQueue cmdlet. The following set of commands creates a new queue, and uses the New-CsRgsCallAction cmdlet to specify what should happen if the queue receives too many calls at the same time:

$x = New-CsRgsCallAction -Action TransferToVoicemailUri -Uri "sip:+14255551298@litwareinc.com"

New-CsRgsQueue -Parent service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk" -OverflowCandidate "OldestCall" -OverflowAction $x -OverflowThreshold 2

Change a Response Group Queue

• To change a queue

To modify a Response Group queue, you must first use the Get-CsRgsQueue cmdlet to retrieve an object reference to the queue to be changed. After making your changes in memory, use the Set-CsRgsQueue cmdlet to write those changes to Lync Server:

$x = Get-CsRgsQueue -Identity Service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk"

$x.OverflowCandidate = "NewestCall"

Set-CsRgsQueue -Instance $x

Delete a Response Group Queue

• To delete a queue

To delete a Response Group queue, use the Remove-CsRgsQueue cmdlet:

Get-CsRgsQueue -Identity service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk Queue" | Remove-CsRgsQueue

The following command removes all the Response Group queues configured for use in your organization:

Get-CsRgsQueue | Remove-CsRgsQueue

For more information

• Haiku #23: The CsRgsQueue Cmdlets

Managing Response Group Workflows

Create a Response Group Workflow

Create a Hunt Group Workflow

• To create a hunt group workflow

To create a hunt group workflow, use the New-CsRgsWorkflow cmdlet:

$prompt = New-CsRgsPrompt -TextToSpeechPrompt "Welcome to the help desk."

$queue = (Get-CsRgsQueue -Identity service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk").Identity

$callAction = New-CsRgsCallAction -Prompt $prompt -Action TransferToQueue -QueueId $queue

New-CsRgsWorkflow -Parent service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk" -PrimaryUri "sip:helpdesk@litwareinc.com" -DefaultAction $callAction

Create an Interactive Workflow

• To create an Interactive workflow

To create an interactive workflow, use the New-CsRgsWorkflow cmdlet:

$ServiceId = "service:ApplicationServer:rtc.contoso.com"

$Group_Sales = New-CsRgsAgentGroup -Parent $ServiceId -Name "Contoso Sales" -AgentAlertTime 20 -ParticipationPolicy Informal -RoutingMethod LongestIdle -AgentsByUri("sip:franz@contoso.com","sip:marco@contoso.com")

$Group_Support = New-CsRgsAgentGroup -Parent $ServiceId -Name "Contoso Support" -AgentAlertTime 20 -ParticipationPolicy Informal -RoutingMethod LongestIdle -AgentsByUri("sip:david@contoso.com","sip:john@contoso.com")

$Queue_Sales = New-CsRgsQueue -Parent $ServiceId -Name "Contoso Sales"

-AgentGroupIDList($Group_Sales.Identity)

$Queue_Support = New-CsRgsQueue -Parent $ServiceId -Name "Contoso Support" -AgentGroupIDList($Group_Support.Identity)

$PromptA1 = New-CsRgsPrompt -TextToSpeechPrompt "Please wait while we're connecting you with the Contoso Sales department."

$ActionA1 = New-CsRgsCallAction -Prompt $PromptA1 -Action TransferToQueue -QueueID $Queue_Sales.Identity

$Answer1 = New-CsRgsAnswer -Action $ActionA1 -DtmfResponse 1

$PromptA2 = New-CsRgsPrompt -TextToSpeechPrompt "Please wait while we're connecting you with the Contoso Support department."

$ActionA2 = New-CsRgsCallAction -Prompt $PromptA2 -Action TransferToQueue -QueueID $Queue_Support.Identity

$Answer2 = New-CsRgsAnswer -Action $ActionA2 -DtmfResponse 2

$PromptQ = New-CsRgsPrompt -TextToSpeechPrompt "Thank you for calling Contoso. To speak with a Sales representative, press 1. To be connected with our Support line, press 2."

$Question = New-CsRgsQuestion -Prompt $PromptQ -AnswerList ($Answer1, $Answer2)

$ActionWM = New-CsRgsCallAction -Action TransferToQuestion -Question $Question

$Workflow = New-CsRgsWorkflow -Parent $ServiceId -Name "Contoso Helpdesk" -Description "The Contoso Helpdesk line." -PrimaryUri "sip:helpdesk@contoso.com" -LineUri "tel:+14255554321" -DisplayNumber "+1 (425) 555-4321" -Active $true -Anonymous $true -DefaultAction $ActionWM

Change a Response Group Workflow

Change a Hunt Group Workflow

• To change settings for a hunt group workflow

To modify a hunt group workflow, use the Get-CsRgsWorkflow cmdlet to create an object reference to the workflow to be modified, make your changes in memory, and then use the Set-CsRgsWorfklow cmdlet to write those changes to Lync Server:

$businessHours = Get-CsRgsHoursOfBusiness service:ApplicationServer:atl-cs-001.litwareinc.com -Name "US Business Hours"

$y = Get-CsRgsWorkflow service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk"

$y.BusinessHoursId = $businessHours.Identity

Set-CsRgsWorkflow -Instance $y

Change an Interactive Workflow

• To change an interactive workflow

To modify an interactive workflow, use the Get-CsRgsWorkflow cmdlet to create an object reference to the workflow to be modified, make your changes in memory, and then use the Set-CsRgsWorfklow cmdlet to write those changes to Lync Server:

$musicFile = Get-Content -ReadCount 0 -Encoding Byte C:\MediaFiles\Hold.wav | Import-CsRgsAudioFile -Identity Service:ApplicationServer:atl-cs-001.litwareinc.com -FileName "HelpDeskHoldMusic.wav"

$y = Get-CsRgsWorkflow -Identity Service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk"

$y.CustomMusicOnHoldFile = $musicFile

Set-CsRgsWorkflow -Instance $y

Delete a Response Group Workflow

• To delete a workflow

To delete a Response Group workflow use the Get-CsRgsWorkflow cmdlet to return an instance of the workflow to be deleted, then pipe that instance to the Remove-CsRgsWorkflow cmdlet:

Get-CsRgsWorkflow service:ApplicationServer:atl-cs-001.litwareinc.com -Name "Help Desk Workflow" | Remove-CsRgsWorkflow

This command deletes all the workflows configured for use in your organization

Get-CsRgsWorkflow | Remove-CsRgsWorkflow

For more information

• Get-CsRgsWorkflow
• New-CsRgsWorkflow
• Remove-CsRgsWorkflow
• Set-CsRgsWorkflow

If you were to tunnel deep enough under the Microsoft campus (note: please don't tunnel under the Microsoft campus, or at least don't tell anyone we suggested it), you would eventually run into the concrete bunker that serves as the Lync PowerShell Fortress of Solitude.

Inside the Fortress of Solitude, teams of dedicated Lync Server PowerShell blog writers monitor the world of Lync Server PowerShell, 24 hours a day, 7 days a week. Whenever they hear about someone who has a problem or a question involving Lync Server PowerShell, they immediately dispatch a highly-trained Lync PowerShell SWAT team, a SWAT team that can be airlifted and parachuted into your facility within hours. Once your facility has been secured, the SWAT team will fix your problem or answer your question, then disappear into the night, awaiting their next assignment.

But while we may not have a Fortress of Solitude, from time-to-time we do get questions about Lync Server PowerShell, and while we might not be a real SWAT team, whenever we do get a question we sit down and try to come up with an answer. (And, before you ask, yes, we usually try to come up with the right answer.)

For example, just the other day we received this email:

"Do you have or can you post a PowerShell script that will go through AD and find all enabled Lync users and then set their LineURI as a normalized version of their Office Phone number? … This would help us out, otherwise we are going to have to sit and do this by hand, not to mention when the Office Number changes it will have to be manually changed in Lync. I’m sure I’m not the only one who could use something like this."

So can we do that? Can we write a script that will find each user who has been enabled for Lync Server, grab that user's phone number (as currently configured in Active Directory), and then assign that phone number to their LineUri attribute? Beats us. But we'll definitely give it the old college try.

Let's start with a very simple scenario. Suppose we have two user accounts that have been enabled for Lync Server. Those two users, and the Active Directory phone numbers that have been assigned to them, are shown below:

What we want to do is take those existing phone numbers, convert them to the line URI format, and then assign those line URIs to their respective users. For example, Ken Myer has the phone number 1-(206)-555-1219. When our script finishes running, he should also have the LineURI TEL:+12065551219. What kind of script can do that for us? This kind of script:

$enabledUsers = Get-CsAdUser -Filter {Enabled -ne $Null}

foreach ($user in $enabledUsers)

    {

        $phoneNumber = $user.Phone

        $phoneNumber = $phoneNumber -replace "[^0-9]"

        $phonenumber = "TEL:+" + $phoneNumber

        Set-CsUser -Identity $user.Identity -LineUri $phoneNumber

    }

Let's see if we can figure out what's going on here. To begin with, we use the following command to return information about all the users who have been enabled for Lync Server:

$enabledUsers = Get-CsAdUser -Filter {Enabled -ne $Null}

Now, you might be looking at the preceding command and wondering: a) why did they use Get-CsAdUser instead of Get-CsUser; and, b) why did they use the filter {Enabled –ne $Null}? After all, if all we want to get back are the users who have been enabled for Lync Server, shouldn't we use this filter instead: {Enabled –eq $True}?

Believe it or not, we have good reasons for using Get-CsAdUser and for using the filter we chose. (And yes, that might be the first time we ever had a good reason for doing something.) Because we're interested only in users who have been enabled for Lync Server, you might have expected us to use the Get-CsUser cmdlet; after all, those are the only kind of users Get-CsUser can return. However, if we want this script to actually work (which we do), then we need to retrieve each user's current Active Directory phone number. Get-CsAdUser returns that phone number for us; Get-CsUser doesn't. That's why we need to use Get-CsAdUser.

As for the filter we chose, well, the Enabled attribute tells whether or not a user has been enabled for Lync Server. The Enabled attribute can have one of three values:

·         $True, which means the user has been enabled for Lync Server.

·         $False, which means the user has been enabled for Lync Server, but his or her Lync account is temporarily disabled.

·         $Null, which means that the user has not been enabled for Lync Server.

As you can see, if we looked for users where the Enabled attribute is equal to $True, we wouldn't get back users whose accounts have been enabled for Lync Server but are temporarily disabled. Therefore, we decided to look for all the users where the Enabled attribute is equal to either $True or $False; in other words, where the attribute is not equal to (-ne) $Null.

After we execute the first line in our script we should have information about all the users who have been enabled for Lync Server; that collection of data then gets safely tucked away in the variable $enabledUsers. In the next line of code, we set up a foreach loop that loops through all the users in that collection. Inside that loop, the first thing we do is grab the user's Active Directory phone number (for example, 1-(206)-555-1219) and stash that in a variable named $phoneNumber:

$phoneNumber = $user.Phone

This is where it gets interesting. (Or, should we say, this is where it gets even more interesting.) As you know, line URIs are finicky little things: they have to be formatted just right or Lync Server will reject them. In particularly, line URIs must start with the prefix TEL:+ and then be followed by a phone number consisting of the country code, area code, and the actual phone number. Oh, and that country code, area code, and phone number? Digits only. No blank spaces, no parentheses, no hyphens, nothing but numbers.

Which means we have two problems here. First, Ken Myer's Active Directory phone number – 1-(206)-555-1219 – doesn't start with the TEL:+ prefix. Second, that phone number contains some invalid characters: (, ), and -. Before we can turn this phone number into a line URI we need to fix both of these problems.

Let's start off by tackling the second problem: the presence of invalid characters. What we need to do here is take our Active Directory phone number and remove everything that isn't a number. That sounds like a pretty daunting task; the truth is, it requires just one line of code:

$phoneNumber = $phoneNumber -replace "[^0-9]"

What we're doing here is using the –replace operator and the regular expression [^0-9] to locate everything that isn't a number and replace it with, well, nothing. We know that we're searching for everything that isn't a number because of the regular expression [^0-9]; that value tells PowerShell to use the numeric range 0 through 9. The caret symbol (^) tells PowerShell to look for characters that aren't in the range 0-9. If we wanted to look for characters that are in the range 0-9 (which we don't) we'd simply omit the caret:

"[0-9]"

And to make sure that non-digit characters are deleted (that is, replaced by nothing) we don't include a replacement parameter. Suppose, for some reason, we wanted to replace non-digit characters with the letter X. In that case, we'd use this syntax:

-replace "[^0-9]", "X"

Which is probably more than you really need to know at the moment.

And so what do we end up with when we remove all the non-digit characters? This:

12065551219

As you can see, that's almost a line URI; the only problem is that it doesn't start with the TEL:+ prefix. But that's easy enough to fix:

$phonenumber = "TEL:+" + $phoneNumber

Needless to say, there's nothing too terribly complicated about that command. All we're doing is adding the prefix TEL:+ to the value stored in the variable $phoneNumber. That means $phoneNumber now looks like this:

TEL:+12065551219

And that value does look like a line URI, doesn't it? Which, in turn, means that all we have to do now is assign this value to the LineUri attribute. You know, like this:

Set-CsUser -Identity $user.Identity -LineUri $phoneNumber

If we take a peek at Active Directory right now we should see something that looks like this:

As you can see, Ken Myer now has a line URI based on his Active Directory phone number. Granted, Pilar Ackerman doesn't have a line URI yet. But that's because we've only made one trip through our foreach loop. As soon as we loop around we'll repeat the process with Pilar's account and she'll end up with a line URI based on her Active Directory phone number:

Etc., etc.

Now, we should note that there is one potential complication here. Our script assumes that you've been storing complete phone numbers in Active Directory; that is, phone numbers that have the country code, area code, and the phone number. As long as you use that format our script will work; for example, it can convert any of these phone numbers to line URIs:

1-(206)-555-1219

1-206-555-1219

1.206.555.1219

1(206)555-1219

And so on.

Now that's great, but what if you don't use the same format we used in our preceding example? Well, in that case, you're going to have to modify the script a little. But don't despair; we'll make a deal with you. We'll show you two additional examples for normalizing your Active Directory phone numbers to the E.164 format used in a line URI. If those examples don't work for you, send an email to cspshell@microsoft.com, making sure to give us an example of how your phone numbers are formatted in Active Directory. We'll hand that email over to one of the SWAT teams and with any luck, within a day or two someone will parachute into your office and hand you the solution.

Or, depending on the budget, someone will email that solution to you.

Let's start by looking at an organization that formats phone numbers like this:

As you can see, this organization doesn't store complete phone numbers in Active Directory; instead, they store only extension numbers. And just to make things a little more complicated, it turns out that the area code varies depending on your extension number: if your extension starts with the number 5 then you're in area code 206. If your extension starts with the number 6 then you're in area code 425.

So how are going to go about assigning line URIs in this organization? We're going to go about it like this:

$enabledUsers = Get-CsAdUser -Filter {Enabled -ne $Null}

foreach ($user in $enabledUsers)

    {

        $phoneNumber = $user.Phone

        $phoneNumber = $phoneNumber -replace "[^0-9]"

        $extension = $phoneNumber -match "^5"

        if ($extension)

            {

                $phoneNumber = "TEL:+120655" + $phoneNumber

            }

        else

            {

                $phoneNumber = "TEL:+142556" + $phoneNumber

            }

        Set-CsUser -Identity $user.Identity -LineUri $phoneNumber

    }

Most of that script should look familiar to you; after all, much of it is copied line-for-line from our previous script. (Of course, we're assuming that you did look at our previous script.) The only real difference comes here:

$extension = $phoneNumber -match "^5"

if ($extension)

    {

        $phoneNumber = "TEL:+120655" + $phoneNumber

    }

else

    {

        $phoneNumber = "TEL:+142556" + $phoneNumber

    }

In this block of code we're checking to see if the extension number starts with a 5; that's what the regular expression ^5 is for. Suppose the first number in the extension is a 5. In that case, that means that the user is in the 206 area code and also has the telephone prefix 555. In that case, and in order to turn this phone extension into a line URI, we need to prefix the extension number with TEL:+120655. Like this:

$phoneNumber = "TEL:+120655" + $phoneNumber

If we do that, we'll end up with a phone number that like this one:

TEL:+12065551219

And if the extension doesn’t start with a 5? Well, in this somewhat-simplistic example, that can only mean that the number is in the 425 area code and must have the telephone prefix 556. This line of code takes care of formatting extensions that don't start with a 5:

$phoneNumber = "TEL:+1425556" + $phoneNumber

Got all that? Good. Now let's do one more. Here's a fairly typical way of storing phone numbers in Active Directory; it includes the complete phone number plus an extension number (the number following the x):

So how do we deal with Ken Myer's phone number, which is a phone number and an extension? Well, for starters, we need to tell you that we might have … misled … you earlier in this article, back when we said line URIs can only contain numbers. That's mostly true, but there are exceptions. For example, this is not only a valid line URI, but it's the way you need to format line URIs that include both a phone number and an extension:

TEL:+12065551111;ext=1219

We need to make Ken Myer's phone number look like that. And here's how we're going to do it:

$enabledUsers = Get-CsAdUser -Filter {Enabled -ne $Null}

foreach ($user in $enabledUsers)

    {

        $phoneNumber = $user.Phone

        $phoneNumber = $phoneNumber -replace "[^0-9|^x]"

        $phoneNumber = $phoneNumber –replace "x", ";ext="

        $phonenumber = "TEL:+" + $phoneNumber

        Set-CsUser -Identity $user.Identity -LineUri $phoneNumber

    }

There are two differences between this script and the script we originally showed you. For starters, there's this line of code:

$phoneNumber = $phoneNumber -replace "[^0-9|^x]"

What's the deal with that line of code? Well, as we know, Ken's phone number starts off looking like this:

1-206-555-1111 x1219

As we also know, we need to remove all the non-digit characters from this number – well, all of them except the letter x. Why can't remove the letter x? We need to keep the letter x in there so we know where the extension part of Ken's phone number begins. That's why we use the regular expression [^0-9|^x]; that pattern tells PowerShell to replace everything that doesn't fall into the numeric range 0-9 or that isn't the letter x (^x). After we execute this line of code Ken's phone number should look like this:

12065551111x1219

That's step 1. Now we need to replace the letter x with the string ;ext=. Which is what we do here:

$phoneNumber = $phoneNumber –replace "x", ";ext="

That gives Ken a phone number that looks like this:

12065551111;ext=1219

That also makes it easy for us to add the TEL:+ prefix and then assign Ken his new line URI.

Oh, and what about Pilar's phone number, a phone number that doesn't use an extension? That's fine. If the script finds an extension it will deal with and, if it doesn't find an extension, it will deal with that.

Which, all in all, really is a heck of a deal, isn't it?

That's all we have time for today; it's time for our shift down in the Lync PowerShell Fortress of Solitude. If you need additional help just send an email to cspshell@microsoft.com. Remember: the SWAT teams are standing by!

Scopes and Filters

Suppose you’re a typical English-speaking American and you get the opportunity to live and work in Rome for a year. Could you survive without learning to speak Italian? Maybe. Would you be better off if you took a little time to sit down and learn some Italian? Definitely. When in Rome, do as the Romans do.

Oh: and talk like the Romans talk.

As it turns out, Microsoft Lync Server 2010 introduces a whole new language and a whole new vocabulary all its own. Can you survive without learning this new vocabulary? Maybe. Would you be better off if you took a little time to sit down and learn this new vocabulary? Well, you know what they say: when in Rome ….

With that in mind, let’s take a minute and talk about three important new terms being introduced along with the new Lync Server implementation of Windows PowerShell: identities, scopes, and filters.

Oh, my!

Identities

At the risk of tooting our own horns, we went to great lengths to explain identities in our Identities article, which means that we’re not going to do it again here. Instead, let’s move on to Scopes.

Man, if all the sections turn out like this one this article will be a cinch to write.

Scopes

To explain what a scope let’s start by listing the available scopes:

•         Global. The global scope is for configuration settings or policies you want enforced throughout your entire Microsoft Lync Server infrastructure. For example, when you configure a policy at the global scope that policy will be applied to every user in the organization. (Well, unless you have configured a policy “downstream.” But more on that in a minute.)

•         Site. The site scope is for, well, sites. In Lync Server 2010, sites are typically based on geographic locations: a Redmond site, a Dublin site, etc.

•         Service. The service scope represents a service. For example, the Registrar service is one Microsoft Lync Server service; user services is another. In the new Lync Server architecture, a given service might be carried out by a single computer or by all the computers in a pool.

•         Tenant. The Tenant scope deals with Lync Server as a service (the so-called “in-the-cloud” scenario). At this point in time the Microsoft Lync Server cmdlets cannot be used “in the cloud.” In turn, that means that it is irrelevant to our needs, and thus won’t be discussed in this article. We mention this only because – as you’ll see in the next section – you might stumble upon a reference to the Tenant scope when trying to determine the allowed scopes for an object.

•         Per-User. To be honest, “per-user” isn’t really the name of the scope, it’s more a description of the scope. (We have yet to come up with a good name for this scope.) The basic concept behind the per-user scope is pretty straightforward. The per-user scope (which applies only to policies, and not to configurations) is reserved for policies that can be directly applied to a user or a group of users. This makes the per-user (or, more simply, “user”) scope very different from the global, site, and service scopes, all of which are tied to your Microsoft Lync Server infrastructure. For example, if you don’t have a site named Redmond then you can’t create a policy at the site:Redmond scope; a site-scoped policy must be tied to an actual site. The Identity of a site-scoped policy or a service-scoped policy is simply the Identity of the site or service – period.

Oh, and each site is limited to one voice policy, one client policy, and so on: you can’t have two site-scoped voice policies at the Redmond site.

By comparison, you can create a per-user policy and give it pretty much any Identity. That’s because these policies do not have to be anchored to real objects such as sites or services. In turn, that means you can create as many per-user voice policies as you want, even if you don’t ever actually use those policies.

Scopes are primarily used for policy (and configuration) resolution. For example, if a user wants to make a phone call Lync Server needs to check to see such things as which voice policy is used to determine how (or even if) the user makes a call. Microsoft Lync Server applies policies and configurations in this order:

1.    First, the system checks to see if something has been applied at the user scope. If so, then that policy (configurations can’t be applied at the user scope) is used.

2.    If nothing can be found at the user scope then the system checks to see if something has been applied at the service scope. If so, then that policy or configuration is applied.

3.    If nothing can found at the service scope then the system checks to see if something has been applied at the site scope. If so, then that policy or configuration is applied

4.    If nothing can be found at the site scope then the system checks to see if something has been applied at the global scope. If so, then that policy or configuration is applied.

Note that there will always be a global policy or a global configuration setting. Global policies and configuration settings are automatically created for you when you install Microsoft Lync Server 2010, and these global objects can never be removed.

Never.

Got all that? Good, because now we can talk about how you specify an identity and, equally important, when you specify an identity.

As we explained in the Identities section of this manual, identities are specified at the time you create a new object; the identity you give that object will depend on both the type of object and on the scope of the object. For example, suppose you want to create a new conferencing policy for use at the site level; what identity will you give that policy? That’s an easy one: a site policy always has an Identity that consists of the string value site: followed by the name of the site. For example, if this conferencing policy is to be assigned to the Redmond site then you would use the following code to create the new policy:

New-CsConferencingPolicy –Identity site:Redmond

OK, then what about a policy that’s supposed to be assigned to a service? That’s another easy one: the Identity is simply the string value service: followed by the service name (i.e., Registrar) followed by the fully qualified domain name of the pool where that service is located. You know, like this:

New-CsClientVersionPolicy –Identity service:Registrar:atl-cs-001.litwareinc.com

As you can see, when you are working at the site scope or the service scope there is no need to assign (or grant) a policy; instead, the policy is automatically assigned based on the Identity you give it. Give a policy the Identity site:Redmond and it will automatically be assigned to the Redmond site.

That leaves us with one last identity/scope to deal with: per-user. Per-user policies (and, again, only policies can be applied at the per-user scope) represent the one time (for the most part) you get to be a little creative: with per-user policies, you get to pick out the Identity. (Hurray!) That’s because per-user policies aren’t automatically assigned to a portion of the Microsoft Lync Server infrastructure; in fact, per-user policies aren’t automatically assigned to anyone or anything. Upon creation they simply exist; they do nothing more than wait for you to explicitly assign them to a user or group of users.

So what does all that look like? It looks a little something like this:

New-CsConferencingPolicy –Identity RedmondConferencingPolicy

In this case, the Identity consists of a string value that is the policy “name”: RedmondConferencingPolicy. You can give your user policy any name you wish.

Is there a way to determine the allowed scopes for an object?

Yes: scope information is included in the Help topic for each cmdlet where this information is relevant. You can determine the allowed scopes simply by perusing the help file for a given cmdlet. That’s the recommended way to determine the allowed scopes for an object.

Suppose you type the command Get-Help New-CsConferencingPolicy –full | more. Do that and then scroll down until you find the section labeled Parameters. In that section you should find the following information:

-Identity <XdsIdentity>

    Unique identifier for the conferencing policy to be created.

    Conferencing policies can be created at the site or per-use

    r scopes.

Notice that the global scope isn’t mentioned. That’s because a global conferencing policy always exists, you can’t create a new one. If you look at the description of the Identity parameter in the help for Set-CsConferencingPolicy, you’ll see this:

-Identity <XdsIdentity>

    Unique identifier for the conferencing policy to be modified.

    Conferencing policies can be configured at the global, site,

    or per-user scopes.

Filters

Suppose you have a dial plan with the Identity site:Redmond. As it turns out, this dial plan is the only dial plan that has an Identity that starts with the string value site:R. Consequently, you might find yourself thinking, “I bet I could use a wildcard character to identify this dial plan.” With that in mind, you try to retrieve the dial plan using a command like this:

Get-CsDialPlan –Identity site:R*

We hate to be the ones to rain on your parade, but this isn’t going to work; if you try running the preceding command all you’ll get back is the following error message:

Get-CsDialPlan : Cannot get “DialPLan” “Site:R*” because it does not exist.

At line:1 char:15

+ Get-CsDialPlan <<<< -Identity site:R*

+ CategoryInfo : ResourceUnavailable: (Site:*:XdsIdentity) [Get-C

sDialPlan], KeyNotFoundException

+ FullyQualifiedErrorId : MissingItem,Microsoft.Rtc.Management.Internal.Ge

tDialPlanCmdlet

So why didn’t this work? One reason and one reason only: you can’t use wildcards when specifying an object’s Identity. If you gave your dial plan the Identity site:Redmond then you’re going to have to type that entire string each time you need to retrieve that plan. And that’s all there is to it; there’s no way to work around this issue, none whatsoever.

Well, unless you use the –Filter parameter, of course.

The -What parameter? The -Filter parameter. For example, the following command will return the dial plan site:Redmond; in fact, it will return any dial plan that has an Identity that begins with the string value site:R:

Get-CsDialPlan –Filter site:R*

In other words, if you’ve been wondering what the –Filter parameter is for, well, now you know: -Filter enables you to use wildcards when specifying the policies or configurations that you want to retrieve. For example, suppose you have the following dial plans in your organization:

•         Global

•         site:Cairo

•         site:Redmond

•         site:Dublin

•         site:Singapore

•         tag:Administrators

•         tag:Contractors

•         tag:Sales

To return all the dial plans you can just call Get-CsDialPlan without any additional parameters:

Get-CsDialPlan

Now, what if you wanted all the dial plans that were configured at the site scope? This command will do the trick:

Get-CsDialPlan –Filter Site:*

See how that works? We used the wildcard Site:* to find all the dial plans that begin with the string value Site: (which, by definition, makes them site policies). It’s just that easy.

OK, so now what if you want to find all the dial plans configured at the per-user scope? Remember that, when we created an object at the per-user scope, we simply gave the identity a unique name, we didn’t have to include a scope. For example, to create the per-user dial plan NorthAmericaHeadquartersDialPlan, we use a command like this:

New-CsDialPlan –Identity NorthAmericaHeadquartersDialPlan

And we can use -Filter to retrieve that particular dial plan:

Get-CsDialPlan –Filter *North*

Of course, the preceding command will retrieve all the dial plans (regardless of scope) that contain the string North. For example, suppose we also had a dial plan defined for a site named NorthRedmond (Identity site:NorthRedmond). The preceding command would retrieve the dial plan with the identity NorthAmericaHeadquartersDialPlan and the dial plan site:NorthRedmond.

Bummer.

So how do you retrieve only the per-user (tag) dial plans? Well, even though we didn’t include the scope when creating an Identity for our per-user dial plan, we can still use tag: to retrieve these dial plans. In other words, we can run a command like this:

Get-CsDialPlan –Filter tag:*

By including the tag: prefix in our Filter value, we can retrieve all the dial plans that were defined using just a name; in other words, all the dial plans that must be explicitly granted to users in order to take effect (the ones configured at the per-user, or tag scope). The reason we can do this is because even though we defined the identity with just a name, the tag: prefix is added in the background. And it’s added for just this reason – so we can continue to filter on these values.

The moral of the story is this: if you want to retrieve policies or settings by using wildcard values then you will need to use –Filter rather than –Identity.

-- The End –

Here's another feature of Microsoft Lync that you might not have known you could control: peer-to-peer video. By default, Microsoft Lync allows users to conduct peer-to-peer video sessions. That means at least two things. First, you can start a video call from within the Contact window:

Second, you can easily add video to any peer-to-peer session; all you have to do is click Video:

But suppose you don't really want your users conducting peer-to-peer video sessions. Based on the fact that there's no setting in the Lync Server Control Panel that allows you to disable peer-to-peer video, you might think you're out of luck.

But hey, as long as you have Windows PowerShell you're never out of luck! (Well, except for those times when you're out of luck.) As it turns out, Lync Server conferencing policies have a setting – EnableP2PVideo – that allows you to disable or enable peer-to-peer video. The one catch is that this setting is available only through Windows PowerShell. That means you need to use a command like this one to disable peer-to-peer video:

Set-CsConferencingPolicy –Identity global –EnableP2PVideo $False

If you run the preceding command, users affected by that policy will lose the ability to make a video call:

In addition to that, the Video menu will disappear from their Conversation window:

The moral of the story? No more peer-to-peer video.

Two things to keep in mind here. First, this setting only affects peer-to-peer video. If you want to allow or disallow conference video, you'll need to use the AllowIPVideo setting in the appropriate conferencing policy.

Second, this is a per-user setting, which – in theory anyway – affects only the user assigned a given policy. Why do we say "in theory anyway?" Well, consider the following scenario, with four users and four different conferencing policies:

Let's take a look at some of the different peer-to-peer scenarios and who gets to use peer-to-peer video in each scenario:

And the moral of that story? Peer-to-peer video is possible only if both users taking part in the session are allowed to have peer-to-peer video. It's basically all or nothing.

As you probably know, Microsoft Lync has the ability to keep an enormous amount of information about everything it does and, perhaps more importantly, anything that might go wrong when it tries to do whatever it does. Needless to say, this information can be incredibly useful when troubleshooting Lync-related problems: there's no real substitute for having multiple log files that pretty much let you recreate a Lync session, SIP message by SIP message. These logs also let you know all the settings and restrictions that were in force when Lync was used. For example, the file Communicator-uccapi-0.uccapilog shows you all the policy settings that were applied when the user connected to Lync Server:

<provisionGroup name="presencePolicyV2" >

    <propertyEntryList >

        <property name="EnablePrivacyMode" >false</property>

        <property name="AutoInitiateContacts" >true</property>

        <property name="PublishLocationDataDefault" >true</property>

        <property name="DisplayPublishedPhotoDefault" >true</property>

        <property name="PersonalNoteHistoryDepth" >3</property>

        <property name="SubscribeToCollapsedDG" >false</property>

    </propertyEntryList>

</provisionGroup>

Pretty cool, huh?

By default, this type of logging (also known as tracing) is disabled on Microsoft Lync. Considering the vast amount of information that's made available to you, why would you ever want to disable tracing in Microsoft Lync?

Well, believe it or not, there are several reasons. For one thing, a lot of the information is of minimal use (if it's even of any use) to a system administrator. For example, take this small snippet extracted from one of the log files:

05/17/2011|10:27:26.701 1978:12E0 TRACE :: CSIPAsyncSocket::Send this 07FB9E90, sending pbSendBuf 05165070, dwSendBufSize = 154

05/17/2011|10:27:26.701 1978:12E0 TRACE :: CSIPAsyncSocket::SendHelper - [0x07FB9E90]

05/17/2011|10:27:26.701 1978:12E0 TRACE :: CSIPAsyncSocket::SendHelper this 07FB9E90, pbSendBuf 05165070, dwSendBufSize = 154, dwBytesSent = 154

05/17/2011|10:27:26.709 1978:12E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x07FB9E98]

Unless you actually wrote the code for Microsoft Lync, thousands of lines like those might not be all that informative.

In addition, log files can quickly consume enormous amounts of disk space. For example, when the author of this article started Microsoft Lync this morning (with tracing enabled), he hit a snag: Lync was unable to connect to the server. Fortunately, after just a few seconds, he was able to get through and make the connection after all. However, that brief 3- or 4-second little snag generated over 72 megabytes worth of log files.

And yes, that is a lot.

Finally, while there is definitely useful troubleshooting information to be found in the log files, much of troubleshooting data of interest/use to system administrators can be gathered by using Monitoring Server. Even better, if you use Monitoring Server and Monitoring Server Reports you can quickly and easily view and analyze this information, much quicker and easier than you could by wading through gigabytes of client log files.

But you know what? It's entirely up to you whether or not you want to enable tracing in Microsoft Lync. Either way, you can manage this option by selecting (or deselecting) the Turn on logging in Lync option:

And before you ask, of course you can manage this setting using Windows PowerShell; all you have to do is manipulate the HKCU\SOFTWARE\Microsoft\Communicator\EnableTracing registry value. For example, the following PowerShell script retrieves the current value of EnableTracing from the local computer. If you'd prefer to retrieve this value from a remote computer, simply set the value of the variable $computer to the name of that remote computer. For example:

$computer = "atl-ws-001.litwareinc.com"

Here's the script for retrieving the value:

$computer = "."

$registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey("CurrentUser", $computer)

$key = $registry.OpenSubKey("SOFTWARE\Microsoft\Communicator", $True)

$value =$key.GetValue("EnableTracing",$null)

if ($value -eq 1) {$value = "Yes"}

if ($value -eq 0) {$value = "No"}

Write-Host "Turn logging on in Lync: $value"

And what if you want to change the value of EnableTracing? Hey, no problem. The following script enables tracing; that's done by setting EnableTracing to 1. To disable tracing, set EnableTracing to 0:

$key.SetValue("EnableTracing",0,"DWORD")

Like this:

$computer = "."

$registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey("CurrentUser", $computer)

$key = $registry.OpenSubKey("SOFTWARE\Microsoft\Communicator", $True)

$key.SetValue("EnableTracing",1,"DWORD")

Keep in mind that there's also a client policy setting – EnableTracing – that can be used to manage tracing. If EnableTracing is set to True in a user's client policy the tracing will be enabled and the user will not be able to change that setting:

It doesn't matter how the registry has been configured: the client policy setting always takes precedence over the registry setting.

Likewise, if the client policy's EnableTracing setting has been set to False then tracing will be disabled and the user will not be able to enable it.

Enable or Disable External User Access for Your Organization

Enable or Disable Remote User Access for Your Organization

• To enable or disable remote user access for your organization

To enable remote user access, use the Set-CsAccessEdgeConfiguration cmdlet to set the AllowOutsideUsers property to True:

Set-CsAccessEdgeConfiguration –Identity global –AllowOutsideUsers $True

To disable remote user access, set the AllowOutsideUsers property to False:

Set-CsAccessEdgeConfiguration –Identity global –AllowOutsideUsers $False

Enable or Disable Federation for Your Organization

• To enable or disable federated user access for your organization

To enable federated user access, use the Set-CsAccessEdgeConfiguration cmdlet to set the AllowFederatedUsers property to True:

Set-CsAccessEdgeConfiguration –Identity global –AllowFederatedUsers $True

To disable federated user access, set the AllowFederatedUsers property to False:

Set-CsAccessEdgeConfiguration –Identity global –AllowFederatedUsers $False

Enable or Disable Anonymous User Access for Your Organization

• To enable or disable anonymous user access for your organization

To enable anonymous user access, use the Set-CsAccessEdgeConfiguration cmdlet to set the AllowAnonymousUsers property to True:

Set-CsAccessEdgeConfiguration –Identity global –AllowAnonymousUsers $True

To disable anonymous user access, set the AllowAnonymousUsers property to False:

Set-CsAccessEdgeConfiguration –Identity global –AllowAnonymousUsers $False

For more information

• Haiku #83: The CsAccessEdgeConfiguration Cmdlets
• The Access Edge Configuration Dialog

Manage Communications with External Users

Manage Remote User Access

• To configure an external access policy to support remote user access

To create an external user access policy that allows access by remote users, use the New-CsExternalAccessPolicy cmdlet and set the EnableOutsideAccess property to True:

New-CsExternalAccessPolicy –Identity "RedmondExternalAccess" –EnableOutsideAccess $True

Manage Federated Partner Access

Configure Policies to Control Federated User Access

• To configure a policy to support access by users of federated domains

To create an external user access policy that allows access by federated users, use the New-CsExternalAccessPolicy cmdlet and set the EnableFederationAccess property to True:

New-CsExternalAccessPolicy –Identity "RedmondExternalAccess" –EnableFederationAccess $True

Enable or Disable Discovery of Federation Partners

• To enable or disable automatic discovery of federated domains for your organization

To enable automatic discovery of federated domains, use the Set-CsAccessEdgeConfiguration cmdlet and the UseDnsSrvRouting parameter, and set EnablePartnerDiscovery to True:

Set-CsAccessEdgeConfiguration -UseDnsSrvRouting -EnablePartnerDiscovery $True

To disable automatic routing, use the UseDefaultRouting parameter, and set DefaultRouteFqdn to the fully qualified domain name of the Edge Server used for federation requests:

Set-CsAccessEdgeConfiguration -UseDefaultRouting -DefaultRouteFqdn "atl-edge-001.litwareinc.com"

Control Access by Individual Federated Domains

• To add an external domain to the list of allowed domains

To add a domain to the list of domains your users are allowed to communicate with, use the New-CsAllowedDomain cmdlet followed by the fully qualified domain name of the allowed domain:

New-CsAllowedDomain -Identity "fabrikam.com"

• To add an external domain to the list of blocked domains

To add a domain to the list of domains your users are not allowed to communicate with, use the New-CsBlockedDomain cmdlet followed by the fully qualified domain name of the "outlawed" domain:

New-CsBlockedDomain -Identity "contoso.com"

Enable or Disable Sending an Archiving Disclaimer to Federated Partners

• To enable or disable sending an archiving disclaimer to federated partners

To display an archiving disclaimer to federated partners at the beginning of an instant messaging session, use the Set-CsAccessEdgeConfiguration cmdlet and set the EnableArchivingDisclaimer property to True:

Set-CsAccessEdgeConfiguration –Identity global -EnableArchivingDisclaimer $True

To prevent the display of the archiving disclaimer, set the EnableArchivingDisclaimer property to False:

Set-CsAccessEdgeConfiguration –Identity global -EnableArchivingDisclaimer $False

For more information

• Haiku $107: The CsExternalAccessPolicy Cmdlets
• Haiku # 83: The CsAccessEdgeConfiguration Cmdlets
• Haiku #3: The CsBlockedDomain Cmdlets
• The Edit External Access Policy Dialog
• The Access Edge Configuration Dialog
• The New Federated Domains Dialog (Allowed Domains)
• The New Federated Domains Dialog (Blocked Domains)

Manage IM Provider Support

Configure Policies to Control Access by Users of IM Service Providers

• To configure an external access policy to support public user access

To enable users to communicate with a public provider such as MSN or AOL, use the Set-CsExternalAccessPolicy cmdlet to set the EnablePublicCloudAccess property of the appropriate external access policy to True:

New-CsExternalAccessPolicy -Identity site:Redmond -EnablePublicCloudAccess $True

Specify Supported IM Service Providers

• To configure support for an IM service provider

To enable users to communicate with a new public provider, use the New-CsPublicProvider cmdlet to add the new organization to the list of approved providers:

New-CsPublicProvider -Identity "Fabrikam" -ProxyFqdn "proxyserver.fabrikam.com" -Enabled $True -VerificationLevel "AlwaysUnverifiable"

Configure Conferencing Policies to Support Anonymous Users

• To configure policies to allow anonymous participation in meetings

To allow users to host meetings that include anonymous users, use the Set-CsConferencingPolicy cmdlet to set the AllowAnonymousParticipantsInMeetings property of the appropriate conferencing policy to True:

Set-CsConferencingPolicy –Identity global -AllowAnonymousParticipantsInMeetings $True

For more information

• Haiku #107: The CsExternalAccessPolicy Cmdlets
• Haiku #128: The CsPublicProvider Cmdlets
• No Conferencing Policy is an Island
• The Edit External Access Policy Dialog
• The Edit Provider Dialog
• The Edit Conferencing Policy Dialog

Apply Policies for External User Access to Users

Apply External User Access Policies to Users

• To apply an external user policy to a user account

To assign a per-user external access policy to a user, use the Grant-CsExternalAccessPolicy cmdlet.

Grant-CsExternalAccessPolicy –Identity "Ken Myer" –PolicyName "RedmondExternalAccess"

To unassign a per-user policy, use Grant-CsExternalUserAccess and set the PolicyName to a null value:

Grant-CsExternalAccessPolicy –Identity "Ken Myer" –PolicyName $null

Apply Conferencing Policies to Support Anonymous Users

• To configure a user policy for anonymous participation in meetings

To allow users to host meetings that include anonymous participants, use the Set-CsConferencingPolicy cmdlet and set AllowAnonymousParticipantsInMeetings to True:

Set-CsConferencingPolicy –Identity site:Redmond -AllowAnonymousParticipantsInMeetings $True

To prevent users from hosting meetings that include anonymous participants, set AllowAnonymousParticipantsInMeetings to False:

Set-CsConferencingPolicy –Identity site:Redmond -AllowAnonymousParticipantsInMeetings $False

Reset or Delete External User Access Policies

Delete a Site or User Policy for External User Access

• To delete a site or user policy for external user access

To delete a per-site external access policy, use the Remove-CsExternalAccessPolicy cmdlet followed by the policy Identity:

Remove-CsExternalAccessPolicy –Identity site:Redmond

You can also use this command to remove all the per-site policies:

Get-CsExternalAccessPolicy –Filter "site:*" | Remove-CsExternalAccessPolicy

To delete a per-user policy, use the Remove-CsExternalAccessPolicy cmdlet followed by the policy Identity:

Remove-CsExternalAccessPolicy –Identity "RedmondExternalAccessPolicy"

This command removes all the per-user policies:

Get-CsExternalAccessPolicy –Filter "tag:*" | Remove-CsExternalAccessPolicy

Reset the Global Policy for External User Access

• To reset the global policy to the default settings

To reset all the properties in the global external user access policy to their default values, use the Remove-CsExternalAccessPolicy cmdlet:

Remove-CsExternalAccessPolicy –Identity global

Note that this command will not remove the global policy. However, all the properties in that policy will be reset to their default values.

For more information

• Haiku #107: The CsExternalAccessPolicy Cmdlets
• No Conferencing Policy is an Island
• The Edit Conferencing Policy Dialog
• The Edit External Access Policy Dialog

As a general rule, the conferencing policy settings aren't too difficult to understand. Some of them have odd names – like EnableDataCollaboration – but once you know what the EnableDataCollaboration setting is for, well, then it's all pretty simple and straightforward.

So is the AllowUserToScheduleMeetingsWithAppSharing setting somehow different from the other policy settings? Well, no, not really: once you know what the AllowUserToScheduleMeetingsWithAppSharing setting is for it turns out to be pretty simple and straightforward, too. But this one is a wee bit more complicated than most settings, if only because it seemingly-conflicts with the EnableAppDesktopSharing setting. How do those two settings conflict, and who wins if and when they do conflict? We'll get to that in just a minute.

But first things first. As you probably know, Microsoft Lync gives the chance to share things during a meeting or a peer-to-peer session: by default, you can share either you entire desktop (which essentially means sharing your entire computer) or a specific application. It's up to you.

And what exactly does it mean to share your desktop or an application? It means two things. First, it means that everything you do on your computer (or in that single application) is visible to everyone else in the meeting; for example, if you're typing away in Microsoft Word, everyone will be able to see what you're typing, how you're formatting the text, etc., etc.

Second (and, again, by default) anyone in the meeting can ask to take control of your desktop or your shared application. Again, suppose you're sharing Microsoft Word. Anyone else in the meeting could request to take control of the application and, if you say OK, they'll be able to start typing in Word. It's your copy of Word and it's running on your computer, but someone else can sit at their desk and type away as if the application belonged to them.

That's the easy part. Now here's where things get a little complicated. (But just a little.) As we noted a minute ago, there are two different conferencing policy settings that control application sharing. The EnableAppDesktopSharing setting is a per-user setting that allows a given user to share:

·         His or her desktop

·         A specific application

·         Nothing

Because this is a per-user setting that means it applies to each individual user each time they join a meeting. In turn, that means that, in a given meeting, some users might be able to share applications and some users might not be able to share applications. (Everyone can always see the shared applications, regardless.) That means you could potentially have a meeting in which the meeting organizer can't share applications but everyone else in the meeting can share applications. That isn't necessarily good or bad; it's just a scenario that could crop up.

And what if you'd just as soon that this scenario doesn't crop up? That's where the AllowUserToScheduleMeetingsWithAppSharing setting comes in. This setting applies to the organizer of the meeting and lets you determine whether or not anyone in a meeting will be allowed to use application sharing. If this value is set to True (and if the meeting organizer is allowed to share his or her desktop) then that organizer will see something like this when he or she clicks on the Share menu in the Conversation window:

Meanwhile, everyone else in the meeting will see whatever options have been granted to them using the EnableAppDesktopSharing setting in their conferencing policy.

Got that? OK. Now suppose our meeting organizer has a conferencing policy in which AllowUserToScheduleMeetingsWithAppSharing has been set to False. In that case, the meeting organizer, and everyone else in the conference, will see something like this when they click the Share menu:

Why are the Desktop and Program options grayed-out? That's easy: because the meeting organizer is not allowed to schedule a meeting that includes application sharing. That means that the organizer can't share applications; equally important, it means that no one else in the meeting can share applications.

No one.

In other words, suppose we have two users and two conferencing policies. Like, say, these two:

Pilar Ackerman schedules a meeting. Will Pilar be able to share applications in that meeting? No. Will anyone be allowed to share applications in that meeting? In a word; no. Pilar's conferencing policy doesn't allow for shared applications.

Now, Ken Myer schedules a meeting. Will Ken be allowed to share applications in that meeting? Maybe; it depends on the value of the EnableAppDesktopSharing setting in his conferencing policy. Will Pilar be allowed to share applications in that meeting? Maybe; it depends on the value of the EnableAppDesktopSharing setting in her conferencing policy. But as long as your EnableAppDesktopSharing setting allows you to share applications then yes, you (whoever you are) can share applications in one of Ken's meetings.

Incidentally, here's some sample code for disabling application sharing in a meeting organized by anyone who uses the global conferencing policy:

Set-CsConferencingPolicy –Identity global –AllowUserToScheduleMeetingsWithAppSharing $False

And here's code that enables application sharing in a meeting organized by anyone who uses the global conferencing policy:

Set-CsConferencingPolicy –Identity global –AllowUserToScheduleMeetingsWithAppSharing $True

When the registry was first introduced in its current form in the Microsoft Windows 95 operating system, everyone at Microsoft was told “DO NOT tell users to touch anything in the registry. Ever.” We then proceeded to tell people that in some cases the only way to change something was to modify the registry.

Flash forward 16 years to 2011. The message from Microsoft today is “DO NOT tell users to touch anything in the registry. Ever.” Hey, at least we’re consistent.

But, again, there are exceptions. One of those exceptions happens to be if you’re writing Windows PowerShell scripts. In the set of articles Working with Microsoft Lync Registry Settings, we show you how to change Microsoft Lync 2010 settings by using scripts to modify the registry. Keep in mind that you can also modify these settings directly from the client, but if you’d like to use a script instead, this is how you do it.

http://blogs.technet.com/b/csps/archive/2011/06/15/regintroduction.aspx

Do you know how many times the authors of the Lync Server PowerShell blog have sat in a meeting and come up with a brilliant idea, only to see that brilliant idea wither and die because no one in the meeting happened to be taking notes? Well, OK, you're right: that's never happened, at least not to us. On the other hand, it could happen to someone else, someone who might actually have a brilliant idea. Which, needless to say, is at least one reason why Microsoft included a feature in Microsoft Lync that allows attendees to record meetings and conferences.

If you didn't know this feature exists, then do the following: the next time you're in a meeting, click the More Options button, the little button that looks like this:

>> 

In the popup menu that appears, you should see the Start Recording option:

Click that, and you'll be able to record the meeting. (And not just the audio: you'll be able to record all the application sharing, polls, whiteboards, instant messages, and anything else that takes place during the meeting.)

Actually, we need to clarify that a bit: you'll be able to record the meeting if the AllowConferenceRecording setting in your conferencing policy has been set to True. If this setting is False (the default value) then the Start Recording option will not be available when you click More Options:

In other words, your ability to record a conference hinges on the settings in the appropriate conferencing policy. What do we mean when we say the "appropriate" conferencing policy? Well, AllowConferenceRecording turns out to be a per-organizer setting: that means it applies to the person who organized the meeting (and, by extension, to everyone who participates in that particular meeting). Consider two users and two conferencing policies:

Pilar Ackerman's conferencing policy does not allow conference recording; Ken Myer's conferencing policy does allow conference recording. What does that mean? That means that conference recording will not be allowed in any meeting organized by Pilar: the Start Recording option will not be available in anyone's copy of Microsoft Lync. And yes, that includes Ken Myer's copy of Lync. When it comes to a per-organizer setting like AllowConferenceRecording, the only conferencing policy that matters is the conferencing policy assigned to the meeting organizer.

Of course, that also means that everyone who participates in a meeting organized by Ken Myer will be able to record the conference. That's because Ken Myer's conferencing policy allows recording, and that setting is thus applied to every single person in the meeting, including Pilar Ackerman. In other words, either everyone in the meeting can record the proceedings or no one in the meeting can record the proceedings.

So how do you enable the conference recording feature? Funny you should ask:

Set-CsConferencingPolicy –Identity global –AllowConferenceRecording $True

To disable recording, just set AllowConferenceRecording to False. You know, like this:

Set-CsConferencingPolicy –Identity global –AllowConferenceRecording $False