One of the great new features of Mitel MCD 5.0 alongside the range of hospitality features is the changes to the licencing, full details are below.

Product Overview / Features & Benefits / Description

Licence Manager is the name given to the new Licensing capability embedded into Mitel Communications Director in Release 5.0. All instances of MCD will include Licence Manager as the controlling mechanism for the licensing enhancements.

The MCD instances that will support Licence Manager following the release of MCD 5.0 will include:

• 3300 Controllers
• 3300 MXe Server
• Industry Standard Servers (ISS)
• Virtual MCD
• Multi Instance Communications Director (MiCD)

Licence Manager will have overall control of licensing on MCD and introduces several new capabilities that will deliver benefits to both our Solution Provider’s and to our end customers.

The new capabilities incorporated into all MCD systems are as follows:

Try Before You Buy

• Trusted Services
• Over Allocation
• Licence Violation management

These new capabilities are discussed in detail later in this document.

An additional Licence Manager capability for MCD Enterprise systems is available following the availability of MCD 5.0 and it is also discussed later in this document:

Enterprise Licensing

MCD Try Before You Buy

Licence Manager introduces a new Try before you Buy capability to all the MCD licence options that have not previously been enabled or configured.

The new Try Before You Buy capability will allow a customer to Try any licence, that they have not purchased or had activated at any time on the system, for a period of 60 days.

What this means is that if a customer has never allocated, for instance, External Hotdesking, then they can do so without any cumbersome administration process. They simply allocate the Try Before You Buy and configure External Hotdesking in MCD – the Try Before You Buy clock then starts running. Once the clock is started it cannot be stopped, so if the customer configures 10 x Users with External Hotdesking for 30 days, and then decides to allow another 5 Users to try it, then the second group of Users will only have 30 days to Try External Hotdesking, not 60 days.

All configurable MCD licences have separate Try Before you Buy clocks. So running an External Hotdesking Try Before You Buy trial doesn’t stop the customer running a separate ACD trial over a different 60 days.

This new Try Before You Buy capability will deliver great flexibility to our Solution Provider’s and customers and save a great deal of money in reduced back office processes. By allowing customers to try a number of licences for 60 days without having to raise Purchase Orders, or creating a process for returning the licences after the trial, this new capability greatly simplifies the process for customers to try MCD capabilities and prove their usefulness and value within their business – all with the view to leading to increased uptake of MCD features and functionality.

Try before you buy fine print:

• Once the Try Before You Buy period has ended the system will fall into Licence Violation until the licences are either purchased or deconfigured. In effect once the TBYB period has ended the Over allocation process takes over.
• Once a type of licence has been configured, it cannot be used as a Try Before You Buy licence again.
• The limitation of licences that can be activated in a TBYB trial is set on a per licence basis. Most licences will allow 20 TBYB licences with the following exceptions:
  • System Type – This cannot be changed except at the AMC
  • Voicemail Hospitality – This is a system wide licence which is either on or off
  • Digital Link Licence – 2 licences
  • SIP Trunk licence – 5 licences
  • G729 Compression licences – 8 licences
  • T38 FAX over IP – 8 licences
  • MLPP – 0 licence
  • IDS – 1 licence
• Setting up a trial with more licences than allowed in TBYB will push the system into Licence Violation.

MCD Trusted Services

With the introduction of MCD 5.0 we will introduce a new Trusted Service that allows connections to Mitel applications to be created on MCD without consuming MCD licences. Simply put, once the application has been purchased there will be NO licence requirements for the MCD system. The Application’s and MCD will verify that the Trusted Application is valid via an encrypted handshaking method.  In the first version of MCD 5.0 we will support Trusted Services for applications that utilise MiNET interaction, like NuPoint and Intelligent Queue. In a future MCD release we will support Trusted Services for applications that utilise SIP lineside interaction, like AWC.

The new Trusted Services will greatly simplify the packaging, selling and implementation of Application’s onto a MCD system. The applications also need to support the Trusted Service model so further announcements will be made from the Application teams.

From the configuration perspective on MCD the administrator simply needs to configure the connection ports as a Trusted Service. No complex configuration is required.

