Kerberos? OK,

Then you can come in. Proxy

Configuration.

TGIF: Thank God it's Friday! Needless to say, after a difficult week in which he had to work two days in a row, the author of today's haiku is excited to see the weekend coming. And not a moment too soon.

You know, we wondered the same thing: is working two days in a row the most days in a row than anyone has ever had to work? Surprisingly, the answer is this: no, it's not. The author of today's haiku didn't have much luck determining the world's record for most consecutive days at work, but he did find evidence of tons of people who've worked for more than 100 days in a row. As near as he can tell, there really aren't a lot of laws governing the number of days you have to work in a row. If you work more than 40 hours in a week your employer has to pay you for those extra hours, but if you have to work 2 days in a row, or even more than that, well ….

At any rate, although we're obviously a bit tired after this long week, we still have a job to do: we have to tell everyone about the CsProxyConfiguration cmdlets (Get-CsProxyConfiguration, New-CsProxyConfiguration, Remove-CsProxyConfiguration, and Set-CsProxyConfiguration). Now, to be perfectly honest, we're not sure that the name CsProxyConfiguration is the best name that could have been given to these cmdlets. (On the other hand, we're even less sure what that best name would be.) Why do we say that? Well, to begin with, the CsProxyConfiguration cmdlets are used to help govern the client-server relationships for Edge servers and Front End servers. That's good; that's something you definitely do want to manage.

However, traditionally the term proxy refers to a proxy server, a computer that acts as an intermediary between a client and a server: the client sends a request to the proxy server, the proxy server forwards the request to the server, the server sends an answer back to the proxy server, and then the proxy server shuffles the answer on to the client. (Yes, just like the old gag, "Well, you tell her that she can just ….") That's actually a pretty good (albeit highly-simplistic) definition of what an Edge server does. But is it an equally good definition of what a Front End server does? Well ….

But all that's beside the point. (Or at least we assume it is, seeing as how we can't remember what the point was in the first place.) The important thing to note is that client-server relationships can be managed using the CsProxyConfiguration cmdlets. And that includes the one thing that everyone wants to manage: the authentication mechanisms that client applications can use to log on to Lync Server.

And who are we to argue with the product team, right? With that in mind, let's review the three authentication settings available to you:

·         UseCertificateForClientToProxyAuth. When set to True (the default value), client endpoints can use certificates for authentication.

·         UseKerberosForClientToProxyAuth. When set to True (the default value), client endpoints can use the Kerberos protocol for authentication. Although Kerberos is a more secure protocol than NTLM, it cannot be used if the client belongs to a different domain than the server.

·         UseNtlmForClientToProxyAuth. When set to True (the default value), client endpoints can use the NTLM protocol for authentication. Although NTLM is a less secure protocol than Kerberos, NTLM can be used if the client belongs to a different domain than the server. That is not true for Kerberos authentication.

As you can see, by default client applications can log on using certificates, Kerberos authentication, or NTLM authentication. But suppose you don't want to allow certificate-based logins; what can you do about that? Well, one thing you can do is use the Set-CsProxyConfiguration cmdlet to disable certificate authentication:

Set-CsProxyConfiguration –Identity global –UseCertificateForClientToProxyAuth $False

If you only want to allow Kerberos authentication, then turn off both NTLM and certificate authentication:

Set-CsProxyConfiguration –Identity global –UseCertificateForClientToProxyAuth $False –UseNtlmForClientToProxyAuth $False

That's all you have to do.

Speaking of NTLM authentication, here's an interesting little parameter that no one knows about: DisableNTLMFor2010AndLaterClients. What's so interesting about that little parameter? Well, suppose you have some older client applications that can't use Kerberos authentication; that means you can't turn off Kerberos authentication altogether. However, what you can do is set DisableNTLMFor2010AndLaterClients to True. If you do, Lync Server will allow older clients to use NTLM authentication; however, anyone running Microsoft Lync 2010 (or a later version) will not be allowed to use NTLM authentication. Instead, all those shiny new client applications will have to use Kerberos.

Oh, yeah, we almost forgot: here's what the code for that looks like:

Set-CsProxyConfiguration –Identity global –DisableNTLMFor2010AndLaterClients $True

