Grab your beach towel

And sunscreen: we're going to

Allow some domains!

Well, it's another beautiful day here in Park City, UT. Of course, it's not even 9:00 AM here in Park City, UT: how do we know it's another beautiful day? That's easy: because it's always a beautiful day in Park City, UT. (We'll ignore the fact that, in a few months, the city will be buried under 300 feet of snow.) In the three-plus weeks that the author of today's haiku has been away from home, the temperature has always ended up in the 80s, and the sun has never once failed to shine. Admittedly, one day we did get a couple of raindrops, but it was literally that: a couple of raindrops. After that the rain clouds slunk away ashamed and embarrassed and the sun came out once again.

Meanwhile, the forecast for the Seattle area calls for partly cloudy skies and a high temperature of 68 degrees. Needless to say, the author of today's haiku can hardly wait to get back home.

Of course, you might be wondering, "OK, so you're in Park City, UT on a beautiful summer day: what exactly do you do in Park City, UT on a beautiful summer day." Well, you know what they say: when in Rome, do as the Romans do. And that can only mean one thing: when in Park City, UT on a beautiful summer day, you sit inside and play around with the CsAllowedDomain cmdlets (Get-CsAllowedDomain, New-CsAllowedDomain, Remove-CsAllowedDomain, and Set-CsAllowedDomain).

You know, we were hoping someone would ask that question: what is an allowed domain? To explain the concept of an allowed domain, we first need to talk a little bit about federation. As you know, federation provides a way for users to exchange instant messages and presence information with people from other domains. If you want to allow your users to communicate with people from any domain, you simply need to use the Set-CsAccessEdgeConfiguration cmdlet to enable federation and to enable "partner discovery." Do that, and your users will be able to communicate with people from any domain in the known universe.

OK, so then what is an allowed domain, especially if every domain seems to be an allowed domain? Well, the concept of an allowed domain comes into play in two ways. First, Lync Server is designed to guard against SPAM, SPIM, and other malicious activities by monitoring the number of messages sent from a domain: if that number gets too high, then Lync Server will block any messages originating from the offending domain.

That's good … provided that the domain in question really is SPAMMING or SPIMMING you. On the other hand, suppose those messages are legitimate, suppose this is a domain your users communicate with on a regular basis? Well, in that case, you can add the domain to the Allowed Domains list. That tells Lync Server, hey, this domain is OK: you can let them send a ton more messages than you let other domains send.

Alternatively, you can turn off partner discovery; if you do that, then your users will only be allowed to communicate with people from domains that are on the Allowed Domains list.

What that means, of course, is that you might end up needing a way to manage your Allowed Domains list. Is that what the CsAllowedDomain cmdlets are for? Let's hope so; if it's not, then today's haiku is going to make even less sense than usual.

Difficult as that might be to believe.

Let's kick things off by talking about adding a domain to the allowed list. To begin with, we should note that you have only one Allowed Domains list; you can't set up separate allowed lists for, say, different sites. If you want to add a domain to this list all you have to do is run a command similar to this one:

New-CsAllowedDomain -Identity "fabrikam.com" -ProxyFqdn "proxyserver.fabrikam.com"

As you can see, there really isn't much to that command: the Identity for the allowed domain is simply the domain's fully qualified domain name, and the ProxyFqdn is the fully qualified domain name of the allowed domain's proxy server. This, by the way, is optional: if you don't use this parameter then DNS SRV discovery procedures are used to determine the location of the SIP proxy server.

About the only other thing you might want to do is enable the MarkForMonitoring property. When this property is set to True, the federation connection between your domain and the allowed domain is monitored by Monitoring Server. You say you want to monitor that federation connection? That's fine; just use this command instead:

New-CsAllowedDomain -Identity "fabrikam.com" -ProxyFqdn "proxyserver.fabrikam.com" –MarkForMonitoring $True

That's all you have to do. As long as fabrikam.com isn't already on the Allowed Domains list (or on the Blocked Domains list) then the command should run without fail and fabrikam.com will be added to the list.

And sure, there's an easy way to verify that fabrikam.com really was added to the list: just run the Get-CsAllowedDomain cmdlet. You know, like this:

Get-CsAllowedDomain