Trusted Applications Fine Print:

• Whilst the Trusted Service connections will not require licenses to be transacted, the resources they use will form part of any system engineering calculation.
• After the introduction of Trusted Services into MCD, the individual applications will also need to be updated to support the trusted service construct.

MCD Over Allocation

One of the consequences of a strict licensing model is that it removes all flexibility for customers and Solution Provider’s to react to events in a speedy and timely manner. Licence Manager’s new Over Allocation will mitigate this problem give our customers a great deal of flexibility while managing their communications system.

Over Allocation will in effect allow the customer to over allocate their system, for a short period, in relation to the number of licences purchased. This will allow the customer or Solution Provider to expand the system, even if they do not have sufficient licences, saving expensive wasted site visits and ensuring the User or device is available and working on the system as quickly as possible. The customer simply purchases the licence, or de-configures the over allocated licenses after the event, to remove the Licence Violation process that will have begun.

The Over Allocation process will be useful in many administration scenarios that currently cause customers and Solution Provider’s logistical headaches, for instance:

• Moving T1/E1 links to a different node that is not licensed – Currently the customer would have to either completely deconfigure the existing PSTN connection, meaning a temporary end to service, or purchase a new Digital Link licence that would not be required after the link move.

• Adding new Users when no User licences available – Currently the User can not be provisioned until after the licence was purchased and activated on the system. This regularly causes site visits to install new handsets to be abandoned.

• Moving SIP Trunk links – Currently the customer would have to either completely deconfigure the existing SIP Trunks, meaning a temporary end to service, or purchase new SIP trunk licences that would not be required after the move.

• Exceeding core package limitations – Certain core packages that are originally purchased include limitations on the number of licences that can be attached to them. For instance, the Survivable Branch Office Gateway or the 3300 MXe Media Gateway do not allow Enterprise User licences to be added to them.

• In certain scenarios the customer may need to add local Users to those systems in a hurry and not want to wait for the upgrade purchasing process to complete.

Licences that cannot be Over Allocated

Due to the concurrent nature of several MCD licences, the following licences cannot be Over Allocated.

• Active ACD Agents

Should a scenario occur where the licence is Over Allocated then the Licence violation will jump straight to Major licence violation. See below for details.

MCD Licence Violation

Licence Manager violation is the process that controls all the new capabilities and features delivered within MCD Licence Manager.

The MCD system or network (see Enterprise licensing) can be placed into licence violation for numerous reasons, these include;

• Over Allocation
• System ID mismatch
• End of Try Before you Buy
• Exceeding Core Package limitations

The easiest resolution to any Licence Violation is to resolve the cause that has forced the system into licence violation. For instance, if the system is over allocated, then purchasing more licences would resolve the licence violation as would de-configuring the correct number of Over allocated services.

Licence Violation process

If the licence violation is not dealt with the following process begins:

The initial Licence violation state is a warning state. While in warning state the system will display the Licence Violation status on the Embedded System Management page.

Day 2 of the licence violation will see the system move to a Minor Licence Violation. While in Minor violation the MCD system will raise a Minor Alarm, the licence violation status on the Embedded System Management will change and each time a user logs into the system they will see a pop up message informing them they are in licence violation.

Day 8 of the licence violation process will see the system move into a Major licence violation. While in Major licence violation the MCD system will raise a Major Alarm, the licence violation status on ESM will change. Any time an administrator opens a form in ESM they will receive a pop up message informing them they are in licence violation and they will be forced to accept the warning before continuing.

Day 14 of the licence violation process will see the system move into a critical licence violation. While in critical violation the MCD system will raise a critical alarm. IP and Digital display sets will all display Licence violation on their screens.

At the different levels of licence violation the messages displayed to the administrator highlight the growing importance that the situation needs to be resolved.

Day 35 of the licence violation –  AND if the System is Over Allocated by more than 5%, OR if it is a Virtual MCD system that has lost connectivity with the AMC – then the system will move into system lock licence violation. The Desktop tool will be disabled for all Users, Normal phones and users will move into the Restricted Service state (as per an unlicensed phone) which does allow the ability to call the Operator console and Emergency services.  Operator Consoles are unaffected by System lock and all incoming calls can be answered.

