You once were lost but

Now you're found. See why we asked

For your location?

The author of today's haiku has always had a soft spot in his heart for product disclaimers, those warning labels/pseudo-legal notices that accompany pretty much everything these days. For example, not too long ago he read a note from someone who bought a bag of peanuts and, before opening the bag, saw the following disclaimer:

Whew; that was close. Likewise, Kia is currently running a commercial in which one of their cars is shanghaied by Poseidon (at least we think it's Poseidon; it might be one of the guys from ZZ Top); abducted by aliens; and sent back in time to a Mayan temple. If you read the fine print that accompanies the ad, you'll see the word "Do Not Attempt." But do not attempt what? Do not attempt to levitate a car if you are the Greek God of the Sea? Do not attempt to steal this car if you are an alien from outer space? We have to be blunt with you, Kia. The authors of the Lync Server PowerShell blog are Americans: if we want to send our car back in time to the Mayans, well, who are you to stop us?!?

So what do disclaimers have to do with Microsoft Lync Server 2010? Well, believe it or not, there are at least two places in Lync Server where we allow you to write your very own disclaimer. (Although you'll never be able to top this one, found on a portable stroller: "Caution: Remove infant before folding for storage."). We've already discussed the conference disclaimer, which is shown to users who join a conference by clicking on a hyperlink. Today, we're going to discuss the Enhanced Emergency Services disclaimer.

Oh, and it’s accompanying Lync Server PowerShell cmdlets: Get-CsEnhancedEmergencyServiceDisclaimer, Remove-CsEnhancedEmergencyServiceDisclaimer, and Set-CsEnhancedEmergencyServiceDisclaimer.

As you probably know, Lync Server's Enhanced 9-1-1 feature (more commonly known as E9-1-1) makes it possible for Enterprise Voice users to dial 9-1-1 in an emergency; more importantly, it enables emergency responders to actually locate an Enterprise Voice user who dials 9-1-1 in an emergency. In order to do this, an organization create a "wiremap", a location map that uses such things as ports, subnets, switches, and wireless access points to help pinpoint a person's physical location. If you make a 9-1-1 call from, say, your office, emergency responders will be able to determine just exactly where you're calling from.

Of course, one of the advantages of Enterprise Voice is that you don't have to make phone calls from your office; you can make phone calls from pretty much anywhere. That's the good news. The bad news? Unless you have made a wiremap of the entire world, the system can't determine your location if you're calling from your backyard or a hotel room.

The solution to that problem is to ask each caller to manually enter their location any time they log on to the system and Lync Server cannot use the wiremap to determine their whereabouts. If you want to prompt users to manually enter their location, you must modify the appropriate location policy, something we won't discuss in any detail today. (For more information, see the help topic for the New-CsLocationPolicy cmdlet.) So what happens if you set the LocationRequired property of a location policy to Disclaimer? Funny you should ask:

If you set the LocationRequired property to Disclaimer, a dialog box will appear any time a user registers from an unknown location. That dialog box will ask the user to enter their location information. In addition, disclaimer text will appear that might tell the person the consequences of not providing a location. (The actual text of that disclaimer is up to you.) One consequence of not entering a location? You'll be allowed to make a 9-1-1 call, but you will not be allowed to call anyone else until you enter that location.

Of course, by now you might be a little concerned. Write your own disclaimer? How are you supposed to do that? And what happens if you write something like the following disclaimer, found on a chainsaw: "Do not attempt to stop the blade with your hand." What then?

Well, the first thing to do is to relax; the CsEnhancedEmergencyServiceDisclaimer cmdlets (Get-CsEnhancedEmergencyServiceDisclaimer, Set-CsEnhancedEmergencyServiceDisclaimer, Remove-CsEnhancedEmergencyServiceDisclaimer) make it easy to manage your organization's emergency disclaimer. (And yes, you can define only one global disclaimer for your entire organization. That makes this even easier to manage.) By default, you do not have an emergency disclaimer. (Well, technically you have one, it just doesn't have any text.) To create a disclaimer, just use a command similar to this one:

Set-CsEnhancedEmergencyServiceDisclaimer -Body "Warning: If you do not provide a location, emergency services may be delayed in reaching your location should you need to call for help."

Believe it or not, that's it. You have only one, global, disclaimer, so you don't need to provide an Identity. And the disclaimer itself has only a single property that needs setting: Body. What if you decide to change that disclaimer later on? That's fine; just use Set-CsEnhancedEmergencyServiceDisclaimer to overwrite the old disclaimer:

Set-CsEnhancedEmergencyServiceDisclaimer -Body "Warning: If you do not provide a location, then you will only be able to make 9-1-1 calls. You will not be able to make any other calls until you enter a location."

If you decide you'd rather not use a disclaimer at all, then just call Remove-CsEnhancedEmergencyServiceDisclaimer to delete all the disclaimer text:

Remove-CsEnhancedEmergencyServiceDisclaimer –Identity global

And if you'd just like to review the text of your current disclaimer, well, that's what Get-CsEnhancedEmergencyServiceDisclaimer is for:

Get-CsEnhancedEmergencyServiceDisclaimer

Pretty easy. And pretty nice, too: it gives you the ability to offer at least some emergency support for your users regardless of where they might be calling from.

Which, come to think of it, is really nice.

See you Monday!

There it is, right there!

Cy, cite the sight of the site.

The Lync Server site.

In the classic children's book Through the Looking-Glass, Humpty Dumpty says, "When I use a word, it means just what I choose it to mean -- neither more nor less." Those are words that we technical writers here at Microsoft have learned to live by.

What does that mean? Well, it means just what we choose it to mean – neither more nor less. However, it also means that sometimes we choose to use words that no one else uses. Foe you example, you know that little portable phone you tote around in your pocket or purse? You probably call that a cell phone. At Microsoft, however, that little device is officially known as a mobile phone. Why can't we call it a cell phone? Well, as a Microsoft editor once told the author of today's haiku, "If you call it a cell phone, no one will have any idea what you're talking about."

So there.

Of course, at other times we Microsoft types use the same word to mean all sorts of things. Take the word site, for example. Here at Microsoft, we've divided the world into two categories: some things are mobile phones, and everything that isn't a mobile phone is a site. (Or so it seems anyway.) For example, Active Directory has sites, but those sites shouldn't be confused with Microsoft Exchange sites. In Microsoft Lync Server 2010 we needed to introduce a new term into our infrastructure, so naturally we choose the word site, which has nothing to do with either Active Directory sites or with Microsoft Exchange sites. To paraphrase Gertrude Stein, a site is a site is a site. Unless it's that site. Or that one.

Sigh.

So what is a Lync Server site? Well, in Lync Server, sites are nothing more than a collection of pools and servers that are typically organized according to geography and/or network bandwidth. For example, suppose all your computers in Redmond are located on the same local area network, a network that features high-speed, low-latency connections.

Now, where were we before we so rudely interrupted ourselves? Oh, right: sites. So if our computers in Redmond are all located on a good, reliable network, we might create a Redmond site that encompasses those computers. Likewise, if our computers in Dublin are located on their own local area network, and share high-speed, low-latency connections, then we might create a separate Dublin site. Sites are also very important in Lync Server management; after all, most policies and settings can be configured at the site scope. That makes it possible (and easy) to do such things as apply one set of dial plans to users in Redmond and a completely different set of dial plans to users in Dublin.

Which, when it comes to dial plans, is probably something you want to do.

Now, before you ask, you cannot create or delete sites using Lync Server PowerShell; sites can only be created or deleted by using Topology Builder. However, you can use the CsSite cmdlets (Get-CsSite and Set-CsSite) to manage your existing sites.

As you might expect, the Get-CsSite cmdlet provides a way for you to return information about your sites. That's useful in and of itself. However, Get-CsSite can also be extremely useful when working with the CsDialInConferencingAccessNumber, CsTrustedApplicationPool, and CsAdminRole cmdlets. Why? Well, when you configure a Region for dial-in conferencing you need to use the site ID; you also need the site ID when assigning a site to the ConfigScopes property with the CsAdminRole cmdlets. The site ID is not necessarily the same as the site Identity or the site display name; fortunately, though, you can use the Get-CsSite cmdlet to return (and then make use of) the site ID for any site:

$x = (Get-CsSite –Identity "Redmond").SiteID

Set-CsAdminRole -Identity "RedmondVoiceAdministrators" -ConfigScopes @{Add=$x}

Oh, yes, good point: when you call Get-CsSite you don't use the site: prefix. If you were working with a site policy, your command would look like this:

Get-CsVoicePolicy –Identity "site:Redmond"

With Get-CsSite, however, you need to leave off the site: prefix:

Get-CsSite –Identity "Redmond"

As for Set-CsSite, well, there are three property values you can modify using this cmdlet:

That's pretty much it for the CsSite cmdlets: they're pretty simple, but they're also very useful. Just like the authors of the Lync Server PowerShell blog.

Well, OK, maybe the authors of the Lync Server PowerShell blog aren't all that useful. But they are simple. And we defy anyone to argue with that!

Uh, anyone want to argue with that? Anyone?

Wow, is it really Thursday already? That means we better come up with a hint for this week’s Challenge. OK, how about this: “This is one you should take personally.”

And no, that is a good hint. You just have to think about it a little.

Challenge Home

Your words still linger

Long after you have left us.

CS Archiving.

The author of today's haiku once read that, when Albert Einstein was teaching at Princeton, university officials would come in after each class, take down the blackboard he used, shellac it, and then save it, just in case Einstein had come up with something truly momentous. To be honest, the author doesn't know if Princeton officials really did do that or not, but he likes to think that they did: that seems like the perfect example of the importance of preserving the written word.

The truth is, sometimes it's nice to preserve the written word; after all, there's always a chance that you've scribbled down a way to carry out cold fusion, an equation that proves that time travel is possible, or an idea for a new flavor of Doritos.

But while sometimes it might be nice to preserve the written word, in other cases, it's absolutely imperative that you preserve the written word. For example, in the world of finance, it's often required that organizations save copies of all their electronic communications, including instant messages and online conference transcripts. And how do you save copies of your Lync Server 2010 instant messages and online conference transcripts? Hey, how should we know? Who do we look like, Albert Einstein?

Besides, we're just kidding around. We know exactly how you save copies of your Lync Server 2010 instant messages and online conference transcripts: by setting up an Archiving server and implementing Lync Server archiving.

Needless to say, we aren't going to detail the process of setting up an Archiving server, at least not today; you can find that sort of information in our Lync Server deployment guide. (Einstein: "There's no need to memorize anything that you can find written down in a book.") We will, however, note that simply setting up an Archiving server doesn't mean that you'll magically have an archive of all your instant messages and online conference transcripts. Instead, you need to do two more things before archiving actually takes place:

·         You need to enable archiving at the global scope, and/or at the site scope.

·         You need to assign an archiving policy that specifies what it is you're going to archive.

Step 2 (the archiving policy) is the subject of today's haiku. (See? We always get to the subject of the day's haiku, sooner or later.) As we noted, setting up an Archiving server doesn't cause instant messages and conference transcripts to be archived. Even enabling archiving doesn't cause instant messages and conference transcripts to be archived; doing that simply makes it possible for things to be archived. To actually start storing instant messages and conference transcripts in your archiving database you need to create/modify and then assign the appropriate archiving policy. These policies can easily be managed using the CsArchivingPolicy cmdlets: Get-CsArchivingPolicy, New-CsArchivingPolicy, Grant-CsArchivingPolicy, Remove-CsArchivingPolicy, and Set-CsArchivingPolicy.

