:::: MENU ::::
Browsing posts in: Church IT

World Backup Day–20% off @Crashplan

Monday March 31st is World Backup Day… and in honor of this day, a brief Public Service Announcement.

Imagine if everything on your computer was gone… I’m talking… All your photos, music, documents and videos gone.  I don’t mean temporarily gone… I mean like forever… never again accessible gone..

In the world of IT, the reality is not if your computer will crash, but when.  At some time your computer’s hard drive / SSD, Power Supply, Motherboard, or other component will die and are you ready for that?

One way to prepare for the inevitable is to have a backup of your data.  This doesn’t prevent your computer from having issues but makes life a little more tolerable when it does. 

Nothing is worse than having someone call me and say they have a problem with a device asking for help and when asked “where is the backup saved” it’s that dreaded deer in the headlights look.

So in Honor of World Backup Day and out of respect for your family member or friend who fixes your stuff… Please Backup your computers.

Imagine this…it’s such a coincidence…  Crashplan.com is even offering a 20% off coupon thru March 31st.  That’s as low as $3.16 per month for one computer or $7.16 per month for up to TEN COMPUTERS!
(And no, thanks for asking I get nothing from Crashplan for referring you, I just want to see you backup your computers!)

What is Crashplan you ask?  It’s a service that does your computer backup for you… off site and secure.  If you use crashplan you don’t have to worry about that pit in your stomach feeling when your computer is dead and your favorite IT Guy or Gal asks where is your backup saved.

End of PSA, you may now continue about your normally scheduled programming.


Goodbye Old Friend Logmein…

So for many years I have found Logmein.com to be an extremely reliable solution for remote access… and it was free!  I’m not going to join the legions of haters… but simply am saying goodbye to a great free tool and make some notes on new tools I have found to fill the void..

Specific to the Logmein Change…Its kind of like a kid who has a ball and lets you play with it for a while and then they decide to go home.. its their choice to take their ball home and not let you use it anymore… Same way with Logmein.. they were offering a free product… its their choice to say its not free anymore… Granted the ‘hey jack, your done in 7 days’ (in the words of Uncle Si) didn’t give warm fuzzies… but its their choice.

So they’ve made their choice.. so I need to make some decisions… use the “new uber awesome” paid Logmein tools (which are way overkill for what I need for helping my family or my small consulting business) or find another solution.

So in a quick quest to beat the 168 hr timer from Logmein, I’m on a quest for a affordable (jason speak for free) remote tool to support family and customers.

Option 1 – TeamViewer
TeamViewer has been around for along time, but i never really give it much consideration since i had already setup machines with LMI, but a quick install of the client and then logging in with TeamViewer to uninstall LMI on my family computers proved it to be a solid alternate.  Some things to keep in mind, it is only free for non-commercial so that rules out consulting customers or for the real job at the non-profit.  To honor the TeamViewer team I have elected not to use this for my consulting customers… being honest, it was very tempting… but hey they are giving something for free lets not be disrespectful and ignore the rules.

One thing for a TeamViewer Noobie…and it may be completely obvious to the rest of the world… but I found its easy to give Grandma access to your computer… not just you access to Grandma’s computer.  In the install process there is a little box that says keep signed in… this is actually in addition to giving you remote access, it’s keeping your account logged in on the remote computer… one click of the machine name in the TeamViewer app and GRANDMA is controlling YOUR PC… not a desired result.  A quick “Log Off” in the app fixes that and you can access the remote PCs but they can’t access yours.

I was a little surprised to see that when the app is kept logged in, there is no password prompt before your connection to the remote computer is started… so the choice here use a easier password to remember than the auto generated lastpasss login password, or lock your PC.  I guess i was just expecting the LMI second authentication to happen.

Option 2 – Meraki
So while I’ve not completely consumed the cool-aid and not yet the FanBoy status that my buddy and pal Dustin Cassady is when it comes to Meraki… The Meraki Dashboard is something to be considered.  When I first looked at the product it did Meraki device management (Switches, APs, Firewalls) but not much else, then they added Free Mobile Device Management, which we have used to track some corporate devices and I have on my mobile devices… then they added desktop/laptop management.