Niote: Theeaffects of the licence violation process are cumulative Please also note that MCD customers must be Over Allocated by more than 5% of total licenses before they can move into the system lock state. The system cannot automatically over allocate licenses itself. It is an active administration process to over allocate licenses that must be carried out by a System Administrator.

MCD email of system alarms

Since MCD 4.1, all MCD systems have had the Remote Management licence enabled. This licence allows the administrator to configure and email up to 10 recipients each time there is an Alarm condition on the system. It is highly recommended that this capability is used for all systems so that Licence Violations can be notified to the correct people in a timely manner. They can then resolve the Licence Violation.

AMC notification of licence violation

When a system is in License Violation and connects to the AMC, the system will inform the AMC of the current License Violation. It is our intention to deliver an update to the AMC that will cause an email to be sent to the Solution Provider AMC administrator informing them that one of their customers is in License Violation. The AMC administrator will receive an email each time the License violation of a particular Application Record changes. We highly recommend that our Solution Providers ensure the AMC accounts and email notification addresses are configured correctly.

Please note that as there are valid scenarios where MCD systems will not be in regular contact with the AMC, Mitel cannot guarantee our Solution Providers will receive AMC notifications of License Violations.

Coming out of licence Violation

After a system has had the licence violation removed, Licence Manager begins a countdown clock before completely removing the Licence Violation history. The countdown clock is based on type of violation and is double the amount of time that the system was in licence violation for. Should the system revert back into licence violation before the countdown clock has expired the licence violation will resume at the same place that it previously ended, rather than starting again.

For instance, System A is in Licence Violation due to Over Allocation for 10 days. The Over Allocation violation is removed for 5 days, before Over Allocation happens again. In this scenario the licence violation clock will start at 10 days not 0.

Base Package Limitations

The Base package limitations that were previously only actively controlled at the AMC are now also managed inside MCD. This means if a customer purchased a Survivable Branch Office Gateway, which does not allow Enterprise User Licenses, and the customer allocated 2 x User Licenses onto it, then the solution will move into License Violation.

MCD Off-Line Licensing

Following the introduction of the AMC as Mitel’s licensing solution in 2004, it has been possible for technicians to automatically License an MCD system across the internet. For MCD systems that did not have Internet access there was a secondary, off-line licensing model. This off-line licensing model allowed Solution Providers to receive printed MCD License information, including the License password for the relevant system they were installing or maintaining. The technician then typed the License key into the system.

There were various limitations with this manual off-line License process and hence in MCD 5.0 the off-line licensing model will change.

From MCD 5.0 there will be no more manual entering of License keys into MCD. Systems that are not connected directly to the Internet can still be Licensed but the process will mirror that of the other Mitel Applications that are Licensed from the AMC. Specifically, the technician will need to connect to the AMC to create an encrypted License file (note this does not need to be done from the customer’s site where Internet access may be limited). This encrypted file is then copied onto the MCD instance to License or re-License the system.

By changing the MCD off-line licensing model we will allow all MCD systems to take advantage of the new licensing capabilities.

While this is a small change, and is consistent with many other Mitel applications, technicians will need to be made aware of this revised process.

MCD Enterprise Licensing

Mitel Enterprise Licensing (License Sharing) is an additional License Manager capability that is available for MCD Enterprise Systems.

Enterprise Licensing allows a customer to easily move Licenses around their solution with no interference from Mitel, the Solution Provider, or our AMC. By activating Enterprise Licensing the customer is setting his MCD licensing up to work as a single solution rather than a group of individually Licensed nodes.

There are many advantages to licensing a group as a single entity including License flexibility, ease of administration and lowering the cost of ownership.

MCD 5.0 Licensing Model

With the introduction of MCD 5.0 there are three different types of License management that can be used for MCD systems:

• Standalone Systems

Standalone Systems are Licensed as today with a single Application Record for each system. MCD License Manager controls all the licensing on the individual system.

• Non-Shared Enterprise Systems

