Lync as a PBX Replacement Series - Analogs

Others in the series...

PBX Network Topology
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-network.html

PBX Dial Plan
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-dial-plan.html

Toll Fraud
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-toll-fraud.html

Overview
When you replace a PBX with Lync Server 2013 no doubt you will have to deal with Analogs. There are several types of Analogs you should be on the look out for when you are gathering documentation on the PBX environment.

• Analog extensions
• Fax machines
• Fax servers
• Modems
• Credit Card machines
• Postage machines
• Door phones
• Gate phones
• Cordless phones
• Paging systems

I'll talk about each of these and how to handle each of them effectively.

Analogs
Analog extensions/Cordless phones
These are probably the easiest of all the analogs to handle. Analog Extensions and Cordless phones are just straight voice extensions that use an analog port on a FXS gateway. Although you can handle Analog extensions completely outside of Lync Server 2013, I recommend that you use the Lync Server Analog Device feature.

Using the Analog Device feature serves two purposes. The first, is to a Lync user it appears as any other Lync user/device/common area phone. When created, it has a contact created in Active Directory and is assigned a Tel URI. This also will allow calls from the Analog device to appear in Monitoring Server reports. The second purpose is to be able to control with Voice Policies what numbers the Analog Extension can dial. This is important in situations where an analog phone is required, like an intrinsically safe enclosure for hostile environments, but still needs to have controls as to what numbers can be dialed.

At some point I plan to do a detailed blog on setting up Lync Server Analog Devices and all the pieces that need to be put in place for it to work as designed.

Fax machines
Fax machines are a bit more of a problem. On the surface the Analog Device feature of Lync gives us the impression we can handle faxes in a similar manner to Analog extensions. There is some limitations to handling Faxes through Lync that ultimately, in my opinion, makes it a non starter.

First of all, when you create an Analog device with the Fax attribute enabled to true, all this does is immediately send the call directly back to the Gateway the Fax call originated from. There is no way to send this call to any other Gateway.

When the Gateway receives the call from Lync Server it follows the routing tables that in turn directs it to the appropriate port. If you have a lot of fax machines for a location, you are limited to the number of Fax ports the Gateway connected to the PSTN can support.

Next issue, in order to send the call through Lync, the codec for the originating call to the Lync Server can not use T.38 or any other Fax specific protocol. The Gateway can only be configured to use G.711 only. If any other codec is sent to the Mediation Server the call will fail.

In theory G.711 protocol should be okay for Fax transmission, but in my experience it is flaky and customers tend to complain when things don't work consistently.

My recommendation is to handle Fax machines outside of Lync Server. Allow the Gateway to route the call to the appropriate port whether that is on the originating Gateway or a different Gateway elsewhere. This will allow the use of T.38 or any other Fax specific protocol and give a more consistent experience.

Fax servers
Fax servers can only be handled through Gateway routing outside of Lync Server. These servers typically only support T.38 and there is no way for the Fax implementation in Lync to send these calls to a Fax server using the Analog Device feature.

I would not under any circumstance route these through Lync to Exchange UM and then over to the Fax server. Even if you did get it to work, I doubt it would work consistently because T.38 is cut out of the picture.

Modems/Credit Card machines/Postage machines
There is no way to handle Modems and Modem like devices within Lync Server. Because of this you will need to use the Gateway routing feature the send these calls to the appropriate Analog port on an FXS Gateway. Depending on the Gateway manufacturer there may be specific codecs that are more appropriate for modems. If this is the case the modem negotiation will be detected once the call is answered and the codec will be renegotiated.

Door phones/Gate phones
These can be setup like an Analog Extension within Lync Server, but they will never receive a call. They only make a call, usually to a specific number. This specific number can be a Response Group or to a receptionist. What makes these devices unique is that they listen for certain DTMF tones to activate a relay to remotely open a door or gate. Sometimes a door phone might be PBX specific and will need to be replaced with an analog equivalent (that might require a professional installation).

Paging Systems
Lync Server does not provide any native ability to do paging. There have been third party developed solutions for this, but as far as the theme of this blog post goes I'm going to stick to talking about overhead paging systems. The first thing to determine is what type of paging interface the PBX has. If it is an analog interface then your job will be easy. If it is some sort of relay (dry loop for instance) then you will need to acquire a paging adapter such as a Valcom V-200X series. An adapter like a Valcom will accept an analog connection and interface to the paging equipment.

