Continuing the series in our Lync Deployment.  As we are approaching the date that we will completely cut over all users to lync we wanted to build in some redundancy to our deployment. 

We have done this by licensing a second standard server and configuring it in the topology as a backup registrar.  This will allow us to have a fail over server to host all voice calls in the event of a failure to the primary standard edition server (PSE).  The Backup Standard Edition Server (BSE) will provide voice capabilities and limited IM capabilities in a production down situation of the PSE. 
Note: for calls to be made in a ‘failed over’ scenario backup calling routes will need to be configured for the BSE mediation role as discussed in a future post

So we have configured our backup in the topology (how to in a future post) and configured the failover routes so it is time to test the scenarios.  For our testing we want to confirm that the PSE can fail and we can still make calls to the PSTN and if the PSTN is not available make a call out the analog backup lines.

You will want to review the default setting in your topology to set it to the lowest value possible when testing otherwise this test could take 15-20 minutes depending upon your value selected to fail over to a backup registrar. 

Our test was to remove the NIC from the PSE, the Lync clients will disconnect, attempt to re-connect and after the specified time connect to the BSE as the fail over registrar and make calls via the PRI and Pots lines.

However after configuring a Backup Registrar Lync Clients wouldn’t login during a failed server.  The clients would drop the connection as expected but however, they wouldn’t login to the backup registrar with limited functionality as expected. 

Side note… Kudos to @DHannifin helping figure this one out…
check out our awesome buddy Dustin’s blog: http://www.technotesblog.com/ for lots of Uber good Lync goodness.

Even after changing the fail over time to just 30 seconds, the phone handset endpoints would login and calls could be made, but the Lync client would fail to login.   After some digging in the trace logs we found client that wouldn’t connect that we were getting an unauthorized error because the newly added BSE server wasn’t in the user certificate issued by the server to the client so the Lync client didn’t trust the backup registrar.

The Lync Client uses a certificate for communications with the front end server.  This certificate is not updated very often, in fact the default value to when it will update is 8760 HOURS that’s 365 DAYS!  (A little longer than we wanted to wait for our testing…)

You can use the PowerShell command: Get-CSWebServiceConfiguration
to review the current values of your setting for MaxValidityPeriodHours’

Since we didn’t have a year to wait, there are a couple solutions.
1. Change the default value by using the PowerShell command
Set-CSWebServiceConfiguration but this changes the cert settings for all clients and would require time for replication.
or
2. Delete the certificate on the machine that you are using for testing. This is a little more killing a fly with a sledge hammer, but for this testing appeared to be the best solution.

So in a testing scenario where you don’t want to change the re-issue certificate settings, on the machine you are using to test, simply launch an mmc window add the add-in for certificates and choose to manage users certificates.  Next browse to the personal certificates where you should find a certificate named the SIP URI of the user you are logged in as and it is issued by ‘Communications Server’. Delete the certificate and then restart your Lync Client (exit the application not just log off). 

Note: After deleting the cert, before you re-launch the Lync Client, you will need your primary front end server online so a new certificate can be issued to the client on the workstation.  Otherwise you still will not have valid certificate to connect and since the PSE is offline your client will try to connect to the BSE for which it still doesn’t have a valid cert.

After you re-connect to Lync to the PSE you can then power off the PSE (or remove the virtual nic from the virtual machine as we did.) You will notice the Lync client log off and after your Backup Registrar time out passes Lync will login to the Backup Registrar.  You will know this has happed when you see the Lync client display the red bar indicating limited functionality.

If you have correctly configured a backup call route to your gateway, all voice calling will route out the gateway as if your Lync topology was operating normally.

Note: In an actual failover after you have configured all backup routes a call in progress should stay active even while the Lync Client is going thru its log off/log on process to connect to the backup registrar.  If you are in an active call during this fail over, your call should stay connected, BUT it will disconnect if you hit cancel on the Lync client during the reconnection process.

We rewired over 60 data locations in just 3 Monday nights, and the work couldn’t have been done without our awesome volunteers.  I just wanted to say thanks again to Steve T, Wayne T, Gene S, Mark B, John S, and Bob P.  Guys your heart for kingdom ministry is awesome and with out your help we couldn’t do what we do!  Ceiling Tile Dust and carting around ladders is more fun with you guys around!

A couple crazy photos from our work nights:

This is a prime example of why we decided to re-wire! Scotch locks on Data wiring NOOOO!

The Growing pile of wire that has been pulled out

The new IDF wiring rack getting installed

Jeremie and the team formulating the action plan.

Steve has a history of wanting to drive… granted there have been a few accidents, but when it was time to clean up we had something special for him to drive that was fairly accident proof.

Thanks to our volunteers our VOIP migration has an end in site.

This post is a continuation of a series of posts about Lync Deployment. The documentation portion of this project has gotten the back burner, and I need to say that a blogger I am not.. but picking up the documentation of this process is important.

This can be used as a resource to configure an Avaya IPOffice (IPO) 412 (software version 5.0) as a Gateway for a Lync deployment calling the PSTN, with AsteriskNOW as a SIP proxy to resolve disconnected calls when placed on hold or transferred, your mileage may vary. Calls are routed over a SIP Trunk (Session Initiation Protocol) configured between the IPO and Asterisk and Asterisk and the Lync Front End server.

Once we deployed the calling from the PSTN via a PRI from the IPOffice to a SIP connection to the Lync Mediation server we were able to make and receive calls from Lync endpoints, however we quickly noticed that when calls were put on hold or needing to be transferred to another extension the call was simply dropped.  It doesn’t matter if the call was being transferred to a Lync extension or an Avaya extension the call would drop.  The only option to “hold” a call was to mute the call.  If Hold was used the call would disconnect.

After a few days of tracking this down we were able to identify this was an issue that happened every time.  It wasn’t specific to a user or extension.  In fact the Avaya white paper noted this as a known issue.

The issue is documented on the final page: https://devconnect.avaya.com/public/download/interop/OCSR2-IPO-PSTN.pdf

The document notes that calls cannot be placed on mute, nor does the PSTN caller ID pass thru to Lync, these notes however that was not our experience.  Mute and Caller ID worked fine on inbound calls.

