In Part 2 I talked about how to architect a discovery and the reasons why each element is required. In this post I am going to be zeroing in on the telephony feature and dependency discovery.
There is no two ways about it, the migration of users or extensions from Avaya or any other VoIP or PBX solution to Skype for Business is the most difficult phase of the overall Microsoft UC deployment project. Users and the business will expect some form of service continuity while expecting change. By this I mean some features we can forget about migrating because they just don’t exist in SfB or SfB’s behaviour just doesn’t require them and the business will accept these after due diligence. However, there are some basic and most relied upon features that must to migrate in order for the business to operate. These are usually broken down into two categories:
- User features
- Business Services
User features are things that one or more inter-linked users depend on in order to serve their customers and maintain the level of coverage they require. These will typically be features such as:
- Bridged Appearance
- Team Call
- Coverage Path
- Coverage Answer Groups
- Group Pickup
- Remote Call Coverage
These tend to be the most common and heavily relied on features that I come across in most businesses. These features are of course migratable (see part 2 for Avaya to SfB feature map).
Business services are front of house or internal service numbers that may have an advanced call workflow configured, or simply provide coverage to a business service (e.g. security office). These can be migrated to SfB, but caution and consideration must be taken to ensure that from a feature set perspective, SfB can recreate or at least re-design the solution to accommodate the workflow, especially from a RGS perspective at least.
Business services are usually easy to solve in the grand scheme of things. More often than not these are validated and rearchitected by using a business engagement strategy to interview the stakeholders and collectively come to a design that is mutually acceptable. User features on the other hand, they can get very very very complex.
Obviously approaching every user and interviewing them on what feature they use is impractical. There is also the fact that they may have a button feature configured from 2005 which they no longer use. This is impossible to remediate out programmatically as CDRs for feature buttons just don’t exist. Anyway, back to the point. A user may have dependencies on other users. Those users may also have dependencies on yet other users and so on. Out of the 9 or so features you can migrate there are 9^9 possible combinations of user dependencies, or 3,87,420,489 (I’m not even sure the commas are right). Truly an astronomical number by any means.
However, don’t panic it never works out to be that complex. You’ll find that most users will have dependencies on between 5 and 15 others as a general average. So, you can stop reaching for your kitchen knife right now, there is light, come back to the light!
So how do you discover these dependencies? If you’re anything like me, I don’t have a wealth of Avaya knowledge, I know enough in order to articulate what I need to in order to migrate, but sit me in front of a CLI and I’d be like er, yeah, can you call me a cab? This is a real challenge in the industry though. Most people come from Microsoft backgrounds in SfB and voice and UC is somewhat of a swamp full of alligators waiting to snap at your heels. Customers expect you to know both the source system and SfB and that is unrealistic, and only a few people in the world will actually have detailed knowledge of both environments in order to complete end to end activities. Luckily there is a tool that starts in a long way to make your lives easier and help you understand only what you need to in order to complete your migration. Recently added to SfB IT Pro Tools, Unimax 2nd Nature MACD application can cut out months of hard labour and frustration making migrations a lot simpler.
I may do some in depth blogs around how 2nd Nature (2N) is architected and how it connects to systems etc. But for the purpose of this blog series I am going to assume that all the setup etc is complete. I will start by saying though that 2N is basically a MACD platform that can add, move, remove and change configuration records on multiple UC / VoIP / PBX solutions at the same time and in a sequence. The ability to perform MACD in an admin defined sequence is what gives it the ability to be used as a migration tool as well.
The most important thing to realize about 2N before you start is that it uses a system hierarchy in order to move / add users across systems. In other words when we are talking about user direct extensions, then the configuration must relate from Parent to Child systems. 2N uses Active Directory as its parent system. All other systems are located logically underneath the AD System. This allows 2N to look at a user in AD and automatically see their configuration across, Avaya, SfB, Exchange UM, AD and Avaya Messaging, giving a complete picture of their old and new world state.
Before you can begin to discover user’s who can migrate to SfB and before you attempt to discover the user’s inter-extension features, you must perform a discovery and remediation exercise to make sure that Avaya extensions can be matched to an AD record. Otherwise, you’re just going to be looking at a bunch of stations with no clue who they belong to. Obviously not all stations will match to an AD user e.g static office phones, common-area, meeting room etc. But these are handled differently anyway.
In order to match an Avaya extension to an AD user, 2N uses a primary key on the AD telephone number. This can be any field, not specifically telephone, but the AD field must contain the Avaya extension as found in Avaya in order to create a matched record. You set this here in the AD system parameters
Now most global businesses will have more than one Avaya CM and have extensions that will be the same in different regions but logically unique. So 2N needs a way to determine how to find a globally unique extension. What can be done is you add a custom field to 2N that you’re going to use to create a globally unique number. If a customer has a global dial plan, then you can use this method, but if not, you can create one in 2N that works inside 2N only. The scenario goes like this:
Avaya CM in London, extension range 6000-7000 & Avaya CM Boston, extension range 6000-9000. So, without doing anything, we wouldn’t be able to match a user to a unique Avaya extension because the extension ranges overlap in Boston and London. If we added another field e.g. Extension 7-digits. Now we can use transformation rules in 2N to transform the 5 digit extension into a 7 digit global unique extension into field Extension 7-digits based on the source system e.g. NYC or London Avaya.
Any extensions from Boston Avaya CM transform 6XXXX to 106XXXX, 7XXXX to 107XXXX, 8XXXX to 107XXXX, 9XXXX to 107XXXX
Any extensions from London Avaya CM transform 6XXXX to 446XXXX, 7XXXX to 447XXXX
Now that we have a unique field in Avaya, we need to do the same for Active Directory. First you need to find an AD attribute (e.g. telephoneNumber) that contains the DDI if there are no attributes that already match a GDP pattern. Once you have got the DDI you need to understand where the DDI ranges relate to an Avaya CM. For instance, in London the DDI range could be this 01782786000-01782787000. Once we have that we can now add a custom field to the AD system in 2N to transform the DDI to the 7 digit Extension like so
So essentially now we have created two records that will be identical and we can now match a User in AD to an Avaya Extension. (assumptions are that there is a level of consistency in AD of course, or that needs remediating before you begin). Let’s assume you do or this blog will be an encyclopaedia. This quick logical diagram may explain it better
OK, so now we are ready to start discovering!
2N is very powerful, so I am going to skip a lot of things, so you’ll have to just accept there will be some blanks in this. You approach the discovery from the AD system down to the source systems. i.e. You want to begin with AD users. The you want to find how many AD users have an Avaya extension. So you need to add an Avaya column to your report and then perform a filter on it to give you the data you’re after.
In each list, you can jump systems. Starting in AD, when you add columns, you’ll notice in the column list different systems e.g. primary extension. This is the user’s Avaya (or Cisco) settings
When you want to add a column that doesn’t natively belong in the top-level report you’re trying to produce, you have to jump systems and then add them in.
Bad example of a field but its only for screenshot purposes. The goal is to get AD data alongside the users Avaya data in the report, so you’ll be able to produce reports like this
Now that we can see both AD and Avaya data, we can filter this report to give us all the users who have an Avaya extension. At a very basic level you could apply something like this e.g. AD extension is equal to Extension in Avaya.
This will update the list to show all users with an Avaya extension match
Now obviously the filters are going to be more complex and unique to your scenario but whatever they are the goal is to produce two lists per site your migrating
- All the users that you know have an Avaya extension
- All the users that you’re unsure of because there is no match to an Avaya Extension
It’s the second list that you need to focus on to remediate. There will be some that you can, some that are false positives (e.g. shared numbers etc.) but you can work your environment down iteration by iteration until ultimately you get to a point where you have a list of users in a site that are potential targets for migration.
Now you have the list of users you can potentially migrate you can focus on their dependencies and configuration.
In Part 4 I will talk about this in more detail and show you how Unimax Migration Pro can help towards making this a simpler process for you.