Once you have a Valcom like adapter, or a paging system that accepts an analog connection, you can again setup a Lync Analog device to direct calls to the appropriate Gateway and then using the Gateway routing tables deliver the call to the appropriate port.

One of the techniques I use with Paging systems in Lync is to normalize a dialing shortcut to reach the paging system. If the PBX accessed the paging system by dialing a feature code like 200 then I might do a normalization rule of *200 and normalize to the TEL URI of the Analog Device I created. Unfortunately not all PBXs work like this and sometimes you just have to ask the customer what they want to dial to reach the paging system.

Lync as a PBX Replacement Series - Toll Fraud

Others in the series...

PBX Network Topology
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-network.html

PBX Dial Plan
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-dial-plan.html

Analogs
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-analogs.html

Overview
Since I have started working on Microsoft based Unified Communications, I hardly ever hear any talk about Toll Fraud. Granted, things have changed as far as telecommunications costs, but there are still other problems that can crop up with regard to Toll Fraud.

When we are considering replacing a PBX, the Toll Fraud prevention the PBX has in place will be gone. Lync should be configured to prevent users from using the system inappropriately. It is important to note that some of the ways I'll point out that Toll Fraud can be committed are not necessarily considered Toll Fraud by every business so it is best to really have a heart to heart with your customer about the subject.

Toll Fraud
900, 976, and 809
Most people in the United States are aware of 900 and 976 Premium numbers that can rack up costs for the caller (mostly sex talk lines). But not a lot of people are aware of 809 scams. The numbers look like Canadian or US telephone numbers, but turn out to be costly, overpriced international calls which bypass consumer protection laws. Some advertise phone sex or other typically premium content. Other ways these scams work, is by leaving an unsolicited messages on voice mail or making bogus claims of being a relative in a family emergency to trick users into calling the international numbers, then attempting to keep the victim on the line as long as possible in order to incur the cost of an expensive international call. Ask yourself this... if you were to get an 809 number on your phone would you call it back? Most people do... and this is how they scam people.

Call Forwarding
This is when a phone within a business is set to call forward to a Long Distance or International number. These days Long Distance is so cheap that you don't hear about this much anymore, but call forwarding to an International number can still be costly. Once a phone is forwarded a person can call that phone and voila they have made a call on someone else's dime. It doesn't even need to be a phone with a DID if you have an Auto Attendant they can use to transfer to that Non-DID phone.

Personal Calls
Most businesses don't care if you make a personal call while at work. However, I'm willing to bet they might care if you made a personal International call on their dime. I really don't have anyone Internationally I want to call on a regular basis, but I have friends that have family and friends overseas. In general, a business will restrict the types of calls a user can make based on their job function and then do periodic audits of phone bills to see if anything sticks out.

411 Calls
Calls to 411 are used for directory assistance. This is one of those grey areas, that some businesses allow their users to dial. The reason why some businesses restrict this is because there is a per call charge of $1.25 for this service. Sometimes this slips through because phone systems need to allow for 911 and other municipal services on 311. Good to investigate what the current phone system allows and then have a conversation with your customer.


Why do we care about Toll Fraud?
As installers of communications systems, we should take great care in making sure the system is functioning properly. That means also making sure the system prevents users from using it ways that are not appropriate.

.Net Regular Expressions
With regard to Lync Server we have a lot of tools to prevent and monitor Toll Fraud.

To start with across the board blocking of numbers can be done at the routing level within Lync Server. For instance the following .Net Regular Expression blocks 900, 976, and 809 numbers, but allows all other area codes to pass whether they are valid or not. If you need to add other numbers it should be self explanatory on how to do that. If you need help with Regular Expressions you can read my blog post.

^\+1(?!(900|976|809))

Call Forwarding and Simultaneous Ring Restrictions
As far as Call Forwarding goes Lync Server 2013 provides a separate ability to restrict Call Forwarding and Simultaneous Ring vs the users ability to dial the PSTN directly. By default it is set to use the users assigned PSTN Usages, but you have the option to restrict to Lync users/endpoints only or Route using custom PSTN Usages. This would be an excellent opportunity to have a conversation with your customer on how they want this setup because this may add more Voice Policies to your deployment if they want users to be able to dial Long Distance but have separate policies restricting the call forwarding and simultaneous ring for different groups of users. Here is what the area in Voice Policies looks like...

