Archive

Archive for the ‘Uncategorized’ Category

Easily Changing CallerIDs for Lync Users

February 9, 2013 Leave a comment

Background: Suppose you have a customer who has employees, (“agents”) who make various calls during the day but need to have their CallerID changed during the day. This can occur if the Agent is placing calls on behalf of one client in the morning, and on behalf of another in the afternoon. Since each client has a different return number, (i.e. CallerID), it can be useful to have a method of changing a Lync agents’ CallerID. This can be done by creating a Lync Voice Policy, Usage and Route for each different number, (i.e. CallerID). Then you can use the CS-GrantPolicy cmdlet to assign, and re-assign the policy associated with a Lync user to change the CallerID that they present to callers. This can be done by writing a PowerShell script, and then assigning someone permissions to run that script, (e.g. Office Manager, etc.).

The first step is to create, and run a set of PowerShell scripts to create the Lync Policies, Usages and Routes.
Then write a set of scripts that someone can run to change the Voice Policy for a Lync user.

Step 1 example:
Create a PS script file named: cp.ps1 and add the text below.
Run this script with the following parameters: cp .
For example if you want the following:
Lync Policy : MI6-Policy
Lync Usage: MI6-Usage
Lync Route : MI6-Route
CallerID : 2085551234

From a Lync Management Shell run the script below as : cp MI6 2085551234

# cp.ps1
$clientname=$args[0]
$ph=$args[1]

$usage=$ clientname +”-Usage”
$policy=$ clientname +”-Policy”
$route=$ clientname +”-Route”

Set-CsPstnUsage -Identity global -Usage @{add=$usage}
New-CsVoiceRoute -Identity $route -numberpattern “.*” -PstnUsages @{add=$usage} -suppressCallerid $true -alternatecallerid $ph -PstnGatewayList @{add=”PstnGateway:10.0.0.41″}
New-CsVoicePolicy $policy -PstnUsages @{add = $usage}

Step 2 example: Suppose you want AD user MI6\money.penny to start placing calls with a CallerID of 2085551234.
Enter and run the following script as: changepolicy ad\money.penny MI6-Policy

# changepolicy.ps1
$loginname=$args[0]
$policy=$args[1]
Grant-cspolicy -identity $loginname -policyname $policy

By building a collection of the Step 2 scripts you can easily delegate the assignment of CallerIDs to different Lync users/agents.

Hugh Marlor
Principal Consultant – Unified Communications
Dell | GICS Public Services
Lync +1 512 723 3378
Customer feedback | How am I doing? Please contact my manager dustin_johnson@dell.com.

“The pessimist complains about the wind; the optimist expects it to change; the realist adjusts the sails.”

Categories: Lync, Uncategorized

Using account codes for client billing with Lync

February 8, 2013 Leave a comment

Background: Traditional PBXs have often implemented what are known as account codes. These account codes are usually two digits and are used by companies that work with multiple clients and need to bill those clients for long distance calls made on those clients behalf. For example, a marketing firm might be placing calls for one of their clients and needs to track and bill for calls made for that particular client. With account codes the calling person dials the destination phone number and after hearing a double beep then enters a two digit account code. The account codes and double beep are provided by the local phone carrier. The customer then receives a bill from the carrier that shows the calls made according to account code. Some PBX manufacturers even provided a serial interface known as the SMDR cable that could be connected to a PC with software that collects in real time the inbound and outbound calling information which can then put in a database or spreadsheet.

Question: How can account codes be implemented in Lync? Although you can’t replicate the scenario described above with the double beeps and codes entered after the number, there is another scenario that does work in Lync.
Answer: Instead of putting the account codes at the end of the number you can have the outbound caller put them in front of the number to dial. For example instead of entering 208 555 1234 in Lync, the caller enters 832085551234 (account code of 83). You then use a Trunk Configuration Associated Translation Rule to remove the account code prior to sending the call to the PSTN. Although you can do this on a Media Gateway, by doing this on a Trunk Configuration the Monitoring Role will still store the dialed number in the LCDR database with the account code. Unlike with a legacy PBX, you are free to use any king of account codes you like, and do not need to have them created by your local phone carrier.
Managing the Trunk Configuration Translation Rules: Unlike media gateway rules, Lync Trunk Configuration Translation Rules can be added and removed with Powershell. This makes it very easy to change account codes anytime you like.<br>
Suppose you have a Trunk Configuration with the identity of: pstngateway:10.0.0.41
To add a translation rule: New-CsOutboundTranslationRule -parent pstngateway:10.0.0.41 – Translation ‘$1’ -pattern ‘^53(\d{10})$’ -name Code53 -priority 2<br>
The above rule adds an account code that removes the number 53 from a 12 digit number and makes it the second rule in the list.

