I just finished installing Lync server 2010 at work and noticed that the "click to call" feature on the client was not making a "lync call" the default for everyone. This is controlled in the CsClientPolicy for users. Here is the Powershell command to change it:
Set-CsClientPolicy -EnableVOIPCallDefault $True
More information on the full set of options and parameters can be found here: http://technet.microsoft.com/en-us/library/gg398300.aspx
Monday, March 11, 2013
Monday, March 4, 2013
Favorite Tools to stress-test a connection
Recently at work I turned up a new Metro connection between two locations. Once it was up, I was asked how I verified that indeed I was getting the full 100mb/s that we were paying for. I had to find a tool that would "stress-test" the connection to it's max to prove that it was working.
Here are two of the tools that I used and how I used them:
First tool is: "iperf" (http://en.wikipedia.org/wiki/Iperf)
Great little tool that just works. Tons of options but basically you put it on a laptop at both ends of the connection. One is the client and one is the server. You turn on the server with this command from the command prompt:
iperf -s
Yup, it's that simple. Then take the other laptop to the other end of the connection and type this command from the command prompt:
iperf -c <ip address of the server>
Again, it's that simple. The client will contact the server and will run as fast as it can flooding the connection. Once it's done, you will get a report that shows how long it took to send the packets and the max throughput. Great tool, especially for contractors to prove that everything is working.
Second tool is "Pathtest" (http://www.testmypath.com)
This is very similar in the way it works to iperf. Same setup as before, just replace the "iperf" with "pathtest" in the commands. The reason I like this one is the report/output is a little neater and easier for none-techie people (like the CFO) to read and understand. They like seeing reports with neat graphs and Pathtest gives them that.
Both tools are ran from the command prompt. The easiest way to open the command prompt is to following these steps:
1. Press and hold the "Windows key" (usually located just left of the space bar) and then press "r"
2. Type in the RUN box the following: cmd
3. Press enter (or click OK)
4. This will bring up a black box. That is the command prompt.
Good luck and I hope this helps next time you need to prove to the bean counters that you are getting what they are paying for.
Here are two of the tools that I used and how I used them:
First tool is: "iperf" (http://en.wikipedia.org/wiki/Iperf)
Great little tool that just works. Tons of options but basically you put it on a laptop at both ends of the connection. One is the client and one is the server. You turn on the server with this command from the command prompt:
iperf -s
Yup, it's that simple. Then take the other laptop to the other end of the connection and type this command from the command prompt:
iperf -c <ip address of the server>
Again, it's that simple. The client will contact the server and will run as fast as it can flooding the connection. Once it's done, you will get a report that shows how long it took to send the packets and the max throughput. Great tool, especially for contractors to prove that everything is working.
Second tool is "Pathtest" (http://www.testmypath.com)
This is very similar in the way it works to iperf. Same setup as before, just replace the "iperf" with "pathtest" in the commands. The reason I like this one is the report/output is a little neater and easier for none-techie people (like the CFO) to read and understand. They like seeing reports with neat graphs and Pathtest gives them that.
Both tools are ran from the command prompt. The easiest way to open the command prompt is to following these steps:
1. Press and hold the "Windows key" (usually located just left of the space bar) and then press "r"
2. Type in the RUN box the following: cmd
3. Press enter (or click OK)
4. This will bring up a black box. That is the command prompt.
Good luck and I hope this helps next time you need to prove to the bean counters that you are getting what they are paying for.
Tuesday, February 12, 2013
Powershell script to make a Lync 2010 "Hunt Group" from scratch
I am really trying to beef up on my Powershell so I decided to make a script that would make a Lync 2010 Hunt Group. There was a challenge that I had where I was required to make (10) Hunt Groups workflows, queues, and groups. They were to be the same settings, just different users and phone numbers. The thought of going through all the wizards for all the settings just made me want to cry, so I decided to put the big boy pants on and learn how to do this via Powershell. Here goes....
Let's start by identifying what systems we will need to touch.
- Exchange server for creating the users and voicemail Unified Messaging (UM)
- Domain Controller for setting the 'telephone' option in the users account attributes
- Lync server for creating the users, worflow, queues, and groups.
Now that we know the systems, let declare the order of operations.
1st - Exchange to create the user account ONLY. Voicemail will come later.
2nd - Domain Controller - telephone attribute
-> This is necessary as Exchange uses this information to assign the SIP URI in the next step
3rd - Exchange - enable the voicemail (UM)
4th - Lync to finish the script
Since we know the order of operations, let's dive into the script. I found that Powershell is much like PHP in the fact that you are declare variables in the beginning to use later. One gotcha here is that you can't call variables that haven't been created yet (hard lesson learned here - more to come about that). Here are the variables that I used:
$SetNumber = '1'
$SetName = 'Johnny Smith'
$SetAlias = 'jsmith'
$SetUserPrincipalName = 'jsmith@domain.local'
$SetSAMAccountName = 'jsmith'
$SetFirstName = 'Johnny'
$SetLastName = 'Smith'
$SetPassword = 'Password'
$SetDBStore = 'DatabaseStore01'
$Telephone = '8005551212'
$SIPResourceID = $SetAlias + '@domain.local'
$SetInboxPermission = $SetAlias + ':\inbox'
This is a good time to go ahead and run the commands. They are a little confusing and overwhelming at first look, but I think if you read the command, you will really see the variables in there and it will make sense:
From the Exchange server:
Command:
New-Mailbox -Name $SetName -Alias $SetAlias -OrganizationalUnit 'domain.local/OU/CHILD_OU' -UserPrincipalName $SetUserPrincipalName -SamAccountName $SetSAMAccountName -FirstName $SetFirstName -Initials '' -LastName $SetLastName -ResetPasswordOnNextLogon $false -Database $SetDBStore
From the Domain Controller (NOTE: We have to declare the "$SetAlias" again as we jumped to a new server):
Variable: $SetAlias = 'jsmith'
Command: Set-ADuser -id $SetAlias -officephone $Telephone
From the Exchange Server (don't have to declare the variables as we already have them):
Command:
Enable-UMMailbox -Identity $SetName -UMMailboxPolicy "UMDefault Default Policy" -SIPResourceIdentifier $SIPResourceID
***EXTRA BONUS COMMAND***
I like to set the permissions on the user to allow for everyone to be able to view their mailbox. IMO, this just saves headaches in the future of you allowing users specifically. Here are the commands:
set-MailboxFolderPermission -id $SetAlias -user default -AccessRights reviewer
set-MailboxFolderPermission -id $SetInboxPermission -user default -AccessRights reviewer
***END - EXTRA BONUS COMMAND***
From the Lync Server:
(Quick NOTE before we get too far. We have to declare more variables here as we have created the user and now we have to get more information that we could only get AFTER we the previous steps have been created)
Variables:
$ServiceId = "service:ApplicationServer:server.domain.local"
$GroupName = "Group 1"
$QueueName = "Queue 1"
$WorkFlowName = "Hunt Group 1"
$PrimaryURI = "sip:8005551212@domain.com"
$LineURI = "tel:+18005551212"
$DisplayNumber = "+1 (800) 555-1212"
$DistoList = "distrolist@domain.local"
$VoiceMail = "sip:jsmith@domain.local;opaque=app:voicemail"
Commands:
1. Create the group:
Command: New-CsRgsAgentGroup -Parent $ServiceId -Name $GroupName -AgentAlertTime 20 -ParticipationPolicy Informal -RoutingMethod Parallel -DistributionGroupAddress $DistoList
2. Create the queue:
Additional Variables: $Group = get-csrgsagentgroup -Name $GroupName
Command: New-CsRgsQueue -Parent $ServiceId -Name $QueueName -TimeoutThreshold 30 -TimeoutAction $ActionTO -AgentGroupIDList($Group.Identity)
3. Create the workflow:
Additional Variables:
$Queue = Get-CsRgsQueue -Name $QueueName
$ActionTO = New-CsRgsCallAction -Action TransferToVoiceMailUri -uri $VoiceMail
$ActionWM = New-CsRgsCallAction -Action TransferToQueue -QueueID $Queue.Identity
$NBACTION = New-CsRgsCallAction -Action TransferToVoicemailUri -uri $VoiceMail
Command:
New-CsRgsWorkflow -Parent $ServiceId -Name $WorkFlowName -Description "Hunt Group 1" -PrimaryUri $PrimaryURI -LineUri $LineURI -DisplayNumber $DisplayNumber -Active $true -Anonymous $true -DefaultAction $ActionWM -NonBusinessHoursAction $NBACTION
Create the user in Lync for the voicemail
Attributes: $Username = "jsmith@domain.local"
Commands:
enable-csuser -identity $UserName -registrarpool lyncserver.domain.local -sipaddresstype Emailaddress -sipdomain domain.local
set-csuser -identity $UserName -enterprisevoiceenabled $true
Grant-CsVoicePolicy -policyname "Voice Policy Name" -Identity $UserName
The script is finished!!!! Now you can go into the Lync control panel and see the changes that you have made. Now the reason for this script, rinse and repeat. Just change the "VARIABLES" to meet your needs. Since this was 1 of 10 users accounts, I just changed it from #1 to #10.
Let's start by identifying what systems we will need to touch.
- Exchange server for creating the users and voicemail Unified Messaging (UM)
- Domain Controller for setting the 'telephone' option in the users account attributes
- Lync server for creating the users, worflow, queues, and groups.
Now that we know the systems, let declare the order of operations.
1st - Exchange to create the user account ONLY. Voicemail will come later.
2nd - Domain Controller - telephone attribute
-> This is necessary as Exchange uses this information to assign the SIP URI in the next step
3rd - Exchange - enable the voicemail (UM)
4th - Lync to finish the script
Since we know the order of operations, let's dive into the script. I found that Powershell is much like PHP in the fact that you are declare variables in the beginning to use later. One gotcha here is that you can't call variables that haven't been created yet (hard lesson learned here - more to come about that). Here are the variables that I used:
$SetNumber = '1'
$SetName = 'Johnny Smith'
$SetAlias = 'jsmith'
$SetUserPrincipalName = 'jsmith@domain.local'
$SetSAMAccountName = 'jsmith'
$SetFirstName = 'Johnny'
$SetLastName = 'Smith'
$SetPassword = 'Password'
$SetDBStore = 'DatabaseStore01'
$Telephone = '8005551212'
$SIPResourceID = $SetAlias + '@domain.local'
$SetInboxPermission = $SetAlias + ':\inbox'
This is a good time to go ahead and run the commands. They are a little confusing and overwhelming at first look, but I think if you read the command, you will really see the variables in there and it will make sense:
From the Exchange server:
Command:
New-Mailbox -Name $SetName -Alias $SetAlias -OrganizationalUnit 'domain.local/OU/CHILD_OU' -UserPrincipalName $SetUserPrincipalName -SamAccountName $SetSAMAccountName -FirstName $SetFirstName -Initials '' -LastName $SetLastName -ResetPasswordOnNextLogon $false -Database $SetDBStore
From the Domain Controller (NOTE: We have to declare the "$SetAlias" again as we jumped to a new server):
Variable: $SetAlias = 'jsmith'
Command: Set-ADuser -id $SetAlias -officephone $Telephone
From the Exchange Server (don't have to declare the variables as we already have them):
Command:
Enable-UMMailbox -Identity $SetName -UMMailboxPolicy "UMDefault Default Policy" -SIPResourceIdentifier $SIPResourceID
***EXTRA BONUS COMMAND***
I like to set the permissions on the user to allow for everyone to be able to view their mailbox. IMO, this just saves headaches in the future of you allowing users specifically. Here are the commands:
set-MailboxFolderPermission -id $SetAlias -user default -AccessRights reviewer
set-MailboxFolderPermission -id $SetInboxPermission -user default -AccessRights reviewer
***END - EXTRA BONUS COMMAND***
From the Lync Server:
(Quick NOTE before we get too far. We have to declare more variables here as we have created the user and now we have to get more information that we could only get AFTER we the previous steps have been created)
Variables:
$ServiceId = "service:ApplicationServer:server.domain.local"
$GroupName = "Group 1"
$QueueName = "Queue 1"
$WorkFlowName = "Hunt Group 1"
$PrimaryURI = "sip:8005551212@domain.com"
$LineURI = "tel:+18005551212"
$DisplayNumber = "+1 (800) 555-1212"
$DistoList = "distrolist@domain.local"
$VoiceMail = "sip:jsmith@domain.local;opaque=app:voicemail"
Commands:
1. Create the group:
Command: New-CsRgsAgentGroup -Parent $ServiceId -Name $GroupName -AgentAlertTime 20 -ParticipationPolicy Informal -RoutingMethod Parallel -DistributionGroupAddress $DistoList
2. Create the queue:
Additional Variables: $Group = get-csrgsagentgroup -Name $GroupName
Command: New-CsRgsQueue -Parent $ServiceId -Name $QueueName -TimeoutThreshold 30 -TimeoutAction $ActionTO -AgentGroupIDList($Group.Identity)
3. Create the workflow:
Additional Variables:
$Queue = Get-CsRgsQueue -Name $QueueName
$ActionTO = New-CsRgsCallAction -Action TransferToVoiceMailUri -uri $VoiceMail
$ActionWM = New-CsRgsCallAction -Action TransferToQueue -QueueID $Queue.Identity
$NBACTION = New-CsRgsCallAction -Action TransferToVoicemailUri -uri $VoiceMail
Command:
New-CsRgsWorkflow -Parent $ServiceId -Name $WorkFlowName -Description "Hunt Group 1" -PrimaryUri $PrimaryURI -LineUri $LineURI -DisplayNumber $DisplayNumber -Active $true -Anonymous $true -DefaultAction $ActionWM -NonBusinessHoursAction $NBACTION
Create the user in Lync for the voicemail
Attributes: $Username = "jsmith@domain.local"
Commands:
enable-csuser -identity $UserName -registrarpool lyncserver.domain.local -sipaddresstype Emailaddress -sipdomain domain.local
set-csuser -identity $UserName -enterprisevoiceenabled $true
Grant-CsVoicePolicy -policyname "Voice Policy Name" -Identity $UserName
The script is finished!!!! Now you can go into the Lync control panel and see the changes that you have made. Now the reason for this script, rinse and repeat. Just change the "VARIABLES" to meet your needs. Since this was 1 of 10 users accounts, I just changed it from #1 to #10.
Lync Common Area Phones (Conference Rooms)
I am deploying a Lync Server 2010 at my office and ran into the conference room phones. I started to configure a user account for each phone but quickly realized that it wasn't going to work like I thought. I had to research a way for multiple users to use this phone. Here were my goals to make this happen:
1. Provide great audio sound and not choppy for calls 2. Work for multiple users with different laptops 3. Had to be user friendly and easy to use (or the users would either always call me to set it up or just wouldn't use it)
I started by choosing the better hardware for the phone. A Polycom CX3000 is a perfect solution for conference room phones. PoE phone but will connect via USB as well. Perfect mix for my conference rooms.
Next I need to make it work for all my users. I got a little lucky in the fact that all of my users have Dell laptops and they all take the same docking station. So I dropped a docking station in each conference room and plugged up a keyboard, mouse, HDMI cable to the TV, Ethernet cable and the Polycom CX3000 via USB. That way users can come in, drop their laptop on the docking station, and they have all the tools already plugged in ready to go.
Now the challenging part; making it user friendly. To start this part let me say that when I deployed the Lync phone system to the users, I spent a lot of extra time on the training slides and presentations to make sure everyone knew EVERYTHING about how to use the client. Also, I have a very tech savvy group of users (that helps!!!). Now, since we already have everything plugged in to the docking station, when the users turn on there laptop (and after a quick, really quick, driver install from Lync on the Polycom phone) the Polycom CX3000 was available as a drop down option for them to use as their "speaker phone" on Lync calls, Go-to-meeting calls, and all other calls. The TV was also ready to go so they can share their screen for everyone in the room and, since we are on Lync, they can share that same screen with the external callers via Lync conferencing.
This was a WIN-WIN for our department. Conference rooms have always been a pain for us, but this has really reduced the calls to the helpdesk as well as made our users a lot happier. They are actually using the solution which is the WIN.
Here is a link to the Polycom phone.
1. Provide great audio sound and not choppy for calls 2. Work for multiple users with different laptops 3. Had to be user friendly and easy to use (or the users would either always call me to set it up or just wouldn't use it)
I started by choosing the better hardware for the phone. A Polycom CX3000 is a perfect solution for conference room phones. PoE phone but will connect via USB as well. Perfect mix for my conference rooms.
Next I need to make it work for all my users. I got a little lucky in the fact that all of my users have Dell laptops and they all take the same docking station. So I dropped a docking station in each conference room and plugged up a keyboard, mouse, HDMI cable to the TV, Ethernet cable and the Polycom CX3000 via USB. That way users can come in, drop their laptop on the docking station, and they have all the tools already plugged in ready to go.
Now the challenging part; making it user friendly. To start this part let me say that when I deployed the Lync phone system to the users, I spent a lot of extra time on the training slides and presentations to make sure everyone knew EVERYTHING about how to use the client. Also, I have a very tech savvy group of users (that helps!!!). Now, since we already have everything plugged in to the docking station, when the users turn on there laptop (and after a quick, really quick, driver install from Lync on the Polycom phone) the Polycom CX3000 was available as a drop down option for them to use as their "speaker phone" on Lync calls, Go-to-meeting calls, and all other calls. The TV was also ready to go so they can share their screen for everyone in the room and, since we are on Lync, they can share that same screen with the external callers via Lync conferencing.
This was a WIN-WIN for our department. Conference rooms have always been a pain for us, but this has really reduced the calls to the helpdesk as well as made our users a lot happier. They are actually using the solution which is the WIN.
Here is a link to the Polycom phone.
Tuesday, April 3, 2012
Conference Bridge in Lync Server 2010
How to create a conference bridge in Lync server 2010.
<Sorry for the quick and dirty version. I just wanted to get this out there. Will clean later>
My company wanted to go out and buy several different conference bridges this week. I decided to make a couple on our Lync server.
Requirements:
- Create separate conference bridge ID's per department
- Make them available for the whole department
- Have to be accessible from the outside
We have DID's (direct inward dial) phone numbers for each of our users. I know that I can create a new user for each of these departments, but I want them to share the same DID. So in Lync server I was able to assign the same DID to each user and give them an extension. This made them unique in Lync based off their extension number. Here is how I did it:
Step 1. Choose a DID to use
Step 2. Create your users in Active Directory
Step 3. Enable the users in Lync Server
Step 4. Give the users the same phone number with unique extensions
Example: tel:+18885551212;ext=100
Step 5. Login to your conferencing options webpage to set the PIN
Step 6. Copy the information in the conferencing options webpage for following:
PIN
Conference URL
Conference ID
Step 7. Give this information out the users/departments.
<Sorry for the quick and dirty version. I just wanted to get this out there. Will clean later>
My company wanted to go out and buy several different conference bridges this week. I decided to make a couple on our Lync server.
Requirements:
- Create separate conference bridge ID's per department
- Make them available for the whole department
- Have to be accessible from the outside
We have DID's (direct inward dial) phone numbers for each of our users. I know that I can create a new user for each of these departments, but I want them to share the same DID. So in Lync server I was able to assign the same DID to each user and give them an extension. This made them unique in Lync based off their extension number. Here is how I did it:
Step 1. Choose a DID to use
Step 2. Create your users in Active Directory
Step 3. Enable the users in Lync Server
Step 4. Give the users the same phone number with unique extensions
Example: tel:+18885551212;ext=100
Step 5. Login to your conferencing options webpage to set the PIN
Step 6. Copy the information in the conferencing options webpage for following:
PIN
Conference URL
Conference ID
Step 7. Give this information out the users/departments.
Tuesday, January 24, 2012
How to send a new Welcome email for Exchange 2010 United Messaging users
I was faced with a challenge today where several users reported that they didn't get their "welcome" email from Exchange when I configured them for Unified Messaging. I looked everywhere in the console for how to resend the email. No Powershell help. Nothing in technet. What to do....
I didn't really want to disable and then enable them. That seems pointless. There has to be a way!!! So I decided to just resent their PIN. Boom...another email was sent out. That is crazy but it worked. They received the email and were able to configure their voicemail.
Here are the steps I took (pretty easy):
1. Open Exchange Management Console
2. Expand "Recipient Configuration"
3. Find the user account that you need to send the email to
4. Right click the user account and choose: "Reset Unified Messaging PIN..."
5. Accept the defaults and click OK on the next screen.
6. This will general a new PIN and send an email to the user.
Here is the PowerShell command:
Set-UMMailboxPIN -Identity "bob ausmus"
I didn't really want to disable and then enable them. That seems pointless. There has to be a way!!! So I decided to just resent their PIN. Boom...another email was sent out. That is crazy but it worked. They received the email and were able to configure their voicemail.
Here are the steps I took (pretty easy):
1. Open Exchange Management Console
2. Expand "Recipient Configuration"
3. Find the user account that you need to send the email to
4. Right click the user account and choose: "Reset Unified Messaging PIN..."
5. Accept the defaults and click OK on the next screen.
6. This will general a new PIN and send an email to the user.
Here is the PowerShell command:
Set-UMMailboxPIN -Identity "bob ausmus"
Monday, December 5, 2011
External Response Group Call Routing with Lync Server
I stole (er...found) this and it is awesome for Lync. Props to http://blog.kiwibees.net/?p=98
Once you start playing with Response Groups in Lync (or OCS) it probably wont be long before you want one to dial out to your PBX. In my case recently it was to get a support line to call an on-call mobile.
Out of the box, Lync wont.
Any outbound call needs a voice route to determine its routing path and permissions – without one it simply cant go anywhere. In short when the RGS tries to dial out it will default to your global voice policy which (unless you’ve changed it – and you shouldn’t) wont route.
Your first task is to therefore create a voice policy that includes the number (or number pattern) you want to call and define a gateway device.
And you’re done. Your RGS can now dial out.
Last tip – make sure the number you’re trying to dial out to is entered fully normalised in the format
+<countrycode><areacode><number>@<sipdomain>.
eg. +6491234567@sipdomain.com
Once you start playing with Response Groups in Lync (or OCS) it probably wont be long before you want one to dial out to your PBX. In my case recently it was to get a support line to call an on-call mobile.
Out of the box, Lync wont.
Any outbound call needs a voice route to determine its routing path and permissions – without one it simply cant go anywhere. In short when the RGS tries to dial out it will default to your global voice policy which (unless you’ve changed it – and you shouldn’t) wont route.
Your first task is to therefore create a voice policy that includes the number (or number pattern) you want to call and define a gateway device.
- You can do this via the Lync Control Panel or Powershell.
- Make sure the voice policy is of type ”User” otherwise you wont be able to apply it to your RGS object
- Make sure you commit the new policy otherwise it wont be available for use (you’ll get a policy is not a user policy error).
Grant-CSVoicePolicy -identity “RGSWorkflowObject” -PolicyName VoicePolicyYouCreatedFor identity, use the display name of your RGS Workflow object.
And you’re done. Your RGS can now dial out.
Last tip – make sure the number you’re trying to dial out to is entered fully normalised in the format
+<countrycode><areacode><number>@<sipdomain>.
eg. +6491234567@sipdomain.com
Subscribe to:
Posts (Atom)