Authorization Codes
Some companies use authorization codes to prevent fraud of someone walking up to a phone and dialing a Long Distance or International number. You might run in to a PBX that has Authorization codes, and even though there are third party developed solutions on Lync to handle this, there is nothing built in to the Lync product with this functionality. Many businesses choose to have a carrier handle Authorization codes for them and then in turn creates a report every month of who made what calls and for how long.

I'd also like to point out that some PBX Authorization codes implemented require the user to dial an authorization code before the phone number. You might have caught this while you were collecting data for the PBX Dial Plan, and have been scratching your head how to get Lync to handle this. I haven't seen a way to handle this across SIP. Your customer will need to remove these restrictions from calls coming from Lync and allow the Lync system to control what a user dials with Voice Policies, PSTN Usages, and Routes.

Voice Policies, PSTN Usages, Routes, and Trunk Configurations...
Now you might be asking what are PSTN Usages at this point. If so that probably means that calls are flowing to the PBX wide open with no restrictions (which is fairly common). I plan to do a whole PBX Replacement Series write up on Class of Service or Call Restrictions, but I'll try to boil down the basics in this post.

Going to Masters was the single hardest thing I've ever done. I wouldn't have missed a single moment of it. Everyone there was top notch and I made some great friends. Everyone came with their specialties and mine happened to be voice. Some of the class struggled in this area, which isn't good because there is one week of information on just the Enterprise Voice part of Lync Server. Doug Lawty was the instructor for most of this week and if you ever get a chance to sit in one of his sessions at Lync Conference you should.

Anyway... my point is that doing Enterprise Voice right, in Lync Server, is not trivial. Understanding Voice Policies, PSTN Usages, Routes, Trunk Configurations and how they all interact with each other can be daunting, especially if you haven't seen an example before. So... with that... the best way I can show you how this stuff works together is by showing you visually.

Got it memorized? The way to read this is to start on the far left and work your way right. The far left is User Voice Policies. That is right... USER. I never use Voice Policies assigned at the Lync Site level. Why you ask? Because you will always run in to that situation where you need to be more granular per office, per floor or even per department and you might as well start out that way.

Anyway pick a green box like DEN-LongDistance, notice the pretty yellow/orange lines that move to the right. Those are leading you to PSTN Usages. PSTN Usages are how you control which routes that Voice Policy has access to. Each PSTN Usage can have Multiple routes assigned to it. Multiple routes can be assigned to Multiple PSTN Usages. Oh, and PSTN Usages can be assigned to multiple routes (evidence of all the pretty colors). So this is why people get really confused and why the picture is important. Don't think the above example is the only way to do this... it is just how I prefer to do it.

If a User Voice Policies doesn't have a usage assigned that allows access to a route assigned, there is no way for the user to get to that route. Are you starting to see how we can restrict what a user is able to dial?

When I build all this out I actually start with my routes. Then I create a User Voice Policy and Create the PSTN Usages within that Voice Policy as I go. Start with the most restrictive Voice Policy because once you build a PSTN Usage you can use it later for other Voice Policies (i.e. DEN-911-Usage).

Like I said I'm going to do a whole blog post dedicated to this area, so don't want to give away all the fun just yet. Hopefully the above visual will help you until then.

I didn't intend to have this post the end all for all types of Toll Fraud. What my real goal was in this blog post was to get you thinking about Toll Fraud in a Lync Server environment. If you have any questions feel free to add a comment I'll do my best to answer.

Lync as a PBX Replacement Series - PBX Dial Plan

Others in the series...

PBX Network Topology
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-network.html

Analogs
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-analogs.html

Toll Fraud
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-toll-fraud.html

Overview
In my next installment, I would like to dive in to PBX Dial Plans. Chances are there is very little PBX documentation or you might also hear my favorite...  "The PBX is the documentation".

There is also an even smaller chance that if there is PBX documentation, it won't be the dial plan. Why? Because it is a pain to really track and do a dial plan well. If you have a seasoned PBX Administrator on staff give them a big hug and buy them a nice steak dinner right now, because they are your single biggest asset to understanding how things are laid out.