We tried several different solutions to resolve this issue.  Our first attempt was routing all calls thru an inGate SIParator.  This is basically a SIP proxy device.  We happen to have one laying around from some testing with a SIP dial tone provider.  This device had worked well with the IPO connecting to SIP Trunks that required authentication with a different authentication handshake than the standard Avaya methods.  However the SIParator did allow to proxy the Avaya to Lync SIP trunk, but didn’t resolve the disconnects when holding or transferring calls.

Next we tried to use a SnomOne software PBX, this had some promise, after configuring the call to forward all calls to the Avaya or Lync (which was a hassle) we found that this resulted in calls connecting but the caller not hearing any of the conversation, or the call would just stop passing audio although it remained connected.  We also found that the SnomOne would keep terminated calls still active and you would have to reset the sessions manually.

Finally we landed on an asterisk installation installed on a virtual machine.  We installed Asterisk now (without the web interface) for simplicity.  Once you configure the two sip trunks (one for Avaya and one for Lync) and build the dial plan to forward all calls from Lync to Avaya and all calls from Avaya to Lync the configuration was basically complete.

Much Credit must go to my great Church IT RoundTable peer Dave Mast (@DaveMast) for his Asterisk Programming help! Kuddos to Dave!

Below are the steps to configure the Avaya and Lync to communicate via an Asterisk Proxy.

Install Asterisk on a machine, (in our case a new VM) and note the IP Address you give the server.  Next configure a new Avaya SIP Trunk and ARS Table. The same steps as noted here, except you need to enter the information of your Asterisk server in step 2 as the ITSP IP Field.

After completing steps 1,2,3 and 4. Complete Step 5 to prepare an incoming call route from Asterisk to the IPO.

Step 6 is basically the same and we repurposed the old ARS table that we created but changed the short codes and features a little. 

Note in step 9 if you have extensions on both IPO and Lync you can’t use variables in your short codes.  This remains true.

After step 10 things change a little so I will document that here.  The information may look very similar to the previous instructions with SIP for IPO and Lync with out a proxy but they are a little different.

Because of how you have to pass calls from Avaya to Asterisk you will need to configure you rARS table a little differently.  Step 10 walks you thru a extension with a DID, that in fact is no different.  But Step 11 has changed. I have quoted the information that hasn’t changed and added what needs to be adjusted for the dialing plan to work with Asterisk.

11. Configure routing for For Lync Extensions without DIDs (as documented here).

An ARS entry will have to be created for each Extension since the IPO cannot use variables in the E.164 formatting of the outbound call and Lync requires the call to come in in the +11235556500;ext=4175 format.

The Asterisk can’t pass the formatting with “;” so we will pass just the 4 digit extension from IPO to Asterisk, and our 4 digit dial plan dialing rule that translates calls TO those extensions from a lync endpoint into +11235556500;ext=4175 format will cause the call to route to the extension when it comes into Lync from Asterisk.

