Archive for the ‘Lync’ 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

$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

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

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:


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 = 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

Edge server update for managing file transfers

March 8, 2012 Leave a comment

An update is available to enable the control of the file transfers through the Access Edge service in a Lync Server 2010 environment

Categories: Lync

Title: Exchange and Lync 2010 IM Integration with OWA

March 8, 2012 Leave a comment

Jeff Schertz has an extremely useful article on his blog that provides the steps needed to add Lync IM integration, (aka CWA from OCS R2) to your OWA users:

During a recent deployment for Lync it was discovered that if the “InstantmessagingEnabled” attribute is already set to “true”, then when you run the Exchange PS CmdLet described in Jeff’s blog you will get an error message that appears to be complaining about parameter syntax not being correct. 

If you come across this situation there is a simple and easy work around. All you need to do is break out the Set-OwaVirtualDirectory statement in to several individual Set-OwaVirtualDirectory statements. If you issue the –InstantMessagingType line as shown below with the attribute set you will get a warning from PS indicating that the value is set. Executing the other three PS Cmdlets will result in the setting of the required attributes as described in Jeff’s blog.

If you need to quickly see which of the InstantMessaging attributes set issue this Cmdlet:

Get-OwaVirtualDirectory | fl instant* [From the CAS Server]

Example of breaking out the PS Cmdlets for setting the InstantMessaging attributes:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingType OCS
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingEnabled:$true
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingCertificateThumbprint 851588624951A8181DAB0CB6A52C19AC4C15DFA4
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingServerName

Thanks to David Sayer at Dell for helping discover this tip.

Categories: Exchange 2010, Lync