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

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

It's like magic but

Better. That can only be

Simple URLs.

Hello everyone, and welcome to the Lync Server PowerShell haiku of the day. Today's topic: the Test-CsCertificateConfiguration cmdlet!

Whoa, hey, take it easy: we were just kidding. Trust us, we haven't forgotten that, in yesterday's haiku, we promised that today's haiku would be about the New-CsSimpleUrl cmdlet. We were just having a little fun with you, sort of like – after the first Harry Potter book was published – J. K. Rowling announced that her next book would be a scientific treatise on the digestive system of the common North American earthworm.

To briefly recap yesterday's haiku (and set the stage for today's haiku), 24 hours ago we noted that the process of creating simple URLs was really a three-step process. (And what exactly is a simple URL? See yesterday's haiku for details.) To create a simple URL you need to:

1.    Specify the actual URL (e.g., https://meet.litwareinc.com) that will be used for online meetings. That's done by using the New-CsSimpleUrlEntry cmdlet.

2.    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 talk about in a few minutes.

3.    Add the newly-created simple URL to a collection of simple URLs (something which we discussed a long, long time ago).

Or, if you prefer code over blather (hint: if you do, you've come to the wrong place):

$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}

In today's haiku we're going to focus on this line of code (which, in our opinion, is better PowerShell code than you'll find in any of the Harry Potter books, including Harry Potter and the Half-Blood Prince!):

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

Before we discuss this command in any detail, let's talk about the three kinds of simple URLs that Lync Server allows you to create:

·         Meet – Provides simple URLs for online meetings. You must have at least one Meet URL for each of your SIP domains.

·         Admin – Provides a simple URL for the Lync Server 2010 Control Panel.

·         Dialin – Provides a simple URL for the Dial-in Conferencing Web page.

The Admin and Dialin simple URLs are optional; if you don't bother to create a simple URL for Dialin, users will still be able to access the Dial-in Conferencing Web page; they just won't be able to do so using a URL like https://dialin.fabrikam.com. However, the Meet URL is a different story. When you install Lync Server, no simple URLs are pre-created for you; you have to create all these URLs yourself. Suppose you decide to skip the Meet URL and create just an Admin URL instead. Here's what will happen when you try to add that URL to a simple URL collection:

Set-CsSimpleUrlConfiguration : There must be an Active URL for Meet for each SIP Domain.

And before you ask, no, there's absolutely no way around that. You must create a Meet simple URL before you can create any other simple URLs. And, as we noted yesterday, you must have a simple URL for each of your SIP domains. Otherwise you're going to run into problems.

Oh, and as long as we're on the subject, every simple URL you create must point to a real, live SIP domain. Suppose you decide to create a few simple URLs now, and then figure you'll create the corresponding SIP domains later. Is that going to work? Nope:

Set-CsSimpleUrlConfiguration : Simple URL cannot be specified for a nonexistent SIP Domain.  Please add the SIP Domain first.

OK, let's go back to our New-CsSimpleUrl command:

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

As you can see, when we call New-CsSimpleUrl we need to first specify the type of URL we are creating (the Component) as well as the URL domain (in this example, fabrikam.com). We also need to include the SimpleUrl parameter followed by the simple URL entry (Web address) that we created using the New-CsSimpleUrlEntry cmdlet. If you've forgotten about that command, it looks a lot like this:

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

Finally, we need to indicate which simple URL is the active URL, the URL that will actually be employed by your users. A simple URL can contain multiple URLs, but only one of those URLs can be active at any time.

If all goes well, we'll end up with a new Meet URL in (in this case) the Redmond site:

Identity  : site:Redmond

SimpleUrl : {Component=meet;Domain=fabrikam.com;ActiveUrl=https://meet.fabrikam.com}

And what if we wanted to create all three simple URL types, and all three at the same time? No problem:

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

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

$urlEntry2 = New-CsSimpleUrlEntry -Url "https://admin.fabrikam.com"

$simpleUrl2 = New-CsSimpleUrl -Component "admin" -Domain "fabrikam.com" -SimpleUrl $urlEntry2 -ActiveUrl "https://admin.fabrikam.com"

$urlEntry3 = New-CsSimpleUrlEntry -Url "https://dialin.fabrikam.com"

$simpleUrl3 = New-CsSimpleUrl -Component "dialin" -Domain "*" -SimpleUrl $urlEntry3 -ActiveUrl "https://dialin.fabrikam.com"

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

Just a couple things to note about these commands. As you can see, we had to create separate URL entries and simple URLs for each component: Meet, Admin, and Dialin. And then when we called the Set-CsSimpleConfiguration cmdlet, we simply had to specify all three of the variables containing the simple URLs. In other words:

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

It's not hard, it's just something you need to watch out for.

Oh, and here's something else to watch out for: always use the Add method when adding a new simple URL:

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

Why does that matter? Well, that will add a new URL to your collection. This syntax is perfectly valid:

Set-CsSimpleUrlConfiguration -Identity "site:Redmond" –SimpleUrl $simpleUrl

However, that syntax will replace all your existing simple URLs with the one URL contained in the variable $simpleUrl. If that's what you want to do, well, then go for it. But if you just wanted to add $simpleUrl to the collection, make sure you do it like this:

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

Needless to say, that's a lesson some of us learned the hard way.

That's pretty much all for today. We've got to go change clothes and head off to a meeting with a representative from Disney. You just wait, J. K. Rowling: Lync Server PowerShell World isn't dead yet. Not by a long shot.

Break glass in case of

A haiku emergency.

Import announcements.

OK, so, originally we planned to have a really exciting and interesting haiku for you today. (Hey, who said, "Well, that would be a nice change"?) Like we said, we planned to have a really exciting and interesting haiku for you today but then … stuff … began to happen, most of it happening between the hours of 3:00 AM and 6:00 AM, and most of it involving an issue that turned out not to be an issue after all, and a long car trip that turned out not to be a long car trip after all.

At any rate, all's well that ends well and in this case, at least, everything ended perfectly well. Except for one thing: somewhere along the way, we must have misplaced our really exciting and interesting haiku, because the only haiku that we could find was this one.

Bummer.

Fortunately, though, there's a bright side here: after all, there's no such thing as a truly bad Lync Server PowerShell haiku. (OK, good point. But we didn't write that one.) And today's haiku is no exception; after all, today's topic is the Import-CsAnnouncementFile cmdlet. Which means that, now that we think about it, we just might have a really exciting and interesting haiku for you after all.

So what's an announcement file? Well, with Lync Server you will likely have valid phone numbers that are currently not assigned to a user. If you want, you can configure an audio file to be played any time someone dials one of those unassigned numbers. For example, you might play a recording that says something like "We're sorry, but the number you have dialed is not currently in service. Your call will now be transferred to our receptionist." Alternatively, you might play In-A-Gadda-Da-Vida by Iron Butterfly. It's entirely up to you.

The important thing is that you can play an audio file (a .WAV or .WMA file) of some kind whenever someone dials an unassigned number (and right before you would then typically transfer that call to another user, to voicemail, etc). And how do you import one of these announcement files to Lync Server 2010? Why, like this, of course:

Get-Content "C:\AudioFiles\NoOneIsHere.wav" -ReadCount 0 -Encoding Byte | Import-CsAnnouncementFile -Parent ApplicationServer:atl-cs-001.litwareinc.com -FileName "NoOneIsHere.wav"

What exactly have we done here? Well, we've first used the Get-Content cmdlet to retrieve the contents of the file C:\AudioFiles\NoOneIsHere.wav. Note that we've also included the ReadCount and the Encoding parameters. Setting the ReadCount to 0 ensures that the file is read in all at the same time (as opposed to being read in piece-by-piece), while setting the Encoding property to Byte tells Get-Content to read the file as a series of bytes rather than, say, a series of plain-text characters.

After we've retrieved the file using Get-Content, we then save that file to Lync Server by using the Import-CsAnnouncementFile cmdlet. To do that we need to specify the service location of the Application Server where the file will be stored (in this case, that's ApplicationServer:atl-cs-001.litwareinc.com) and we need to give the file a file name. For this file, that file name is NoOneIsHere.wav.

As soon as you've imported the file, it can then be used by the Lync Server announcement service. We won't discuss the details in today's haiku (after all, we already discussed the details in haiku #31), but here's a sample command that turns our imported file into a real, live announcement:

New-CsAnnouncement -Identity ApplicationServer:atl-cs-001.litwareinc.com -Name "No One is Here" -AudioFilePrompt "NoOneIsHere.wav"

That's all you have to do.

Coincidentally enough, that's all that we have to do, at least for now. But don't worry: we're going to spend the rest of the day writing Lync Server PowerShell haikus and storing them away in case of emergency. Next time, we're going to be better prepared.

See you tomorrow.

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.