As you probably already guessed, the Set-CsProxyConfiguration cmdlets are used to modify existing proxy configuration settings. What if you wanted to create new proxy configuration settings? No problem: just use the New-CsProxyConfiguration cmdlet. New settings can be configured at the site scope or at the service scope (for either the Edge service and/or the Registrar service). For example, suppose you don't want to allow certificate authentication on one of your Edge servers. How do you prevent that? Like this:

New-CsProxyConfiguration –Identity "service:EdgeServer:atl-edge-001.litwareinc.com" –UseCertificateForClientToProxyAuth $False

Just specify the Identity of the Edge server in question, and away you go.

And here's an exciting variation on the preceding command: it creates new proxy settings for all your Edge servers:

Get-CsService –EdgeServer | ForEach-Object {New-CsProxyConfiguration –Identity $_.Identity –UseCertificateForClientToProxyAuth $False}

The fun just never stops, does it?

And what if you later decide to delete some (or even all) of these handmade proxy configuration settings? As you might expect, that's the job of the Remove-CsProxyConfiguration cmdlet. For example:

Remove-CsProxyConfiguration –Identity "service:EdgeServer:atl-edge-001.litwareinc.com"

Or how about this example, which removes all the settings configured for individual Edge servers:

Get-CsProxyConfiguration –Filter "service:EdgeServer:*" | Remove-CsProxyConfiguration

Pretty cool, huh? In this case, we used the Get-CsProxyConfiguration cmdlet and the Filter parameter to return all the proxy configuration settings that have an Identity that begins with the string value service:EdgeServer:; by definition, those are going to be settings configured for an individual Edge server. And then, of course, we pipe that collection to the Remove-CsProxyConfiguration cmdlet, which proceeds to get rid of all the settings in that collection.

Which reminds us: we should probably mention that Get-CsProxyConfiguration lets you return information about your existing proxy configuration settings. For example, suppose someone asks if any of your proxy configuration settings prohibit certificate authentication. How can you determine the answer to that question? Why, by running this command, of course:

Get-CsProxyConfiguration | Where-Object {$_.UseCertificateForClientToProxyAuth -eq $False}

And so on and so on.

That's about all we have for today; after all, the weekend is practically here. We'll see you again on Monday, the first day of our heroic effort to try to work five days in a row. Will we succeed? Only time will tell.

But don't count on it.

Natural beauty?

True beauty comes from CS

Conferencing settings.

Well, we're back. (Oh, please don't say you didn't even know we were gone: that hurts.) The author of today's haiku has spent the past few days in Moab, Utah, and has spent most of that time hiking every hikeable trail in Arches National Park. That meant he's spent the past few days trudging through deep sand and clambering over narrow rock ledges, all in weather over 100 degrees, with no shade, no place to stop and rest, and no food or water other than what you were able to carry with you.

And yet still he found that to be better than working. Go figure, huh?

At any rate, if you've never been there, the author of today's haiku highly recommends that you take a trip to Arches someday. (Here are a whole bunch of reasons why you might want to do that.) And sure, you probably could go to Arches sometime other than in August; that's something to think about if traipsing through the desert as the temperature climbs to 104 degrees Fahrenheit doesn’t necessarily appeal to you. Would we call you a wimp if you went, say, in April, when the average temperature is way closer to 60 degrees than to 100 degrees Fahrenheit? You bet we would. But what difference should our opinion make? That's what we thought.

The one thing that the author of today's haiku learned while at Arches National Park is that the same questions keep popping up over and over again, number one being, "Where are the bathrooms?" And the answer being, "For the most part, there aren't any."

Other questions that popped up from time-to-time included: 1) How are the arches formed? (Typically through wind and water erosion); 2) Does the park really rest on a giant layer of sand? (Yes, sand left over from huge seas which once covered the area some 300 million years ago); and, 3) How can I specify the maximum values for such things as conferencing handouts or conference content grace periods?

Well, as the park rangers patiently explained over and over again, the answer to the last question is a little more involved than the answer to some of the other more-frequently asked questions. (How many restaurants and concession stands are there in the park? Zero.) But there is a short and snappy answer: by using conferencing configuration settings. And how do you manage conferencing configuration settings? You got it: by using the CsConferencingConfiguration cmdlets (Get-CsConferencingConfiguration, New-CsConferencingConfiguration, Remove-CsConferencingConfiguration, and Set-CsConferencingConfiguration).

