To deploy a Microsoft Unified Communications Managed API 2.0 Core SDK application, configure the Microsoft Office Communications Server environment, establish trust between the application and Office Communications Server, and then create Contact records in Active Directory directory service.

Routing Types for Office Communications Server Applications

There are two types of routing for Office Communications Server applications:

User-routing, used by Microsoft Office Communicator.
Application routing, used by UCMA 2.0 Core SDK applications.

Within the category of application routing, there are two choices:

Redundant application deployment—The redundant application deployment model features hardware load balancers and multiple instances of the application. Each instance of the application is represented by a trusted service entry (TSE). When an application is deployed on a load balancer, the certificate subject must be for the address of the load balancer, not the address of the individual computers behind the load balancer.

The following illustration depicts a redundant application deployment with four application servers and a hardware load balancer. The application servers and the hardware load balancer comprise an application pool. The application servers and Active Directory share a single Contact object (labelled C0 1 in the illustration). The members of the application pool can be distinguished by their trusted service entries (TSE). TSE 1, the pool-level trusted service entry, specifies the FQDN of the hardware load balancer. TSE 2 through TSE 5 are the machine-level trusted service entries for the application servers behind the hardware load balancer. Each of these entries contains the FQDN of one of the individual application servers. Each application server in the application pool installs the same certificate, which specifies the pool FQDN in Subject Name.

The value of the ApplicationDescriptionDNproperty in the Contact object is the TSE of the hardware load balancer. From this information Office Communications Server is informed that it should route calls to the hardware load balancer when a call comes in for the Contact object. The curved links in the following illustration indicate this relationship. Not shown in the same illustration are links between each application server TSE and the TSE for the hardware load balancer. The TlsTargetproperty for the TSE of each application server contains the FQDN of the hardware load balancer. The ApplicationDescriptionDNproperty in the Contact object and the TlsTargetproperty in each TSE make it possible for an application to discover all of the routing information, given the values of the Fqdnand Typeproperties.
Nonredundant application deployment—The nonredundant application deployment model is used when there is only a single instance of the application.

The following illustration depicts a nonredundant application deployment. As is also the case for redundant application deployment, the ApplicationDescriptionDN property on the Contact object contains the TSE for the application server.

Load Balancing

When running applications on Office Communications Server, authors may choose to use either Enterprise Edition or Standard Edition. With Enterprise Edition there may be more than one Front End Server. If more than one Front End Server is used, the application's outbound connections should be load balanced across the Front End Servers using a hardware load balancer. Standard Edition uses a single Front End Server, so load balancing is not required.

A hardware load balancer is not required for SIP-only scenarios (instant messaging and presence subscription and publishing), nor is one required for deployments that have only one Edge server. However, for voice deployments that require AVEdge server failover, a hardware load balancer is required.

Activating the Application

To activate an application, create TSEs for all application servers and for the load balancer in the application pool. An application Contact object for each publicly-routable entity must be created and tied to the application pool.

To communicate over a Mutual Transport Layer Security (MTLS) connection, Office Communications Server and the application server must have a valid certificate signed by a mutually-trusted certification authority. As an additional security measure, Office Communications Server also refers to a Trusted Service Entry (TSE) for the application. A TSE is a record stored in Active Directory that indicates which servers are trusted by the domain.

Create an Application Pool

Create an application pool to establish communications at the connections level.

Note:
To make changes in Active Directory, you must have the appropriate permissions. For more information, see Required Active Directory Permissions.

To create an application pool

In Active Directory, for each application type, activate one trusted service entry for each instance of the application. In the preceding illustration for redundant application deployment, the trusted service entries are labelled TSE 2 through TSE 5.
In Active Directory, activate one trusted service entry for the hardware load balancer used as the entry point to the application pool (TSE 1 in the preceding illustration).
Manually provision the hardware load balancer to map the application instance’s resource template to the hardware load-balancer connection tuple corresponding to this application pool.

Creating Trusted Service Entries

To create TSEs, use the WMI class cimv2\MSFT_SIPTrustedAddInServiceSetting. Required properties are listed in the following table.