This example extensions 4150-4175 don’t have DIDs but were valid Lync extensions, in order for IPO extensions to call extensions 4150-4175 a short code would be required for 41xx Pointing to the the SIP-Lync ARS Table. (Assuming no other extensions in the 4100 range are homed on the IPO).
Then entries for each extension would need to be added to the ARS table.
Code: 41XX, Feature: Dial (if the IPO has any restricted calls to outside use Dial Emergency)
Telephone Number: +1235556500”ext=4150@192.168.1.100”
Telephone Number: 41N”@192.168.1.100” (the “”s are required to tell IPO that nothing contained in this part of the string is a variable. All extensions in this range can use this variable.

Next you will need to configure Lync to see the Asterisk as a gateway.

1. Configure Lync Call routing to use the Asterisk as a Gateway. This assumes you have enabled users for enterprise voice which is a fairly well documented process: http://technet.microsoft.com/en-us/library/gg413011.aspx
After users are enabled, go to the Topology builder and browse the Standard Server. Check the box for Enterprise Voice

Edit the properties and go to the Mediation Server. Enable Collocated Mediation Server. Define your Listening Ports and click new gateway enter the IP address of the Asterisk and the Port that it is listening for SIP traffic on.

Next associate the Gateway with the mediation server

Publish the Topology.

2. Configure Dial Plan and Trunk. Open Lync Control Panel and go to Voice Routing then Trunk configuration open the newly added Gateway and change the Encryption support level to Optional, Uncheck Media Bypass, Uncheck Centralized Media Processing and Uncheck Enable Refer Support.

3. Add a translation rule to call 4 digit extensions on the IPO via the Asterisk. This allows a normalized call from the Lync server to pass just 4 digits to the IPO so it correctly routes to the extension on the IPO.
Starting Digits: +12355565
Length: Exactly 12
Digits to remove: 8
This rule tells the Lync server to simply pass 65xx to the IPO.

You will also need to create a translation rule to pass all digits without the +
Starting Digits: +
Length: Exactly 12
Digits to remove: 0
This rule tells the Lync server to pass 11 digits to the Asterisk.

4. Create a Call Route. Select New Route and name it and add a description. Leave the Pattern to match the default “*” which matches all calls.

5. Scrolling down select Add for Associated Gateways and select the PSTN Gateway. Do not yet associate a PSTN Usage. But confirm the Gateway is added.

6. Create a Site Voice Policy Choose new and select the site you want to add a voice policy for. Add a Description and enable all appropriate features. Then New.

Associate the route just created in step 6 by hitting select

choose the route.

Go back to Routes and edit the Asterisk PSTN route and scroll to the bottom and Associate the PSTN Usage created.

Commit all Changes.

Configure the Asterisk Box

Finally you need to configure the Asterisk.

1.   First Configure the SIP Trunks
   Login as root to the asterisk server and enter: nano –w /etc/asterisk/sip.conf
   Your configuration should be as follows:
   [General]
   bindport=5060
   bindaddr=0.0.0.0
   tcpbindaddr=0.0.0.0
   tcpenable=yes

   [Lync_Trunk_Name]
   type=peer
   port=5068
   host=0.0.0.0 (where 0.0.0.0 is the ip address of your lync front end server)
   dtmfmode=rfc2833
   context=name-of-lync-context (use what ever name you want)
   qualify=yes
   transport=tcp

   [Avaya_Trunk_Name]
   type=peer
   host=0.0.0.0 (where 0.0.0.0 is the ip address of your ayava IPO)
   dtmfmode=rfc2833
   context=name-of-avaya-context (use what ever name you want)
   port=5060
   Transport=tcp
   Hit Ctrl-X and choose to save

   
   

2.   Next Define your Dial plan to forward all calls.
   enter nano –w /etc/asterisk/extensions.conf
   Your configuration should be as follows:
   [Name-of-lync-context]
   exten => _+1xxxxxxxxxx,1,Dial,(SIP/Avaya_Trunk_Name/${EXTEN},45)
   exten => _+12xx,1,Dial,(SIP/Avaya_Trunk_Name/${EXTEN},45)
   exten => _1xxxxxxxxxx,n,Hangup()

   NOTE:
   Line 1 passes PSTN calls from lync to the PSTN
   Line 2 passes 4 diget extensions dialed from the Lync to IPO

   
   [Lync_Trunk_Name]
   exten => _+1xxxxxxxxxx,1,Dial,(SIP/Lync_Trunk_Name/${EXTEN},30)
   exten => _+41xx,1,Dial,(SIP/Avaya_Trunk_Name/${EXTEN},30)
   exten => _1xxxxxxxxxx,n,Hangup()

   NOTE:
   Line 1 passes PSTN calls and all Lync Extensions WITH DID to Lync
   Line 2 passes 4 digit extensions dialed from the IPO that don’t have a DID.
   
   Exit and Save the configuration

   

   One item to note, the value of 45 is the seconds the phone rings before disconnecting the call.  We had to change the default of 30 to 45 because when someone would call a cell phone FROM Lync via the IPO PRI the call sometimes wasn’t getting to the cell phone voicemail before the 30 seconds and would drop the call before the Lync caller could leave a voicemail for the person they were calling.  After adjusting this value above 30 these dropped calls stopped happening.

3. Reload the Configurations
   Enter: asterisk –r
   Enter: reload

   After the config reloads enter: /sip Show peers
   your status for both SIP trunks should show “OK”

   You are new ready to make calls from lync to the PSTN and place calls on hold.

This post is a continuation of a series of posts about Lync Deployment.   This can be used as a resource to configure an Avaya IPOffice (IPO) 412 (software version 5.0) as a Gateway for a Lync deployment calling the PSTN, but your mileage may vary.  Calls are routed over a SIP Trunk (Session Initiation Protocol) configured between the IPO and the Lync Front End server.

An ISDN/PRI trunk provides inbound and outbound voice call access to the PSTN. Avaya IP
Office sends and receives SIP Invites to and from Lync Standard Server, Lync converts call signaling between standard SIP and Microsoft signaling protocol (MTLS).

The flow for an outbound call from an Enterprise Voice Lync User routes as the following: When an user dials a number,Lync normalizes the dialed number. If there is a match,
Lync checks that the number called is assigned to another Lync user. If so, Lync sends the call to the called user’s Lyc client. If not, Lync looks up a call routing table for a match of the
E.164-formatted called number. If there is a match, Lync routes the call to the Gateway for that route, which in this configuration is the IPO and then the IPO routes the call to the PSTN.

For inbound calls from the PSTN, Avaya IP Office receives the incoming call. Based on the
called party number,IPO looks up the corresponding Short Code (if the called number is a Lync Extension) and routes the call to the Lync server via SIP.

For this configuration an inbound call hits an IPO Inbound call route, matches the last 4 digits to a 4 digit short code which routes to an ARS table which matches the short code digits translates to E.164 format and routes the call over a SIP trunk to the Lync frontend server.

Configuration was modified from an OCSR2 & IPO document found here:
https://devconnect.avaya.com/public/download/interop/OCSR2-IPO-PSTN.pdf

Updated 2/5/2012

When configuring Lync and IPO directly as noted in the white paper above, hold may not function and disconnect the call.  Additionally calls originating from the the PRI on the IPO or an IPO homed extension when transferred to a lync extension cannot be placed on hold or transferred to any other extension (lync or avaya).  The work around used to resolve this issue is SIP proxy as noted here: http://jasonmlee.net/archives/447

Configuring Avaya IPOffice

1. Verify Avaya SIP Trunk license. Login to the IPO Manager application.   In the tree view navigate to Licensing and confirm that you have an active SIP Trunk Channel License.  If a valid license is not configured in the IPO calls will not route over the SIP Trunk.  You can purchase IPO 412 license keys from http://dpctelcom.com/

   

2. Create the SIP line for Lync Server. Select Line in the left panel. Right click
   and select New SIP Line. Enter the SIP Domain Name of local Domain in the ITSP
   Domain Name field. Enter the Lync Server IP Address in the ITSP IP
   Address field. Select Remote Party ID in the Send Caller ID field.
   Network Configuration is as follows:
   Layer 4 Protocol is TCP,
   Send Port is the Receive port on your Lync Server in Topology Builder Default is 5060
   Listen Port is the Send port in your Lync server Topology Builder Default is 5060
   Network Topology Info set to NONE

   

3. Configure SIP URI for known caller ID. Go to the URI Tab and and click add.  Create a primary SIP URI. Enter a unique number for the Incoming Group (Line Group 100) and Outgoing Group (Line Group 100) fields. Enter * for the Local URI, Contact and Display Name fields. Use defaults for all other field. Press the OK button.

   

4. Configure SIP URI for Unknown Caller ID. The documentation indicates a need for a SIP URI for calls received from the PSTN with withheld caller ID. However this appears not to be 100% necessary nor applicable, but was configured in our installation. Select the SIP URI tab and click on Add again. Enter another a unique number for the Incoming Group (Line Group 101) and Outgoing Group (Line Group 101) fields. Enter 000000000 for the Local URI, Contact and Display Name fields. Calls received with hidden caller ID from the PSTN will be shown as coming from this number on the Lync client. Use defaults for all other field. Press the OK button.

   

5. Create an Incoming call route for outbound calls from Lync incoming to the IPO over the SIP trunk. (This call can be both IPO extensions or out to the PSTN)  Select Incoming Call Routes in the Left Tree and right click and choose NEW.  Set the Incoming Group ID to the value you set in step 3 as your Incoming Group ID for the SIP URI (Line Group 100).

   

   In the Destinations Tab enter . in the Destination Field and select OK

   

6. Configure a Alternate Route Selection table (ARS) for calls going from PSTN or IPO Extensions to Lync.  The ARS is used to route the call to the SIP Trunk formatted in E.164 format for Lync to receive the calls correctly . Select ARS in the left panel. Right-click and select New. Enter a unique identifier for the route in the Route Name field (e.g. SIP-Lync) and use defaults for all other field on the ARS tab.

   

   Click on Add button and add short code.  Enter a code matching the 4 digits of the Lync Extension you are wanting to call. 
   Deployment of Lync Extensions with DIDs: In a deployment with DIDs of (123)555-65xx with 4 digit extensions in the 6500-6599 range and a Lync server ip address of 192.168.1.100 and the unique Line Group ID of the SIP trunk is 100 the following short code could be used. (note use of the xx and N variables to allow for creating just one short code for 100 DIDs or Extensions)
   For Deployments without DIDs see step 11 below.

   

7. Create a short code to route 4 digit extension calls from IPO to to Lync. 
   This short code allows for 4 digit dialing from the IPO to Lync extensions as well as will allow for inbound call routes to be configured for DIDs that are homed on Lync.
   Select Short Code in the left panel. Right-click and select New. Enter the first 2 digits of the extension range you are wanting to route to Lync followed by xx (example 65xx).  Select Dial for the Feature. Select the SIP-Lync ARS created previously from the Line Group Id drop down list. Enter “65N” for the Telephone Number field. Use default values for all other
   fields. Press the OK button.

   

8. Create a short code to route Lync calls to the PSTN.  This short code will be matched for any number if a Lync user calls the PSTN and the IPO has no extension match, the call will be routed to the PSTN, without the rule, the IPO doesn’t know what to do with digits dialed that aren’t extensions on the IPO.
   Select Short Code in the left panel. Right-click and select New. Enter “?” in the Code field. Select Dial for the Feature. Select the ISDN/PRI line Outgoing Group Id from the Line Group Id drop down list. Enter “.” for the Telephone Number field. Use default values for all other fields. Press the OK button.

   

9. Create a Short Code for each Lync 4 Digit Extension.  For the IPO to be able to route calls or allow Avaya Extensions to dial 4 digits to call a Lync user, each Lync Extension needs to have a IPO Short Code.  In Hybrid environment, you have to let IPO know that this 4 digit extension is not homed on the IPO but rather on Lync for each user.  Variables can’t be used in a hybrid environment because some extensions live on IPO and some on Lync.
   This example is for a Lync user extension 6500
   Select Short Code in the left panel. Right-click and select New. Enter “6500” in the Code field. Select Dial for the Feature. Enter “6500” for the telephone number and Select the SIP-Lync from the Line Group Id drop down list.  Use default values for all other fields. Press the OK button.

   

10.   Create incoming call route for Lync DIDs
    For an example DID (123) 555-6500 extension 6500
    Select Incoming Call Route in the left panel. Right-click and select New.  Select the PSTN’s incoming Group ID in the Line Group ID drop down box.  Enter “6500” in the Incoming Number to match the ICR last for digits.

    

    On the Destinations Tab enter “6500” to point to the short code created in step 7 above and the call will route via the ARS table to the SIP trunk to Lync formatted as +11235556500@192.168.1.100

    

11.   Configure routing for For Lync Extensions without DIDs (as documented here). An ARS entry will have to be created for each Extension since the IPO cannot use variables in the E.164 formatting of the outbound call and Lync requires the call to come in in the +11235556500;ext=4175 format.
    This example extensions 4150-4175 don’t have DIDs but were valid Lync extensions, in order for IPO extensions to call extensions 4150-4175 a short code would be required for 41xx Pointing to the the SIP-Lync ARS Table. (Assuming no other extensions in the 4100 range are homed on the IPO).

    

    Then entries for each extension would need to be added to the ARS table.
    Code: 4150, Feature: Dial
    Telephone Number: +1235556500”ext=4150@192.168.1.100” (the “”s are required to tell IPO that nothing contained in this part of the string is a variable.  Each subsequent extension would need a ARS entry.

    

12.   Configure Lync Call routing to use the IPO as a Gateway.  This assumes you have enabled users for enterprise voice which is a fairly well documented process: http://technet.microsoft.com/en-us/library/gg413011.aspx
    After users are enabled, go to the Topology builder and browse the Standard Server.   Check the box for Enterprise Voice

    

    Edit the properties and go to the Mediation Server.  Enable Collocated Mediation Server. Define your Listening Ports and click new gateway enter the IP address of the IPO and the Port that it is listening for SIP traffic on.  

    

    

    Publish the Topology.

13.   Configure Dial Plan and Trunk.  Open Lync Control Panel and go to Voice Routing then Trunk configuration open the newly added Gateway and change the Encryption support level to Optional, Uncheck Media Bypass, Uncheck Centralized Media Processing and Uncheck Enable Refer Support.

    
    

14.   Add a translation rule to call 4 digit extensions on the IPO.  This allows a normalized call from the Lync server to pass just 4 digits to the IPO so it correctly routes to the extension on the IPO.
    Starting Digits: +12355565
    Length:  Exactly 12
    Digits to remove: 8
    This rule tells the Lync server to simply pass 65xx to the IPO.

    

15.   Create a Call Route. Select New Route and name it and add a description.  Leave the Pattern to match the default “*” which matches all calls.

    

    Scrolling down select Add for Associated Gateways and select the PSTN Gateway.  Do not yet associate a PSTN Usage.  But confirm the Gateway is added.

    

16.   Create a Site Voice Policy  Choose new and select the site you want to add a voice policy for.  Add a Description and enable all appropriate features.  Then New.

    

    Associate the route just created in step 15 by hitting select

    

    choose the route.

    

    Go back to Routes and edit the AVAYA PSTN route and scroll to the bottom and Associate the PSTN Usage created.

    

    Commit all Changes.

After these steps you should be able to make calls via the IPO as a Lync Gateway.

This post isn’t in the planned sequence of documenting the Lync Deployment in this series, but I found the topic fairly frustrating and undocumented today so I decided to go ahead and post this now.  Our primary location has DIDs for each extension, but or second campus only has a few POTs (Plain Old Telephone) lines for service so there are not DIDs for each extension.

Lync Extensions without the use of DIDs (Direct Inward Dial)
When deploying Lync Enterprise Voice each user is configured with a SIP Address as well as a telephone Line URI.  In deployments where every extension has a DID the Tel URI can simply be the external DID number associated with that user.

When you make a 4 digit extension call internally, Lync uses your defined Dialing Rules and normalizes the number to the E.164 format.  When dialing extension 5555 Lync would normalize (because you configured this normalization rule already) it to: +112355555555 for a US telephone number of (123) 555-5555 and will route the calls internally to the appropriate user.  Since the call matches a Lync user the call isn’t routed to the PSTN (Public Switched Telephone Network).

When a user doesn’t have a DID, you can also enter a user’s Tel URI with the extension added  in the following format: +112355555555;ext=1234 where the main telephone number is (123)555-5555 and the extension is 1234.

Even though you have created the user with the main number and extension you won’t be able to make 4 digit calls without adding additional dialing rules so the call can be completed.

To make calls to 4 digit extensions that do not have DIDs go to Lync Server Control Pannel > Voice Routing and select the appropriate Dial Plan. Once you are viewing the appropriate dial plan choose new “Associated Normalization Rule”.  Give the new Rule a Name and Description. Then skip all the boxes for Starting Digits, Length, Digits to Remove and Digits to add and go to Pattern To match and select Edit.

This example will allow dialing for 4 digit extensions starting with 12## associated with the main number (123) 555-5555
(extensions 1200-1299)
The Value for “Match this Pattern” is: ^(12\d{2})$
The Translation Rule is: +11235555555;ext=$1

After you save and Commit the Rules and they replicate to your Lync Clients you will now be able to dial 4 digit extensions that don’t have a DID.

For all the info on the update go here. To update the clients kick off Microsoft Office Auto Update and it will download the new link client.

The one one remaining feature missing… white boarding and PowerPoint sharing…. but I can live without that for now.

This article should be read by IT Pros as a look inward to make those natural hang-ups less of an issue and for those who manage IT Pros to understand a little more of why IT pros do what they do.

From "The Unspoken Truth About Managing Geeks”  found on ComputerWorld.com written by Jeff Ello.

——————————————-

Understanding why IT pros appear to act the way they do makes working with, among and as one of them the easiest job in the world.

It’s all about respect
Few people notice this, but for IT groups respect is the currency of the realm. IT pros do not squander this currency. Those whom they do not believe are worthy of their respect might instead be treated to professional courtesy, a friendly demeanor or the acceptance of authority. Gaining respect is not a matter of being the boss and has nothing to do with being likeable or sociable; whether you talk, eat or smell right; or any measure that isn’t directly related to the work. The amount of respect an IT pro pays someone is a measure of how tolerable that person is when it comes to getting things done, including the elegance and practicality of his solutions and suggestions. IT pros always and without fail, quietly self-organize around those who make the work easier, while shunning those who make the work harder, independent of the organizational chart.

This self-ordering behavior occurs naturally in the IT world because it is populated by people skilled in creative analysis and ordered reasoning. Doctors are a close parallel. The stakes may be higher in medicine, but the work in both fields requires a technical expertise that can’t be faked and a proficiency that can only be measured by qualified peers. I think every good IT pro on the planet idolizes Dr. House (minus the addictions).

While everyone would like to work for a nice person who is always right, IT pros will prefer a jerk who is always right over a nice person who is always wrong. Wrong creates unnecessary work, impossible situations and major failures. Wrong is evil, and it must be defeated. Capacity for technical reasoning trumps all other professional factors, period.

Foundational (bottom-up) respect is not only the largest single determining factor in the success of an IT team, but the most ignored. I believe you can predict success or failure of an IT group simply by assessing the amount of mutual respect within it.

The elements of the stereotypes
Ego — Similar to what good doctors do, IT pros figure out that the proper projection of ego engenders trust and reduces apprehension. Because IT pros’ education does not emphasize how to deal with people, there are always rough edges. Ego, as it plays out in IT, is an essential confidence combined with a not-so-subtle cynicism. It’s not about being right for the sake of being right but being right for the sake of saving a lot of time, effort, money and credibility. IT is a team sport, so being right or wrong impacts other members of the group in non-trivial ways. Unlike in many industries, in IT, colleagues can significantly influence the careers of the entire team. Correctness yields respect, respect builds good teams, and good teams build trust and maintain credibility through a healthy projection of ego. Strong IT groups view correctness as a virtue, and certitude as a delivery method. Meek IT groups, beaten down by inconsistent policies and a lack of structural support, are simply ineffective at driving change and creating efficiencies, getting mowed over by the clients, the management or both at every turn.

The victim mentality — IT pros are sensitive to logic — that’s what you pay them for. When things don’t add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event. The more things that occur that make no sense, the more cynical IT pros will become. Standard organizational politics often run afoul of this, so IT pros can come to be seen as whiny or as having a victim mentality. Presuming this is a trait that must be disciplined out of them is a huge management mistake. IT pros complain primarily about logic, and primarily to people they respect. If you are dismissive of complaints, fail to recognize an illogical event or behave in deceptive ways, IT pros will likely stop complaining to you. You might mistake this as a behavioral improvement, when it’s actually a show of disrespect. It means you are no longer worth talking to, which leads to insubordination.

Insubordination — This is a tricky one. Good IT pros are not anti-bureaucracy, as many observers think. They are anti-stupidity. The difference is both subjective and subtle. Good IT pros, whether they are expected to or not, have to operate and make decisions with little supervision. So when the rules are loose and logical and supervision is results-oriented, supportive and helpful to the process, IT pros are loyal, open, engaged and downright sociable. Arbitrary or micro-management, illogical decisions, inconsistent policies, the creation of unnecessary work and exclusionary practices will elicit a quiet, subversive, almost vicious attitude from otherwise excellent IT staff. Interestingly, IT groups don’t fall apart in this mode. From the outside, nothing looks to be wrong and the work still gets done. But internally, the IT group, or portions of it, may cut themselves off almost entirely from the intended management structure. They may work on big projects or steer the group entirely from the shadows while diverting the attention of supervisors to lesser topics. They believe they are protecting the organization, as well as their own credibility — and they are often correct.

Credit whoring — IT pros would prefer to make a good decision than to get credit for it. What will make them seek credit is the danger that a member of the group or management who is dangerous to the process might receive the credit for the work instead. That is insulting. If you’ve got a lot of credit whores in your IT group, there are bigger problems causing it.

Antisocial behavior — It’s fair to say that there is a large contingent of IT pros who are socially unskilled. However, this doesn’t mean those IT pros are antisocial. On the whole, they have plenty to say. If you want to get your IT pros more involved, you should deal with the problems laid out above and then train your other staff how to deal with IT. Users need to be reminded a few things, including:

• IT wants to help me.
• I should keep an open mind.
• IT is not my personal tech adviser, nor is my work computer my personal computer.
• IT people have lives and other interests.

Like anyone else, IT people tend to socialize with people who respect them. They’ll stop going to the company picnic if it becomes an occasion for everyone to list all the computer problems they never bothered to mention before.

How we elicit the stereotypes
What executives often fail to recognize is that every decision made that impacts IT is a technical decision. Not just some of the decisions, and not just the details of the decision, but every decision, bar none.

With IT, you cannot separate the technical aspects from the business aspects. They are one and the same, each constrained by the other and both constrained by creativity. Creativity is the most valuable asset of an IT group, and failing to promote it can cost an organization literally millions of dollars.

Most IT pros support an organization that is not involved with IT. The primary task of any IT group is to teach people how to work. That may sound authoritarian, but it’s not. IT’s job at the most fundamental level is to build, maintain and improve frameworks within which to accomplish tasks. You may not view a Web server as a framework to accomplish tasks, but it does automate the processes of advertising, sales, informing and entertaining, all of which would otherwise be done in other ways. IT groups literally teach and reteach the world how to work. That’s the job.

When you understand the mission of IT, it isn’t hard to see why co-workers and supervisors are judged severely according to their abilities to contribute to that process. If someone has to constantly be taught Computers 101 every time a new problem presents itself, he can’t contribute in the most fundamental way. It is one thing to deal with that from a co-worker, but quite another if the people who represent IT to the organization at large aren’t cognizant of how the technology works, can’t communicate it in the manner the IT group needs it communicated, can’t maintain consistency, take credit for the work of the group members, etc. This creates a huge morale problem for the group. Executives expect expert advice from the top IT person, but they have no way of knowing when they aren’t getting it. Therein lies the problem.

IT pros know when this is happening, and they find that it is impossible to draw attention to it. Once their work is impeded by the problem, they will adopt strategies and behaviors that help circumvent the issue. That is not a sustainable state, but how long it takes to deteriorate can be days, months or even years.

How to Fix It
So, if you want to have a really happy, healthy and valuable IT group, I recommend one thing: Take an interest. IT pros work their butts off for people they respect, so you need to give them every reason to afford you some.

You can start with the hiring process. When hiring an IT pro, imagine you’re recruiting a doctor. And if you’re hiring a CIO, think of employing a chief of medicine. The chief of medicine should have many qualifications, but first and foremost, he should be a practicing doctor. Who decides if a doctor is a doctor? Other doctors! So, if your IT group isn’t at the table for the hiring process of their bosses and peers, this already does a disservice to the process.

Favor technical competence and leadership skills. Standard managerial processes are nearly useless in an IT group. As I mentioned, if you’ve managed to hire well in the lower ranks of your IT group, the staff already know how to manage things. Unlike in many industries, the fight in most IT groups is in how to get things done, not how to avoid work. IT pros will self-organize, disrupt and subvert in the name of accomplishing work. An over-structured, micro-managing, technically deficient runt, no matter how polished, who’s thrown into the mix for the sake of management will get a response from the professional IT group that’s similar to anyone’s response to a five-year-old tugging his pants leg.

What IT pros want in a manager is a technical sounding board and a source of general direction. Leadership and technical competence are qualities to look for in every member of the team. If you need someone to keep track of where projects are, file paperwork, produce reports and do customer relations, hire some assistants for a lot less money.

When it comes to performance checks, yearly reviews are worthless without a 360-degree assessment. Those things take more time than a simple top-down review, but it is time well spent. If you’ve been paying attention to what I’ve been telling you about how IT groups behave and organize, then you will see your IT group in a whole different light when you read the group’s 360s.

And make sure all your managers are practicing and learning. It is very easy to slip behind the curve in those positions, but just as with doctors, the only way to be relevant is to practice and maintain an expertise. In IT, six months to a year is all that stands between respect and irrelevance.

Finally, executives should have multiple in-points to the IT team. If the IT team is singing out of tune, it is worth investigating the reasons. But you’ll never even know if that’s the case if the only information you receive is from the CIO. Periodically, bring a few key IT brains to the boardroom to observe the problems of the organization at large, even about things outside of the IT world, if only to make use of their exquisitely refined BS detectors. A good IT pro is trained in how to accomplish work; their skills are not necessarily limited to computing. In fact, the best business decision-makers I know are IT people who aren’t even managers.

As I said at the very beginning, it’s all about respect. If you can identify and cultivate those individuals and processes that earn genuine respect from IT pros, you’ll have a great IT team. Taking an honest interest in helping your IT group help you is probably the smartest business move an organization can make. It also makes for happy, completely non-geek-like geeks.

Jeff Ello is a hybrid veteran of the IT and CG industries, currently managing IT for the Krannert School of Management at Purdue University. He can be contacted at jello@techoped.com.

Project Scope
Preparing for Deployment – Research and Education and Pricing
Deployment of Standard Server & Director Role
Deployment of Edge and Reverse Proxy
Deployment of Lync Voice Capabilities
Configuring Lync PSTN Calling thru Avaya IPOffice
Configure Lync 4 Digit Extension Dialing without DIDs
Configure Asterisk as a SIP Proxy for Avaya IPO and and Lync
Deployment of Lync Client to users
Training

Preparing for Deployment – Research and Education and Pricing
We started reviewing products that would fulfill the requirements of our project in late summer of 2010.  At that time most of the products we were reviewing were primarily video conferencing/voice providers.  The list included but wasn’t limited to: Skype, WebEx, Adobe Connect, ooVoo, TokBox, Windows Live Messenger, Microsoft Office Communications Server and some various locally hosted IM solutions.   While many would fit many of our requirements few would allow for centrally managed and deployed solutions.  Others wouldn’t fit the budget.

Many times we reviewed OCS but felt that it lacked many of the “WebEx” type web conferencing tools and was quite costly for IM and Presence.  Not to mention deployment appeared to be a fairly large undertaking.

Most “free” or low cost solutions had no integration points with our existing voice system and/or deployment and management were extremely difficult to manage on a scale past just a couple computers.  Example: Skype and ooVoo could both do video/voice but deployment was nearly impossible to the whole organization even though the price was right (Free or almost free)

In the Early fall of 2010 MS Lync was on the horizon and better integrated many of the ‘lacking’ features of its predecessor OCS.  Very quickly Lync was much more than IM and started to fit many of our criteria.

After attending WinConnections conferencing in Las Vegas in November 2010 we had enough information to make a decision…. Lync was the right tool for our organization.

Documentation/Tools/Resources for Learning about and Deploying Lync

Because Lync is a fairly young product I have documented the tools/resources that we have used as educational guides and deployment guides for Lync.  Because we started testing for our deployment in the fall of 2010 MS Lync was still in RC (Release Candidate) form.  Most of the documents can be applied to the RTM version and since then MS has released other resources… but here is a good list to start you off:

• WinConnections Conference – While I was somewhat skeptical of this conference, primarily because we didn’t know a soul who had attended it before. A large portion of the conference was dedicated to Exchange, Windows 7 and Lync… all projects in 2010 we were working on.  WinConections is managed by the same group that produce publications like WindowsITPro magazine and has proved to be a VERY valuable training especially for the Lync Deployment project. (Even if it was in Las Vegas on Halloween… all I can say is wow, crazy!) This Conference is available 2x’s per year in the spring and fall and while not ‘cheap’ provided a great deal of learning on various Microsoft Server technologies that has moved many of our projects forward.
• Microsoft Lync Server 2010 (Release Candidate) Lab Deployment Guide – a great step by step tutorial for deploying MS Lync in a smaller environment. This guide I used as a step by step guide for our test deployment and then edited the document with our network information and used as a deployment guide for our production server.
• Microsoft Lync Server 2010 Deployment Guide – both Online and word .doc downloads of various topics.  Most helpful for us were:
  • Planning for Microsoft Lync Server 2010
    • Planning Primer: Planning for Your Organization
    • Determining Your Infrastructure Requirements
    • Planning for IM and Presence
    • Planning for External User Access
    • Planning for Enterprise Voice
    • Planning for Virtualization, Management, and Other Features
    • Planning for Clients and Devices in Lync Server 2010
  • Deployment
  • Operations
• http://www.technotesblog.com/ – Dustin is a MS MVP and is an awesome volunteer (most recently serving at Granger Community Church) and has been a HUGE resource to us.  If you are deploying Lync Dustin is a must follow person on twitter: @dhannifin
• http://www.darylhunter.me/ – Daryl (a former CITRT Peer) works for a vendor Mirazon (a vendor that provides technical services to the various markets including the Church Market) and has documented his deployment of Lync 2010… while Daryl’s site wasn’t a resource to us in 2010 because it wasn’t yet updated to include the Lync Deployment, both Daryl and his blog are a great resource for Lync Deployment. Twitter: @darylhunter
• http://imaucblog.com/ – managed by Adam Jacobs a Unified Com Blogger & MVP for MS Lync
• http://www.evangelyze.net/ – a 3rd party developer making web site “customer service” chat type services that integrate into Lync as the backend. (SmartChat) The support staff can use just one client for both corporate IM as well as the public facing “help” service chat.  They are also preparing to deploy a product (SmartClass) that facilitates Lync Video E-learning that archives the ‘classes’ back into SharePoint as an archive (dynamically)
• Lync Licensing – Lync licensing explained… Note that the Standard and Enterprise CALs stack.. its not an either or selection for the CALs.   Our best pricing was thru PCMall ping me for contact info.
• Lync Public Instant Messaging Connectivity – What is PIC explained … The ability to IM from Lync to AOL, Windows Live (2011 Version of MSN allows for HD Video Conferencing with Lync users), Google Talk and Yahoo (Yahoo is NOT Free)
• http://communicationsserverteam.com/ although a retired blog, good info on OCS
• http://communicatorteam.com/ Microsoft Lync Team Blog
• http://blogs.technet.com/b/nexthop/ Microsoft Lync Server team’s customer response channel
• http://www.leedesmond.com/weblog/?p=450 – while this is a OCS 2007 R2 deployment guide, it helped us get up to speed with terms and technologies that are in Lync 2010.  It also helped to see what was different in OCS and Lync since at the time of deployment documentation exclusively to Lync were limited.
• http://blog.schertz.name/ a wealth of Lync information by Jeff Schertz MS Lync MVP
• Certificates
  • http://www.digicert.com/ocs-server-ssl-certificates.htm – didn’t go this route too much $$
  • http://www.godaddy.com/ssl/ – we went with the Multiple Domains UCC cert

Previous: Project Scope
Next: Deployment of Standard Server & Director Role

Project Scope
Preparing for Deployment – Research and Education and Pricing
Deployment of Standard Server & Director Role
Deployment of Edge and Reverse Proxy
Deployment of Lync Voice Capabilities
Configuring Lync PSTN Calling thru Avaya IPOffice
Configure Lync 4 Digit Extension Dialing without DIDs
Configure Asterisk as a SIP Proxy for Avaya IPO and and Lync
Deployment of Lync Client to users
Testing Configuration of Backup Registrar
Training

Project Planning:

A significant project in the past several months has been researching and preparing to deploy a organization wide instant messaging/presence and video conferencing solution.  The need for such a solution has increased primarily because of our launch of a campus in Galesburg.  While we are still only in the preparation stages of this campus opening, already we have seen the need for better connectivity between staff in two physical locations helping us define the list of requirements for this project.

Requirements:

• Provide a toolset that allows intercampus communications via Instant Messaging, Video and Voice.
• A product that is standardized and has enterprise level support.
• A product that can be centrally managed and deployed across the organization
• A product that fits in budget.
• A product that can interact with various platforms  both OS and Communications Platform (primarily IM)
• A product that can cohabitate with or eventually replace our Avaya IPOffice PBX
• A product that can work with Analog POTS Lines, PRI Services and SIP Trunks
• A tool that allows for staff connectivity (Voice/Video & IM) anywhere there is a internet connection.

Next: Preparing for Deployment – Research and Education and Pricing

Part 1: Why Biometric?
Part 2: Why Vein Scanning?
Part 3: Installing M2sys Vein Scan Server & Configuring the Database
Part 4: Installing M2Sys BioPlugin Vein Scanning Client
Part 5: Configuring the M2sys Vein Scanning Client and ACS CheckPoint

In the previous installation steps: evaluating the type of scanning and installing the server and client were documented.  Now final step of configuring the scanning client to connect to the database and work with ACS CheckPoint remains.

After you have confirmed that the server is operating correctly and you have connected the scanner and installed the driver you are ready to configure the client.

Workstation Configuration MUST be done by a user who has local admin rights, a user with less rights can make the changes but once the settings window is closed all changes are lost.

Since these workstations are public machines it is wise to make them as hardened as possible to prevent non-designed use of the workstation.

Configuring Client and Server Communications

The first step is accessing the settings portion of the application. 
This is done by clicking on the icon that looks like a finger print in the System Tray (near the clock). 

The Finger Scan application will display and you have two options: Fingerprint Admin or Settings. 
Selecting Settings allows us to configure the client.  FingerPrint Admin will be used later to capture scans.

Next you are prompted for the Admin Password which by default is ‘Admin’

If you are running the server application on a separate machine from the workstation you need to change the Server Address from localhost to the IP address or the DNS name of the server. 
Note: DO NOT use the Fully Qualified Domain name, only enter the Server Name or the application will not connect.

While entering the server name choose how many scans the software will prompt you to capture.

Capturing two scans during registration allows the user to scan a finger on either hand.
Two fingers scanned is helpful for two reasons:

• People forget which hand they registered, by capturing both hands this isn’t an issue
• When you capture two fingers the user can try the second finger if the scan fails to lookup the individual.

Next Select the Notifications Tab

Below are the Default Values

Changing the value for how long to display the scan notification to a lower value than 5 has helped so when a person’s finger fails to scan for various reasons the right side of the screen doesn’t fill up with failed scan alerts during the check-in process.

Next choose the Security Tab

The default is to require a password for both Settings, Exiting the application and FingerPrint Admin

We elected to turn off requiring the password for FingerPrint (Vein Scan) admin for several reasons:

• You can only set one password, and we didn’t want to give the password to change settings to volunteers.
• It becomes very cumbersome for the volunteers to have to enter a password for registration admin.
• Volunteers who have access to the workstations that can capture scans don’t really need restricted from accessing the scan admin.

Testing Client and Server Communications

At this time the client application has been configured and can be tested to confirm the client and server are communicating.

Open the BioPlugin application from the SysTray

Select FingerPrint Administration

Enter the Member ID for a test. 
Later once CheckPoint is configured the Member ID is the individual barcode assigned to each person in the database.

Enter the Value of the Member ID.

Select the finger that you are scanning (the index fingers will be captured in the example below)
After selecting the finger “Click Here to Capture Finger Vein” and the application will go into capture mode.

Once the scanner is in Capture mode, the following screen will display until the scanner has captured a vein scan.  The individual being scanned should lay the finger completely across the scanner and rest the finger on both the front and back ‘finger rests’ in the scanner.  After the scan is captured you will be returned to the previous window.

After the scan has been captured close the FingerPrint Administration window.
Launch Notepad and scan one of the fingers captured for the test.  If the system is working correctly notepad should display the value you used when register the test user on the first line and the cursor will move to the next line in the document.

Configure BioPlugin and CheckPoint

After completing the test scan, re-launch the settings window and select Destination Window Tab.

Right Click on “My Test Keystroke Destination” and choose Rename.

Enter Destination Name ‘CheckPoint”
This is not telling BioPlugin where to send the scan, simply naming the destination you are going to define.

Next Change the Window Title from ‘Notepad’ to ‘Checkpoint’
Note: Window Title value is case sensitive

Next choose the Startup Tab

It is helpful to the end user if you define select several settings on this tab:

• Load BioPlugin Snap-On when windows starts (for all users)
• On Kiosks (self-service) choose Start Minimized
• On Assisted Check-in/out locations it might be a helpful choice to not start minimized since these locations will be used to capture scans and it is helpful to have the application maximized for ease of use.
• Select Launch another application after BioPlugin Loads and enter “c:\winacs\awcpkio.exe’

The BioPlugin client is now configured to work with Checkpoint. 

The final step to configure Check-in via vein scanning you must enable the setting ‘By scanning barcode’
 

After the settings are complete restart the kiosk. After the reboot, you will be prompted to activate the software license.  You will need to login to the workstation as an Administrator to activate the software license.

• If you purchased the licensing from ACS directly, contact support and provide support the Installation ID and they will activate the install and provide you with the Activation ID.  Enter this value and reboot the kiosk.

Once the client machine is configured, Launch CheckPoint Express Check-In start a session.  Users can now scan their finger and  CheckPoint will return the individual/families record for Check-in.

Register CheckPoint users to Check-in With Biometrics

When registering users, Open both ACS Desktop (CheckPoint Tab>Check IN/Out) and BioPlugin FingerPrint Administration.

Lookup the individual that you are registering.
Right click on the name of the person in the Individual List and select Copy BarCode

Go to FingerPrint Admin and Paste the barcode into the BioPlugin Screen and proceed with the registration process that was used in the testing scenario above.  Once the individual is registered they can immediately visit any other kiosk running Express Check-in and scan their finger and Check-in.

Optional Settings
If you would like for the Registration Admin to default to a finger other than the middle finger you can edit the client.ini file.  Since our first roll out of vein scanning was with Jr. High ministry we elected to change the default finger to the index finger.

Finger Print Scanning returnes the best results when the middle finger is the print registered, and M2sys has indicated that remains the same for vein scanning

Access the Client.ini file by browsing to c:\program files\BioPlugin\

Right Click on client.ini and choose Open.
Edit the line Default_LeftFinger=3 and change it to Default_LeftFinger=2
Edit the line Default_RightFinger=3 and change it to Default_RightFinger=2
Note: Thumb is = 1 and pinky is =  5

Previous Part 4: Installing M2Sys BioPlugin Vein Scanning Client