But suppose you have a falling-out with fabrikam.com, and you no longer want them to be on your Allowed Domains list; what then? Well, then you should run the Remove-CsAllowedDomain cmdlet:

Remove-CsAllowedDomain -Identity "fabrikam.com"

And yes, we know: that does seem kind of harsh. But they asked for it!

Last (and possibly least) we have the Set-CsAllowedDomain cmdlet. Typically domains don't change much from day-to-day, but you never know; for example, fabrikam.com might set up a brand-new proxy server. If that happens, you're going to have to modify fabrikam's entry on the Allowed Domains list. And that, as you already guessed, is a job for Set-CsAllowedDomain:

Set-CsAllowedDomain -Identity "fabrikam.com" -ProxyFqdn "newproxyserver.fabrikam.com"

Etc., etc.

That's pretty much all there is to say about the CsAllowedDomain cmdlets. Wow, it's still early, we've finished today's haiku, the sun is shining and the mountains are beckoning. What are we going to do now? The only thing we can do: tackle the CsDeviceUpdateRule cmdlets! Is this gonna be a great day or what?

See you tomorrow.

So far we’ve written a couple of articles on using the Lync 2010 SDK to write scripts that will retrieve your list of contacts and will send an instant message. Initially we weren’t sure how many people would try out these scripts, but as it turns out they’ve been pretty popular. (By “popular” we mean that at least one person has tried at least one of the scripts.) How do we know these articles are popular? Well, we actually got a request to expand on one of the scripts. So we did.

In the new article Continue an Instant Messaging Conversation, we’ve taken the “Send an Instant Message” script and expanded on it. Instead of creating a new IM conversation every time the script is run, the script first checks to see whether a particular conversation already exists. If it does, it adds a message to the existing conversation; if it doesn’t, it creates a new one.

If there’s a second, or even – could it be? – a third or fourth person out there reading this, let us know what you think and what else you’d like to see.

http://blogs.technet.com/b/csps/archive/2011/08/31/continueim.aspx

Have you ever had a conversation with someone and later thought “Oh, I should have said this,” or “I wish I’d said that”? (True, sometimes you say “I wish I hadn’t said that,” but that’s another story.) If you're like most of us, you tend to come up with the perfect thing to say 20 minutes after the conversation is over. Well, that’s the cool thing about instant messaging. You can keep the conversation window open and just keep adding to it for as long as you want. As it turns out, you can even do that with a script.

A while ago we wrote an article about how to write a script that would use the Lync 2010 SDK to send an instant message. The script started a conversation, added participants, and sent a message. Now, we thought that might be a pretty handy script to have, but it turns out we can make it even handier. We received email from one of our avid readers (we’re going to assume he’s an avid reader anyway) asking how to modify the script so that you can continue an existing IM conversation rather than start a new conversation each time the script is run. And our response was “Hey, that’s a good question, how would you do that?”

When we realized no one else was going to answer our question, we got to work. (Something we do on rare occasions.) And, as it turns out, it is possible to find an existing conversation and add more messages to that conversation. We ended up with what might be considered a little bit of a workaround, and our solution isn’t completely foolproof, but it seems to work.

This script looks for a specific IM conversation based on the subject of the conversation. If it finds that conversation it adds a message. If it doesn’t find the conversation, it creates a new conversation and sends the message. Here’s the script:

$assemblyPath = “C:\Program Files (x86)\Microsoft Lync\SDK\Assemblies\Desktop\Microsoft.Lync.Model.DLL”

Import-Module $assemblyPath

$IMType = 1

$found = $False

$d =  New-Object "System.Collections.Generic.Dictionary[Microsoft.Lync.Model.Conversation.InstantMessageContentType,String]"

$d.Add(0, "System tests are complete.")

$cl = [Microsoft.Lync.Model.LyncClient]::GetClient()

if (($cl.ConversationManager.Conversations).Count -ge 1)

{

    foreach ($c in $cl.ConversationManager.Conversations)

    {

        $subject = $c.Properties[524289]

        if ($subject -eq "Send Alerts")

        {

            $found = $True

            $m = $c.Modalities[$IMType]

            $null = $m.BeginSendMessage($d, $null, $d)

        }

    }

}

if (!$found)