For example, suppose you want to archive instant messages and conference transcripts for all your users. The easiest way to do that is to enable archiving in the global archiving policy. In order to do that, you use a command similar to this:

Set-CsArchivingPolicy –Identity global –ArchiveExternal $True –ArchiveInternal $True

As you can see there are two options available to you. If you set ArchiveExternal to True (the default value is False), then all your "external" communication sessions will be archived.

And if you set ArchiveInternal to True (again, the default value is False), then all your "internal" communication sessions will be archived. Before you ask, an internal session is one in which all the participants are authenticated users who have Active Directory accounts within your organization.

That's really all there is to it. Archiving policies can be set at the site scope or the per-user scope as well as the global scope; that makes it easy to ensure that instant messages and conference transcripts for certain select users are archived while those same items are not archived for other users. For example, these two commands create a new per-user archiving policy and then assign that policy to all the users in the Finance department:

New-CsArchivingPolicy –Identity "FinanceArchiving" –ArchiveExternal $True –ArchiveInternal $True

Get-CsUser –LdapFilter "Department=Finance" | Grant-CsArchivingPolicy –PolicyName "FinanceArchiving"

Etc., etc.

That's if for today. We'd like to finish things off by once more quoting from the immortal Albert Einstein: "A scientist is a mimosa when he himself has made a mistake, and a roaring lion when he discovers a mistake of others."

Today is a big day here at the Lync Server PowerShell blog. Today is the birthday of composer George Frederic Handel, Dell CEO Michael Dell, and of course, actress Dakota Fanning. It’s also the birthday of the dad of one this blog’s writers.

To celebrate, we decided to answer a question we recently received from a customer about working with Response Group queues. It was either that or publish the answer to Dad’s last question: “I saved a file in Word; where did it go?” Believe it or not we were able to figure out the answer to that question, but since it had nothing to do with Lync Server PowerShell we decided to go with the Response Group question for the article.

So, if you’ve been wondering how to List the Names of the Agent Groups Assigned to a Response Group Queue, read this article. If you’ve been wondering where your Word files have gone after you saved them, well, you’ll have to try a different blog.

http://blogs.technet.com/b/csps/archive/2011/02/23/rgslistnamesofagentgroups.aspx