To remove a translation rule: remove-csoutboundtranslationrule -identity “pstngateway:10.0.0.41/code53”

Once you have collected this data then you can use Dell/Quest MessageStats to report against it.

Categories: Uncategorized

Lync 2013 Group Chat Permission Error

February 5, 2013 1 comment

I am working with a client where we are installing and configuring Persistent Chat for Lync 2013. We set up the PC server, created the databases with no issues and started the PC services with no errors. Yet, if we attempted to enumerate the PC Categories, (to which chat rooms are created in) we would get an error when attempting to create your first Persistent Chat Category.  

The Lync Admin GUI displays this error:

Get-cspersistentchatcategory: The current user is not part of the RTCUniversalServerAdmins Group

Of course we checked that it was indeed in that group.  The install process also makes sure that CSAdministrator and RTCUniversalServerAdmins are in the Local Group RTC Local Administrators.

After some time we noticed that the PC server name is longer than 15 characters. After working with MSFT we found out that when the PC server calls the Windows API to determine if the currently logged on user is a member of the local group “RTC Local Administrators”, it finds a mismatch with the server name. It turns out that when the server enumerates the local group lists by: servername + “\”+ “local group name” the server name is truncated to 15 characters. The problem is that the server uses the full hostname + “\” + “rtc local administrators” to see if the current user is part of that group.
For example: Actual FQDN of server = ahlncgroupchat001, (just NETBIOS part). Truncated NETBIOS name = XXlncgroupch0.
When the PC server goes to determine if the current user is part of the local group “RTC Local Administrators” it is looking for
“XXlncgroupchat001\RTClocal administers” but that group as enumerated on the server is actually “XXlncgroupchat0\RTC Local Administrator”
This results in a miss-match and the message above!

Resolution: Rename the server to less than 15 characters, re-install PC and re-start services.

Lesson Learned!

Categories: Lync, Uncategorized

Enabling Music On Hold for calls to and from the PSTN for Lync

December 17, 2012 1 comment

I recently had a need to enable music on hold for a Lync customer utilizing a Sonus/NET UX1000/UX2000 gateway. The process is very simple, yet I discovered one step missing that I hope others would like to avoid. The Sonus/NET gateways supports both an FXS (phone line) input, and an uploaded file. This document describes how to upload and enable a wav file on your Sonus/NET media gateway.

Wav file format: Make sure that the wav file is sampled at 8,000 hertz, mono and saved as PCM. The Audacity tool is great for converting files from sources such as iTunes, that are stereo MP4, and converting them. You also need to make sure that the file size for a UX1000 is less than 1 MB, and for a UX2000 less than 2 MB.

Enabling music on hold on the media gateway:
• Connect to the media gateway web interface
• Make sure that you are running firmware version 2.1 or higher
• Select Media / Media System Configuration
• Select File as the Source
• In the upper left click on the text “upload music file”, (very easy to miss)
• Verify that the file is uploaded by going to System / DSPs and view the Music on Hold File Status
• Now select Signaling Groups and open the Signaling group for your Lync Mediation server(s)
• Under Media Information select “Always Enabled” for Music on Hold. This is the step that is missing from the Sonus/NET documentation.
You should now have music on hold for when users call Lync users from the PSTN, or if a Lync user calls a PSTN user and puts them on hold.

Categories: Uncategorized

Outbound Account Codes in Lync 2010 – How to use them

November 14, 2012 Leave a comment

One of the features often used with legacy phone systems are what are known as Account Codes.
Account Codes are a method of tracking outbound calls, and grouping them together. For example, suppose your company performs outbound calls for a set of clients that have hired your company to create appointments for those clients’ sales people. People, (“agents”), might be placing calls on behalf of client “A”, and then later in the day on behalf of client “B”. Your company would like to track, and group the calls made by the agents for clients “A” and clients “B”. The purpose being so that your company’s clients are billed for that portion of your company’s service.
Legacy phone systems have long had the ability to allow a calling person to enter an outbound phone number followed by a two digit code, (“Account Code”). These correspond to the client they are making calls on behalf of. For example, Agent Sally might enter “208 555 5000”, wait for a double beep, and then enter “82” as the Account Code. The PBX and/or the local carrier will then remove the “82”, and the PBX and/or the carrier will store the phone number and Account Code entered. At a later time the Telecom admin can produce a report that shows what numbers were dialed with the corresponding Account Codes for billing purposes.

Question: How can a similar process be addressed in Lync 2010?