{

    $conv = $cl.ConversationManager.AddConversation()

    $null = $conv.BeginSetProperty([Microsoft.Lync.Model.Conversation.ConversationProperty]::Subject, "Send Alerts", $null, $null)

    $gs = $cl.ContactManager.Groups

    $i = 0

    foreach ($g in $gs)

    {

        foreach ($contact in $g)

        {

            if ($contact.GetContactInformation($LastName) -eq "Myer")

            {

                $i++

                $null= $conv.AddParticipant($contact)

                $m = $conv.Modalities[$IMType]

                $null = $m.BeginSendMessage($d, $null, $d)

                break

            }

        }

        if ($i -gt 0) {break}

    }

}

As with all scripts that use the Lync SDK, we first have to tell PowerShell where to find the DLL containing the objects and properties available in the SDK, then load that DLL into the script:

$assemblyPath = “C:\Program Files (x86)\Microsoft Lync\SDK\Assemblies\Desktop\Microsoft.Lync.Model.DLL”

Import-Module $assemblyPath

After setting a couple of variables that we’ll use later, we then create a Dictionary object:

$d =  New-Object "System.Collections.Generic.Dictionary[Microsoft.Lync.Model.Conversation.InstantMessageContentType,String]"

$d.Add(0, "System tests are complete.")

When we send the instant message, that message must be sent as a Dictionary object. So here we’ve defined that object and then added the text that will be in the message (System tests are complete). This is where you’ll put whatever message you want to send.

Now we call the GetClient method of the LyncClient object. This line captures the currently-running instance of Lync and saves it to the variable $cl:

$cl = [Microsoft.Lync.Model.LyncClient]::GetClient()

If Lync isn’t running on the computer, your script will crash right here.

Now that we’re all set up, the fun begins. (Aren’t you having fun? We thought this was the fun part. Although our definition of “fun” sometimes doesn’t line up with most people’s.)

At this point we look to see if we have any IM sessions currently running on the computer. We do that by checking the Count property of the Conversations collection:

if (($cl.ConversationManager.Conversations).Count -ge 1)

The Count property contains the number of conversations in progress; if the Count is greater than or equal to (-ge) 1 then there is at least one conversation in progress. If there is at least one conversation, we want to check to see whether one of those conversations is the one we want to continue. To do that we have to loop through the collection of conversations with a foreach loop:

foreach ($c in $cl.ConversationManager.Conversations)

The way we’ve decided to go about finding a specific conversation is by looking at the Subject of the conversations that are in progress. Earlier we said this solution isn’t necessarily foolproof, and this is the spot where you could have a problem. If you happen to have more than one conversation with the same subject, you might end up adding your message to the wrong conversation. But we decided the odds of having multiple conversations with the same subject, especially since we set the subject value (which we’ll show you in just a bit), are pretty slim.

At this point we run into this line of code:

$subject = $c.Properties[524289]

Yes, we know, that looks a little odd. What’s happening here is we’re saving the Subject property of the conversation to the variable $subject. The properties available as part of a Conversation object are stored as an enumeration. If we were writing this in C# we could simply use syntax something like this: c.Properties.Subject. Unfortunately Windows PowerShell doesn’t understand enumerations as easily as managed programming languages like C# do. So instead of just saying we want the Subject property, we have to specify the value that represents the Subject property, which just happens to be 524289.

Now that we have the subject name of the conversation, we check to see whether that conversation is the one we want to add to:

if ($subject -eq "Send Alerts")

In this case we’re looking for a conversation we named “Send Alerts.” (Where did we set that conversation name? Be patient, we’ll show you that soon.) If the subject of the current conversation is Send Alerts, we want to add our message to that conversation. The first thing we do if we find the conversation is to set the variable $found to True:

$found = $True

We’re using this flag to let the script know that we found an existing conversation so we don’t need to create a new one. Since we found the conversation we want to continue, we’re ready to add our message to that conversation:

$m = $c.Modalities[$IMType]

$null = $m.BeginSendMessage($d, $null, $d)

We set the modality to specify that we’re sending an instant message, then we send the message. (Remember that the message is in our Dictionary object, stored in the variable $d.)

If the current conversation in the foreach loop didn’t have a subject matching the subject we were looking for, we would continue to loop through all the active conversations until we’d either checked all of them or found the one we were looking for.

Once we’re done looping around we reach an if statement:

if (!$found)

Remember the flag we set to tell our script we found the conversation? Well, if we never found the conversation we wanted, $found would still be False and we’d want to begin a new conversation to send our message. So we check to make sure that $found is False (that’s what !$found means, it really means not $found, or $found is not True).

If we didn’t find the conversation, we need to call the AddConversation method to create it:

$conv = $cl.ConversationManager.AddConversation()

When we were looking for the conversation earlier in the script, we looked for a specific subject name. Back then we told you to be patient, that we’d show you where we set that, and we didn’t lie. (We never lie. Well, almost never.) After we create the conversation, we add a subject to it, like this:

$null = $conv.BeginSetProperty([Microsoft.Lync.Model.Conversation.ConversationProperty]::Subject, "Send Alerts", $null, $null)

Now, you might think that, since we retrieved the subject name like this:

$subject = $c.Properties[524289]

That we could set it like this:

$c.Properties[524289] = "Send Alerts"

Initially that’s what we thought, too. But we were wrong. (That does happen on occasion.) Instead, in order to set a conversation property, you have to call the BeginSetProperty method. We pass the full name of the enumeration (Microsoft.Lync.Model.Conversation.ConversationProperty) followed by the name of the property (Subject). And no, we didn’t even have to use the enumeration value (524289) here. That made the code a little longer, but this is how it works and it’s easier to decipher.

At this point we retrieve the user we want to send the IM to and send the message. We’re not going to explain the rest of this here, this is exactly the same as the script in our article on sending an instant message.

And that’s all there is to it. The script is a little long, but it’s really not that complicated once you break it down. Which, coincidentally, is what we just did. We’ve been told we’re very good at breaking things.

Wait, that’s different from breaking things down, isn’t it? Oh well, everyone has their talents.

Oh, and if we think of something else to add to this article 20 minutes from now, we’ll be sure to do that.

There are known knowns and

There are unknown knowns. Like, say,

Media bypass.

You know what's the worst thing about writing a daily haiku on Lync Server PowerShell? Well, OK, the second worst thing: obviously the worst thing is having to get up early and actually do some work every single day. (We still think there should be laws against that.) At any rate, the second worst thing about writing a daily haiku on Lync Server PowerShell is this: sooner or later, you're going to have to cover a set of cmdlets, and an underlying technology, that you know absolutely nothing about.

Why do we mention that on the same day that we're writing about the New-CsNetworkMediaBypassConfiguration cmdlet? Oh, no reason. It's just something that popped into our heads.

At any rate, New-CsNetworkMediaBypassConfiguration is a very nice little cmdlet and you should use it any time you need to create a new network media bypass configuration. See you tomorrow!

Nah, hey, just kidding. Well, sort of: New-CsNetworkMediaBypassConfiguration is a very nice little cmdlet and you should use it any time you need to modify your network media bypass configuration settings. And in the next few paragraphs, we'll explain what that means.

Well, sort of.

To explain what media bypass is all about, we have to first journey back in time to a very primitive and long-forgotten era, an era where there was no such thing as Microsoft Lync Server 2010. (Yes, we know. But try to picture such a time as best you can.) Back in those days (a time that paleontologists refer to as the Office Communications Server 2007 R2 Era), the signaling portion of a call made with Office Communicator and the media portion of that same call all had to pass through a Mediation server before it could be forwarded on to a PSTN gateway or an IP-PBX. (In other words, before that Communicator call could be sent out on the "regular" telephone network.) What's wrong with having both the signaling portion of a call and the media portion of a call routed through a Mediation server? Well, nothing really: the system definitely worked. On the other hand, the more hops introduced into a network path the more chances you have for something to go wrong. (And, as you might expect, more hops also equals slower transmission times.) Likewise, the Mediation server had to convert the signal to a codec that could be understood by the gateway. The more times you have to decode and encode a signal the more chances you have for something to go wrong.  (And, as you might expect, more decoding/encoding also equals slower transmission times.)

In other words, it was a system that worked, but it was also a system that was ripe for improvement. And if that isn't the perfect lead-in to media bypass, well, then we don't know what is.