Property name	Comment
Type	Identifier for the application.
FQDN	Fully qualified domain name (FQDN) of the system receiving SIP traffic for the application. If the TSE is associated with the hardware load balancer, this property is the FQDN of the load balancer. If the TSE is associated with one of the application servers behind a hardware load balancer, this property is the FQDN of the application server.
TlsTarget	For the TSE of a hardware load balancer or for the TSE of an application server in a nonredundant deployment, this property is null. In these cases, the certificate used by the application should have its subject set to the TSE’s FQDNproperty For the TSE of an application server in a redundant deployment, this property contains the FQDN of the hardware load balancer. In this case, the certificate used by the application should have its subject set to the value in the TlsTargetproperty, the FQDN of the hardware load balancer.
Port	The network port the application listens on. The valid range for port numbers is 1 to 65535.
Routeable	Set to TRUE.
RoutingPoolFqdn	The FQDN of the OCS pool on which this application pool is homed. This property gets its value from an instance of the Msft_PoolSetting class.
Version	Must be set to 4.

The following properties of the TSE are automatically created: InstanceID, GRUU, and TrustedServiceDN.

Trusted service entries can also be created by using the ApplicationProvisioner sample provided with this SDK. For more information, see Using ApplicationProvisioner.

Adding Certificates

When an application is deployed behind a hardware load balancer, the certificate subject must be for the address of the load balancer, not the address of an individual computer behind the load balancer. Office Communications Server passes any calls to the application to the hardware load balancer, which distributes the calls to individual application servers.

Create a certificate for the application computer that will be trusted by Office Communications Server, and then import that certificate to the application host computer. This certificate must be installed in the Console Root\Certificates(Local Computer)\Personal\Certificates folder.
Get the root certificate and install this certificate in the Console Root\Certificates(Local Computer)\Trusted Root Certification Authorities\Certificates folder.

Ensure that the account used for the application has read access to the certificate store and the private key.

Adding Contact Objects

After a TSE is created, create a Contact object to provide routing to the application. To create a Contact object, use the WMI class cimv2\MSFT_SIPApplicationContactSetting.

Note:
After the Contact object is created there is a delay of about ten minutes before the Contact object replicates from Active Directory domain services to the server.

Required properties are listed in the following table.

Property name	Comment
ApplicationDestinationDN	The value of the associated Trusted Service Entry (TSE). For a redundant deployment, set this property to the TSE of the hardware load balancer. For a nonredundant deployment, set this property to the TSE of the application server.
PrimaryURI	The SIP URI of the Contact object; for example, “sip:bob@contoso.com”.
DisplayName	The name under which the contact will appear in the address book.
DisplayNumber	The telephone number that will appear in the address book.
Enabled	A Boolean value that indicates whether the object is SIP-enabled. Set this to TRUE.
EnabledForEnhancedPresence	A Boolean value that indicates whether the object is enabled for enhanced presence. Set this to TRUE.
EnabledForFederation	A Boolean value that indicates whether the object is enabled for federation. Set this to TRUE or FALSE, depending on the application and function performed.
HomeServerDN	The Distinguished name of the Active Directory object representing the pool that created the Contact object. The value is available in MSFT_SIPPoolSetting.PoolDN. An instance of MSFT_SIPPoolSetting is available for each pool configured in the enterprise. Pick the pool that is most applicable.
LineURI	The phone number of the Contact object. Set this to tel:< phone number>. This value can be set to NULL.
UCEnabled	A Boolean value that indicates whether the object is enabled forUnified Communications.

The following properties of the Contact object are automatically created: ContactDNand InstanceID.

The following properties of the Contact object are not used, and are set to NULL: LocationProfileand MeetingPolicy.

Provisioning the Application

To provision the application in Office Communications Server, first configure authorization, set permissions, and then configure authentication.

To configure authorization, activating the TSE will populate and update the appropriate authorization in Office Communications Server.
UCMA 2.0 Core SDK applications require the following permissions: registry read access, permission to execute unmanaged code, and file write access if tracing is enabled. Also, application user accounts must be members of the RTCService domain security group.
To configure authentication, create certificates on Office Communications Server Standard Edition or the Front End Server of an Enterprise pool, and on the application computer.