Prevent Lync from Auto Saving of Credentials, (e.g. multi-user pc)

April 12, 2012 Leave a comment

I have a customer who has computers that are used with a common AD logon by multiple people. For example, a central area that a pc has a logon but that several different people might run a Lync client under the same logon profile.

The issue and scenario that might be considered problematic is: 
  • James Bond signs in to Lync on this PC and his credentials are saved, (i.e. next logon James Bond does not have to enter his credentials)
  • Money Penny signs in to Lync on this PC and his credentials are saved, (i.e. next logon Money Penny does not have to enter his credentials)
  • The problem now is that anyone can walk up to this pc and login as James Bond or Money Penny

So how can this situation be avoided and what can we learn about how the Lync client stores credentials?

The Lync client will actually receive a Lync server created certificate that is downloaded to the User local cert store. It is this certificate that contains the user’s logon credentials that are saved. There are also two local registry settings that control the prompting of a users’ credentials that need to be set if you do not want a user to be prompted for credentials.

If you have a pc that has already had people who have logged on and saved their credentials, all you need to do is configure the two registry entries on that particular machine.

However, before you do that you must first remove the Lync Server created certificates:
• Open the local certificate store on the pc – start / run / mmc / Add / Certificates (make sure to select “My User Account” and that you are logged on as the user who will need to be prompted for Lync credentials no matter who is signing in to Lync)
• Expand Certificates / Personal / Certificates
• Delete the certificates in this folder

Make this regedit change:
Turning off Save Password, (make sure the value is set to “0”):
http://social.technet.microsoft.com/Forums/en-US/ocsclients/thread/db78a39c-9ad1-4b51-b164-7969bb545da6

Make this regedit change:
Note: Make sure the value is set to “0”:
http://social.technet.microsoft.com/Forums/en-US/ocsedge/thread/c267f2ae-53ee-48e5-ab60-0686eb76c386

Reboot the PC and you should now not be prompted for credentials

Categories: Uncategorized

Edge server update for managing file transfers

March 8, 2012 Leave a comment

http://support.microsoft.com/kb/2621840

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: http://blog.schertz.name/2010/11/lync-and-exchange-im-integration/

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 lab1ls.csmvp.net

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

Categories: Exchange 2010, Lync

Why do they call it a Trunk anyway?

February 22, 2012 Leave a comment

Ever wondered why they call a phone trunk a “trunk”? Has this not been something keeping you awake at night?

In the interest of helping those losing sleep over this question, the following might provide some assistance:

A very long time ago when telephones were being installed, it was necessary to bury cables in the ground that would connect houses to the phone company offices, which then connected to what is now known as the PSTN, (Public Switched Telephone Network). These cables were 3 or 4 inches around, grey in color, and resembled the look of an elephant “trunk”. As cables were laid, and the PSTN network grew the name “trunk” stuck. The intern-connecting of these pacaderm appendages came to be known as the act of “trunking” 

Categories: Lync EV, Uncategorized

To E1 or to T1? – that might be the question

February 22, 2012 Leave a comment

I was recently working on a Lync engagement that involved deploying Lync Enterprise Voice to connect to a legacy PBX. In order to route calls to and from the legacy PBX, we needed to configured a media gateway and a Q.SIG trunk. Q.SIG is a protocol that runs on a T1 PRI. It was originally invented as an industry standard to allow PBX’s from different vendors to route calls to each other. Prior to Q.SIG, if you have a Nortel PBX, (“switch”), and an Avaya PBX, and you wanted to route calls, there was no way to do this because each legacy PBX vendor used their own proprietary protocols to route and communicate with their own PBXs.

Q.SIG was developed to allow different vendor PBXs to route and communicate calls. Q.SIG runs on a standard T1 PRI. The Q.SIG protocol contains various pieces of information such as the Called Number, (who you are trying to dial), and the Caller ID, (who is calling). In order to connect two PBXs with a Q.SIG trunk, each PBX is installed and configured with a Q.SIG “card” so that the T1 PRI cable, (i.e. what we call a standard RJ45 Ethernet cable), can connect the two. The connection can also be a leased line T1 but for simplicity I am using the cabling example.

It turns out that media gateways from the major vendors also support Q.SIG, so that if you want to integrate a legacy PBX supporting Q.SIG with Lync, then you can use a media gateway to do the protocol conversion by connecting the Q.SIG port on a media gateway to the legacy PBX, and then configure the Ethernet “side” of the media gateway to communicate with Lync.

Q.SIG running over a T1 PRI only supports 23 concurrent calls occurring between the media gateway and the legacy PBX. The reason that it is only 23 calls, is that a T1 is a 1.5 MB “pipe”. Since each call is dedicated 64 kb/s of bandwidth you then divide 1.5 mb/s by 64 kb/s and you get the number 23. You might notice that the “maths” does not quite come out as “23” but there is another channel called the “D” channel that provides the signaling, (i.e. start the call, stop the call, etc.). The “D” channel is the telephony version of SIP, whereas the voice channels are the media streams like RTP in the Lync “world”.

But what if you wanted to get a few more calls from your Q.SIG connection?

Turns out that the T1 standard is used in the US, and that the E1 standard is used outside the US. The E1 standard has 30 channels instead of 23, (still 64 kb/s) and total bandwidth of 1.5 MB/s. When Q.SIG was developed, the designers accounted for both the T1 and E1 standards. This means that when you set up the Q.SIG card on the PBX, you can have the PBX administrator set it to “E1” instead of “T1”, and on the media gateway set the gateway to use Q.SIG with “E1” instead of “T1”, and you will then get up to 30 concurrent calls between the PBX and the gateway & Lync.

