So just how many people can you have in any one meeting? That's a good question. And the answer is: it depends on the conference policy that the meeting organizer has been assigned.

By default, you can have a maximum of 250 people in a meeting. Note that this doesn't mean you can only invite a maximum of 250 people to a meeting. Lync Server doesn't place any limit on the maximum number of people you can invite to a meeting; if you want to, you can invite everyone in the world to your meeting.

Like we said, you can invite as many people as you want to a meeting. However, the people who will actually be able to get into that meeting will be determined on a first-come, first-served basis. In other words, by default the first 250 people to show up will be allowed to join the meeting. And what happens to the 251^st person? This:

As you can see, he or she will receive a message stating that the meeting is full, and will be given the option to try again. Of course, that next try will also fail unless someone has dropped out of the meeting and opened up a slot.

The good news is that the user who is unable to join the meeting will know why they aren't able to join the meeting: the meeting is full. However, the meeting organizer won't get a similar notice. During the meeting the organizer will be able to see that Pilar is trying to join the meeting:

However, when Pilar is denied entrance (because the meeting is full) the organizer will only see the following somewhat-misleading message:

As far as we know, there's nothing that can be done about that. That's just the way the system works.

Here's something else you should know about the system and how it works. You can modify the maximum number of people allowed in a meeting by using the CsConferencingPolicy cmdlets and the MaxMeetingSize parameter. For example, this command sets the maximum meeting size in the global conferencing policy to 100 people:

Set-CsConferencingPolicy –Identity global –MaxMeetingSize 100

That's the good news. The bad news is that you can seemingly allow an all-but infinite number of people to participate in a single meeting. Do you want to allow 999,999,999 people to join a meeting? Well, believe it or not, this command will actually work:

Set-CsConferencingPolicy –Identity global –MaxMeetingSize 999999999

So do we recommend that you set the maximum meeting size to 999,999,999. Uh, no. Instead, meeting sizes should be limited to any integer value between 2 and 250, inclusive. You can't go less than 2 (which means that everyone is at least allowed to initiate a peer-to-peer session), and you should never go higher than 250. Yes, you can set MaxMeetingSize to a higher value, but, then again, there are lots of things in life than you can do but shouldn't do.

And this is one of them.

Incidentally, the maximum size of a meeting is a setting that applies to the organizer of a conference. For example, suppose we have two users with two different conferencing policies:

If Pilar Ackerman sets up a meeting, that meeting can have no more than 50 people in it, period. By comparison, if Ken Myer sets up a meeting that meeting can have as many as 250 participants. Suppose Ken Myer is the 51^st person who tries to join one of Pilar's meetings. Will he be allowed in? Nope; any meeting organized by Pilar can have only 50 people. And what if Pilar is the 51^st person who tries to join a meeting organized by Ken; will she be allowed in? You bet she will. Because she's not the meeting organizer, her conferencing policy doesn't apply.

Based on numerous (you know, like two or three) questions we’ve received over the past few months, there seems to be a little confusion around conferencing policies. Why does this policy apply in this case but not in this other case? What’s the difference between a per-organizer setting and a per-user setting? What is a per-organizer setting?

This set of articles, An In-Depth Guide to Conferencing Policy Settings, is our attempt at removing some of the confusion. We walk you through individual policy settings and explain who they apply to, how they apply, and when they apply.

Enjoy.

http://blogs.technet.com/b/csps/archive/2011/08/11/confpoliciesintro.aspx

One cmdlet stands

Tall, as if walking on stilts:

New RGS prompt.