On a side note... many PBX Administrators are really scared of Lync right now. They think because Microsoft is replacing their PBX, they will get replaced too by the "server administrators". That is the farthest thing from the truth. Sure the server administrators will probably take a greater role in managing the communications environment, but they won't get "Voice" like a seasoned PBX Administrator. Most of the knowledge these professionals have can't be learned easily anymore. They also have years and possibly decades of experience of how not to do things that might be specific to the business environment you are working in. What you should encourage them to do is embrace learning a new skill set that will make them even more valuable because not only do they have critical knowledge about telecommunications, but they will also learn new Server and Applications skills (which is easier for them to do than for a server administrator to learn telecommunications). Those two together are really powerful, throw in some data communications and QoS and you get what I call a true Converged Engineer.

Meanwhile... back at the ranch, let's dig in to PBX Dial Plans...


PBX Dial Plan
First off, I want to go in to the two different types of PBX dial plans. They are Coordinated and Uniform (Nortel speak). Haven't heard those terms before? Doesn't surprise me. I never heard those terms until I started at Nortel even though I was a network manager at a university and had voice for the university under my domain. There is also a good chance that depending on the PBX vendor the terms might be defined differently or have different names (which can be confusing... I know). No worries, I plan to describe them in detail so hopefully we will all get on the same page regardless of what each of us calls them.

Coordinated
In a coordinated dial plan each extension in the PBX network is unique and all the same number of digits. Each person can dial each other directly using just the digits of the extension regardless of where they are.

Typically you will see ranges of numbers dedicated to a site. For instance, all the Denver numbers start with 45XX and all the Dallas numbers start with 46XX. The range is totally arbitrary and can really be any range.

A well managed Coordinated dial plan will usually break ranges in to 10s, 100s, 1000s... 10000s you get the idea. An example of a badly managed dial plan would have Denver range be 4523 through 4547 and the Dallas range be 4548 through 4581. Although it is certainly valid, these are harder to handle in routing tables in the PBX (and harder in Lync too).

If you are in the rare situation where you are developing your own dial plan, you will want to pick ranges that allow for future growth. There isn't any hard set rule on what you should do. So most people go with their gut... or base it on some knowledge they have about the business and how much they grow.

DIDs in a coordinated dial plan usually start out by matching the last few digits of the DID number. For example 3035554500 would correspond to an extension 4500. When you have 4 or 5 digits for an extension, you will find that assigning all 4 or 5 digits to an extension can chew through a dial plan number availability quickly. One way PBX Administrators handle this potential overlap is even though your carrier may send you 4500 the users DID (3035554500) they map to an extension that is really 3500. These nuances are really important to understand and have documented. When you start to write normalization rules, knowing details like this up front will save you a lot of effort. Also, keep a watchful eye for situations where the DID does not line up with an extension in some sort of pattern. You'll need to write one off normalization rules to handle these properly and you should also see if the customer can clean these up in any way (might be a multi year process).

As you might have surmised above... the biggest challenge with Coordinated Dial Plans is that they run out of digits once you go past a few sites. Depending on the number of users, you might start to feel pain around the 10 site mark. If you start to run out of room there isn't really any easy way out. You will feel pain. My suggestion these days is to move to an E.164 dial plan (along the lines of Uniform below) where users calling another site have to dial 10 digits. Within a site can still be their short extension. If you move to an E.164 dial plan there is no chance or conflict (this goes for International dial plans as well)

Uniform
In a Uniform dial plan, each site has access to the entire range of numbers, but when dialing another site, it requires a site code or prefix to identify where you are calling. In the example of Denver calling Dallas you might have a site code of 20 in front of the extension so the user would dial 204623 to reach a user and vice versa Dallas calling Denver would dial 214512 as an example. A Denver user calling another Denver user would just call the 4 digits, but certainly could call the site code too if they wanted.

Now usually with this type of dial plan you also have an Access code associated with internal site to site dialing. Think of it as like dialing a 9 before a PSTN number. At Nortel, we used to use a 6. So in the example above the Dallas user would dial a 6+21+4512 to reach the user in Denver.

Site codes don't have to be just 1 or two digits. Typically for really large PBX networks you might see more. Nortel used a 3 digit site code with 4 digit extensions. They were a truly global company with over 100,000 people at one point just to give you some perspective.


