Application Server consists of a single Windows service—Application Host (OCSAppServerMaster.exe)—and one or more instances of another Windows service—OCSAppServerHost.exe. Each instance of OCSAppServerHost.exe on a server hosts an Application Server application unique to that server. There will never be multiple instances of any particular Application Server application on a server.
In the Enterprise Edition consolidated pool topology, all Front End Servers run identical instances of each Application Server application selected at the time of Office Communications Server installation.
The Application Server applications themselves are written as .NET Framework 3.5 managed assemblies. All OCSAppServerHost.exe process instances and the OCSAppServerMaster.exe process run under the RTCComponentService account security context.
Each Application Server application leverages the following Office Communications Server 2007 R2 components:
- WMI – Each application uses the lcwmi WMI provider to
store/retrieve global and pool settings. For each Application
Server application, all instances in a pool use a common set of
settings stored in the backend RTCConfig database. Global settings
are stored in Active Directory Domain Services.
- Unified Communications Managed APIs (UCMA) 2.0 –Application
Server applications interface these APIs to access the SIP and
media stack on each front end server. Communications between the
Application Server applications and other SIP endpoints all route
through a SIP Proxy in the same pool as the application (but not
necessarily on the same physical server).
- Contact Objects/Trusted Services – Application Server
applications are SIP Application Endpoints and as such require a
SIP Address of Record (AOR) in the form of a SIP URI or Tel URI.
This is accomplished by assigning an Active Directory Domain
Services Contact object to each application and setting the
application as a Trusted Service. These assignments enable the
application to act as a SIP User Agent without having to
authenticate or register, and enables them to subscribe to the
presence of registered users and publish presence on behalf of
- Management – The Office Communications Server 2007 R2
Management Console exposes service start-up and shut-down control
of the Application Server services on a per-server basis in the
same way it provides control of the other Office Communications
Server 2007 R2 services, such as the Front End services or
Conferencing Servers. If an Application Server application requires
pool-level configuration, the Management Console can list the
application under the new
Applicationsoption under the pool’s
Propertiesmenu in Office Communications Server 2007 R2. This
will launch a new snap-in for managing that application’s pool
level settings. (In R2, only the Response Group feature requires
pool-level configuration.) The Management Console also can expose
property sheets on the Forest container as needed to configure
global properties associated with the Application Server
application. In Office Communications Server 2007 R2, Communicator
2007 R2 Attendant is the only Application Server application that
requires configuration at this level. Because all Application
Server application instances in a pool are identical, configuration
of Application Server applications on a per-server basis is
- Installation/Activation – the Application Server environment
and each Application Server application are packaged as Windows
installer (.MSI) files called from the main Office Communications
Server installation program (if one or more Application Server
applications were selected for installation). After you install it,
they are activated or deactivated in AD DS using lcscmd.exe
- Logging –Application Server applications can expose new
components to the Office Communications Server 2007 R2 Logging Tool
(OCSLogger.exe) for tracing communications with the application.
Other Key Application Server Characteristics
The Office Communications Server Application Host process does not listen on the network at all, but like the Office Communications Server Conferencing Servers, each Application Server application has a TCP port assigned to it. All servers in the pool listen on those assigned ports for each the specific Application Server application they host, and the hardware load balancer also listens on those ports and distributes inbound traffic to Application Server application instances on a server in the pool. All SIP communications with an Application Server application occurs over TLS between a SIP Proxy in its pool using the pool’s SSL certificate, even if the Application Server application instance happens to be on the same physical server as the SIP Proxy. As with other UC endpoints, media communications are direct between the client and the Application Server application instance that took the call. For example, once a call has been routed to a Conferencing Attendant instance, the audio media flows directly between it and the Mediation Server that handled the call.
Application Server applications are stateless in that they do not persist data between sessions, and each instance operates autonomously of the other instances of that application in the pool or across pools.
All Application Server instances of a particular application are equivalent across servers in pool and do not communicate with each other or another server process (unlike the Conferencing Servers, which communicate state information to the Conferencing Server Factory). Furthermore, Application Server applications do not register with the SIP Registrar and thereby do not support multiple points-of-presence. A call to an Application Server application is routed to only one Application Server instance and the other instance remain unaware of that call.
The Office Communications Server Application Host service (OCSAppServerMaster.exe) also does not monitor the state of the Application Server applications on its server, other than monitoring whether the instances are running and if it detects an unhandled exception in the application, it will restart it automatically.