Enterprise Systems that are Licensed with individual Application Records and cannot share Licenses. This licensing model is how all existing Enterprise systems that have upgraded to MCD 5.0 will appear. Every system is linked to its own Application Record and each system is controlled by the individual License Manager. In effect this is how Enterprise Systems are Licensed currently (4.2 and below).

Enterprise customers who do not wish to invoke Enterprise Licensing can happily continue to License their systems individually.

• Shared Enterprise Systems

The new MCD 5.0 Enterprise licensing model. Enterprise licensing allows groups of MCD systems to be amalgamated into a single Application Group at the AMC. The customer chooses a single system within the group of systems to act as the Designated License Manager (DLM), which connects to the AMC Application Group. All the underlying systems licensing is controlled by the DLM.

AMC Application Group

The first place to begin is to explain the new Application Group construct in the AMC.

An Application Group is created through the activation of an “Enterprise License Group” License, part number 54005330, on the AMC. This part number will be a chargeable License and creates a Designated License Manager on the AMC – shown below.

A single Enterprise License will be delivered with each new purchase of Enterprise Manager, following the release of Enterprise Manager 7.0. Existing customers and those upgrading to Enterprise Manager 7.0 will need to purchase the “Enterprise License Group” part number.

Once an Application Group (License Server) is created the Solution Provider can add the customer’s individual Application Records into the Group for the systems that are going to share Licenses.

Once the Application Records are added to the Group, all the Licenses from the individual Application Records are transferred to the Group and can not be removed from the Group.

Note: Once an Application Record has been added to an Application Group it cannot be removed by the Solution Provider and none of the Licenses that have been transferred to the Group can be returned. Please be very sure that you are putting the correct Application Records into an Application Group.

For instance, if an Application Group is created and two Application Records each with 100 x Enterprise User Licenses are added to the Group, then the 100 x Enterprise User Licenses will be moved out of the individual Application records and into the Application Group. The Application Group will then show 200 x Enterprise User Licenses as available for the customer solution.

The entire Application Group Licenses are shown on the Designated License Manager Application Group Record.

Please note that only Enterprise MCD systems that have been upgraded to MCD 5.0 can be added to the Application group.

Designated License Manager

To collect all the information from the Application Group on the AMC, the customer (or Solution Provider) chooses one of the MCD systems in the network (the MCD system must be one of the systems in the Application Group) to be the Designated License Manager (DLM).

The DLM connects to the AMC, and the relevant Application Group, and collects all the licensing information for the entire Application Group. This information includes all the Licenses and the underlying MCD system information.

Once the chosen DLM system has initially connected to the Application Group and registered as the DLM, an SDS synchronization from the DLM is carried out. Enterprise Licensing is then configured and running. Information sent between the individual MCD systems and the AMC will only be very basic information about its own software release and Core package limitations from the AMC.

Once the systems have registered with the DLM, Licenses can be freely allocated and moved around the group without changing anything at the AMC. All the systems within the Application Group will contact the DLM every 60 minutes to ensure the License integrity of the solution. If this License communication fails three times in succession the solution will fall into License Violation.

In pre-MCD 5.0 licensing each system had its own Application Record with all the Licenses available for that individual system only available to the individual system.

In MCD 5.0 the individual Applications Records are consumed into a single Application Group. All the Licenses are moved to the top level Application Group. All the individual Application Records maintain are the Base package limitations and the Software level the individual system is running. All the solution Licenses are now available to any of the underlying systems within the Application Group.

Application Group and Enterprise Licensing small print:

• Licenses included in the core software packages can be moved by the customer (without interaction with the AMC) to other systems following the implementation of Enterprise licensing.
• A single customer can have multiple Application Groups in a single Cluster. They can group their licensing requirements however they want.
• Each Application Group has a single DLM and each DLM has to be in regular contact with all the systems allocated into their Application Group.
• An Application Record can only ever belong to one Application Group at one time.
• Once the Application Record is added to the Application Group, all the underlying Licenses are permanently moved to the Group.
• Licenses cannot be shared or moved between different Application Groups.
• Only Mitel can move an Application Record once it has been allocated into an Application Group. And we will only move it to the same customer. Application Records cannot be passed between different customers.
• Should customers deactivate certain systems within an Application Group, Mitel will deactivate the Application Record and it will be permanently retired. The licenses included in the Core package will be removed from the Group.
• Should customers want to change an existing hardware unit that is running as the Designated License Manager with a new hardware unit or 3300 Controller then this scenario is completely supported. The Solution Provider simply resets the Hardware ID of the Application Group Record in the AMC and the resync’s the solution.
• Try Before You Buy limitations are valid across the whole Application Group when using Enterprise Licensing.
• Over Allocation rules are valid across the whole Application Group when using Enterprise Licensing.
• Only systems running MCD 5.0 can be added to an Application Group.
• The DLM must be able to communicate with all the underlying systems in the Application Group via System Data Synchronization.
• The 3300 MXe Server and Virtual MCD cannot be the Designated License Manager (DLM).
• Customers with a mix of old MCD 4.0 Base packages or older and new MCD 4.1 or above Enterprise Base packages can integrate all the systems together. The licenses can then be allocated to any underlying system in the Enterprise Licensing solution.
• Only Enterprise Systems can be added to the Application Group, and hence support Enterprise Licensing.
• The system that is the DLM can be changed by resetting the Hardware ID of the Application Group at the AMC and connecting a different system to the Designated License Server.
• Once an Application Record has been moved into an Application Group all the Licenses are moved to the Group. They cannot be moved out of the group back to the individual Application Record.
• Existing customers upgrading to MCD 5.0 should be confident and sure that they have no intention of downgrading their systems before implementing Enterprise licensing. Systems being downgraded would need to be moved out of the Application Group by Mitel and they would be moved with NO Licenses.
• If an Application Record is moved out of an Application Group the only Licenses that go with the Record are those Licenses embedded in the original base package. All other Licenses that may have been attached to the individual Application record over time will stay with the Application Group.
• License Violation affects the entire Application Group when using Enterprise Licensing
• Only systems belonging to the same end customers can be integrated to Enterprise Licensing. Systems being used by different end customers cannot share licences
• Customers upgrading to Enterprise licensing need to be aware of the process of creating the Application Group and the process that needs to be followed to ensure all the SWA expiry dates are in synchronization. See below for more details.

License Violation

The License Violation for Enterprise licensing is the same as for individual systems except that the License Violation process affects the entire group of systems that are Licensed together. This means any effects are felt across all the systems.

There are also certain other Enterprise scenarios that will place the group into License Violation:

• DLM cannot communicate with a Licensed system within the group
• A non-DLM system that is part of Enterprise Licensing cannot communicate to its DLM

Upgrading to Enterprise Licensing

Existing Enterprise customers will be able to upgrade to Enterprise licensing. This is true for customers who purchased their systems with the old MCD 4.0 base packages and new MCD 4.1 base packages.

All the customer systems that are being incorporated into Enterprise licensing must be upgraded to MCD 5.0 before being added into the Application Group.

Customers upgrading to Enterprise licensing with older MCD 4.0 have some additional benefits:

• Existing License restrictions on User Licenses and SIP User Licenses will be removed.

This means, for instance, customers who have two 64 device packages will be able to move more than 64 old MCD 4.0 Licenses onto a single system following the upgrade to MCD 5.0 and Enterprise Licensing.

The Analog License restriction will remain on those systems.

Moving Application Records between Different Customers in the AMC

This Bulletin announces that the current AMC capability that allows Application records to be moved between different customers will be closed on May 1, 2012. This is to stop people reassigning licenses between different customers.

For Solution Providers who have a legitimate requirement to move an Application Record to a different customer group, they will be able to request that Mitel moves the record for them. The process for Mitel moving the Application Record to a different customer will be the same process as the existing process that allows Application Records to be moved between different Solution Providers.  Requests to move

We will continue to allow licenses to be reassigned inside the AMC between systems that belong to the same customer.

Software Assurance

Software Assurance (SWA) will not be extended to the specific Enterprise Licensing capability. However with the consolidation of all the MCD systems into a single Application Group for Enterprise Licensing solutions, we will update SWA to work for the entire Group of systems rather than on an individual basis.