Ok.. so who cares. In fact I have had the client management on my MBP and Windows machines for quite a while but really never paid any attention to it… but then I remembered when we setup Dustin’s Lync Environment he kept talking about Meraki Remote management.  Sure enough, right in the client info there was a Remote Desktop Button… Granted that button bombs, but clicking on the Remote Desktop In the navigation bar sure enough, i was remotely controlling my machines from Meraki.  The Remote agent appears to be offline until you select which device you want to connect and then it fires up a VNC session.  One nice feature you can setup networks and give access to other users depending on their needs…. Very Similar to LogMeIn Central.  One drawback, Meraki’s remote uses Java and VNC… ugh Java…but for now i can look over that.

One negative, since Meraki is using VNC and Java, the interface does seem a little laggy compared to LMI or TeamViewer.  But it’s a free option for a “commercial” use.

Option 3 – Crossloop
Not alot of time using this … you only get 1 or two machines free so i’ve only briefly tried it… but its another option to review.

Option 6 – Lync
Now I think you would be disappointed if i didn’t include Lync in the list… Lync does screen sharing.. and is free to non-profits thru Office365, however just setting up Lync for this is a little overkill.  Additionally, you can’t remotely access a machine with Lync, the user has to be present to share the screen.  And, possibly the most challenging part, for those sharing their windows computer screen, when a UAC prompt displays the remote user can’t enter credentials to proceed.

Option 5 – Logmein
Well… not really a ton of options here… Pay for 2 computers $99/yr ($50 for the first year) $250 for 5 computers and up.  Not likely.  So the other option several have suggested was to use Logmein  Central that was already being paid for by my day job… SomethingIi don’t’ feel comfortable combining Business, Personal and Consulting… so LMI and LMI Central really aren’t options.

 

I’m sure there are things i haven’t considered, or other options… this isn’t an exhaustive list… but leave a comment if there is a product that should be on the list or a comment that needs included.


Lync 2010 to Lync 2013 Migration completed … Almost… A Missing Step from Technet Migration Guide

We are nearly completed in our project to move Lync from 2010 to Lync 2013.  The project has gone amazingly smooth.  The step by step documents and tools on the Technet Migration from Lync Server 2010 to Lync Server 2013 have proven to be a great guide.

Our “test” or “lab” migration was done on our good friend Dustin Cassady’s environment simply because he hadn’t yet rolled it into production for his staff and he hadn’t yet deployed enterprise voice.  It made sense to migrate him before adding enterprise voice and then turn around and migrate.  So with that knowledge we proceeded to upgrade the Northwoods Lync infrastructure.  Since you can read about the process and plan your own deployment I won’t bore you with all the details but simply say our process was:

  • Spin up a new Lync 2013 Pool
  • Move a handful of users to the new pool.
  • Realize we forgot to run the Exchange ExchUCUtil for the new pool and fix voicemail for those users.
  • Enjoy fun with Certificates
  • Learn about the new WebApps Server Role
  • Spin up a new Survivable Branch Pool
  • Again forget to run the ExchUCUtil for the new pool and fix voicemail for those users.
  • Migrate all Gateways, Common Area phones & Analog Extensions
  • Migrate all users to the new Pool
  • Test new mobility and Windows8 Clients
  • Decommission the old environment

All of this went pretty smooth except for two three pieces:
Reponses Groups Fail to Migrate
Migrating UM Messaging Contacts not Documented
Migrating Unassigned Numbers not Documented (added 5/28/13)

Reponses Groups Fail to Migrate
Our first area of heartburn was Phase 9 Step 1, Migrate Response Groups.  I followed the steps, all groups moved but they didn’t work.  A bit of clarification, the Workflows and Queues of the Response Groups worked fine, but calls would not alert the agents in the groups.  We had to delete the groups and re-create them.  With new Groups everything worked great.