So what exactly are conferencing configuration settings? Essentially, conferencing configuration settings provide a way for you to manage the server side of your online conferences; for example, you can use these settings to specify the ports used for such things as client audio, client video, and client file transfers. You say that's not what you want to do, that you actually want to manage what your users can do in a conference? Well, in that case, you want to use conferencing policies. For more information on conferencing policies, contact the National Park Service.

Or, even better, see Haiku No. 175.

So is any of this hard to do? Not really, but it can be a little tricky. For example, by default Lync Server is configured to use any port between 1024 and 65535 (inclusive) for media traffic (e.g., audio, video, and file transfer). Suppose you don't really like that, suppose you'd like to limit the ports used for media traffic. In that case, you need to do a couple of things. To begin with, you need to enable the use of client media port ranges; that is, you need to tell Lync Server you want to use a specific set of ports for, say, client audio as opposed to any old port between 1024 and 65535. How do you do that? That's easy: you just set the ClientMediaPortRangeEnabled property to True. For example:

Set-CsConferencingConfiguration –Identity global –ClientMediaPortRangeEnabled $True

And if you decide later to go back to using any old port? Then just reset ClientMediaPortRangeEnabled to False:

Set-CsConferencingConfiguration –Identity global –ClientMediaPortRangeEnabled $False

But wait, that's not all. When you install Lync Server, default port ranges for different media traffic are preconfigured for you. For example:

ClientAudioPort                    : 5350

ClientAudioPortRange               : 40

ClientVideoPort                    : 5350

ClientVideoPortRange               : 40

ClientAppSharingPort               : 5350

ClientAppSharingPortRange          : 40

ClientFileTransferPort             : 5350

ClientFileTransferPortRange        : 40

In other words, client audio will use ports 5350 through 5389. How do we know that? Because client audio starts on port 5350 (ClientAudioPort) and uses a total of 40 ports. To the best of our mathematical ability, that means ports 5350 through 5389.

If that's OK with you, well, then that should be OK with you. But suppose you'd prefer to use ports 6000 through 6499 for audio. In that case, you need to use a command similar like this to configure the starting audio port and total number of ports set aside for audio traffic:

Set-CsConferencingConfiguration –Identity global –ClientAudioPort 6000 –ClientAudioPortRange 500

And, of course, we could have enabled port ranges and configured the audio port settings by using just one command:

Set-CsConferencingConfiguration –Identity global –ClientMediaPortRangeEnabled $True –ClientAudioPort 6000 –ClientAudioPortRange 500

That's entirely up to you.

About the only limitations we're aware of are this. First, each port range must have at least 20 ports; don't try to set an audio port range that starts at port 5350 and ends at 5351. The cmdlets will let you do that, but it's not recommended.

Unless you don’t care whether your conferences actually work or not.

Second, if you want to employ Quality of Service then your different media types (such as audio or video) should have unique port ranges. By default, all the different media traffic use the same port settings: a starting port of 5350, and a total number of 40 ports. To keep things unique, you might want to do something similar to this:

But, again, if you aren't using Quality of Service then it doesn't really matter.

The only other tricky thing to watch out for is setting the content grace period, which specifies how long conference content remains on the server following the end of a meeting. The content grace period can be any value between 30 minutes and 180 days. That's not too tricky; the tricky part is how you specify that value. To set a content grace period to something less than 24 hours, use syntax like this:

Set-CsConferencingConfiguration –Identity global –ContentGracePeriod 23:00:00

The 23 represents the number of hours, the first 00 represents the number of minutes, and the second 00 represents the number of seconds. (You can actually leave the second 00 off if you simply can't bring yourself to type another 00.)

Now, suppose you'd like to set your content grace period to a day and a half: 36 hours. This command will not work:

Set-CsConferencingConfiguration –Identity global –ContentGracePeriod 36:00:00

Instead, you'll get this error message:

Set-CsConferencingConfiguration : Cannot bind parameter 'ContentGracePeriod'. Cannot convert value "0.36:00:00" to type "System.TimeSpan". Error: "The TimeSpan could not be parsed because at least one of the hours, minutes, or seconds components is outside its valid range."

Granted, it might not be obvious what you did wrong. (OK, what we did wrong.) But what we did wrong was to set the hours to 36; we can't do that, because a day can only have a maximum of 24 hours. (Unless you're on Pluto, where a day can have approximately 154 hours.) To set a content grace period of 36 hours we need to use this command:

Set-CsConferencingConfiguration –Identity global –ContentGracePeriod 1.12:00:00

In other words, 1 day, 12 hours, 00 minutes, and 00 seconds.

And there you have it. The New-CsConferencingConfiguration cmdlet provides a way for you to create new conferencing configuration settings at the site or service scope (albeit only for the Conferencing server service). You can use Remove-CsConferencingConfiguration to delete any of those settings you just created using New-CsConferencingConfiguration, and, of course, you can use Get-CsConferencingConfiguration to return information about your existing settings. Do you have any settings where the client media port range has been enabled? This command will tell you:

Get-CsConferencingConfiguration | Where-Object {$_.ClientMediaPortRangeEnabled -eq $True}

How about any settings where the content grace period is less than 1 day? Well, try this command:

Get-CsConferencingConfiguration | Where-Object {$_.ContentGracePeriod -lt "1.00:00:00"}

And yes, commands like that do make you wonder why someone would drive all the way down to Moab, UT when he could have spent that time sitting at the dining room table running the CsConferencingConfiguration cmdlets instead.

Apparently there's just no accounting for taste.

See you tomorrow.

Port 8061?

That's unacceptable! Set

CS Web Server.

For those of you who've been keeping track, the author of today's haiku has now worked for eight consecutive days. (That's right, eight!) That can only mean one thing: it's time for him to take a few days off.

At any rate, as the author of today's haiku pursues the vacation part of his vacation/work-remotely, that means that this will be the last Lync Server PowerShell haiku of the day until Thursday, August 25^th. Originally, we were going to do one those good news/bad news things here. But when we told people that there would be more daily haikus starting next Thursday they told us they couldn't help us come with the good news part.

There were, however, plenty of suggestions for the bad news part.

As you might expect, any time you leave for vacation there are plenty of things to do: stop the newspaper delivery; put plenty of food out for the cat; make sure all the house plants have been watered. Of course, because the author of today's haiku is already on vacation (you know you're getting lazy when you feel the need to take a vacation from your vacation) he didn't have to do any of those things. Therefore, he decided to do the one thing that vacation-goers always want to do before they leave, but never seem to have time for: he decided to write a haiku about the Set-CsWebServer cmdlet.

Although, to be perfectly honest, there really isn't much to say about Set-CsWebServer. As is the case with most of the server role cmdlets (like, say, Set-CsApplicationServer), Set-CsWebServer is a pretty simple little cmdlet: its primary purpose is to enable you to specify the ports used for various types of Web traffic. For example, one of the protocols used by Lync Server Web servers is the PSOM (Persistent Shared Object Model) protocol; this protocol is used for Web conferencing content such as conference ID, security keys, expiration time, and user roles and privileges. By default, the PSOM protocol uses port 8061 for anyone connecting to a conference from outside your organization's firewall. But suppose port 8061 won't work for you; suppose you need to change that to port 8062? Hey, all you had to do was ask:

Set-CsWebServer -Identity "WebServer:atl-cs-001.litwareinc.com" –ReachExternalPsomServerPort 8062

That's all you have to do. Want to change both the HTTP and HTTPS ports for your internal users? Hey, why not? After all, that's as easy as this:

Set-CsWebServer -Identity "WebServer:atl-cs-001.litwareinc.com" –PrimaryHttpPort 81 –PrimaryHttpsPort 444

The only even remotely tricky part about using the Set-CsWebServer cmdlet crops up when you want to configure ports for application sharing; this is tricky simply because you can configure a range of ports for application sharing. (If you do that, then any time someone shares an application, Lync Server will dynamically choose one of the ports in that range.) By default, Lync Server sets aside 16,383 ports for application sharing, starting with port 49152 and continuing on from there. You say you don't like that? You say that you'd rather start at port 50000 and set aside 6000 ports for application sharing? That's fine; all you have to do is call Set-CsWebServer and specify the initial port (50000) and the total number of ports to be used for application sharing (6000). In other words:

Set-CsWebServer -Identity "WebServer:atl-cs-001.litwareinc.com" –AppSharingPortStart 50000 –AppSharingPortCount 6000