Why do we care about PBX Dial Plans?
Simple... we want to replicate the voice dialing user experience in Lync.

Normalization Rules
One primary way your users will complain is if they have to learn a new way to dial Bob in Accounting. To keep this from happening, an understanding of how the users dial numbers today is needed, so you can replicate that with Normalization rules in Lync. Need help with Normalization rules? See one of my first blog posts for some help.

So I'm going to assume you have great documentation at this point. If not, you better get cracking and better hope this deployment isn't due to be done this week. If you are having to create documentation chances are you won't get everything. In this case you need to consider using a generic normalization rules that will catch all the extensions you don't know about. To do this normalize using the HQ main office number +13035551000;ext=XXXX. When you configure your Trunk Configuration to strip out what you don't need, you'll just grab the extension and pass to the PBX and the call will complete.

As you are going through your documentation look for things that aren't consistent. If it doesn't look right, or stands out... ask questions. Usually there is something more sinister going on. Worst case scenario would be a dial plan that has different number of digits depending on what site they call. If you run in to one of these... stop the presses (hopefully SOW isn't signed yet) and tell the customer that they need to make everything consistent across the board. Proceeding will only mean pain for everyone. If you proceed, you will be in an endless loop of workarounds that at some point will become unmanageable.

When you are putting together normalization rules, you should at least be looking for information to complete the following:

• 911 with and without Access Code
• Special formatted numbers (Paging, Hunt Groups, Emergency Notification etc)
• Dial Receptionist for each site (Company Operator)
• Extension (for example 4-Digit)
• 10-Digit for Internal DIDs
• PSTN Local 7-Digit with and without Access Code (if needed)
• PSTN Long Distance with and without Access Code
• PSTN International with and without Access Code

Also, when you start out developing your dial plan in Lync, ask yourself at least one critical question. Will I need to handle Non-DID extensions? Those are the extensions that a user can call internally that have no dedicated PSTN number. They can only be reached from an internal phone, or by transferring from an internal phone. For Non-DID dial plans you have no choice but to use the +1XXXXXXXXXX;ext=XXXX format when assigning numbers to users or endpoints. I would use the format anyway for other reasons like Pin auth and Dial in conferencing authentication, but regardless Non-DID REQUIRES you use this format.

Since I am a fan of +1XXXXXXXXXX;ext=XXXX, even in environments that all have DIDs, you should always write User Dial Plan rules for extension dialing to normalize to this format, but also 10-Digit versions of Internal DIDs that specifically normalize to the +1XXXXXXXXXX;ext=XXXX format. I know... I know... Microsoft will match the first part... but I've been working with this stuff long enough that I don't trust that to work 100% of the time. I follow this rule religiously, and it creates a lot of extra work, but my deployments have a great track record. Also, don't forget to make sure you Normalize the Lync Address Book in the same way.

Now, if you have a Uniform dial plan you will want to include the site code after the ;ext= when you assign numbers to endpoints or normalize (+1XXXXXXXXXX;ext=21XXXX). Why? mainly to make Caller ID to the PBX easier. Wasn't what you expected was it? I am a fan of doing all Number manipulation on Lync. This includes having separate Trunks in Lync for PBX routes so I can strip down the Caller ID to match the user experience on the PBX. Don't do this and you'll be writing a ton of rules in the Trunk Configuration. Don't do it Trunk Configuration? Then when the user goes to dial the person back the call won't complete because they won't know the site code. Get it? Got it? Good!

Routing
More than likely you will have more than one place you are connecting to the PBX network through. Because of this you will want to know what numbers in the dial plan go where. If the PBX Network is Hub and Spoke there are finite resources available and not sending the calls to the closest PBX to its destination could cause congestion.

This is also important if you are doing any routing for analog devices that are connected to the Gateway.

Unassigned Number Handling
At first when you are doing co-existence you will not want to have Unassigned Numbers in Lync. But as you eliminate each PBX you will want to add Unassigned Numbers to Lync. This will prevent routing loops in your PRI Gateway's and SBCs. Unfortunately you can't do ranges of DIDs with the ;ext= format. You can only do straight E.164 numbers or numbers with ;ext= and the first part of the number being the same +13035551000;ext=1000 through +13035551000;ext=2000. No Bueno.

This will mean that your call will route out to the PSTN and back in before it gets unassigned number handling. Not optimal, but configuring the rest of Lync to work around this one issue causes more problems in my opinion.

So what this looks like is your User Dial Plan rule will normalize to +1XXXXXXXXXX;ext=XXXX not find a match for user, endpoint or unassigned number and route out through a PSTN Trunk. That call will then come back in on another channel and your PSTNGateway Dial Plan should normalize that incoming PSTN number to E.164 in the following format +1XXXXXXXXXX and then try to match a user or endpoint. When there is not user or endpoint found it will stop at your unassigned number handling.

911 Emergency
I know the normalization rules for 911 are fairly trivial to write, but what you need to find out in your dial plan is if each site, or floor, or zone has a specific number that needs to be passed to 911 operators. You can handle this a couple different ways. Either doing a Location Policy or handling with Voice Policies and Routes (with a Caller ID override).

If the PBX is actually doing true E-911 then you might need to consider using the E-911 function in Lync or using a similar E-911 or ELIN capability in the Gateway.

Paging
Within the dial plan you will also want to identify any paging within the PBX environment. Sometimes these are feature keys on the phone, but other times, they might actually dial something the resembles an extension. If it is a feature key, then you will need to develop a plan on how to handle Paging (usually analog FXS/FXO gateway connected to Paging system with Analog port). If it is extension based paging you have more detective work to do. You will need to identify how the paging system is connected and can you use a similar method with Lync or does the whole paging system need to be swapped out.

The above items are the critical pieces that get forgotten about when the talking heads go on about PBX replacement. PBX replacement is not easy and you need to always be prepared for that surprise that no one thought about.

Lync as a PBX Replacement Series - PBX Network Topology

Others in the series...

PBX Dial Plan
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-dial-plan.html

Analogs
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-analogs.html

Toll Fraud
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-toll-fraud.html

Overview
I thought I'd put together a few blog pieces going through some of the decision points I consider when replacing a PBX with Lync Server. This series does not cover any decision points regarding replacing PSTN connections with SIP trunks. This also does not specifically address PSTN concerns outside the United States.

Regardless of which vendor you have chosen, almost always you will need to deal with a period of co-existence when your goal is to replace a PBX. The areas I cover in this series stem from the complications of having two different systems coexisting and what areas you need to fully understand so that your strategy is sound and will be a good solution for your environment.

In this installment, I will be talking about the PBX Network Topology. Even before a Statement of Work is signed or if you are going about this on your own... you start turning the screws. Some PBX documentation needs to be dug up or created. I've fixed too many projects where someone has just started doing the integration without understanding the whole picture when it comes to the PBX. Once you have some documentation you'll probably have more questions, but that isn't a bad thing when it comes to working with the core communications of a business.

PBX Network Topology
Much like a data network, a PBX network has a topology as well. Depending on how well the PBX environment was managed this could be very logical layout... or a complete mess of spaghetti. Either way, when you look at it in a diagram you should see a network Topology pop out at you like a Hub and Spoke, Mesh, or Stand alone topology. This doesn't mean that you won't have some Branch to Branch direct connections that don't follow the topology... people do lots of crazy things over time and then forget why they did them. But overall, the design should pop out at you.

Hub and Spoke
In a Hub and Spoke scenario, there is typically one or more main sites and several branch offices connected to each main site. All sites can call each other, but for one branch to reach another branch it may have to pass through one or more main sites.

Typically Hub and Spoke is seen with TDM based connections between PBXs because the cost to connect all sites to each other is cost prohibitive. I've seen a Hub and Spoke network where all the PSTN access (Incoming and Outgoing) for a branch had to go to a main site. I've also seen where all sites had least cost routing to where a branch could make a Long Distance call and it would be a local charge because of sophisticated PBX routing.

Each PBX has its own routing table, but only to the next hop, much like a default gateway in a data network.

One last little thing to consider in a Hub and Spoke is that you may have Branch office PBX equipment that is dependent on the main site during normal operation. When you are looking at the PBX configuration, a branch may seem like it is part of the main site, but it is not. The Branch office PBX equipment is designed to come in to play when there is a failure to reach the main office. A that point the Branch office PBX takes over and starts serving the local users. In Avaya speak these are Local Survivable Processors (LSPs) and in Nortel speak you might hear CS1000B, Business Communication Manager (can be PBX too), Mini Carrier remote, or Fiber remote.

Mesh
In a Mesh scenario, all sites can route calls to each other directly. Each PBX may have its own dial plan, or they may reference a central routing server (H.323 Gatekeeper or SIP Proxy). A Mesh style PBX Network Topology is usually seen when a PBX network is VoIP enabled with either H.323 or SIP. This is also seen when there are multiple types of PBXs whether from one manufacturer or several.

Stand alone
Fairly self explanatory. You may have just one PBX you are replacing, but it is also possible your environment has several PBXs, but none of them are connected to each other. In this case, each of those PBXs would be considered stand alone. The PBX only has routing to the PSTN in this scenario.


Why do we care about the PBX Network Topology?
Gateway Placement
One of the reasons we care is that this directly impacts where we connect to the PBX network during the co-existence and the type of connection we will use.

With Hub and Spoke, it makes the most sense to use the Hub sites for PRI Gateway placement. PRI Gateway because you typically will see this with TDM based PBX networks. Placing a single Gateway at a Hub will more than likely cause a bottleneck either at PRI Gateway or a TDM connection in the PBX network. You can use ERLANG calculations to estimate the capacity needed at each hub to handle the highest volume of calls between Lync and the PBX (50% Lync and 50% PBX will be highest). When calculating you should consider calls between Lync and PBX extensions, but also Lync and the PSTN. If you don't want to use ERLANG calculations you can assume 1 out of 4 people will be on the phone at any given time calling either an Extension or the PSTN (doesn't count for contact centers). If the PBX environment has existing Call Detail Records (CDR) then those are also an excellent way to determining capacity and calling patterns.