OK, so then what is media bypass? Well, suppose you have the right kind of gateway, a gateway that supports media bypass. (And knowing whether or not you do have the right kind of gateway is something that goes way beyond what we can talk about today … or that we could ever talk about, to be perfectly honest. But see this page for more information.) If you do have the right kind of gateway then you can enable media bypass. In turn, that means that the media portion of a call does not have to pass through a Mediation server. And that means fewer hops, and fewer encoding/decoding sessions. That makes for faster and more robust calls, and saves enormous wear-and-tear on your Mediation servers. So much so that Mediation servers no longer have to be stand-alone machines; instead, they can be collocated on your Front End servers, saving you money on both hardware and software.

OK, so then what's the New-CsNetworkMediaBypassConfiguration cmdlet for? Well, New-CsNetworkMediaBypassConfiguration has one purpose in life: it creates a new media bypass settings object, an object that determines if (and, to a certain extent, how) media bypass is implemented. In turn, that object can then be used to configure the MediaBypassSettings property for your network configuration settings.

Actually, we're a little confused ourselves. So let's look at an example:

$x = New-CsNetworkMediaBypassConfiguration -AlwaysBypass $True -Enabled $True

Set-CsNetworkConfiguration -MediaBypassSettings $x

So what have we done here? Well, in the first command, we've used New-CsNetworkMediaBypassConfiguration to create a new media bypass settings object, an object that gets stored in a variable named $x. In this example, we've set the AlwaysBypass parameter to True, meaning that we want to attempt to use media bypass on every call.

Oh, and we also set the Enabled property to True, which simply enables media bypass on the global scale.

After creating the media bypass settings object, we then use the Set-CsNetworkConfiguration cmdlet to set the MediaBypassSettings property to the value of $x. Because you can only have a single, global collection of network configuration settings, this will potentially enable media bypass for all your gateways.

Why did we say "potentially?" Well, even after you've enabled media bypass on a global scale, you still need to enable it for each individual gateway. (If you didn't, then media bypass would automatically be enabled even for gateways that don't support the technology.) To enable media bypass on an individual gateway, use the CsTrunkConfiguration cmdlets.

Keep in mind that there's no Set-CsNetworkMediaBypassConfiguration cmdlet and there's no Get-CsNetworkMediaBypassConfiguration. But that's not a big deal. You can always review your current settings by running this command:

Get-CsNetworkConfiguration | Select-Object –ExpandProperty MediaBypassSettings

And what if you want to change your current settings? That's even easier: just repeat the same process we used a minute ago. For example, this set of commands disables media bypass:

$x = New-CsNetworkMediaBypassConfiguration -Enabled $False

Set-CsNetworkConfiguration -MediaBypassSettings $x

That replaces the existing media bypass settings with a new media bypass object in which the Enabled property is to False and all the other property values (such as AlwaysBypass) are set to their default values. What if you wanted to change just one property value of your media bypass settings? That's fine. All you have to do is retrieve the current media bypass settings and store those settings in a variable (e.g., $x). You can then change the property value in question (for example, setting AlwaysBypass to False) and then use Set-CsNetworkConfiguration to write the changes back to Lync Server.

In other words:

$x = (Get-CsNetworkConfiguration).MediaBypassSettings

$x.AlwaysBypass = $False

Set-CsNetworkConfiguration -MediaBypassSettings $x