Answer: If you have Lync 2010 deployed with Enterprise Voice utilizing a media gateway, then the media gateway can be used to manage entered Account Codes. The idea is that you have callers enter a phone number in the format of: “Account Code” + “Dialed Number”, (e.g. 82 208 555 5000). Then configure your media gateway to remove the Account Code prior to sending on to the PSTN. You simply create an outbound “rule” on the gateway for each Account Code. For US dialing you should make sure that your rule looks for the Account Code, and that the total number length is 12. You might also have a rule that checks for the Account Code at the start, (i.e. first two digits), and that the total is either 12 or 13 digits, (i.e. account for 11 digit dialing).
Once you are collecting this data, then you can utilize the Lync 2010 Monitoring server to collect this data and then report against it. Dell/Quest’s MessageStats will even “pull” the Lync Monitoring Role data in to their database, and provides some very nice reports, (e.g. break out by area code, Outbound numbers, etc.). All of which can be exported easily to Excel for further manipulation.

Categories: Lync, Lync EV, Uncategorized

Using Exchange 2010/2013 UM for voice mail for either Lync users or legacy PBX users at the same time

November 13, 2012 Leave a comment

Exchange 2010 SP1 supports what are known as Secondary Dial Plans.

These are very useful for a situation where Exchange UM may be taking messages for Lync, but you also have users who are not on Lync, or Lync is not yet their primary phone. However, you wish to have Exchange UM be their voice mail provider, (i.e. as part of the process of decommissioning your existing legacy voicemail).

To create a Secondary Dial Plan on your Exchange UM server, do the following steps here:

  •  http://technet.microsoft.com/en-us/library/ff629383.aspx
  •  http://voipnorm.blogspot.com/2011/06/using-exchange-unified-messaging.html

Note: make sure that prior to these steps you have performed the Lync to Exchange UM integration so that Lync can act as a “PBX” to route the un-answered calls from your Legacy PBX to Exchange UM.

To enable a user for Exchange UM, and allow your legacy PBX to utilize Exchange UM, (i.e. take messages for that user’s extension), the following steps should be performed. This is for a user who has not been enabled for Lync.

  •  Have the user provide their Legacy 4/5 digit extension and AD logon
  •  Sample: Alexander Bell – AD = abell.local.ad Legacy PBX Ext: 5-2145
  •  Start the Exchange Management Console, (EMC)
  •  Locate Alexander’s mailbox
  •  Right click on Alexander’s entry and select “Enable Unified Messaging
  •  Click Browse, (for UM Policy)
  •  Select Legacy DialPlan and OK
  •  Select Next, (you may also enter their UM PIN but not necessary since Exchange will provide that PIN in an email that is auto generated)
  •  Click Next again
  •  Click Enable
  •  Instruct your telecom admin to “program” this extension on the Legacy “side” so that if a call is placed to this user’s extension, or they are on the phone, (“busy”), that it is not answered. Then needs to be routed to Exchange UM. Your telecom admin will know how to implement that routing. Just make sure to provide them with the IP address of the media gateway or Direct SIP trunk that routes to Lync. In the case of a Direct SIP, the Lync server(s) will route the transferred call to Exchange UM. This is because you will have already done the Lync/UM integration that allows Lync to route un-answered calls to UM.

 

Lync 2010 Response Groups, (RGS) not updated automatically when users SIP address change nor if they are removed from Active Directory.

November 1, 2012 3 comments

I recently worked with a client who I assisted with creating several Lync Response Groups that are used for Hunt Groups, (ring multiple phones at once for incoming calls) and IVR, (providing menu options for inbound calls and routing to various extensions).

My customer has built several Lync Response Groups by adding Agents, (those whose Lync phones will ring), under the Agents option of “Define a custom group of agents”.  Using this option you can add or remove “Agents”, (sip addresses), from a Lync Response Groups.

Un-expected behavior found: If a Lync enabled user’s SIP address changes or that person is removed from Active Directory, (e.g. the person leaves the company), we discovered that Lync Response Groups user names are not automatically removed.  In other words, the “Custom Group of Agents” does not behave like an AD group does when users are removed or their name changes.

Issue solved: If you wish to have Lync Response Groups agent lists change automatically there is another option:

  • Before you create a Lync Response Group, create an Email enabled distribution list.
  • For simplicity make the name of the email enabled AD distribution group the same as what you will call your Lync Response Group.
  • Then add the AD users that will be used by the Lync Response Group that you will create.
  • Now create your Lync Response Group but under the Agents option select “Use an existing email distribution list”.
  • Enter the email address of the email enabled distribution group that you previously created.  Make sure to check your spelling since the Lync admin tool does not validate the address entered.

Now when a user’s SIP address changes or they are removed from Active Directory your Lync Response Group Agent lists will stay current.  Please note that you can also change existing response groups by using the above process by creating distribution groups and changing the Agent option.  This can also be done with PowerShell cmdlets, but that is for another day…

Categories: Lync, Lync EV, Uncategorized