With Mesh, if there is a SIP Proxy available, then the connection can be made there. Otherwise it is best to connect to each PBX directly. This type of connection is commonly referred to as "Direct SIP". If H.323 is involved, then one or more sites will need to be made into Hub sites and treated like a Hub and Spoke type implementation until all the sites are on Lync. One word of caution, don't assume all SIP is created equal. Make sure you have support for a Direct SIP connection, if not, you will either want to consider an SBC in between that is support by both Microsoft and your PBX vendor, or go back to a PRI Gateway connection.

With Stand alone, it becomes very important to determine if each site has a data connection present. If they do, you can deploy a Gateway to each site and use that to bring PSTN calls for those users to Lync. In order to do so, you will either need to replace the PBX in one fail swoop or do an Upstream (between PBX and PSTN) or Downstream (Gateway is connected to PBX and reaches PSTN through PBX) gateway implementation during co-existence. Since the PBXs are not already connected, the environment will need to have a dial plan created and users will need training on how to communicate directly with each other once they are on Lync.

Dial Plan
If you haven't already figured it out, this is where you will spend most of your time in designing your plan for co-existence and migration. I plan to dedicate a series to this, but your goal should be to work within the PBX dial plan and not have to change how users reach each other. Yes, this will take more work, but in the end your customer/users will be much happier.