Migrating UM Messaging Contacts not Documented
The second area of heartburn is the fact that Technet doesn’t include the step of moving Exchange UM Messaging Contact Objects.  This step is in the OCS 2007 to Lync 2013 guide here, but that step is never mentioned in the Lync 2010 to Lync 2013 guide.  This caused a problem for us when we started Phase 8 of the Migration Guide and started to shut down the 2010 pool.  We stopped all 2010 services and then calls would ring 4 times and disconnect rather than the Auto Attendant answering.  In the Lync logs we saw a 504 Server Time-Out error. 
Lync Logs

And kudos to Dustin Hannifin asking a great question “Did you run UCUMUTil on the 2013 pool”… Well of course I had, but I didn’t to think to check which pool the objects were homed to… sure enough they were homed to the old 2010 pool which was powered off.
(Contact Server Pool was NCC-…)
Contact 2010

So starting the Front End service on the 2010 server and one powershell command later, all Contact Objects were homed on the 2013 pool and  the auto attendants were once again answering calls.
(Contact Server pool is now NWP-….)
Contact 2013

Steps can be found here to migrate the Contact object or use the following powershell command:
Get-CsExUmContact -Filter {RegistrarPool -eq “pool01.contoso.net”} | Move-CsExUmContact -Target pool02.contoso.net

Migrating Unassigned Numbers not Documented (Added 5/28/2013)
Like the contact objects the technet article doesn’t mention moving unassigned telephone numbers from the 2010 pool to the 2013 pool.  The steps and instructions of moving the Unassigned number can be found in the Lync Server 2013 Resource Kit Tools Documentation.  After installing the Resource kit the powershell command will move the unassigned number groups from the 2010 pool to the 2013 pool.


ACSTech Ideas to Impact Workshop

This year I had the privilege of leading a workshop again at the ACSTechnologies Ideas to Impact Conference.  Its super fun to have these conversations with my peers and I enjoy learning how others are harnessing technology in Ministry.

Again this year we had a awesome IT RoundTable on Tuesday as a pre-convention day.  Dean Lisenby does a great job hosting this event that is for both ACS Customers and anyone involved in church IT.

If you are an ACS Customer, Ideas to Impact is a don’t miss this yearly event… Not to mention that Impact2013 is in Orlando FL @ Disney!  It is invaluable to attended the workshops and learn about the tools we have available, but even more so to interact personally with your peers and the staff at ACS.

I lead a workshop this year on 10 Best Practices for IT in the Church.  While these aren’t the only best practices but 10 important practices in Church IT.

We talked thru multiple technologies and various resources so I have posted the slide deck & links here as requested by the attendees of the workshop.


Site to Site Streaming without breaking the bank – Test 1

About this time last year we were preparing to open our campus in Galesburg, IL.  Since the opening last spring this Campus has been using the recording of Saturday night’s teaching during their 11 am service on Sundays.  This solution has been a fairly stable, but has hasn’t operated without issues.  Additionally our pastor has really wanted to be able to teach the Galesburg campus live but we have multiple limitations… the distance between campuses is 50+ miles, our Peoria Campus is about 3-5 miles from any internet connections that can provide more than 10mb upload and any ISPs offering more speed has wanted nearly 6 figures in construction costs, and point to point connectivity is way more than we can afford.

In addition to the current limitations the locations we are evaluating for future campuses don’t improve limitations on the list above.. in fact, they might be even more challenging.  Yet, being live is a huge desire from our leadership, so our quest continues.

Since Fiber isn’t an option at either of our campuses (but hopefully soon), we are limited to 50×10 cable modem in Peoria and a 16×2 cable modem in Galesburg.

our requirements for site to site streaming needs to:
-  provide 1080i display in the remote locations
-  not rely upon a private point to point connection
-  not require more than 10 mb upload from the sending location
-  be a solution that is easily reproduced for future sites in smaller towns with limited connectivity
-  be easily powered up and down by volunteers (not a 30 step process between multiple platforms).

We have demoed the Haivision Mako encoder/decoders and while the encoded video they produce is pretty amazing.. the pricetag is way to high to “not break the bank” not to mention  too high for for a “test environment” as we figure out what “live streaming” really means to our organization.  (However, you should at minimum demo their gear.. the Haivision gear gives a great benchmark for anything else you test.)