Categories: Lync EV, Uncategorized

Integrating Lync with a T1: What to make sure you and the customer ask the phone company

February 22, 2012 Leave a comment

When integrating Lync with a T1 PRI via a media gateway there are some questions that you might wish to ask the customer prior to beginning the Lync / Telephony integration that can save you and the customer some time:

• For calls to the PSTN: How does the T1 PRI expect to receive the Called Number and Calling Number fields from Lync? For example, should those numbers be 10 digits or 11 digits or is the T1 provider capable of accepting both?
• For calls from the PSTN: How will the T1 PRI provider send the Called Number and Calling number fields to the media gateway? For example, while they be 10 digits, or 11 digits, (Phone providers other than SIP providers won’t send E.164).
• What T1 PRI protocol(s) does the T1 PRI that has been provisioned support, (e.g. NI2, 5ESS, 4ESS or DMS100)? This is needed to configure the media gateway to communicate with the T1 PRI.
o Make sure to avoid the customer purchasing a T1 PRI that is utilizing CAS. CAS does not support CallerID, (i.e. you won’t know who is calling)
• What phone numbers are being routed to the T1 PRI? For example, is it a block of numbers or a list of numbers out of sequence? If all numbers are going to a single Lync server/pool, then the gateway can be configured to route all calls on the T1 PRI to Lync’s IP address. However, if you have multiple locations you may need to set up routing tables on the media gateway that depending on the Called Number may dictate to which Lync server/pool the call is routed.
• Before going onsite ask the customer, “Has the T1 PRI local loop has been turned-up and accepted”. When a phone provider, (i.e. the CLEC) technician goes onsite, they will connect the T1 to a box known as a DMARC (demarcation point). At that time the phone technician will verify that the T1 can communicate back to the phone company, (i.e. the “CO” – central office). After that is done, the customer will be asked to call the phone provider, and “accept the local loop” for that T1. At that time, the customer should ask the person on the phone to verify that BOTH the data and voice channels are “up”. Very often a phone provider will “turn up” the data channel, (the “D” channel) and not “turn up” the voice channels, (really).
• After the T1 PRI “turn up” is verified, then make sure that the customer also calls the phone provider to accept the block of phone numbers, (i.e. DIDs) that have been provisioned. This is a separate call since it will be a separate work order for the phone company, (really). The customer should tell the phone provider to go ahead and “point” those numbers to the new T1 even though the media gateway has not been yet connected.

Hopefully this is helpful when rolling out a media gateway with Lync and a T1 PRI by saving you some time onsite engaging in thumb-twiddling exercises 

Categories: Lync EV, Uncategorized Tags:

A Unique and clever method for providing Lync and legacy phone co-existance with minimal user pain

February 2, 2012 Leave a comment

I recently have been at a client who has decided to move from Centrex based phones to Lync EV. This customer decided that doing a something like a weekend cut-over to Lync from their legacy phone system would be too drastic for end users, (about 15,000 people). This organization like many has legacy functions such as hunt groups, (e.g. 3 or 4 phones ring at the same time in a dept and anyone can answer). The team responsible for the move to Lync and eventual support of Lync decided that they needed a solution that allowed both “phone” systems to run in parallel so that users can use both Lync and their legacy phones while legacy functionality such as response/hunt groups can be migrated to Lync.

This customer came up with a somewhat unique and clever way allow Lync to run alongside the legacy system, and provide EV without changing the end user’s phone number. This particular customer is using Centrex, but this would easily apply to Cisco, Avaya, or other PBX infrastructures. This solution also has the added benefit of providing a path for the customer to stop using TDM voice and move to a SIP provider:

Lync and Centrex co-existence – how it is done:

• Customer purchased block of DIDs on a Windstream SIP trunk, (e.g. 202 475 xxxx)
• User is enabled for Lync and Lync EV
• User is enabled for Exchange UM for voice mail
• Current Centrix DID, (e.g. +1 303 444 1234) is saved as LineURI field (E.164 format)
• User is assigned a DID from the Windstream SIP trunk, (e.g. +1 202 475 1234)
• User’s SIP trunk DID is set as a Lync Unassigned number using set-csunassignednumber cmdlet
• A Lync Announcement is created that forwards calls to the unassigned SIP URI of the +1 202 475 1234 number to the LineURI of the user, (e.g. +1 303 444 1234). This is done by using set-csannouncement cmdlet BUT not assigning a greeting AND setting the -TargetURI parameter to the SIP address of the end users’ LineURI, (e.g. tel:+13034441234). This means that calls forwarded from the end users’ Centrex phone to their SIP trunk DID, (e.g. 1202 475 1234), to route to the unassigned number, ( +1202 475 1234) which plays NO greeting and itself is forwarded to the end users’ LineURI, (i.e. the -targetURI parameter of the set-csannouncement).
• At this point the following behavior occurs for a user:
o User maintains their current phone number
o User places calls from Lync via the SIP trunk and their CallerID is their Centrex number
o Calls placed to their Centrex number forward directly to their Lync client/phone
o If the user wishes to not receive calls on their Lync client they can turn off the autoforward. If they make calls from Lync their CallerID will still be their Centrex number
• At a later point in time the customer will begin porting the Centrex numbers over to the Windstream SIP trunk provider and start to get rid of Centrex phones.

Categories: Lync EV