Archive for February, 2013

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

$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:″}
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
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

“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:
To add a translation rule: New-CsOutboundTranslationRule -parent pstngateway: – 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:”

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