So we have been doing some testing with various other streaming solutions and thought we might share our mileage.

For our testing / phase 1 project we decided to try several pieces of gear:
-  Marshall VS-102 Encoder/Decoders
-  Wirecast and Wowza Streaming to a Roku
-  Marshall VS-102 and Zixi.com Hybrid

Our Media director thru the Church Technical Leaders and our peers at Willow Creek came across a encoder/decoder hardware (Marshall VS-102) made by the Display Monitor company Marshall Electronics (and Marshall USA).  We had heard that people were having good success using the VS-102 on the LAN but the device was capable of WAN streaming site to site.  The hardware is also able to additionally stream bi-directional Audio… (hmm maybe ClearCom in addition to the video’s audio?) This device across a LAN some pretty awesome results!  I came into the test expecting YouTube quality and was amazed.  If you are looking for a way to extend your HD/SDI video infrastructure this is a device you should checkout.  I don’t know of many hardware encoder/decoders in this price point … let alone something that can provide such a quality signal.

After a local LAN test, We quickly configured the boxes and streamed from site to site over our hardware VPN connections.  Remember we are using cable modems for our internet.. and the streaming at 1mb was solid.. but video quality was lacking… moving much above 2.5 mb we started to get a lot of jitter and audio drop outs.  If you have more than 10 mb upload.. I suspect you would have much better results, but those are just suspicions since we weren’t able to do such testing.

Next enter Chris Kehayias and his teaching us about Zixi.com.  Zixi is an internet based “private CDN” (Content Delivery Network), their strength is delivering HD video content over the public internet, including higher latency connections without the receiving end dropping frames or loosing quality or dropping audio.  The really awesome piece of the puzzle is the ability to stream from Zixi to a Netgear 550 Media Player.. (a endpoint and decoder for under $100 similar concept to roku).

So with all this new knowledge we started some field testing in Galesburg, so I thought I would share what we have tested and what our results were.

We first started streaming site to site with the two VS-102 units, with similar results to our pretesting, dropping frames and audio if we went above 3 mb.  Next we tested a roku streaming via the Amazon EC2 services but had stability issues even at 1 mb.  The quality of the video, when stable was pretty good, but couldn’t get it dialed in to keep a constant connection.  Next we configured the VS-102 encoder to stream a TS-Mpeg stream rather than the default streaming VS-102 to VS-102.  It streams to the Zixi “sending” application on a PC on the same network.  This PC is responsible for applying the Zixi goodness to the stream and sending it to their cloud.  Then at the remote campus we configured a Netgear 550 Media Player, pointed it to the stream and we have video.  We let the stream ‘chew’ for over 2 1/2 hrs, never dropped a frame or received the audio garbled.

The only real test we couldn’t get working was to us the VS-102 decoder rather than the Netgear 550.  This was because we couldn’t get the VS-102 to receive what the Zixi receiver was pushing across the LAN.  We are working with Marshall support and expect to test this part soon.  Our motivation to getting the VS-102 to be the end point in Galesburg, 1 is the output of HD/SDI but also hopefully an improved video output beyond the Netgear Media Player.

After a fairly strong showing in Galesburg on Friday, we took the advice of Chris Kehayias, testing the stream during service to see the impact when our Wi-Fi is most populated and everything is buzzing… So during the Sunday Am services we tried streaming from the Peoria Campus to my house via Zixi, first 2 hrs total fail.. too much chewing thru our upload… and after smacking around a dropbox upload we were able to get a stable connection to Zixi and from there smooth sailing… even while the Sending Zixi software reporting having to recover over 50k dropped packets.  On the receiving end, you wouldn’t have known that Zixi was working so hard to keep the stream stable.

Overall I have been impressed by the flexibility of the VS-102, however their support has been limited.  The service of Zixi has been pretty amazing..  keeping a stream rock solid even with pretty poor ISP conditions.


Top Ten Reasons to attend the Church IT Roundtable 2012

The 2012 top ten reasons to attend the Church IT RoundTable in Dallas Texas April 18th – 20th.

 