If you do the math, that means ports 50000 through 55999 (a total of 6000 ports) will be reserved for application sharing.

Actually, now that we think about it, there are a couple of other slightly-tricky aspects to the Set-CsWebServer cmdlet. For example, how did we know that the default port used for PSOM traffic is port 8061? Well, for one thing, we are highly-trained and highly-skilled Microsoft professionals.

OK, we didn't really expect anyone to buy that. To be honest, we simply ran to the Get-CsService cmdlet (along with the WebServer parameter) to retrieve that information:

Get-CsService –WebServer

That's going to return all sorts of information about your Web servers, including the current port settings.

The other thing that can be a little tricky is the fact that you can't directly pipe objects to the Set-CsWebServer cmdlet. Big deal, you say? Well, it can be. For example, suppose you wanted to set the PrimaryHttpPort for all your Web servers to port 81. This command won't cut it:

Get-CsService –WebServer | Set-CsWebServer –PrimaryHttpPort 81

Instead, you'll get the following error message:

Set-CsWebServer : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input.

If you want to set multiple Web servers with a single command, you'll need to pipe the data to the ForEach-Object and then let ForEach-Object call the Set-CsWebServer cmdlet.

You seem a bit confused. Maybe it would help if we showed you an example:

Get-CsService –WebServer | ForEach-Object {Set-CsWebServer –Identity $_.Identity –PrimaryHttpPort 81}

All we've done here is use the Get-CsService cmdlet (and the WebServer parameter) to retrieve a collection of all our Lync Server Web servers. We've then piped that data to the ForEach-Object cmdlet, which takes each Web server in the collection, grabs the Identity of that Web server ($_.Identity) and then uses Set-CsWebServer to change the HTPP port. It might look a little confusing at first, but think about it for a second and you should see what it's doing, and why.

As for what we're doing, we're taking a few days off. And why are doing that? Do you even have to ask?

See you next week.

Utah: the land of

Mountains, smiles, Beetdiggers, and

Conference policies.

As you no doubt know by now, the author of today's haiku is currently in Utah, partly to take a few days of vacation here and there, and partly to do his regular old work. (Based on the kind – and amount – of work he does, he can easily do that from Redmond, from Utah, or even from the dark side of the Moon.) And because he is supposed to be working from time-to-time, he thought he'd start out today's haiku by reporting on some of the things he's learned during his stay in Utah:

·         Up until a couple of years ago, Utah required bars and restaurants to install a "Zion curtain," a partition that separated a bartended from his or her customers. The Zion curtain is no longer required; however, new bars and restaurants are required to mix drinks in a separate part of the building, where the bartenders can't be seen by customers.

·         Like most newspapers, the Salt Lake Tribune does restaurant reviews: 3 stars is exceptional; 2 stars is very good; 1 star is good. What about a restaurant that isn't very good, that is downright bad? Hey, this is Utah, and the people are incredibly nice here: they would never write a review that called a restaurant bad!

·         Jordan High School's nickname is The Beetdiggers. To be honest, the author of today's haiku was a little disappointed by that. The Fighting Beetdiggers would have been way cooler. "Ladies and gentlemen, your Jordan High School Fighting Beetdiggers!"

·         In Utah, everyone's favorite set of Lync Server cmdlets is the CsConferencingPolicy cmdlet set: Get-CsConferencingPolicy, Grant-CsConferencingPolicy, New-CsConferencingPolicy, Remove-CsConferencingPolicy, and Set-CsConferencingPolicy.

So what makes the CsConferencingPolicy cmdlets so popular? Well, to tell you the truth, we can't really speak for the people of Utah. (Nor would they really want us to.) Speaking for ourselves, however, we like the CsConferencingPolicy cmdlets simply because we've already written a whole bunch of articles about these cmdlets (for example, An In-Depth Guide to Conferencing Policy Settings). That means that we won't have to write very much for today's haiku: we'll just refer you to all our previous articles (such as No Conferencing Policy is an Island: Per-Organizer Settings vs. Per-User Settings).

As the name implies, conferencing policies determine what users can and cannot do while in a conference. (In Lync Server, a conference is roughly defined as a communication session involving 3 or more people. A session involving just 2 people is generally referred to as a peer-to-peer session.) For example, there are conferencing policy settings that determine whether users can transfer files within a conference; settings that determine whether users can use video within a conference; and settings that determine whether users can record conferences that they take part in.