Software Assurance will be purchased / renewed for the entire group rather than on a per-node basis. This will ensure that customers who choose distributed networks do not get penalized with the per-user graduated pricing of SWA and solutions with many distributed Users will be able to utilize the per User pricing advantages of larger solutions.

The SWA expiry date on the Application Group will initially be set to 90 days after the Application group is created in the AMC.

As the Application Group is created and the individual systems are added to the Application Group, ALL the Software Assurance expiry dates MUST be consolidated before the Group is created OR the individual Application Record must have ZERO extra licenses added to the record. If the individual Application Record does not have any additional licenses on it then it can be added to the Application group and the SWA expiry date will automatically change to match that of the Application group.

If the SWA expiry dates are within 30 days of each other, the Solution Provider AMC Administrator will be asked if they wish to complete the move of the Application record into the Application Group. By agreeing to this question, the SWA expiry date of the individual system will change to the same as the Application group.

What this means is:

• For Application Groups that are created with existing Application Records that already have Software Assurance with different expiry dates, the expiry dates between the Application Group and individual Application Records must be made the same. This means the SWA expiry date of all the Application Records being placed into the Application Group must be the same as the SWA expiry date of the Application Group.

This can be carried out using the existing AMC Software Assurance quoting mechanism.

• For new Solutions using Enterprise Licensing, as long as the Individual Base Application Records do not have any further licenses added to them, they can be added to the Application Group without changing the SWA expiry date and they will take on the SWA expiry date of the Application Group

For new Solutions that will utilize Enterprise Licensing we would recommend that ALL additional licenses are added to the Application Group and not to individual Application Records. As soon as the individual App Records are moved into the Group, all the licenses are moved anyway, but leaving those App records empty simplifies the creation of the Application Group as you do not need to change the SWA expiry dates.

Virtual MCD Systems

Virtual MCD systems can be activated as Standalone or Enterprise Systems following the release of MCD 5.0. All Standalone or Enterprise Systems acting in a non-shared environment MUST be able to contact the AMC at all times. In this scenario the Virtual MCD system will regularly contact the AMC (several times per day) to ensure there are no cloned instances of the MCD Licenses being used. Should the connection between the Virtual MCD and AMC not be available for a defined period of time then the Virtual MCD will begin the License Violation process.

For Virtual MCD systems working in a shared Enterprise solution, the Virtual MCD acts the same as any other MCD system, except that the Virtual MCD system CANNOT be the Designated License Manager (DLM). When a vMCD system is incorporated into an Application Group it does not need to contact the AMC regularly. The DLM ensures that there is no vMCD cloning taking place.

Other MCD Licensing Changes

MCD Active Directory Integration

In MCD 5.0 we will introduce an embedded Active Directory integration. Each MCD system that is connected to Microsoft Active Directory requires an IDS license.

Further details on this integration are included in the MCD 5.0 Administration Product Bulletin.

Multi Device User License

In MCD 5.0 we will introduce a new Enterprise and Standard Multi-device User License that allows Multi-device User Groups to be created without licensing the individual Users/devices in the group. Further details in the MCD 5.0 Administration Product Bulletin.

Multi-device Suite License

In MCD 5.0 we will introduce a new Hospitality Multi-device Suite License that allows MCD Suites to be created without licensing the individual devices in the Suite. Further details in the MCD 5.0 Hospitality Product Bulletin.

Resilient ACD Licenses

In previous versions of MCD, ACD resilience required an ACD License on both the Primary and Secondary Controllers.

In MCD 5.0, we will remove the requirement for any License requirements on the Secondary Controller for the resilient ACD agent.

In MCD / 3300 Controller variants before MCD 4.1 this was typically accomplished by purchasing the following License:

• ACD Resilient License

In MCD 4.1, when an Enterprise System was purchased the customer needed to purchase the MCD Enterprise Active Agent License for ACD functionality. When the Enterprise Active Agent License was purchased, the following License was made available for the customer’s Secondary Controller:

• MCD Resilient Active Agent License