10. You have a project you need to finish by May 1st and don’t have a clue how to do it… nothing like 100+ free consultants to help you.

9. BBQ (nuff said)

8. North Texas spring thunderstorms are awesome!

7. LAN Party (Throw back to an old school LAN party) Bring your own DEW.

6. In & Out Burger AND Chick-Fila AND Hard 8 BBQ in the same city!

5. Free Workshops on Networking/Vmware, VOIP, Wifi and Exchange.  Yes I said FREE!

4. Trying out some of the cheapest most promising site to site streaming gear.

3. Building relationships with some of the most committed partners (aka vendors) serving the Church IT market who are ready to make your ministry shine.

2.  Because everyone else is going.. and you’ll be sad if you aren’t.

1. Hundreds possibly Thousands of Dollars worth of training and peer learning for only the cost of admission $75!

Don’t wait Register NOW!


Testing Lync Failover to Backup Registrar “Got Ya”

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

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. 

Failover

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…Winking smile)

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

CSWebserviceConfig

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.

Lync Backup Registrar

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.


Lync Deployment continues thanks to our Volunteers

Over the past month we have been re-wiring our “Phase 1” portion of our Peoria campus in preparation for our move to our new phone system Lync.  As part of that project, we have pulled out hundreds and hundreds of feet of old cat3 and cat5 wiring that was abandoned, wired wrong or damaged.

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.

Wiring work night

 

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.

wiring work night cleanup

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


Configure Asterisk as a SIP Proxy for Avaya IPO & Lync

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

 

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.

Avaya PSTN Config

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. 
Ars table

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). NoDIDShortCode
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.

4 digit short code

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

EnableEnterpriseVoice

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.

DefinenewGateway

Next associate the Gateway with the mediation server

AddGateway

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.

TrunkConfiguration

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.

IPOTranslationRule

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. VoiceRoute-1

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.

    VoiceRoute-2

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.

VoicePolicy

Associate the route just created in step 6 by hitting select

Associate PSTN Route

choose the route.

Select PSTN Route

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

VoiceRoute-3

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

    SIPConfig-1
    SIPConfig-2

  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


    [Name-of-Avaya-Context]
    exten => _+1xxxxxxxxxx,1,Dial (SIP/Lync_Trunk_Name/${EXTEN},30)
    exten => _+41xx,1,Dial (SIP/Lync_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

    asterisk dialplan

    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.


Configuring Lync PSTN Calling Thru Avaya IPOffice

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

 **Update 1/01/2013 – Note that Calls placed on hold or muted would drop when trunked from the IPO to Lync.  Our resolution was to use Lync & the IPO with an AsteriskNOW install proxying the SIP trunks.  The IPO connects to the asterisk and the asterisk connects to the Lync Mediation server.  See Configure Asterisk as a SIP Proxy for Avaya IPO and and Lync how to use the Asterisk as a proxy.***

**Update 2/14/2013 – We are selling our old Avaya phones here, we have a IPO 412 and several modules also for sale leave a comment for more information***

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.com/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/

SipTrunkLicense

  • 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 NONESipLine
  • 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.SIPURI1
  • 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.SIPURI2
  • 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).IncomingRoute

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

    Destinations

  • 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.ARS

    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.

    shortcode

  • 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.ShortCode2
  • 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.OutboundShortCode
  • 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.Extn6500
  •   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.6500ICR

    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

    6500ICR-Destination

  •   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).NoDIDShortCode

    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.

    ARSShortCodeNoDID

  •   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 VoiceEnableEnterpriseVoice

    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.

    DefinenewGateway

    AddGateway

    Publish the Topology.

  •   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.TrunkConfiguration
  •   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.IPOTranslationRule
  •   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.VoiceRoute-1

    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.

    VoiceRoute-2

  •   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.VoicePolicy

    Associate the route just created in step 15 by hitting select

    Associate PSTN Route

    choose the route.

    Select PSTN Route

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

    VoiceRoute-3

    Commit all Changes.

 

 

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


Pages:1234567...16
UA-2932131-1