What the name doesn't imply, however, is the fact that conferencing policies are also used to determine what users can and cannot do while in a peer-to-peer session: there are also conferencing policies that manage file transfers, video use, and recording within peer-to-peer sessions. That's important to know, because the Microsoft Lync features available to a user might change depending on whether or not a user is in a conference or a peer-to-peer session. For example, suppose Ken Myer is in a conference where file transfers are allowed. There are currently three people in this conference.

Now, suppose one of those three people drops out. At that point, you no longer have a conference: you now have a peer-to-peer session. And if Ken's conferencing policy doesn't allow him to do peer-to-peer file transfers then, just like that, Ken will no longer be able to do peer-to-peer file transfers. In many cases there's a sharp distinction drawn between the things you can do in a conference and the things you can do in a peer-to-peer session.

A little confusing? Possibly. What's even more confusing is the fact that some settings apply to the organizer of a conference and some settings apply to the individual users in a conference. We won't go into a whole lot of detail on that topic today; instead, we'll take the easy way out and refer you to a previous article on that very subject. Briefly, however, let's take the AllowIPVideo setting as an example. This setting applies to the organizer of a conference, which means it also applies to every single person who joins that conference. Suppose Ken Myer is not allowed to use video in conferences he organizes (AllowIPVideo is False). If Ken organizes a conference no one will be able to use video in that conference; Ken's conferencing policy won't allow it. (With a per-organizer setting, the only conferencing policy that matters is the organizer's conferencing policy.)

What's that? You say Ken has been invited to a meeting hosted by Pilar Ackerman, and Pilar's policy allows IP video? That's cool: Pilar will thus be able to use video in her conference, and so will everyone who joins that conference, including Ken Myer. Remember, the only conferencing policy that matters is the organizer's conferencing policy.

For better or worse, there are also policy settings that apply to the individual user. For example, your ability to share a single application (or to share your entire desktop) is enforced at the per-user level. Suppose Ken Myer's conferencing policy prohibits him from sharing anything. In that case, Ken won't be allowed to share an application (or his desktop) in any meeting he organizes. However, if Pilar Ackerman is allowed to share her desktop, she can do so in any meeting, even in one organized by Ken. (Which, admittedly, leads to the odd scenario in which the meeting organizer can't share anything but a meeting participant can share everything.) The reverse is also true: in a meeting organized by Pilar, Ken still can't share anything. His conferencing policy won't allow it.

Yes, we know: we can get confused by all this, too. But take a look at No Conferencing Policy is an Island for more information. And take a look at some of our policy setting articles if you want to see what this per-organizer/per-user stuff really means.

Other than that, there isn't anything particularly noteworthy about conferencing policies. These policies can be created (at the site or the per-user scope) by using the New-CsConferencingPolicy cmdlet:

New-CsConferencingPolicy -Identity SalesConferencingPolicy -MaxMeetingSize 50

Existing policies can be modified using the Set-CsConferencingPolicy cmdlet, and those existing policies can be deleted by using – that's right, the Remove-CsConferencingPolicy cmdlet. Need to assign a per-user policy (by the way, that's the per-user scope, not the per-user setting) then just use the Grant-CsConferencingPolicy cmdlet:

Grant-CsConferencingPolicy -Identity "Ken Myer" -PolicyName SalesConferencingPolicy

And, of course, there's everyone's favorite, the Get-CsConferencingPolicy cmdlet, which allows you to retrieve information about your conferencing policies. This command retrieves information about all your conferencing policies:

Get-CsConferencingPolicy

And this one retrieves information only about those policies where the maximum meeting size is greater than 50:

Get-CsConferencingPolicy | Where-Object {$_.MaxMeetingSize -gt 50}

Etc., etc.

At any rate, that's about all we have to say for the CsConferencingPolicy cmdlets. As for the state of Utah, we've also learned that the weather is always beautiful here (although we've seen some evidence that there was a foot of snow on the ground here in Park City as late as April 23^rd). We've also learned, the hard way, that people in Utah drive just as terribly as people from Washington.

But we'd still give them one star for their driving ability.

Or was that one fing – nah, never mind, See you tomorrow!

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.