With Hub and Spoke and Mesh, your goal is to figure out if the Topology defines how users dial a number. In other words, are you dealing with prefixed numbers that indicate a specific set of digits to identify a site. This will vastly change your Lync dial plan and create a lot of work to replicate how users dial their phone today and you need to account for this in your Statement of Work or Project Plan.

Voicemail
You got this awesome plan to use Exchange Unified Messaging once you are on Lync (I know it is the only supported)... but have you given thought to the order in which you will be replacing PBXs? Hint: if the PBX environment has centralized voicemail you won't want to start there or at the very least leave the PBX in place until all the others are migrated.

Order of Deployment
Speaking of "order of deployment".... Voicemail isn't the only thing that impacts this. Yes, you might have business reasons for the order or deployment (for future job security please don't put the executives on first), but you really want to consider your trunk capacity as you do your migration. When you start to approach that 50% mark you might want to choose one of your big sites... so that you won't ever hit that 50% mark, but jump right over it. This will help with your trunk capacity because you will go from having most of the users on the PBX to having most of the users on Lync. Once most the users are on Lync, guess what? They will call each other direct and won't be using a trunk.

Ways to use Twync effectively (and some not so effective ways)

So Twync just got released and I already found some great ways to use the Twitter to Lync over Federation tool EventZero created. If you don't want to bother reading what I have to say here is the original posting over at EventZero for Twync. Yea, the same EventZero who is sponsoring The UC Architects Party(ies) at the Lync Conference in Las Vegas (blog post).

