|
|
Walkthrough
|
Enabling a User for Microsoft Lync Server 2010 and Enterprise Voice: A Comprehensive Lync Server Walkthrough
Well, it’s your first day at your new job: Lync Server administrator for Litware, Inc. You’re pretty excited about your new position, and even more excited to see that your first big assignment was already sitting on your desk when you showed up for work this morning: another new person, Ken Myer, has been hired by the company, and you need to enable Ken for both Microsoft Lync Server 2010 and for Enterprise Voice. Wow, that is exciting, isn’t?
Well, to be honest, it was exciting, at least until you found out that your new company is using Microsoft Lync Server 2010 rather the application you’ve been administering up until now: Office Communications Server 2007 R2. (Now you wish, when they asked in your job interview if you had experience with “Communications Server,” that you’d asked them to be a little more specific.) Your new boss will be in in about half an hour, and she’ll expect that her new administrator will have been able to complete such a simple task in that amount of time. And, truth be told, you probably could complete this simple task in that amount of time, except for one thing: you don’t have the slightest idea how to enable a user for Lync Server 2010, llet alone how to enable that user for Enterprise Voice.
Uh-oh.
Of course, you don’t have much choice but to give it the old college try, do you? Drawing on your 2007 R2 experience, you’ve gone into Active Directory Users and Computers and right-clicked Ken Myer’s user account – repeatedly. Unfortunately, you can’t find anything in Active Directory related to Lync Server. “Oh, my,” you’re thinking. “One day on the job and I’m already going to be fired, aren’t I?”
Sadly, yes, yes you are. But, hey, what are we supposed to do about that? Write you a step-by-step guide to enabling a user for Microsoft Lync Server 2010 and Enterprise Voice?
A Step-by-Step Guide to Enabling a User for Microsoft Lync Server 2010 and Enterprise Voice
Fortunately for you, we don’t have much interest in being fired, either; because of that, we decided that we would go ahead and write you a step-by-step guide to enabling a user for Microsoft Lync Server 2010 and Enterprise Voice. Before doing so we should note that there are two ways to enable users for Lync Server: either by using the Lync Server Control Panel (a Web-based administration tool) or by using Windows PowerShell. Seeing as how this is a site devoted to the Lync Server implementation of PowerShell we decided to focus on explaining how you can enable users by using PowerShell.
Which, come to think of it, is just exactly what we were about to do.
Note. This walkthrough includes a lot of text that explains everything we’re doing and why we’re doing it. You say you don’t have time to read a bunch of text, you just want to practice enabling a user for Lync Server and Enterprise Voice? Then you need to take a look at our barebones walkthrough. Of course, if you do that you’ll miss all our funny jokes and amusing anecdotes, and – hmmm, come to think of it, maybe we’ll go take a look at the barebones walkthrough ourselves.
Step 1: Starting the Lync Server Management Shell
So how do you enable users by using Windows PowerShell? Well, to begin with, we should make it clear that you can’t just start up any old instance of Windows PowerShell and start enabling users for Lync Server. Instead, you have to go about this in one of two ways:
· Option 1: Use Windows PowerShell 2.0 and remote PowerShell management techniques to connect to a computer running the Lync Server implementation of Windows PowerShell. Because this approach requires a little extra work to make the connection and to load in all the Lync Server cmdlets, we’re going to skip option 1 and proceed directly to option 2. (However, if you’d like to give remote management a try, take a peek at the article Quick Start: Managing Microsoft Lync Server 2010 Using Remote PowerShell. After you’ve made the connection you can then use the exact same commands included in this walkthrough to enable Ken Myer’s user account.)
· Option 2: Use the Lync Server Management Shell. This is the preferred option. Why? Because the Management Shell automatically makes the connection to Lync Server and preloads all the required cmdlets. That’s much easier, although you will have to carry out all these commands on a computer where the Management Shell has been installed.
OK, so then how do you enable users by using the Lync Server Management Shell? Well, the first thing you need to do is start the Lync Server Management Shell. To do that, log on to a computer where the Management Shell has been installed (that is, any machine running a Communications Server service or server role), making sure that you log on using an account that has administrative rights to both Lync Server and the local computer. After logging on, do this:
· Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell.
And that’s it for Step 1. Now let’s move on to Step 2.
Tip. When you first start the Lync Server Management Shell your prompt is going to look something like this:
PS C:\Users\Administrator.LITWAREINC>
And you’re right: that doesn’t leave much room for typing in commands, does it? To change your prompt to something a bit shorter (e.g., PS C:> ) type the following at the Windows PowerShell prompt and then press ENTER:
Set-Location C:\
Or, if you don’t like to type:
cd C:\
Step 2: Locating a User Account
We’re going to assume that you don’t know any of the details regarding Ken Myer’s Active Directory account; that is, you don’t know his display name; his domain name or his logon name; his SIP address; his User Principal Name; etc. Does that really matter? Well, yes, it does. In order to enable a user for Lync Server you must specify the Identity of the user account you want enabled. (Which makes sense: you can’t just tell Lync Server “go enable that user account that’s supposed to be enabled” and expect it to know what you’re talking about. Maybe in a future version of the product, but no in this version.)
So how do you specify the Identity of a user account? By using one of the following items:
· The user’s Active Directory display name (e.g., "Ken Myer")
· The user’s SIP address (e.g., "sip:kenmyer@litwareinc.com")
· The user’s User Principal Name (e.g., "kenmyer@litwareinc.com")
· The user’s domain name and logon name, in the format domain_name\logon_name (e.g., litwareinc\kenmyer)
Two quick notes. OK, so there is a fifth type of Identity: the distinguished name of the Active Directory user account, which will look something like this: cn=Ken Myer,ou=Finance,ou=Redmond,dc=Litwareinc,dc=com. If you really want to type all that in, well, that will work; it’s up to you.
Second, everyone we’ve ever talked to about enabling users has asked the same question: why can’t we just use the person’s SamAccountName as the Identity? (The SamAccountName is the user’s logon name, the kenmyer portion of litwareinc\kenmyer.) And here’s the answer we’ve given to everyone: you can’t use the SamAccountName because these names do not have to be unique in a forest; for example, both the litwareinc.com domain and the fabrikam.com domain (domains in the same forest) could have a kenmyer. If two people can have the same SamAccountName that means that the SamAccountName can’t be used as a unique identifier. It’s the same reason you can’t use someone’s first name as a unique identifier: after all, your organization could have a whole bunch of Gertrudes.
Well, OK, you’re right about that. But you could (and probably do) have a whole bunch of Davids or Ambers or Justins.
Update: Here's a little more information about using DisplayName and/or SamAccountName as an Identity.
Fortunately, Lync Server includes a pair of cmdlets – Get-CsUser and Get-CsAdUser – that return user account information. To be perfectly honest, Get-CsUser is of little use to us at the moment; that’s because Get-CsUser only returns information about users who have already been enabled for Lync Server. (And if Ken Myer had already been enabled for Communications Server we wouldn’t have had to write this walkthrough in the first place.)
By contrast, Get-CsAdUser returns information about all your Active Directory user accounts, including accounts that have been enabled for Lync Server and accounts that have not been enabled for Lync Server. That means that, for the moment, we want to use Get-CsAdUser.
Note. OK, so if there are two different cmdlets that can return user account information, how do you know which cmdlet to use any time you need to return that information?
When choosing between Get-CsUser and Get-CsAdUser there are at least two things to keep in mind. First, if you need to return information about users who have not been enabled for Lync Server then you must use Get-CsAdUser; Get-CsUser has no knowledge of, and no interest in, users who have not been enabled for the product. What if you want information only about users who have been enabled for Lync Server? Well, in that case you could use either cmdlet. Get-CsUser might be the more obvious choice, but this command uses Get-CsAdUser to return only those users enabled for Lync Server:
Get-CsAdUser –Filter {CsEnabled –eq $False}
So now which one would you use? Well, at this point it depends on the user account information you want returned. With only a few exceptions, Get-CsAdUser and Get-CsUser return different sets of information: Get-CsAdUser returns generic Active Directory attribute values (such as Department, Title, and HomePhone) while Get-CsUser returns Lync Server-related attribute values such as LineServerUri, DialPlan, and EnterpriseVoiceEnabled. For a complete list of properties returned, by default, by the two cmdlets see the reference article Properties Returned by Get-CsUser and Get-CsAdUser.
With that in mind, let’s take Get-CsAdUser out for a test drive. Type the following at the PowerShell prompt and then press ENTER:
Get-CsAdUser
In return, Get-CsAdUser returns a whole bunch of information, information about all your Active Directory user accounts; in fact, depending on the number of accounts you have it could take years for all that information to finish scrolling past. (But don’t panic: if you don’t want to spend years waiting for all your user account information to be returned, just press Ctrl+C to stop the current command.) Obviously we need to come up with Plan B, don’t we?
Fortunately, there are a couple of Plan Bs that we can try, different ways to zero in on one user account in particular. Remember when we talked about the different ways to identify a user account? Well, all those identifiers can be used to return one user account. For example, here’s how we can use the display name Ken Myer in an attempt to return just the Ken Myer user account:
Get-CsAdUser –Identity "Ken Myer"
Tip. Yes, we know: having to type the parameter –Identity is a lot of work, isn’t it? Fortunately, though, you don’t have to type –Identity each time. As it turns out, -Identity is a “positional parameter;” in this case, that means that Get-CsAdUser (and Get-CsUser, for that matter) expect the first parameter to be the –Identity parameter. Because of that, you can actually omit –Identity and simply issue a command that looks like this:
Get-CsAdUser "Ken Myer"
We’ll use –Identity throughout this walkthrough just to make it clear to everyone what we’re doing. But if you don’t want to explicitly use the –Identity parameter, well, we sure can’t make you. (We actually looked into whether or not we could make you, but Microsoft’s legal team advised against that. So have at it!)
For more information on how you can minimize typing in Windows PowerShell, take a look at the article Tab Expansion. And, while you’re at it, you might as well check out the Shortcut Keys article, too.
Assuming you picked the correct display name, Ken Myer’s user account information will be returned. Of course, there’s no guarantee that you did pick the correct display name; for all you know Ken’s Active Directory display name could be Kenneth Myer. So is there a way to retrieve user account information when you aren’t 100% certain of the user’s display name, or his or her UPN, or SIP address, or domain name/logon name, or ….
Of course there is; Lync Server PowerShell always provides plenty of alternate ways to retrieve information. (Well, except on those occasions when it doesn’t.) Are you reasonably sure that Ken’s last name (Myer) appears somewhere in his display name? Then try using this command:
Get-CsAdUser –Identity "* Myer*"
As you can see, what we’re doing here is using a standard wildcard character (*) to search for any user whose display name includes a blank space followed by the string value Myer. The two wildcard characters simply say that we don’t care what (if anything) comes before or after Myer; just that the display name includes a blank space followed by Myer.
Note. Right now you might be thinking, “Well, that’s easy; I already know how to do wildcard searches like this.” Needless to say, that’s the whole point: Windows PowerShell is easy.
A couple quick notes before we can go any farther. First, the asterisk is the only wildcard character you can use when trying to locate a user account; for example, this command, which uses the ? wildcard character, will fail:
Get-CsAdUser –Identity "Ken ?yer"
Why does it fail? We don’t know the exact reason; we only know that Get-CsAduser and Get-CsUser don’t allow the question mark, the wildcard range (e.g., [a-k]) or else anything other than the asterisk.
Second, the only Active Directory attribute that gets looked at when you perform a wildcard search is the display name. Suppose you try this command:
Get-CsAdUser "sip:ken*@litwareinc.com"
Is that command going to work? Nope; not unless you have a user who has a display name like sip:kenmyer@litwareinc.com. If you throw in a wildcard then search is limited to the display name.
Period.
Incidentally, it’s possible to have a whole family of Myers working for you; that means that the Identity "* Myer*" could bring back a whole flock of user accounts. (That’s one potential problem with doing a wildcard search.) To help you narrow things down you might run a command similar to this:
Get-CsAdUser "* Myer*" | Select-Object FirstName, LastName, DisplayName, Department
What this command does is retrieve information for all the user accounts in Active Directory (or at least all those accounts that have a display name featuring a blank space followed by the string value Myer). That could, potentially, be a whole bunch of information that scrolls across our screen, information that we not only don’t care about but that also gets in our way of locating the one and only Ken Myer. Consequently, what we’ve done in this command is take all the data returned by Get-CsAdUser and piped it to the Select-Object cmdlet; we then ask Select-Object to show us only the following attribute values: FirstName, LastName, DisplayName, and Department. In other words, we’re going to get back information that looks like this:
FirstName LastName DisplayName Department
--------- -------- ----------- ----------
Andrew Myer Andrew Myer Sales
Gail Myer Gail Myer Shipping
Ken Myer Ken Myer Finance
Sharon Myer Sharon L. Myer Finance
Note. did youy notice that Sharon Myer’s display name is actually Sharon L. Myer? That means a command that uses the Identity Sharon Myer will fail to return any data. Definitely one case where wildcards come in handy.
As long as we’re on the subject, you can also use a command like this one to return information about all your Active Directory user accounts:
Get-CsAdUser | Select-Object FirstName, LastName, DisplayName, Department
If you call Get-CsAdUser without specifying an Identity then the cmdlet automatically returns information about all your Active Directory user accounts. Almost all of the Lync Server Get- cmdlets do the same sort of thing; for example, if you call Get-CsConferencingPolicy without specifying a policy Identity you’ll get back information for all your conferencing policies.
Just thought you should know that in case it pops up as a question on Jeopardy or something.
We’re going to assume that, using one command or another, we’ve managed to determine Ken Myer’s display name, a display name we can now use as his official Communications Server Identity. In turn, that means that it’s time to enable Ken’s account for Lync Server.
Step 3: Enabling a User for Microsoft Lync Server and Enterprise Voice
Let’s start out by showing you how to do this in two steps: first we’ll enable Ken Myer for Lync Server and then we’ll enable Ken for Enterprise Voice. After we’ve done that, we’ll switch gears and show you how – with a little bit of PowerShell wizardry – you can accomplish this in just one step.
That’s right: just like Harry Potter would do it.
To begin with, and to toot our own horns a little, we actually wrote an entire article (cleverly titled Enabling a User for Microsoft Link Server 2010) that explains, in some detail, the ins and outs of enabling a user for Lync Server. (See why we thought the title was so clever?) Because of that, we aren’t going to explain the different options available to you when enabling a user account for Lync Server; instead, we’re just going to show you the following option:
Enable-CsUser –Identity "Ken Myer" –RegistrarPool atl-cs-001.litwareinc.com –SipAddressType FirstNameLastName –SipDomain litwareinc.com
What we’re doing here is using the Enable-CsUser cmdlet to enable Ken Myer for Lync Server. (Yes, Enable-CsUser is another clever name, isn’t it? But we can’t take credit for that one.) In addition to specifying the Identity of the user account to be enabled we also included three other parameters:
· -RegistrarPool
· -SipAddressType
· -SipDomain
Why did we include these three parameters? Mainly because they (or some variation of them) are required any time you enable a user for Lync Server. We need to use the –RegistrarPool parameter because we have to indicate the Registrar pool where the user account will be “homed.” Users who aren’t assigned to a Registrar pool can’t log on to Lync Server, regardless of whether or not their account has been enabled.
Quick tip. Here’s a command that can quickly tell you whether or not you have any users who have been enabled for Lync Server but are not assigned to a Registrar pool:
Get-CsUser –UnassignedUser | Select-Object DisplayName
Granted, you typically won’t have any users who are not assigned to a Registrar pool; after all, and as we just saw, you have to assign a user to a pool before that user can be enabled for Lync Server in the first place. Still this can happen (for example, if you have to take down a Registrar pool for some reason), so better safe than sorry, right?
As for –SipAddressType and –SipDomain, well, users have to have a SIP address in order to be enabled for Lync Server. If we wanted to, we could supply a specific SIP address (for example, sip:kmyer@litwareinc.com) when enabling Ken Myer’s user account. In this case, however, we’re asking Lync Server to create the SIP address for us. That address, in case you’re wondering, consists of the SIP: prefix; Ken’s first name (FirstName); a period (.); Ken’s last name (LastName); the @ sign; and the SIP domain litwareinc.com. In other words:
SIP:
Ken
.
Myer
@
litwareinc.com
Or:
SIP:Ken.Myer@litwareinc.com
And that’s all we have to do; as soon as we run Enable-CsUser Ken Myer will be enabled for Lync Server, will be able to log on to Microsoft Lync, and will be able to send and receive instant messages.
However, what he won’t be able to do is use Enterprise Voice, Microsoft’s implementation of VoIP (Voice over IP). Why not? Because, by default, users newly-enabled for Lync Server are not enabled for Enterprise Voice. And before you ask, no, you can’t enable users for Enterprise Voice simply by running Enable-CsUser; that’s because Enable-CsUser doesn’t give you the option of enabling or disabling Enterprise Voice.
Instead, you need to use the Set-CsUser cmdlet to enable a user for Enterprise Voice and, at the same time, to assign the user a line URI. Fortunately, all of that can be done with one little command:
Set-CsUser –Identity "Ken Myer" –EnterpriseVoiceEnabled $True –LineUri "TEL:+14255551298"
In other words, to enable Ken Myer’s account for Lync Server and to enable Ken for Enterprise Voice you need to run a pair of commands similar to these:
Enable-CsUser –Identity "Ken Myer" –RegistrarPool atl-cs-001.litwareinc.com –SipAddressType FirstNameLastName –SipDomain litwareinc.com
Set-CsUser –Identity "Ken Myer" –EnterpriseVoiceEnabled $True –LineUri "TEL:+14255551298"
Nice, huh?
What’s that? You say that having to do two things is too much work, that you want to be able to enable a user for both Lync Server and Enterprise Voice all in the same command? For example, why can’t you just run a command like this one, which seems to enable the user and then pipe the newly-enabled user account to the Set-CsUser cmdlet:
Enable-CsUser –Identity "Ken Myer" –RegistrarPool atl-cs-001.litwareinc.com –SipAddressType FirstNameLastName –SipDomain litwareinc.com | Set-CsUser –Identity "Ken Myer" –EnterpriseVoiceEnabled $True –LineUri "TEL:1+4255551298"
Here’s why you can’t use a command like that: by default, the Enable-CsUser cmdlet doesn’t send information across the pipeline. If you run the preceding command, Ken Myer will be enabled for Lync Server. However, as soon as Enable-CsUser finishes running, the command stops dead in its tracks. That means that Ken’s user account information will never get sent to Set-CsUser; in fact, Set-CsUser will never even run. As if that wasn’t bad enough, you won’t get any sort of error message, either. Why not? That’s easy: because there weren’t errors. Instead, Enable-CsUser did what it was supposed to do: it enabled Ken Myer’s user account and then stopped. As far as PowerShell is concerned, everything worked as expected.
Note. Here’s a quick way to verify that, by default, nothing gets sent across the pipeline when you run Enable-CsUser. The following command enables Ken Myer’s user account then, in theory, pipes the user account object to the ForEach-Object cmdlet; in turn, ForEach-Object should echo the message in the pipeline for each object piped to it:
Enable-CsUser –Identity "Ken Myer" –RegistrarPool atl-cs-001.litwareinc.com –SipAddressType FirstNameLastName –SipDomain litwareinc.com | ForEach-Object {Write-Host "In the pipeline"}
Got all that? OK. Now, here’s what you get when you run the command:
That’s right: you don’t get anything at all. Why not? Because nothing was ever transmitted across the pipeline, and ForEach-Object never even ran.
Of course, the more observant among you might have noticed that we keep saying that “by default” Enable-CsUser doesn’t send objects across the pipeline. Does that mean that there’s a way to talk Enable-CsUser into sending objects across the pipeline?
Well, to be perfectly honest, we aren’t sure if there’s a way to talk Enable-CsUser into anything; Enable-CsUser is one stubborn cmdlet. But there’s definitely a way to make Enable-CsUser send objects across the pipeline:
Enable-CsUser –Identity "Ken Myer" –RegistrarPool atl-cs-001.litwareinc.com –SipAddressType FirstNameLastName –SipDomain litwareinc.com –PassThru | Set-CsUser –EnterpriseVoiceEnabled $True –LineUri "TEL:+14255551298"
At first glance this might look a lot like the command we just ran, the command that didn’t send objects across the pipeline. In this case, however, there’s one very important addition: the –PassThru parameter. –PassThru is a generic Windows PowerShell parameter that, in this case, tells Enable-CsUser, “Look, I know you don’t usually send objects across the pipeline, but I’m afraid you’re gonna have to do it this time, like it or not.” The net effect? Enable-CsUser passes Ken Myer’s user account object over the pipeline, handing that object off to Set-CsUser. In turn, Set-CsUser then changes the EnterpriseVoiceEnabled and LineUri properties for that object.
Note. If you already enabled Ken Myer’s user account then you will receive this message when you run the preceding command:
WARNING: Object not changed, Identity: CN=Ken Myer,OU=Redmond,DC=Litwareinc,DC=COM.
This message is simply telling you that Ken Myer’s user account was already enabled; thus there was nothing for Enable-CsUser or Set-CsUser to do. If you want to see how this command really works then you should disable Ken’s Lync Server account before running the command. Here’s how you disable a Lync Server user account:
Disable-CsUser –Identity "Ken Myer"
Pretty cool, huh? Now, keep in mind that not all Lync Server cmdlets support –PassThru, and not all of them need to support -PassThru; many of the cmdlets pipe objects by default. But –PassThru is definitely a handy little thing to have in your toolbox.
Tip. How do we know for sure that Ken Myer has been enabled for both Lync Server and Enterprise Voice? Here’s one way; run this command and see for yourself:
Get-CsUser –Identity "Ken Myer" | Select-Object DisplayName, CsEnabled, EnterpriseVoiceEnabled, LineUri
If everything did work you should get back the following:
DisplayName CsEnabled EnterpriseVoiceEnabled LineURI
----------- --------- ---------------------- -------
Ken Myer True True TEL:+14255551298
Step 4: Assigning a Dial Plan and a Voice Policy
If Litware, Inc. happens to be a relatively small organization, and if all your users are located in the same building, then Step 4 might be optional. In order to make use of Enterprise Voice, users need to be assigned a dial plan and a voice policy. Is that a problem? Not necessarily. After all, when you install Lync Server 2010 a global dial plan and a global voice policy are created for you; by default, these global entities are applied to all of your users. So, like we said, depending on the size and the needs of your organization, the global dial plan and the global voice policy might suffice.
Note. Alternatively, you might have site-scoped dial plans and voice policies that are automatically applied to users and require no additional work on your part. See the article Scopes and Filters for more information.
On the other hand, not assigning dial plans or voice policies doesn’t make for a very exciting walkthrough, does it? With that in mind, let’s pretend that someone has created some per-user dial plans and voice policies, and you now need to assign Ken one of these per-user dial plans and one of these per-user voice policies. (Before you ask, no, you can’t assign multiple dial plans or multiple voice policies to a user; it’s one dial plan and one voice policy per user.) How are you going to do that? Well, here’s one way:
Grant-CsDialPlan –Identity "Ken Myer" –PolicyName "RedmondDialPlan"
Grant-CsVoicePolicy –Identity "Ken Myer" –PolicyName "RedmondVoicePolicy"
Note. If you don’t understand how these two commands work, well, too bad for you; looks like you are about to get fired, aren’t you?
No, hey, just kidding. If you’d like more information on how to assign policies, take a look at our article Assigning Policies.
And yes, now that you mention it, that is another cleverly-titled article, isn’t it? Obviously what they say is true, at least when it comes to thinking up titles for articles: when you’re hot you’re hot.
Assigning a dial plan and a voice policy with two simple commands is actually pretty good, except for one thing: you don’t like running two separate commands, do you? Well, OK. What if we told you that you can enable a user for Lync Server, enable that user for Enterprise Voice, assign that user a dial plan and assign that user a voice policy, and do all that in a single command?
That’s what we thought you’d say.
Here’s the command we’re talking about:
Enable-CsUser –Identity "Ken Myer" –RegistrarPool atl-cs-001.litwareinc.com –SipAddressType FirstNameLastName –SipDomain litwareinc.com –PassThru | Set-CsUser –EnterpriseVoiceEnabled $True –LineUri "TEL:+14255551298" –PassThru | Grant-CsDialPlan –PolicyName "RedmondDialPlan" –PassThru | Grant-CsVoicePolicy –PolicyName "RedmondVoicePolicy"
Admittedly, that looks like a pretty complicated command. But, believe it or not, it’s really not that bad; it just looks complicated because we tied together four different commands:
· Enable-CsUser –Identity "Ken Myer" –RegistrarPool atl-cs-001.litwareinc.com –SipAddressType FirstNameLastName –SipDomain litwareinc.com –PassThru
· Set-CsUser –EnterpriseVoiceEnabled $True –LineUri "TEL:+14255551298" –PassThru
· Grant-CsDialPlan –PolicyName "RedmondDialPlan" –PassThru
· Grant-CsVoicePolicy –PolicyName "RedmondVoicePolicy"
And the key to making this all work? That’s right: it’s the –PassThru parameter. This parameter causes Enable-CsUser to pass its user object to Set-CsUser; it also causes Set-CsUser to pass that same user object on to Grant-CsDialPlan then to pass the user object on to Grant-CsVoicePolicy. As the user object gets passed along each cmdlet makes a change to it. For example, here’s what the user object looks like before we run Enable-CsUser:
|
Property
|
Value
|
|
DisplayName
|
Ken Myer
|
|
RegistrarPool
|
|
|
SipAddress
|
|
|
EnterpriseVoiceEnabled
|
|
|
LineUri
|
|
|
DialPlan
|
|
|
VoicePolicy
|
|
Here’s what the user object looks like after Enable-CsUser finishes doing its thing:
|
Property
|
Value
|
|
DisplayName
|
Ken Myer
|
|
RegistrarPool
|
atl-cs-001.litwareinc.com
|
|
SipAddress
|
sip:Ken.Myer@litwareinc.com
|
|
EnterpriseVoiceEnabled
|
|
|
LineUri
|
|
|
DialPlan
|
|
|
VoicePolicy
|
|
See the changes made by Enable-CsUser? Now here’s what that same object looks like after we run Set-CsUser:
|
Property
|
Value
|
|
DisplayName
|
Ken Myer
|
|
RegistrarPool
|
atl-cs-001.litwareinc.com
|
|
SipAddress
|
sip:Ken.Myer@litwareinc.com
|
|
EnterpriseVoiceEnabled
|
True
|
|
LineUri
|
TEL:+14255551298
|
|
DialPlan
|
|
|
VoicePolicy
|
|
Continuing down the pipeline, here’s what happens to the Ken Myer account after we run Grant-CsDialPlan:
|
Property
|
Value
|
|
DisplayName
|
Ken Myer
|
|
RegistrarPool
|
atl-cs-001.litwareinc.com
|
|
SipAddress
|
sip:Ken.Myer@litwareinc.com
|
|
EnterpriseVoiceEnabled
|
True
|
|
LineUri
|
TEL:+14255551298
|
|
DialPlan
|
RedmondDialPlan
|
|
VoicePolicy
|
|
Last, but surely not least, here’s where we stand after Grant-CsVoicePolicy finishes executing:
|
Property
|
Value
|
|
DisplayName
|
Ken Myer
|
|
RegistrarPool
|
atl-cs-001.litwareinc.com
|
|
SipAddress
|
sip:Ken.Myer@litwareinc.com
|
|
EnterpriseVoiceEnabled
|
True
|
|
LineUri
|
TEL:+14255551298
|
|
DialPlan
|
RedmondDialPlan
|
|
VoicePolicy
|
RedmondVoicePolicy
|
Nice.
We hope this gets you started with the process of enabling users for Lync Server and for Enterprise Voice. Admittedly, we skipped over a few infrastructure steps. For example, we didn’t tell you how to create dial plans or voice polices; we just assumed that these dial plans and voice policies were magically created for you. Does that mean we should probably do a walkthrough or two on creating dial plans and voice policies? Well, to tell you the truth, we never thought of that. But we’ll see what we can do. In the meantime, it’s your first day on the job at Litware, Inc; shouldn’t you be working rather than browsing articles on the Internet?