And there you have it: everything we know (and a few things we didn't even know we knew) about the New-CsNetworkMediaBypassConfiguration cmdlet. And, with any luck, this will be the last time we have to talk about a cmdlet, and a technology, that we don't know anything about.

Except maybe when we get to the CsCertificate cmdlets. Or the CsDatabase cmdlets. Or the – well, never mind: we'll cross those bridges when we come to them. See you tomorrow.

Why do you want to

Run computer cmdlets?

Just because they're there.

For those of you who've been sitting up all night waiting for the final outcome, you can finally rest assured: Sunset Peak has been conquered!

Yes, it's true: yesterday afternoon the author of today's haiku (and his wife/Sherpa porter) reached the summit of Sunset Peak, all 10,648 feet of it. As far as they know, they are the first people to ever reach the summit of Sunset Peak!

Well, except for the two guys who were hiking ahead of them. And the family of four – Dad, Mom, two girls – who were already walking around the summit when they got there. And the couple that, having conquered Sunset Peak, moved on to climb another nearby mountain before starting on their way down. But other than that, they are – possibly – the first people to ever reach the summit of Sunset Peak!

At any rate, if you ever happen to find yourself at the Brighton Ski Resort in the middle of summer, and have a few hours to kill, the author of today's haiku recommends hiking up to Sunset Peak. It's a bit of a challenge: 2000 feet of elevation gain in just 2.5 miles. But it's a pretty cool little hike: fields of wildflowers, scrambles up granite boulders, cool little lakes, and rushing streams. The author and his wife even had the chance to climb up a waterfall!

Well, OK, it was really more of a stream trickling downhill than, say, Niagara Falls. But hey, a waterfall's a waterfall, right?

Right.

At any rate, a good hike, and one of the crowning achievements in the life of the author of today's haiku.

Nevertheless, summiting Sunset Peak pales a bit before his greatest achievement ever: successfully running the CsComputer cmdlets (Disable-CsComputer, Enable-CsComputer, and Test-CsComputer).

Now, admittedly, that's not really much of an achievement, either: the CsComputer cmdlets aren't particularly difficult to run. It's just that, with the possible exception of Test-CsComputer, these are also cmdlets you won't find yourself running very often, either. So, the fact that hardly anyone ever runs these cmdlets, and the author of today's haiku has run these cmdlets, well, that counts as an achievement.

For him anyway.

Let's take on Disable-CsComputer, for starters. By default, Disable-CsComputer disables all the Lync Server services/server roles on a computer. Suppose you want to take a Lync Server machine out of commission, but for some reason the Setup Wizard won't let you do this. That's fine; just run this command instead:

Disable-CsComputer

The preceding command disables all the services/server roles on a computer, but does not uninstall Lync Server from that computer. (In theory, that means you can resume all the Lync Server services simply by running Enable-CsComputer. For better or worse, however, things don't always go quite that smoothly.) If you do want to uninstall all the Lync Server components, then simply include the Scorch parameter, like so:

Disable-CsComputer -Scorch

And yes, "Scorch" is a really cool parameter name, isn't it?

Enable-CsComputer, as you might expect, is used to enable Lync Server services and server roles on the local computer. (Sorry, but you can't run this cmdlet remotely, either.) Enable-CsComputer is actually a cmdlet you might find yourself running from time-to-time. For example, if you change your simple URLs you might need to run Enable-CsComputer to make sure that those changes take effect; likewise, users who upgrade from the evaluation version of Lync Server to the real, live version of Lync Server need to run the cmdlet at the end of the upgrade process. Oh: and Enable-CsComputer can also be used to repair share permissions on your Lync shares.

Anyway, the point is this: there might actually come a time when you need to run the Enable-CsComputer cmdlet. And what are you supposed to do when that time comes? This:

Enable-CsComputer

Yep, that's it. If you want to get fancy we suppose you could do this:

Enable-CsComputer -Report "C:\Logs\EnableComputer.html"

That command, with the Report parameter, lets you specify the file path for the report that Enable-CsComputer automatically creates each time it runs. But that's about as fancy as it gets, at least when dealing with Enable-CsComputer.

As for Test-CsComputer (which, again, can only be run locally), this command verifies the status of all the Lync Server services/server roles on the computer; checks to see if the appropriate firewall ports have been opened on the computer, and determines whether or not the Active Directory groups created when you installed Lync Server 2010 have been added to the corresponding local groups. (For example, Test-CsComputer verifies that the Active Directory group RTCUniversalUserAdmins has been added to the local Administrators group.) In other words, Test-CsComputer verifies that all the Lync Server components on a computer have been installed and configured correctly. And how do you actually run Test-CsComputer? You got it:

Test-CsComputer

And that brings today's haiku to a rousing conclusion. If you get bored sometime, and if you have a spare computer running Lync Server, you might mess around with the different CsComputer cmdlets and see happens. (We should note that you can run Enable-CsComputer and Test-CsComputer any time you want, and on any computer you want: they're essentially harmless.) Alternatively, you might write to the wife of the author of today's haiku, who recently tamed Sunset Peak, and encourage her to set her sights on Mt. Timpanagos, 11,749 feet. The author of today's haiku nagged her into hiking up Sunset Peak; so far, nagging about Mt. Timpanagos hasn't gone quite as well.

See you tomorrow.