Since you are still with me... you must find my opinion valuable... either that or you want to see me make a fool of myself. Either way... Welcome! :-)

Pat Richard (@patrichard) was the first post I saw about Twync. It was a suggestion to follow @TheUCArchitects using this tool by sending "follow @TheUCArchitects" to twync@eventzero.com . Great idea!

Then I thought to myself... hmmm... who else could I follow? Here is my suggestions so far.

Critical stuff to consider...
follow @TheUCArchitects (we need to know when the next podcast is available immediately...)
follow @BreakingNews (because when news happens I want to know)
follow @Office365Status (because knowing when your customers Office365 is down is important)
follow @ColoradoDOT (Colorado Dept of Transportation... I'm sure you have your own DOT)
follow @msftLync (official Microsoft Lync twitter... need I say more)
follow @DrRez (official Lync Product Team twitter)
follow @lyncdialog (what did you expect?)

Distractions...
follow @lifehacker
follow @gizmodo
follow @engadget
follow @altonbrown (if you never watched Good Eats... you haven't lived)
follow @johnacook (let's see if he notices)

Anyway... you get the idea... feel free to share in the comments other twitter accounts to follow. If they are good I'll update the blog with credit from you.

What I'm really hoping for in the future is...

• The ability to subscribe to keyword matches like I do in TweetDeck "ucoms OR lync OR mslync OR Lync2010 OR Lync2013 OR lyncdev OR lyncfromanywhere"... Yes that could be a bit much... but there might be keywords I really want to know immediately in my Lync client.
• The ability to subscribe to Twitter lists like my Lync Rockstars

Other Features
Alright... now we have that out of the way I also wanted to point out there are other features that can be listed out by sending "help" to twync@eventzero.com

echo

• handy way to tell if the bot is alive send "echo test" and a "test" should reply shortly

show subscriptions

• if you followed all the stuff above... this is the way to check to see who you are following

show mode

• shows the mode you are in (see modes below)

follow @username

• self explanatory... you should do "follow @lyncdialog" to twync@eventzero.com now

unfollow @username

• self explanatory... never enter "unfollow @lyncdialog"

unfollow all

• self explanatory... if you enter this.. immediately enter "follow @lyncdialog" after

mode always

• this is the default you start off with. You get IMs whenever the bot finds new tweets based on your subscriptions.

mode active

• any tweets you should have received while active... when you are not active... are lost.

mode queue

• any tweets you should have received while active... when you are not active... are queued.

Complete Windows Server 2012 and Windows Server 2012 R2 Documentation in PDF

Just came across a PDF download of the complete documentation for Windows Server 2012 and Windows Server 2012 R2. Considering the table of contents is 347 pages long, and the document is in total 7970 pages long... I'd say this is a gem of information to have "offline".

It appears on the download page from Microsoft, as if it is the entire contents of the TechNet Library for Windows Server 2012 and Windows Server 2012 R2.

The download is almost 111 MB... enjoy

Windows Server 2012 R2 and Windows Server 2012 TechNet Library Documentation

Colorado Unified Communications User Group for 2014

It's 2014 and the Colorado Unified Communications User Group is getting ready to fire back up again. The leaders have been working on a new schedule for this year and we have some great plans for this year... some I'll share... some will have to wait til later in the year ;-).

First off... we are going to have a monthly discipline that is going to be either Lync, Office 365, or Exchange. We try to find a sponsor every month related to the discipline and then we will have either one of the leaders or a member give at least one presentation... also related to the discipline.

Also, at every meeting, during the time we are serving food and beverage, we are going to have a new "Lync Update" presentation that will be a quick summary of the big Unified Communications related news items since the last meeting. This may include issues, announcements, blog posts... you name it. Anything we deem the Colorado Unified Communications User Group community might be interested in knowing.

First up for January, Plantronics will be our sponsor and they will be giving away some headsets! The topics for this meeting on January 30th at 4:00pm are:

• Lync Meeting Etiquette
• Deploy Lync Voice

The meeting will be held at the Microsoft office in the Denver Tech Center.

Microsoft Offices
7595 Technology Way
Suite 400
Denver, CO 80237

Please RSVP so we can make sure there is enough food and drink