Last night the author of today's haiku caught the last part of Project Runway (which, to be honest, is one more part than he typically catches). He has to admit, however, that last night's edition was definitely an interesting one: for some reason (if only he'd caught the first part of the show!) all the models were walking on stilts.

After what happened to Mondo in last year's Project Runway finale the author of today's haiku vowed he would never watch the show again. (Although, in all honesty, he probably would have made that vow regardless of what happened to Mondo.) Still, last night's show definitely caught his attention, especially when one of the judges noted that he really liked one outfit and that "I could picture that outfit on a woman who wasn't wearing stilts." Ha! Like any self-respecting woman would be caught dead without her stilts. Even the author of today's haiku knows that much about fashion.

Inspired by Project Runway, the author of today's haiku decided to write today's haiku while on stilts! However, in an oversight he'll never forgive himself for, he neglected to pack his stilts for the trip to Park City, UT. As a result, today's haiku is – alas – being written without the use of stilts.

However, the author is sitting in a really tall chair, if that helps.

Fortunately, the New-CsRgsPrompt cmdlet makes for a pretty good show even without a pair of stilts. As you probably know, one important use of the Response Group application is the ability for Lync Server to answer a phone call when no one else is available to answer that call. For example, Lync Server might answer a call, inform the caller that all the agents are currently unavailable, and then tell the caller that someone will be there to help them as quickly as possible. Alternatively, Lync Server might answer the phone and tell the caller that no agents are available after 5:00 PM, and then transfer the call to voice mail. You get the idea.

Anyway, as smart as Lync Server is (and, to be honest, the software is pretty darn smart), the system relies entirely on you to tell it what to say to callers in these situations; you can't just ask Lync Server to answer the phone and then figure out for itself what to say. Instead, you need to create a Response Group prompt, which can be one of two things:

·         An audio file that is played when Lync Server answers the phone ("Please hold; your call is very important to us.").

·         A text-to-speech prompt. You supply the words ("Please hold; your call is very important to us."), and then Lync Server uses its text-to-speech capabilities to "read" those words to the caller.

Regardless of which prompt style you choose (and you can choose both styles if you want) you need to create that prompt by using the New-CsRgsPrompt cmdlet.

Which, fortunately for all of us, we did pack for the trip to Park City.

It's also fortunate for us (or at least those of us who have to write about the cmdlet) that New-CsRgsPrompt is also remarkably easy to use. You say you want to create a new text-to-speech prompt? No problem:

$prompt = New-CsRgsPrompt -TextToSpeechPrompt "Please hold; your call is very important to us."

As you can see, there really isn't much to do here. We simply call the New-CsRgsPrompt cmdlet, making sure to include the TextToSpeechPrompt parameter followed by the text we want Lync Server to read to the caller. It's too bad we didn't bring our stilts, because that's a command we probably could write while walking on stilts.

Probably.

Oh, yeah: you might have noticed that we saved the resulting Response Group prompt to a variable named $prompt. Is that important to know? You might say that: if we didn't do that then our prompt would disappear immediately after we created it. With the prompt saved in a variable we can then add the prompt to a Response Group call action. You know, like this:

$callAction = New-CsRgsCallAction -Prompt $prompt -Action TransferToQueue -QueueID $queue.Identity

And no, sorry, but we won't explain how call actions work; for that, see Haiku #63. The point is, a Response Group prompt is pretty much useless unless that prompt gets added to a call action.

In fact (and this is probably a good thing for you to know) there's no way to save and re-use prompts. Remember the prompt we just created? Well, suppose a week later you'd like to use that same prompt with another Response Group workflow. Can you retrieve that prompt from somewhere (say, by using a Get-CsRgsPrompt cmdlet), or can you maybe copy that prompt from another workflow? No, not really; after all, there's no such thing as a Get-CsRgsPrompt cmdlet. Instead, you'll need to recreate that prompt using New-CsRgsPrompt. And that also means you'll need to re-import any audio files used for making an audio file prompt.

Speaking of audio file prompts, here's how you do that:

$audioFile = Import-CsRgsAudioFile -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -FileName "PleaseHold.wav" -Content (Get-Content C:\Media\PleaseHold.wav -Encoding byte -ReadCount 0)

$prompt = New-CsRgsPrompt -AudioFilePrompt $audioFile 

As you can see, this is a two-part process: first you import the audio file by using the Import-CsRgsAudioFile cmdlet, and then you use the New-CsRgsPrompt cmdlet along with the AudioFilePrompt parameter. And what's the value for the AudioFilePrompt parameter? You got it: the audio file object we just created using Import-CsRgsAudioFile.

And if you want to be really cool, include both a text-to-speech and an audio file prompt in the same Response Group prompt:

$audioFile = Import-CsRgsAudioFile -Identity "service:ApplicationServer:atl-cs-001.litwareinc.com" -FileName "PleaseHold.wav" -Content (Get-Content C:\Media\PleaseHold.wav -Encoding byte -ReadCount 0)

$prompt = New-CsRgsPrompt -AudioFilePrompt $audioFile -TextToSpeechPrompt "Please hold; your call is very important to us."

So what happens if a prompt includes both a text-to-speech prompt and an audio file prompt? Well, by default, Lync Server will first try to play the audio file prompt. Only if that fails will the system resort to using the text-to-speech prompt.

That's pretty much all there is to say about New-CsRgsPrompt. As for models on stilts, the author of today's haiku did a little research and discovered that the Project Runway models were actually professional stilt walking models. (Coincidentally, several years ago the author of today's haiku had to choose between becoming a technical writer and becoming a professional stilt walking model. For some reason, he decided to become a technical writer.) These models work for an entertainment company that can also supply you with belly dancers, living statues, fire-eaters, psychics, and, of course, lipstick analysts. Yet another career option the author of today's haiku gave serious thought to before becoming a technical writer.

See you tomorrow.

The sky rumbles and

Roars. We should talk about voice

Normalization.

Well, it looks like another nice day here in Park City: there are a few clouds in the sky, but the sun is shining and the temperature is expected to creep very close to – if not vault right over – the 80-degree mark. To be honest, there's nothing unusual about that: the author of today's haiku has now been gone for a week, and he has yet to see a day below 82 degrees, pretty nice when you compare it to the temperatures in Seattle for the past week: 68, 70, 73, 75, 70, and 70. For the first time all summer, the author of today's haiku is no longer a pale, pasty shade of white. He's still short and fat, but no longer pale and pasty!

Now, if you happened to drive through Park City at 2:00 AM you might not have expected decent weather today: last night we had thunderstorms, we had lightning, we had torrential rain, and we had gusts of wind blowing so hard that the author and his wife had to get up and close all the windows before their condo blew away. (Remember the tornado scene in The Wizard of Oz? The author of today's haiku half-expected to glance out his window and see his wife furiously peddling through the sky on her mountain bike.)

At any rate, some people might think last night's storm was a sign from heaven, a warning that the author of today's haiku should spend a little less time riding bikes and hiking through the mountains and a little more time actually doing his work. To be honest, the author of today's haikus isn't particularly superstitious (except when he's playing baseball), and he doesn't believe in signs from heaven. Will a little thunder and lightning keep him from enjoying himself while he's out of town? No way.

By amazing coincidence, however, it turns out that what the author of today's haiku enjoys doing is writing about the CsVoiceNormalizationRule cmdlets: Get- CsVoiceNormalizationRule, New-CsVoiceNormalizationRule, Remove-CsVoiceNormalizationRule, Set-CsVoiceNormalizationRule, and Test-CsVoiceNormalizationRule.

As most of you probably know, normalization rules convert the phone number dialed by a user into the E.164 phone number format used by Lync server. For example, suppose you need to make a quick phone call to Ken Myer, whose office is just down the hall. Using the E.164 format, you would need to dial a number similar to this:

+12065551219

Good question: setting aside the fact that you have to include the country code and the area code, how do you dial a + as part of a phone number? And that's the whole point of normalization rules. If you want to call Ken Myer, you shouldn't have to dial his official E.164 phone number; instead, you should be able to just dial his extension: 1219. The job of a voice normalization rule is to take the "simple" phone number dialed by a user (1219) and convert it to something Lync Server can work with (+12065551219).

So how does all this happen? Well, we'd like to tell you that it's magic; then we wouldn't have to try to explain how this all happens. As it turns out, though, there's nothing magical about it: instead, you use regular expressions to tell Lync Server how to convert a certain type of phone number into the E.164 format. Why do we say "certain type of phone number?" Well, if someone dials 1219 we know that's an internal extension number, and we can go ahead and convert that number to +12065551219. How do we convert a four-digit number like that? That's easy: we just tack on +1206555:

+12065551219

But suppose someone else dials this:

12065550712

A number like that probably is not an internal extension. That means we don't want to just tack on +1206555:

+120655512065550712

That's not going to work.

Which simply means that a voice normalization rule really needs to do two things: 1) it needs to identify the type of phone number being dialed; and, 2) it needs to convert that specific type of number to the E.164 format. And, best of all, you get to tell the voice normalization rule how to do all that!

You can see why we find this so much more fun that hiking or mountain biking.

What we’ll do today is show you one example of a voice normalization rule and how you can create that rule using the New-CsVoiceNormalizationRule cmdlet. And, in yet another amazing coincidence, here's that example right now:

New-CsVoiceNormalizationRule -Parent site:Redmond -Name InternalExtensionRule -Description "Dialing with internal four-digit extension" -Pattern '^(\d{4})$' -Translation '+1206555$1'

Let's see if we can explain how this works. To begin with, notice that we didn't use the Identity parameter here. (We could have, but we didn't.) Instead, we used two parameters: Parent and Name. Technically, the Parent parameter specifies the scope at which our new rule is to be created; more practically, the Parent parameter specifies the dial plan where the new rule will be stored. As it turns out, Lync Server won't let you create a voice normalization rule that simply exists on its own. Instead, all voice normalization rules must be associated with an existing dial plan (in this case, the site:Redmond dial plan). Suppose we tried to create this new rule and the site:Redmond dial plan didn't exist. In that case, our command would fail and we'd get back this error message:

New-CsVoiceNormalizationRule : Invalid identity "site:Redmond/InternalExtensionRule": "Cannot add a normalization rule to missing dial plan "site:Redmond". You must create the dial plan first."

The name is simply the unique identifier for that rule. When we say "unique identifier," we mean within that particular dial plan. We just added a rule named InternalExtensionRule to the site:Redmond dial plan. Could we add a rule named InternalExtensionRule to the global dial plan? Sure we could. That's because the Identity for a normalization rule is composed by combining the Parent and the Name properties. Thus these two rules have the same Name, but different Identities:

·         site:Redmond/InternalExtensionRule

·         global/InternalExtensionRule

Next up we have the Pattern parameter (we probably don't need to explain that the Description is simply a description of our new rule):

-Pattern '^(\d{4})$'

The pattern is a regular expression that specifies the number dialed by the user. Now, to be honest, we aren't going to explain regular expressions in today's haiku; that's way too big of a job. (However, for a nice little introduction to regular expressions and voice normalization rules, you might take a peek at this article: http://theucguy.wordpress.com/2010/09/30/ocs-lync-server-normalization-rules). What we will explain, without going into a lot of detail, is that our pattern here looks for dialed numbers that start with 4 digits. The ^ means "starts with;" the \d means digits (numbers); and the {4} means that we're looking for exactly 4 digits. And the $ character means "the end of the phone number." In other words, we're looking for a phone number that consists of just 4 digits: 1219.

And suppose we find a 4-digit number; what then? Well, that's what the Translation pattern is for:

-Translation '+1206555$1'

The Translation pattern tells Lync Server how to translate that 4-digit number into an E.164 number. In this case, we're saying take the 4-digit number (represented by $1) and tack on +1206555. In other words, turn this:

1219

Into this:

+1206555129

Hmmm, maybe it is magic after all.

Oh, and here's something very important: when specifying the Pattern and the Translation parameter values, make sure you surround those values with single quote marks. Why? Well, here's what the Translation property looks like if we use single quotes:

Translation         : +1206555$1

What's wrong with that? Nothing; that's exactly what we want it to look like. But suppose we used double quotes with the Translation parameter, like this:

-Translation "+1206555$1"

If we do that (and we shouldn't do that) our Translation property will look like this:

Translation         : +1206555

If you look closely, you'll notice that $1 has disappeared. (And yes, that is a bad thing.) Why did it disappear? Well, when a parameter value is enclosed in single quotes, PowerShell uses that value exactly as typed:

+1206555$1

However, if you surround a value in double quotes, PowerShell attempts to "interpolate" any variables within that value; in this case, that means it treats $1 as a variable (remember that all variables in PowerShell start with $) and tries to substitute in the value of the variable $1. Because $1 doesn't actually have a value $1 thus gets replace by, well, nothing:

+1206555

Here's a way you can test that: in this example, we're going to set $1 to a value (bob) and then create a new normalization rule:

$1 = "bob"

New-CsVoiceNormalizationRule -Parent site:Redmond -Name InternalExtensionRule -Description "Dialing with internal four-digit extension" -Pattern '^(\d{4})$' -Translation "+1206555$1"

And here are the properties for our new, virtual rule. Note how, in the Translation, $1 has been replaced with bob:

Identity            : site:Redmond/InternalExtensionRule

Priority            : 4

Description         : Dialing with internal four-digit extension

Pattern             : ^(\d{4})$

Translation         : +1206555bob

Name                : InternalExtensionRule

IsInternalExtension : False

The moral of the story? Use single quotes, not double quotes.

We won't spend any time today talking about Get-CsVoiceNormalizationRule, Remove-CsVoiceNormalizationRule, and Set-CsVoiceNormalizationRule; you can probably figure those out for yourself. (Take a look at the help documentation if you can't figure them out for yourself.) However, we will take just a moment to look at Test-CsVoiceNormalizationRule, a handy little cmdlet that lets you verify that your voice normalization rules are working as expected. Here's an example of how to use Test-CsVoiceNormalizationRule:

Get-CsVoiceNormalizationRule -Identity "site:Redmond/InternalExtensionRule" | Test-CsVoiceNormalizationRule -DialedNumber 1219

As you can see, what we've done here is used the Get-CsVoiceNormalizationRule cmdlet to retrieve our InternalExtensionRule rule. We've then piped that rule to Test-CsVoiceNormalizationRule, essentially saying, "Hey, what's going to happen if we use this rule and someone dialed the number 1219?" (Note the DialedNumber parameter.) In turn, we should get output similar to this:

TranslatedNumber

----------------

+1206555bob

Is that good? No, that's bad: our normalization rule gives us a translated number of +1206555bob. (Remember how we intentionally messed up the value of $1?) If we fix our rule (using the original statement to create the Translation with single quotes), we should get back something a little better:

TranslatedNumber

----------------

+12065551219

Needless to say, something a lot better.

Anyway, that's all we have time for today; after all, we have a lot more work to do, and we want to get started on all that work right now, right away.

Just in case any of the weather gods are listening.

See you tomorrow.

Heart-pounding thrills and

Excitement. Must be time for

Simple URLs.

Yesterday afternoon the author of today's haiku (and his wife) took a trip to the Utah Olympic Park. Was it the most exciting time he ever had in his entire life? Probably not. Still, it was interesting. For example, he learned why Park City, UT – smack-dab in the middle of the desert – gets as much snow as it does. (An average of 360 inches per year at the Jupiter ski lift located just outside of town.) Likewise, he learned how heavy a curling stone actually is. (Surprisingly heavy, although, considering the fact that curling stones are made of granite, that probably shouldn't have come as that much of a surprise to him.)

The author and his wife hiked around a bit, but didn't try any of the thrill rides available at the Park. They watched the bobsleigh (its official name), but they didn't ride it. That was pretty much a matter of being too cheap: at $60 apiece for a 1-minute ride, that just didn't seem worth it. (Especially since you don't actually get to either drive or push the bobsleigh.) As the author's wife noted, that's $1 per second for each ride, and that just seemed a bit much to pay for such a short ride.

The Xtreme Zipline was much more affordable, but with the Xtreme Zipline you sit in a little harness suspended 100 feet high in the air, then get rocketed down the mountainside at speeds in excess of 50 miles per hour. (From what we've been told, the Xtreme Zipline is the "fastest and steepest" zipline in the world. The world!) The author and his wife didn't ride the Xtreme Zipline because – well, it doesn't really matter why the author and his wife didn't ride the Xtreme Zipline. Let's just say that one of them isn't really a thrill-seeker, especially when heights are involved.

On the other hand, one of them obviously is a thrill-seeker. After all, if he wasn't a thrill-seeker then he wouldn't dare to write a haiku about – gasp – the New-CsSimpleUrlEntry cmdlet!

As the name implies, the New-CsSimpleUrlEntry cmdlet is used to help create simple URLs. Simple URLs are, to put it simply, one of Microsoft Lync Server 2010's better innovations. Back in the old days (that is, back in the days of Office Communications Server 2007 R2) people could schedule online meetings. That was good. What wasn't so good is the kind of URL that was generated for those meetings. For example:

https://imdf.litwareinc.com/Join?uri=sip%3Akenmyer%40litwareinc.com%3Bgruu%3Bopaque%3Dapp%3Aconf%3Afocus%3Aid%3A125f95a0b0184dcea706f1a0191202a8&key=EcznhLh5K5t

Try reading that URL to someone over the phone.

You know, unless you're chicken or something.

Anyway, in Lync Server 2010 simple URLs provide a way for you to create meeting URLs that are, well, simpler. For example, here's a Lync Server meeting URL:

https://meet.litwareinc.com/kenmyer/071200

Granted, fellow thrill-seekers will find URLs like that a bit dull. But they are a little easier to work with.

For today's haiku, we're going to skip over the infrastructure requirements for setting up simple URLs; you can get more information on that in Haiku #29. We're also going to largely skip past the use of the New-CsSimpleUrl cmdlet; that's something we'll cover in tomorrow's exciting conclusion to this two-part series. (By the way, this is a two-part series.) Do we really need a two-part series to cover simple URLs? No. We really need a 10-part series. But we're going to try and cover it all in just two parts.

So what does the New-CsSimpleUrlEntry cmdlet do? Well, to create a simple URL in Lync Server is actually a three-step process:

1.    You must specify the actual URL (e.g., https://meet.litwareinc.com) that will be used for online meetings. This is done using the New-CsSimpleUrlEntry cmdlet.

2.    You must create a simple URL that, among other things, references the URL you just created. The simple URL is created using the New-CsSimpleUrl cmdlet (which we'll discuss tomorrow).

3.    You must add the newly-created simple URL to a collection of simple URLs.

Confused? We don't blame you. But here's what the process actually looks like:

$urlEntry = New-CsSimpleUrlEntry -Url "https://meet.fabrikam.com"

$simpleUrl = New-CsSimpleUrl -Component "meet" -Domain "fabrikam.com" -SimpleUrl $urlEntry -ActiveUrl "https://meet.fabrikam.com"

Set-CsSimpleUrlConfiguration -Identity "site:Redmond" -SimpleUrl @{Add=$simpleUrl}

As you can see, in line 1 we specify our URL by using the New-CsSimpleUrlEntry cmdlet. Note that New-CsSimpleUrlEntry has only one parameter: URL. You simply specify the URL you want to use for (in this case) online meetings and then stash that URL in a variable (in this example, $urlEntry). That variable will then be used in line 2, where we create a simple URL that also gets stored in a variable ($simpleUrl). Finally, in line 3 we use the Set-CsSimpleUrlConfiguration cmdlet to actually write that new simple URL to Lync Server.

But we'll worry about lines 2 and 3 tomorrow. For today, let's just focus on the first line in our set of commands:

$urlEntry = New-CsSimpleUrlEntry -Url "https://meet.fabrikam.com"

Like we said, there really isn't much to creating a simple URL entry. However, there are a few things you need to know about the kind of URL you can, and cannot, create. If you actually want your simple URLs to work, and if you actually want your users to be able to schedule online meetings, then make sure that your URL:

·         Begins with https:// (the http: protocol is not allowed).

·         Does not have the same name as any of your Lync Server computers or pools.

·         Does not include a query string parameter (for example, something like https://meet.fabrikam.com/meet.htm?type=meeting).

·         Is a valid fully qualified domain name.

And here's something really important: the domain referenced in the simple URL must be a valid SIP domain. All simple URLs must reference a valid SIP domain, and all of your SIP domains must have a collection of simple URLs. Why? Well, when a user schedules an online meeting, Lync Server retrieves the SIP domain for that user and then looks up the corresponding simple URLs for that domain. If the SIP domain doesn't exist, or if the corresponding URLs don't exist, then Lync Server cannot create a meeting URL. And without a meeting URL you can't have an online meeting.

Period.

Too much excitement for one day? Well, now you can see why we decided to turn this into a two-part series. Try to calm yourself down a bit, get a good night's sleep, and tomorrow we'll talk a little bit about the New-CsSimpleUrl cmdlet.

Brace yourselves.