ࡱ > T ^ q i Z bjbj ʌ l >f >f >f >f >f >f >f 4 rf 0 0 0 h 1 T h2 < rf _N @ 9
G : G G G H 8% m v RM TM TM TM TM TM TM S U TM E >f { H H { { TM 7} >f >f G G M P 7} 7} 7} { >f G >f G RM 7} { RM 7} 7} / >f >f $ G 9 Frf : 0 | B % L( M v _N
$ CW | CW $ 7} rf rf >f >f >f >f Live Communications Server 2005 with SP1 Reference Guide
August 2005
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.
2005 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
TOC \o "1-3" \h \z \u HYPERLINK \l "_Toc111622842" Introduction PAGEREF _Toc111622842 \h 3
HYPERLINK \l "_Toc111622843" Active Directory Schema Extensions PAGEREF _Toc111622843 \h 3
HYPERLINK \l "_Toc111622844" Active Directory Classes PAGEREF _Toc111622844 \h 3
HYPERLINK \l "_Toc111622845" Active Directory Attributes PAGEREF _Toc111622845 \h 3
HYPERLINK \l "_Toc111622846" Descriptions of New Attributes PAGEREF _Toc111622846 \h 3
HYPERLINK \l "_Toc111622847" Cleaning up the Live Communications Server 2003 Schema PAGEREF _Toc111622847 \h 3
HYPERLINK \l "_Toc111622848" Permissions PAGEREF _Toc111622848 \h 3
HYPERLINK \l "_Toc111622849" Active Directory Permissions PAGEREF _Toc111622849 \h 3
HYPERLINK \l "_Toc111622850" Active Directory Permissions for the Forest Root Domain PAGEREF _Toc111622850 \h 3
HYPERLINK \l "_Toc111622851" Active Directory Permissions for Any Live Communications Server Domain PAGEREF _Toc111622851 \h 3
HYPERLINK \l "_Toc111622852" Optional Active Directory Permissions for an OU Container PAGEREF _Toc111622852 \h 3
HYPERLINK \l "_Toc111622853" Local Permissions (Access Proxy, Standard Edition Server, Enterprise Edition Server) PAGEREF _Toc111622853 \h 3
HYPERLINK \l "_Toc111622854" Database Permissions for an Enterprise Pool or Standard Edition Server PAGEREF _Toc111622854 \h 3
HYPERLINK \l "_Toc111622855" Permissions for an Archiving Scenario PAGEREF _Toc111622855 \h 3
HYPERLINK \l "_Toc111622856" Archiving Back-End Database Structure and Schema PAGEREF _Toc111622856 \h 3
HYPERLINK \l "_Toc111622857" Flat File Logging PAGEREF _Toc111622857 \h 3
HYPERLINK \l "_Toc111622858" Flat File Logging Events PAGEREF _Toc111622858 \h 3
HYPERLINK \l "_Toc111622859" Flat File Logging Format PAGEREF _Toc111622859 \h 3
HYPERLINK \l "_Toc111622860" Structure of the File Content Definition PAGEREF _Toc111622860 \h 3
HYPERLINK \l "_Toc111622861" Structure of the Log Data PAGEREF _Toc111622861 \h 3
HYPERLINK \l "_Toc111622862" Log Categories PAGEREF _Toc111622862 \h 3
HYPERLINK \l "_Toc111622863" Configuring Flat File Logging PAGEREF _Toc111622863 \h 3
HYPERLINK \l "_Toc111622864" Registry Key PAGEREF _Toc111622864 \h 3
HYPERLINK \l "_Toc111622865" Messenger Policies PAGEREF _Toc111622865 \h 3
HYPERLINK \l "_Toc111622866" Registry Keys PAGEREF _Toc111622866 \h 3
HYPERLINK \l "_Toc111622867" Messenger Policy Keys PAGEREF _Toc111622867 \h 3
HYPERLINK \l "_Toc111622868" Proxy Keys PAGEREF _Toc111622868 \h 3
HYPERLINK \l "_Toc111622869" The New BENOTIFY Request PAGEREF _Toc111622869 \h 3
HYPERLINK \l "_Toc111622870" Supporting BENOTIFY PAGEREF _Toc111622870 \h 3
HYPERLINK \l "_Toc111622871" SIP Traffic Flow Through an Enterprise Pool PAGEREF _Toc111622871 \h 3
HYPERLINK \l "_Toc111622872" Adding, Removing, and Modifying Performance Counters PAGEREF _Toc111622872 \h 3
HYPERLINK \l "_Toc111622873" Maintaining the Live Communication Server 2005 Back-End Database PAGEREF _Toc111622873 \h 3
HYPERLINK \l "_Toc111622874" User Replicator PAGEREF _Toc111622874 \h 3
HYPERLINK \l "_Toc111622875" Configuring User Replicator PAGEREF _Toc111622875 \h 3
HYPERLINK \l "_Toc111622876" Configuring Domains for User Replicator PAGEREF _Toc111622876 \h 3
Introduction
Welcome to the Microsoft Office Live Communications Server 2005 Reference Guide. This document provides background and reference material for administrators who are deploying or have deployed Live Communications Server 2005. The information contained herein supplements and is to be used in conjunction with the following documentation, which can be found at:
Live Communications Server 2005 Planning Guide
Live Communications Server 2005 Deployment Overview
Live Communications server 2005 Enterprise Edition Deployment Guide
Live Communications Server 2005 Standard Edition Deployment Guide
Live Communications Server 2005 Deploying Access Proxy and Director
Live Communications Server 2005 Proxy Deployment Guide
Live Communications Server 2005 Deploying Archiving
Live Communications Server 2005 Deploying a SIP/PSTN Gateway
Live Communications Server 2005 Applications Deployment Guide
Live Communications server 2005 Active Directory Preparation
Live Communications Server 2005 Security Guide
Live Communications Server 2005 Configuring Certificates
Live Communications Server 2003 Upgrading and Coexistence
Live Communications Server 2005 Technical Overview
Live Communications Serve 2005 Online Help
The Live Communications Server 2005 Reference Guide contains information about:
Microsoft Active Directory directory service schema extensions for Live Communications Server 2005.
Using and configuring flat-file logging of SIP traffic.
The structure and schema of the archiving back-end database.
Maintaining the Live Communications Server 2005 Back-End database.
Client Group Policies.
The new BENOTIFY request.
Proxy Registration keys supported by Live Communications Server 2005.
SIP traffic flow through an Enterprise Edition Pool.
Additional sources of information.
Active Directory Schema Extensions
The schema for the MicrosoftActive Directory directory service contains formal definitions of every object class that can be created in an Active Directory forest. The schema also contains formal definitions of every attribute that can exist on an Active Directory object. The Active Directory global catalog contains replicas of all the objects for the forest, along with a subset of the attributes for each object.
Microsoft Office Live Communications Server 2003 added new attributes and objects to the Active Directory schema. The changes included:
Adding attributes, most of which are static, to the user and contact objects, such as SIP (Session Initiation Protocol ) address and home server. Some of these attributes are marked for global catalog replication.
Creating a new Microsoft container under both the System and Computer containers. The Microsoft containers are the new standard locations for all Microsoft settings.
Creating a new RTC Service object under the System\Microsoft object and a new Global Settings object under the RTC Service Object. The Global Settings object holds all settings that apply throughout the Live Communications Server 2003 deployment. The RTC Service Object holds the Global Settings object, along with the msRTCSIP domain objects.
Note
These new containers should be managed only through the Microsoft Windows Management Interface (WMI). Direct editing or management is unsupported and can produce undesirable results.
Live Communications Server 2003 added five new classes and 34 new attributes. Live Communications Server 2005 further extends the Active Directory schema by adding seven new classes and 18 new attributes.
Active Directory Classes
Live Communications Server 2005 adds five standard and two auxiliary classes to the Active Directory schema. Both standard and auxiliary classes can contain attributes. Unlike standard classes, auxiliary classes cannot be instantiated as objects. They serve as a convenient way to group related attributes. Figure 1 shows the new classes introduced by Live Communications Server 2005.
The names of all Live Communications Server classes and attributes begin with msRTCSIP-.
EMBED Visio.Drawing.11
Figure SEQ Figure \* ARABIC 1 Active Directory classes specific to Live Communications Server 2005
Figure 2 depicts the relationships among the classes shown in Figure 1. Arrows on the thicker lines indicate the direction of the relationship. The text interrupting each arrow lists the attribute that defines the nature of the relationship. For example, a SIP-enabled user or contact contains a link to a Live Communications Server 2005, Enterprise Edition, pool through the msRTCSIP-PrimaryHomeServer attribute. This attribute specifies the users registration server and whether it is a Microsoft Office Live Communications Server 2003, Standard Edition, server or Microsoft Live Communications Server 2005, Enterprise Edition, server.
EMBED Visio.Drawing.11
Figure SEQ Figure \* ARABIC 2. Relationships among new Active Directory classes in Live Communications Server 2005
When a Standard Edition Server, Enterprise Edition Server, or proxy server is installed on a computer that is joined to a forest or domain, an msRTCSIP-Server object is created as a connection point to the Computer object. If the server is an Live Communications Server 2005, Enterprise Edition server, its msRTCSIP-Server object points to a Pool object to which it belongs. If it is a Live Communications Server 2003, Standard Edition, home server, its msRTCSIP-Server object does not point to a Pool object. In either case, a corresponding msRTCSIP-TrustedServer object is created for this server. The set of msRTCSIP-TrustedServer objects also includes Live Communications Server 2003, Standard Edition, home servers from the same forest or, in the case of a cross-forest topology, different forests. No Live Communications Server 2005 Access Proxy servers or Live Communications Server 2005 Proxy servers can be a trusted server (that is, represented by an msRTCSIP-TrustedServer object). All Access Proxy servers are represented in the schema as msRTCSIP-EdgeProxy objects.
Live Communications Server adds the following classes to the Active Directory schema. Classes introduced with Live Communications Server 2005 are marked (new).
msRTCSIP-Server
This class represents a single SIP server.
msRTCSIP-EnterpriseServerSettings
This auxiliary class to msRTCSIP-Server holds attributes that represent settings for SIP servers.
msRTCSIP-Service
This class holds the global settings container and msRTCSIP-domain objects.
msRTCSIP-GlobalContainer
This class holds all settings that apply throughout an Live Communications Server deployment.
msRTCSIP-Registrar
This auxiliary class to msRTCSIP-GlobalContainer holds attributes that represent user settings maintained by the SIP registrar servers.
msRTCSIP-Search
This auxiliary class to msRTCSIP-GlobalContainer holds attributes that limit and control the scope of search results.
HYPERLINK \l "_msRTCSIP-Federation" msRTCSIP-Federation (new)
This auxiliary class to msRTCSIP-GlobalContainer holds all settings that are related to federation.
HYPERLINK \l "_msRTCSIP-Domain" msRTCSIP-Archive (new)
This auxiliary class to msRTCSIP-GlobalContainer holds all settings that are related to archiving.
HYPERLINK \l "_msRTCSIP-Pools" msRTCSIP-Pools (new)
This class holds multiple Live Communications Server 2005, Enterprise Edition, pools. It does not have any attributes itself.
HYPERLINK \l "_msRTCSIP-Pool" msRTCSIP-Pool (new)
This class represents a single Live Communications Server 2005 pool.
HYPERLINK \l "_msRTCSIP-PoolService_(new)"msRTCSIP-PoolService (new)
This class represents the service connection point of a pool. Users that are homed on a pool have their msRTCSIP-PrimaryHomeServer attribute point to an instance of this class.
msRTCSIP-TrustedServer
This class holds attributes that identify whether the server is a trusted server.
msRTCSIP-Domain
This class holds attributes that define the configured domains of the SIP registrar.
HYPERLINK \l "_msRTCSIP-Pools" msRTCSIP-EdgeProxy (new)
This class container represents a single Live Communications Server access proxy. Because an access proxy is deployed in the perimeter network (also known as DMZ, demilitarized zone, and screened subnet), and customers usually do not allow Active Directory access from the perimeter network, access proxies are not joined to the intranets Active Directory network. Therefore, access proxies are not automatically registered in Active Directory. You must manually configure the existence of each access proxy in Active Directory.
HYPERLINK \l "_msRTCSIP-Pools" msRTCSIP-ArchivingServer (new)
This class represents a single instant messaging archiving server. An instance of this class is created when a computer is activated as an instant messaging archiving server, such as a computer with the Instant Messaging Archiving Service installed.
Active Directory Attributes
Live Communications Server 2005 adds 24 new attributes to the Active Directory schema. Eight attributes added previously by Live Communications Server 2003 have been removed from the Active Directory schema for Live Communications Server 2005. These obsolete attributes will not be present in an Active Directory that is being extended for the first time by Live Communications Server 2005. If your Active Directory has been previously extended by Live Communications Server 2003, a tool, Lcsclean.wsf, is available to clear the obsolete attributes. An existing Active Directory attribute, dnsHostName, is associated with two Live Communications Server classes.
The following list shows all attributes and associated classes for Live Communications Server 2005. New and obsolete attributes are so noted. Attributes associated with additional classes are marked (add). Attributes marked with an asterisk (*) are reserved.
User
msRTCSIP-PrimaryUserAddress
HYPERLINK \l "_msRTCSIP-HomeServer_(removed)" msRTCSIP-HomeServer (obsolete)
HYPERLINK \l "_msRTCSIP-HomeServerString_(removed)" msRTCSIP-HomeServerString (obsolete)
msRTCSIP-UserEnabled
HYPERLINK \l "_msRTCSIP-IsMaster_(removed)" msRTCSIP-IsMaster (obsolete)
msRTCSIP-TargetHomeServer
msRTCSIP-OriginatorSID
msRTCSIP-PrimaryHomeServer
msRTCSIP- HYPERLINK \l "_FederationEnabled_(added)" FederationEnabled (new)
msRTCSIP- HYPERLINK \l "_InternetAccessEnabled_(new)" InternetAccessEnabled (new)
HYPERLINK \l "_msRTCSIP-ArchivingEnabled_(new)" msRTCSIP-ArchivingEnabled (new)
msRTCSIP-UserExtension *
Contact
msRTCSIP-PrimaryUserAddress
HYPERLINK \l "_msRTCSIP-HomeServerString_(removed)" msRTCSIP-HomeServerString (obsolete)
msRTCSIP-UserEnabled
msRTCSIP-OriginatorSID
HYPERLINK \l "_msRTCSIP-PrimaryHomeServer_(new)" msRTCSIP-PrimaryHomeServer (add)
HYPERLINK \l "_msRTCSIP-TargetHomeServer_(new)" msRTCSIP-TargetHomeServer (add)
msRTCSIP- HYPERLINK \l "_FederationEnabled_(added)" FederationEnabled (new)
msRTCSIP- HYPERLINK \l "_InternetAccessEnabled_(new)" InternetAccessEnabled (new)
HYPERLINK \l "_msRTCSIP-ArchivingEnabled_(new)" msRTCSIP-ArchivingEnabled (new)
msRTCSIP-UserExtension *
Computers
serviceConnectionPoint
msRTCSIP-Server
msRTCSIP-EnterpriseServerSettings
msRTCSIP-EnterpriseServices
HYPERLINK \l "_msRTCSIP-HomeUsers_(obsolete)" msRTCSIP-HomeUsers (obsolete)
HYPERLINK \l "_msRTCSIP-LCSPoolPath_(new)" msRTCSIP-PoolAddress (new)
msRTCSIP-ServerData *
msRTCSIP-Service
msRTCSIP-GlobalContainer
msRTCSIP-Registrar
msRTCSIP-Search
msRTCSIP-Federation
msRTCSIP-Registrar
msRTCSIP-MinRegistrationTimeout
msRTCSIP-DefRegistrationTimeout
msRTCSIP-MaxRegistrationTimeout
msRTCSIP-MinPresenceSubscriptionTimeout
msRTCSIP-DefPresenceSubscriptionTimeout
msRTCSIP-MaxPresenceSubscriptionTimeout
msRTCSIP-MinRoamingDataSubscriptionTimeout
msRTCSIP-DefRoamingDataSubscriptionTimeout
msRTCSIP-MaxRoamingDataSubscriptionTimeout
HYPERLINK \l "_msRTCSIP-SubscriptionAuthRequired_(" msRTCSIP-SubscriptionAuthRequired (obsolete)
msRTCSIP-NumDevicesPerUser
msRTCSIP-MaxNumSubscriptionsPerUser
msRTCSIP- HYPERLINK \l "_EnableBENotify_(new)" EnableBestEffortNotify (new)
HYPERLINK \l "_msRTCSIP-UserDomainList_(new)" msRTCSIP-UserDomainList (new)
HYPERLINK \l "_msRTCSIP-GlobalSettingsData" msRTCSIP-GlobalSettingsData *
msRTCSIP-Search
msRTCSIP-SearchMaxResults
msRTCSIP-SearchMaxRequests
msRTCSIP-MaxNumOutstandingSearchPerServer
HYPERLINK \l "_msRTCSIP-Federation_(new)" msRTCSIP-Federation (new)
HYPERLINK \l "_msRTCSIP-DefaultRouteToEdgeProxy_(n_1"msRTCSIP-DefaultRouteToEdgeProxy (new)
HYPERLINK \l "_EnableFederation_(new)" msRTCSIP-DefaultRouteToEdgeProxyPort (new)
HYPERLINK \l "_msRTCSIP-EnableFederation_(new)" msRTCSIP-EnableFederation (new)
HYPERLINK \l "_EnableBENotify_(new)" msRTCSIP-Archive (new)
HYPERLINK \l "_EnableBENotify_(new)"msRTCSIP-ArchiveDefault (new)
HYPERLINK \l "_msRTCSIP-FederationDefault_(new)" msRTCSIP-ArchiveFederationDefault (new)
msRTCSIP-Domain
msRTCSIP-DomainName
msRTCSIP-WMIInstanceId (obsolete)
msRTCSIP-DomainData *
msRTCSIP-TrustedServer
msRTCSIP-TrustedServerFQDN
HYPERLINK \l "_msRTCSIP-IsMaster_(obsolete)" msRTCSIP-IsMaster (obsolete)
HYPERLINK \l "_msRTCSIP-Version_(new)"msRTCSIP-TrustedServerVersion (new)
msRTCSIP-TrustedServerData *
HYPERLINK \l "_msRTCSIP-EdgeProxy_(new)_2" msRTCSIP-EdgeProxy (new)
HYPERLINK \l "_msRTCSIP-EdgeProxyFQDN_(add)" msRTCSIP-EdgeProxyFQDN (new)
msRTCSIP-EdgeProxyData * (new)
HYPERLINK \l "_msRTCSIP-ArchivingServer_(new)"msRTCSIP-ArchivingServer (new)
HYPERLINK \l "_dnsHostName_(new)" dnsHostName (new)
msRTCSIP-ArchivingServerData *
HYPERLINK \l "_msRTCSIP-Pools_(new)" msRTCSIP-Pools (new)
HYPERLINK \l "_msRTCSIP-Pool_(new)" msRTCSIP-Pool (new)
HYPERLINK \l "_msRTCSIP-PoolDisplayName_(new)" msRTCSIP-PoolDisplayName (new)
HYPERLINK \l "_msRTCSIP-BackEndServer_(new)" msRTCSIP-BackEndServer (new)
HYPERLINK \l "_msRTCSIP-LCSPoolType_(new)" msRTCSIP-PoolType (new)
HYPERLINK \l "_dnsHostName_(new)" dnsHostName (new)
msRTCSIP-PoolData * (new)
msRTCSIP-PoolService (new)
HYPERLINK \l "_msRTCSIP-FrontEndServers_(new)_1"msRTCSIP-FrontEndServers (new)
HYPERLINK \l "_User" msRTCSIP-HomeServer (obsolete)
HYPERLINK \l "_User" msRTCSIP-HomeServerString (obsolete)
HYPERLINK \l "_User"msRTCSIP-IsMaster (obsolete)
HYPERLINK \l "_msRTCSIP-EnterpriseServerSettings" msRTCSIP-HomeUsers (obsolete)
HYPERLINK \l "_msRTCSIP-Registrar" msRTCSIP-SubscriptionAuthRequired (obsolete)
Descriptions of New Attributes
The following list describes the Active Directory schema attributes for Live Communications Server 2005. The naming convention for attributes begins with the name of the class to which the attribute belongs, followed by the qualifier for the attribute.
For example, if an attribute that specifies the version number of the server needs to be added to the Archive class, the naming convention is:
Class namepurposeAttribute namemsRTCSIP-Archive+Version=msRTCSIP-ArchiveVersion
HYPERLINK \l "_User" msRTCSIP-FederationEnabled (new)
Controls whether a single user is enabled for Federation. Enforced by the Enterprise Services layer. Marked for global catalog replication.
Valid values are TRUE or FALSE.
HYPERLINK \l "_User" msRTCSIP-InternetAccessEnabled (new)
Controls whether a single user is enabled for outside user access. Enforced by the Enterprise Services layer. Marked for global catalog replication.
Valid values are TRUE or FALSE.
HYPERLINK \l "_User"msRTCSIP-ArchivingEnabled (new)
Controls whether a single users communications are to be archived. Enforced by the Archiving Agent layer. Marked for global catalog replication.
Valid values:
0 Use the default value defined by msRTCSIP-ArchiveDefault. If there is no such default value, use the default value defined by msRTCSIP-ArchiveFederation.
1 Archive.
2 Do not archive.
3 Archive without the message body.
HYPERLINK \l "_Contact" msRTCSIP-PrimaryHomeServer (add)
Enables a user or contact for SIP messaging. Added to the contact class because in the central forest topology, contact objects, not user objects, are SIP enabled.
Valid value is the domain name of the home server or pool where on which a user is homed.
HYPERLINK \l "_Contact" msRTCSIP-TargetHomeServer (add)
Enables moving a user or contact from one Live Communications Server to another. Added to the contact class because in the central forest topology, contact objects, not user objects, are SIP enabled.
Valid value is the distinguished name of the target SE (Standard Edition) server or EE (Enterprise Edition) pool to which a user is to be moved.
HYPERLINK \l "_msRTCSIP-EnterpriseServerSettings" msRTCSIP-PoolAddress (new)
Specifies a link back to the pool to which a computer belongs. This attribute is set regardless of whether the computer is an SE server or an EE server. Marked for global catalog replication.
Valid value is the domain name of the pool.
HYPERLINK \l "_msRTCSIP-Registrar" msRTCSIP-GlobalSettingsData
Stores name:value pairs. The already defined name:value pair is for the allow polling for presence setting.
HYPERLINK \l "_msRTCSIP-Registrar" msRTCSIP-DefaultRouteToEdgeProxy (new)
Specifies the FQDN (fully qualified domain name) of either the Live Communications Server Access Proxy Server, if directly accessible, or of the hardware load balancer for a bank of access proxies. If the access proxies are accessible only through one or more Live Communications Server directors, this attribute specifies the FQDN and, optionally, the port number of the director or of the hardware load balancer that is serving a bank of Directors.
Valid value for each segment is a string of no more than 63 characters; for the entire FQDN, a string of no more than 255 characters.
HYPERLINK \l "_msRTCSIP-Registrar"msRTCSIP-DefaultRouteToEdgeProxyPort (new)
Represents the port number that should be used to connect to the Live Communications Server Access Proxy Server.
Valid value is an integer value specifying the port to be used. Default value is 5061.
HYPERLINK \l "_msRTCSIP-Registrar" msRTCSIP-EnableFederation (new)
A global switch that specifies whether users are allowed to communicate with users from other organizations. The value of this attribute overrides an individual users FederationEnabled attribute. The msRTCSIP-EnableFederation attribute can be useful to protect the internal network from Internet attacks that may be caused by worms, viruses, or targeted attacks on the company.
Valid values:
TRUE Allow federation
FALSE Block federation
HYPERLINK \l "_msRTCSIP-Domain"msRTCSIP-ArchiveDefault (new)
Specifies the global default within the forest boundary for whether all users communications are to be archived or not. Enforced by the Archiving Agent layer.
Valid values:
TRUE Archive all users
FALSE Do not archive all users
HYPERLINK \l "_msRTCSIP-Archive_(new)"msRTCSIP-ArchiveDefaultFlags (new)
Controls globally within the forest boundary how users communications within an internal network are archived. This attribute is enforced only when the attribute, HYPERLINK \l "_msRTCSIP-ArchiveFederationDefault_("msRTCSIP-ArchiveDefault, is set to TRUE.
Valid values:
0 Archive the message body.
1 Do not archive the message body.
HYPERLINK \l "_msRTCSIP-Archive_(new)"msRTCSIP-ArchiveFederationDefault (new)
Specifies the global default within the forest boundary for whether all communications with federated partners are to be archived. Enforced by the Archiving Agent layer.
Valid values:
TRUE Archive all communications with federated partners
FALSE Do not archive all communications with federated partners
HYPERLINK \l "_msRTCSIP-Archive_(new)"msRTCSIP-ArchiveFederationDefaultFlags (new)
Controls globally within the forest boundary how users communications with federated partners are archived. This attribute is enforced only when the HYPERLINK \l "_msRTCSIP-ArchiveFederationDefault_("msRTCSIP-ArchiveFederationDefault attribute is set to TRUE.
Valid values:
0 Archive the message body.
1 Do not archive the message body.
HYPERLINK \l "_msRTCSIP-Registrar"msRTCSIP-EnableBestEffortNotify (new)
Controls whether a server generates a BENOTIFY request, which does not require a 200 OK response, instead of a NOTIFY request, in response to a SUBSCRIBE request from a client. Best Effort NOTIFY (BENOTIFY) is a performance-enhancing extension to the subscribe notification handshake where the server will generate BENOTIFY requests instead of regular NOTIFY requests. The performance benefit is that a BENOTIFY request does not require a 200 OK response from the client as the NOTIFY request does.
Valid value is TRUE or FALSE.
Note
To interoperate with server applications that are written using Live Communications Server 2003 server functions running on Live Communications Server 2005 and third-party servers, this feature can be disabled by setting its value to FALSE.
This feature is not currently part of the IETF (Internet Engineering Task Force) SIP standardization process.
HYPERLINK \l "_msRTCSIP-Domain" msRTCSIP-UserDomainList (new)
Provides a list of all the domains in a forest that host SIP-enabled users. An empty list (the default) indicates that all domains in the forest are SIP enabled.
Valid values are multiple strings that represent the names of individual SIP enabled domains.
HYPERLINK \l "_msRTCSIP-TrustedServer"msRTCSIP-TrustedServerVersion (new)
Specifies the version number of a server in the trusted server list.
Valid values:
NULL Live Communications Server 2003
2 Live Communications Server 2005
HYPERLINK \l "_msRTCSIP-Pools" msRTCSIP-EdgeProxyFQDN (new)
Specifies the FQDN of the Live Communications Server Access Proxy Server.
Valid value for each segment is a string of no more than 63 characters; for the entire FQDN, a string of no more than 255 characters.
HYPERLINK \l "_msRTCSIP-Pools"msRTCSIP-EdgeProxyData (new)
Reserved for future use.
HYPERLINK \l "_msRTCSIP-Pool" dnsHostName (new)
An existing attribute in Active Directory now associated with the new msRTCSIP-Archive and msRTCSIP-Pool classes. Specifies the FQDN of a pool as registered in DNS.
Valid value for each segment is a string of no more than 63 characters; for the entire FQDN, a string of no more than 255 characters.
HYPERLINK \l "_msRTCSIP-Pool" msRTCSIP-PoolDisplayName (new)
An arbitrary name for a pool that is displayed by the management console. This name can be changed by the administrator.
Valid value is a string that represents the name of a pool.
HYPERLINK \l "_msRTCSIP-Pool" msRTCSIP-BackEndServer (new)
Specifies the FQDN of the back-end server of the pool. Because there can only be a single back-end server per pool, this is a single-valued attribute.
Valid value for each segment is a string of no more than 63 characters; for the entire FQDN, a string of no more than 255 characters.
HYPERLINK \l "_msRTCSIP-Pool" msRTCSIP-PoolType (new)
Specifies whether a server pool Live Communications Server, Standard Edition, or Live Communications Server, Enterprise Edition.
Valid values:
Live Communications Server, Standard Edition
Live Communications Server, Enterprise Edition
HYPERLINK \l "_msRTCSIP-PoolService_(new)"msRTCSIP-FrontEndServers (new)
A multivalued list of the domain names of all Live Communications Server Enterprise Edition servers associated with a pool.
Cleaning up the Live Communications Server 2003 Schema
If your Active Directory schema was extended by Live Communications Server 2003 and then again by Live Communications Server 2005, you can remove the following obsolete attributes:
msRTCSIP-HomeServer (User object)
msRTCSIP-HomeServerString (User and Contact objects)
msRTCSIP-IsMaster (User object)
msRTCSIP-HomeUsers (msRTCSIP-EnterpriseServerSettings class)
msRTCSIP-SubscriptionAuthRequired (msRTCSIP-Registrar class)
msRTCSIP-WMIInstanceId (msRTCSIP-Domain class)
msRTCSIP-IsMaster (msRTCSIP-TrustedServer object)
Permissions
Microsoft Office Live Communications Server 2005 with SP1 manages permissions by creating five domain global groups and five local groups. Global groups are responsible for domainwide administration, and local groups are responsible for pool and server administration.
Domain Global Groups
Live Communications Server 2005 with SP1 creates six domain global groups, as listed below. The first two groups listed support the administrative model, and the others support permissions for the services.
RTCDomainServerAdmins
RTCDomainUserAdmins
RTCHSDomainServices
RTCArchivingDomainServices
RTCABSDomainServices
RTCProxyDomainServices
Live Communications Server 2005 with SP1 supports two basic kinds of administrator groups: RTCDomainServerAdmins group, which has rights to all of the server settings for one or more servers, and RTCDomainUserAdmins group, which has rights to manage all the settings of live communications users on one or more servers. Although these roles can be combined in some enterprises, the permissions and rights of each are different, and they allow for the splitting of roles where desired. By default, the scope of permissions for both server administrators and user administrators is domainwide, and both administrative groups have access to the root domain for global settings. .
If you need additional administrative delegation, such as OU level, per pool-server level, or read-only administration roles, see the later sections of Live Communications Server 2005 Active Directory Preparation.
Members of the RTCDomainServerAdmins group are generally tasked with deployment, pool, and server configurations and operations, as well as with management of enterprisewide global settings. Server administrators control the global settings (in Active Directory), which include both controls that affect users (for example, user search, user registration, federation, and archiving) and global topology information that is configured (such as user SIP domains and Access Proxies) or added as part of setup activation (such as Pools, Trusted Servers, and Archiving Services). Server administrators also control configuration settings for an Enterprise Pool or Standard Edition Server. The settings are stored in WMI and the Configuration Database.
Server administrators are also added to the Administrators group on each Enterprise Edition Server and Standard Edition Server so that they can configure certificates for listening addresses and routes. (Doing so requires giving permissions to certificate private keys to the service.) Both server administrators and user administrators can move users between any two Enterprise Pools or Standard Edition Servers. The server administrator, therefore, receives write permission on some user attributes in Active Directory (for example, RTC Property Set). But server administrators cannot enable users or manage user search permissions, because they do not have permissions on the RTC User Search Property Set or the Public Information Property Set.
Server administrators are also given the Admin Role on the User Database so they can perform maintenance operations such as db_backupoperator.
Members of the RTCDomainUserAdmins group are generally tasked with enabling and configuring users, managing user search permissions, troubleshooting users, and moving users between pool and server. The user administrators receive limited read permission on the global settings in Active Directory. User administrators are currently allowed to view global settings that affect users, such as user search, registration, federation, and archiving; however, the user administrator is allowed only a limited view of global topology information. By default, user administrators can see all Enterprise Pools and Standard Edition Servers, but they cannot see the list of SIP domains, Access Proxies, Archiving Servers, or Trusted Servers. User administrators have full read and write permissions on all user settings, including the Public Information Property Set and the RTC User Search Property Set. The user administrator also receives permissions on WMI similar to those granted to the server administrator, in order to support configuring user settings and data via WMI; however, the user administrator has only read permissions on the Configuration Database.
Live Communications Server 2005 also creates four domain global service groups.
RTCHSDomainServices gives permissions to the service accounts of the Enterprise Pools and Standard Edition Servers. RTCHSDomainServices allows the pool and servers to read user information inside Active Directory that is required for routing, user search, archiving, and authorizing various user capabilities (federation, remote internet access, and public IM cloud connectivity). RTCHSDomainServices also allows the pool and servers to access the global settings and topology information stored inside the Active Directory forest root domain. For an Enterprise Pool deployment, the Enterprise Edition Servers of the Enterprise Pool will also use this group to access the Enterprise Pool Back-End user and configuration databases. Also, for an archiving deployment, Enterprise Pools and Standard Edition servers will use the RTCHSDomainServices group to write messages to the destination queue (Microsoft Messaging Queue) of the Archiving Service.
The RTCArchivingDomainServices group gives permission to the service accounts of any Archiving service to access the Archiving Service Database. This group supports the two-tiered deployment topology, in which the archiving service component and the database are on separate computers.
The RTCABSDomainServices group gives permission to the service accounts of an Address Book Service to access the Enterprise Pool Back-End User Database that the Address Book Service leverages to retrieve user information from Active Directory. The Address Book Server is a offline address book that can be used by the Live Communicator client for easy search of users for instant messaging and voice calls. For details, see the Address Book Service or Communicator documentation.
The RTCProxyDomainServices group gives the service accounts of a forwarding Proxy permission to write messages to the destination queue (Microsoft Messaging Queue) of a remote Archiving Service.
Local Groups
In addition to the domain global groups described in the previous section, Microsoft Office Live Communications Server 2005 with SP1will create five local groups on any Standard Edition Server or Enterprise Edition Server of an Enterprise Pool.
RTC Local Administrators
RTC Local User Administrators
RTC Server Local Group
RTC ABS Service Local Group
RTC Server Applications
The three local groupsRTC Local Administrators, RTC Local User Administrators, and RTC Server Local Groupgive local rights and permissions on each Standard Edition Server or Enterprise Edition Server to their respective member domain global groups (RTCDomainServerAdmins, RTCDomainUserAdmins, and RTCHSDomainServices, respectively). These local groups receive the permissions described in Local Permissions on each Standard Edition Server or Enterprise Edition Server later in this guide.
These three local groups are also used to allocate permissions on the User Database and the Configuration Database for a Standard Edition Server, because the Standard Edition Server uses an MSDE (Microsoft SQL Server 2000 Desktop Engine) instance, which supports only local execution. For an Enterprise Pool, database permissions are given to the domain global groups because the Enterprise Pool uses SQL Server 2000, which supports remote execution. For details, see Database Permissions for each Enterprise Pool or Standard Edition Server later in this guide.
Similarly, the RTC ABS Service Local Group gives limited local permissions to an Address Book Server on the User Database of a Standard Edition Server MSDE instance. As noted earlier, the Address Book Server will leverage the Live Communications Server User Database to retrieve user information from Active Directory.
The RTC Server Applications group authorizes applications that are to be loaded by the Live Communications Server 2005 service (rtcsrv) when the service is started (onto the API module).
Active Directory Permissions
This section lists Active Directory rights and permissions given to the various Live Communications Server 2005 groups described in the previous sections.
The actual rights, as shown in ADSIEdit, are summarized in the following table. The Summary column shows the default ADSIEdit view, and the Advanced View column shows more detailed and extended rights.
Table SEQ Table \* ARABIC 1.ADSIEdit Views
ADSIEdit Summary PageADSIEdit Advanced ViewFull ControlFull ControlReadList Contents +Read All Properties +Read PermissionsWriteWrite All Properties +All Validated WritesList ContentsRead All PropertiesWrite All PropertiesDeleteDelete SubtreeRead PermissionsModify PermissionsModify OwnerAll Validated WritesAll Extended RightsCreate All Child ObjectsCreate All Child ObjectsDelete All Child ObjectsDelete All Child Objects
Object Hierarchy
The overall object hierarchy for Active Directory objects used by Live Communications is:
For the forest root domain where global settings are stored:
CN=System
CN=Microsoft
CN=RTC Service
CN=Global Settings
CN=GUID(objectcategory=msRTCSIP-Domain)
CN=Pools
CN=Pool
CN=PoolService
For any domain that is prepared for Live Communications Server 2005:
CN=Users
SIP extensions on the User
CN=Computers
CN=MachineXXX
CN=Microsoft
CN=RTC Services (objectcategory=msRTCSIP-Server)
msRTCSIP-Server
The objects and their permissions are described in the following tables, grouped into several sections.
Active Directory Permissions for the Forest Root Domain
The permissions for the objects that are described in the following tables are all applied only during the root Domain Prep procedure and during the root Domain Add procedure. These permissions are applied on the Microsoft container (Service Connection Point SCP) under the Systems container (CN=Microsoft, CN=Systems, DC=Domain), and the relevant child objects of the Live Communications Server global setting objects inherit the permissions. The permissions are set during domain preparation of the forest root. They are also set whenever a child domain is added to the forest root.
The pool object, the archiving server object, and the edge proxy object are created only during initial.
Table SEQ Table \* ARABIC 2.msRTCSIP-Service Object
ACE (access control entity)Permission status Associated permissionsGlobal Home Server GroupAllowRead All properties
List ChildrenGlobal Server Admin GroupAllowRead All properties
List ChildrenGlobal User Admin groupAllowRead All properties
List Children
Table SEQ Table \* ARABIC 3.msRTCSIP-GlobalContainer Object
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All properties
List ContentsGlobal Server Admin GroupAllowRead All Properties
Write All Properties
List ContentsGlobal User Admin group
Table SEQ Table \* ARABIC 4. Container Object Type
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All properties
List ContentsGlobal Server Admin GroupAllowRead All Properties
Write All Properties
List Contents
Create All Childs
Delete All Childs
Delete TreeGlobal User Admin groupAllowRead All properties
List Contents
Table SEQ Table \* ARABIC 5.msRTCSIP-Domain Object
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupAllowRead All Properties
Write All Properties
Delete TreeGlobal User Admin groupAllow
Table SEQ Table \* ARABIC 6.msRTCSIP-Trustedserver
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupAllowRead All Properties
Write All Properties
Delete TreeGlobal User Admin groupAllow
Table SEQ Table \* ARABIC 7.msRTCSIP-EdgeProxy
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupAllowRead All Properties
Write All Properties
Delete TreeGlobal User Admin groupAllow
Table SEQ Table \* ARABIC 8.msRTCSIP-ArchivingServer
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupAllowRead All Properties
Write All Properties
Delete TreeGlobal User Admin groupAllow
Table SEQ Table \* ARABIC 9.msRTCSIP-Pools
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowGlobal Server Admin GroupAllowRead All Properties
Write All Properties
Delete Tree
Create Child
Delete ChildGlobal User Admin groupAllow
Table SEQ Table \* ARABIC 10.msRTCSIP-Pool
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All Properties
List ContentGlobal Server Admin GroupAllowRead All Properties
Write All Properties
Delete Tree
Create Child
Delete ChildGlobal User Admin groupAllowRead All Properties
Table SEQ Table \* ARABIC 11.msRTCSIP-PoolService
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupAllowRead All Properties
Write All Properties
List ContentGlobal User Admin groupAllowRead All Properties
Active Directory Permissions for Any Live Communications Server Domain
RTCPropertySet
The RTCPropertySet object contains the following attributes for Live Communications Server 2005 with SP1:
msRTCSIP-UserEnabled
msRTCSIP-TargetHomeServer
msRTCSIP-OriginatorSID
msRTCSIP-PrimaryHomeServer
msRTCSIP-FederationEnabled
msRTCSIP-InternetAccessEnabled
msRTCSIP-ProviderAccessEnabled
msRTCSIP-ArchivingEnabled
msRTCSIP-OptionFlags (new with SP1)
msRTCSIP-Line (new with SP1)
msRTCSIP-LineOptions (new with SP1)
msRTCSIP-UserExtension (new with SP1)
If you are upgrading from Live Communications Server 2003, this property set will also contain the following attributes:
msRTCSIP-HomeServer (obsolete)
msRTCSIP-HomeServerString (obsolete)
msRTCSIP-IsMaster (obsolete)
The permissions for the RTCPropertySet object, as described in the following table, are set at the domain root, and they are set for inheritance. The permissions are set during preparation of the domain and whenever a domain is added.
Table SEQ Table \* ARABIC 12.RTC Property Set Covering Extensions on the User Object (CN=User)
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupAllowRead All Properties
Write All Properties
Delete TreeGlobal User Admin groupAllowRead All Properties
Write All Properties
Delete Tree
RTCUserSearchPropertySet
The RTCUserSearchPropertySet object contains properties that apply to an individual user. It includes a users primary SIP URI (universal resource identifier). The Live Communications Server will evaluate permissions on this property set to authorize searching of users when the Windows Messenger client user search functionality is used. Users who have Read permissions on a users property set are authorized to search that user. The server and the administrators also must have permission to read and write, respectively, this property set.
By default, authenticated users are given Read permission on each others RTCUserSearchPropertySet, so that Windows Messenger-based user search functionality will work for all users without restriction, upon installation of Live Communications Server. More fine-grained permissions can be applied to a users RTCUserSearchPropertySet (replacing Authenticated Users) if required to restrict user search.
Note
As delivered, Live CommunicationsServer does not set ACEs (access control entities) on the contact object. If deploying in a cross-forest scenario, consult the Deployment Guide.
The ACEs in the following table are set at the domain root, and they are set for inheritance. The ACEs are set during preparation of each domain and whenever a domain is added. They are also set whenever the Domain Add procedure is run in User Only mode.
Table SEQ Table \* ARABIC 13.RTCUserSearchPropertySet (CN=User)
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupGlobal User Admin groupAllowRead All Properties
Write All Properties
Delete TreeAuthenticated UsersAllowRead All Properties
Public Information Property Set
The public information property set gives access rights to the Proxyaddresses attribute. This attribute stores the SIP address of a user to enable user address resolution for the getPresence scenarios.
The ACEs in the following table are set at the domain root, and they are set for inheritance. The ACEs are set during preparation of each domain and whenever a domain is added.
Table SEQ Table \* ARABIC 14. Public Information Property Set (CN=User)
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupGlobal Server Admin GroupGlobal User Admin groupAllowRead All Properties
Write All Properties
DirSyncControl
The global Home Server group is given Read access in Replicate Directory Changes. This permission is used during DirSync control execution to verify the information used for attribute and object changes in the directory.
The ACEs in the following table are set at the domain root, and they are set for inheritance. The ACEs are set during preparation of each domain and whenever a domain is added. They are also set whenever the Domain Add procedure is run in User Only mode.
Table SEQ Table \* ARABIC 15. DirSyncControl Cookie (CN=Domain)
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowControl AccessGlobal Server Admin GroupGlobal User Admin group
Microsoft Container (Service Connection Point)
This is the ACE that applies to the objects created under the Computer object during the setup activation procedure to enable global topology discovery. This ACE is set on the Microsoft container (of type service connection point) under the Computer object and applies via inheritance to the server object under the Microsoft container. These permissions allow administrators and the pools and servers to access this topology information.
The ACEs in the following table are set on the service connection point. They are also set for inheritance from the server object (CN=Computers, CN=ComputerXXX, CN=Microsoft, CN=RTCService). The ACEs are set during the activation procedure for each SE (Standard Edition) and EE (Enterprise Edition) Server.
Table SEQ Table \* ARABIC 16. Microsoft Container (CN=Computers, CN=Machine XXX, CN=Microsoft)
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupAllowRead All Properties
Write All PropertiesGlobal User Admin groupAllow Read All Properties
Domain Container
This permission is set to guarantee that Live Communications Server 2005 with SP1 has access to the domain container.
The ACEs in the following table are set at the domain root. They are set directly, without inheritance. The ACEs are set during preparation of each domain and whenever a domain is added.
Table SEQ Table \* ARABIC 17.Domain Container
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All Properties
Read Permissions
List ContentGlobal Server Admin GroupAllowRead All Properties
Read Permissions
List ContentGlobal User Admin groupAllowRead All Properties
Read Permissions
List Content
Built-in Containers (Systems, Users, Domain Controllers, Computers)
This permission is set directly on each of the built-in containers in the domain naming context under the domain container, to guarantee that Live Communications Server 2005 with SP1 has access.
The ACEs in the following table are set on each of the built-in containers. They are set directly, without inheritance. The ACEs are set during preparation of each domain and whenever a domain is added.
Table SEQ Table \* ARABIC 18.Built-in Containers
ACE (access control entity)Permission statusAssociated permissionsGlobal Home Server GroupAllowRead All Properties
Read Permissions
List ContentGlobal Server Admin GroupAllowRead All Properties
Read Permissions
List ContentGlobal User Admin groupAllowRead All Properties
Read Permissions
List Content
Configuration Container and the Display Specifiers Container
These permissions are set directly on the Configuration Container and on the Display Specifiers Container underneath in the configuration naming context. This is done to guarantee that Live Communications Server 2005 with SP1 has access.
The ACEs in the following table are set on each of the containers in the configuration naming context (the Configuration container and the Display Specifiers container under it). They are set directly, without inheritance. The ACEs are set during preparation of each domain.
Table SEQ Table \* ARABIC 19.Configuration Container and the Display Specifier Container
AccountPermission statusAssociated permissionsGlobal Home Server GroupAllowRead All Properties
Read Permissions
List ContentGlobal Server Admin GroupAllow*Read All Properties*
Read Permissions*
List Content*Global User Admin groupAllowRead All Properties
Read Permissions
List Content* Set only on the Configuration container, not on the Display Specifiers container.
Optional Active Directory Permissions for an OU Container
All the permissions that are described in HYPERLINK \l "_Active_Directory_Permissions" Active Directory Permissions for Any Live Communications Server Domains, earlier in this guide, can also be set directly on containers instead of at a domain level. The procedures (for example, the CreateLcsOuPermissions action in the Lcscmd.exe command line utility) allow organizations who have locked-down Active Directories to compensate for permission inheritance being disabled. Because permission can be applied directly to the lower-level containers, the permissions will at least apply to relevant objects in those containers.
The per-container procedures will apply permissions according to object type, user, contact, InetOrgPerson, or computer.
For User, Contact, or InetOrgPerson objects, running the CreateLcsOuPermissions action creates permissions similar to those listed in the section HYPERLINK \l "_Active_Directory_Permissions" Active Directory Permissions for Any Live Communications Server Domains earlier in this guide. Specifically, the permissions for RTC Property Set, RTC User Search Property Set, and Public Information are all set. Furthermore, the RTCHSDomainServices are given read permission on the Personal information and General information property sets.
Personal Information Property Set
The Personal Information property set is required so that the Live Communications Server 2005 with SP1User Replicator and for certain management components, such as MMC, can run correctly in a locked-down Active Directory topology.
The ACEs in the following table are set at the container /OU that is specified by the administrator. They are set for inheritance. The ACEs are set if the administrator runs CreateLcsOuPermissions, usually in an environment with locked-down Active Directories and with permission inheritance explicitly disabled.
Table SEQ Table \* ARABIC 20. Public Information Property Set (CN=User)
AccountPermission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupGlobal User Admin group
General Information Property Set
This is required for the Live Communications Server 2005 with SP1User Replicator and/or for certain management components (i.e., MMC) to execute correctly in a locked-down Active Directory topology.
The ACEs in the following table are set at the container /OU that is specified by the administrator. They are set for inheritance. The ACEs are set if the administrator runs CreateLcsOuPermissions, usually in an environment with locked-down Active Directories and with permission inheritance explicitly disabled.
Table SEQ Table \* ARABIC 21. General Information Property Set (CN=User)
AccountPermission statusAssociated permissionsGlobal Home Server GroupAllowRead All PropertiesGlobal Server Admin GroupGlobal User Admin group
For Computer objects, running the CreateLcsOuPermissions procedure will create similar permissions to the ones for the Microsoft containers listed under the Computer object in Active Directory Permissions that Apply to Any Live Communications Server Domains. CreateLcsOuPermissions would be run after the servers are activated so that the administrator and the servers have access to global topology information.
Local Permissions (Access Proxy, Standard Edition Server, Enterprise Edition Server)
The Active Directory permissions described earlier are required for Live CommunicationsServer 2005 with SP1 Standard Edition servers and Enterprise Pools.
This section describes the local computer resources that every server role will need permission to access. The local permissions described in this section apply to the Enterprise Edition server, Standard Edition servers, Proxy, and the Access Proxy.
Access Rights on the WMI CIM Repository
Note
All database permissions described in this section are for the Enterprise Pool and the Standard Edition Server only. They do not apply to the Proxy or Access Proxy.
The Live CommunicationsServer proxy settings are stored in the Windows Management Instrumentation (WMI) Common Information Model (CIM) repository. To provide the necessary access to these settings, the Local machine RTC Local Administrators, RTC Local User Administrators, and RTC Server Local groups are granted read and write access to the WMI Namespace ROOT\CIMV2 and WMI Namespace ROOT\DEFAULT\WINRTC_REPOSITORY.
Note
Because the access rights can only be set at the level of a namespace, the RTC Local User Administrators group who need only to manage user settings and user data will have read and write access to the entire namespace.
The specific permissions given are :
Provider Write.
Enable Account
Remote Enable.
Access Rights for Tracing
Tracing in the Live CommunicationsServer is enabled and is controlled by the tracelog or logman command line tool. The default security setting for Web Presence Provider (WPP) tracing allows members of the following groups to control the tracing:
Administrators
LocalSystem
NetworkService
PerfmonLogUsers
Normally, this security setting is good, because the tracing contains only software debugging information. However, in the SIPSTACK component, when the TL_MESSAGE flag is enabled, all traffic on the network gets logged in the tracing files. When encryption is enabled through TLS/SSL, this security setting will defeat the encryption, so Live CommunicationsServer needs to lock down all components that write sensitive data into the log files. Because there is a dependency upon TL_MESSAGE-based logging to provide a support tool, it is not an option to turn off tracing. So, for Live CommunicationsServer, members of the following groups are given the right to control the tracing:
Local Administrators
RTC Server Local Groups (only for Standard Edition server or Enterprise Edition server)
RTC Local Administrators Group
Access Rights on Files
The system applies the default permissions.
Access Rights to Manage Certificates
To enable a RTC Server Administrator to request, upload, and configure a certificate Live Communications Server 2005 with SP1 (for listening addresses and/or routing settings), the following permissions are set:
Setup gives Read permission to the RTC Local Administrator group at HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg registry key.
For the Enterprise Edition server and the Standard Edition server, Setup adds the RTCDomainServerAdmins to the machines Local Administrator groups. In the Access Proxy and Proxy, a user who is a member of the Local Administrators group will need to configure certificates.
When certificate are configured for Live Communications Server 2005 by an administrator, WMI will impersonate the administrator and assign GENERIC_FILE_READ permissions to the local RTC Service group.
Domain Global Groups Given Access to Local Server Resources Via Local Groups
Note
The information in this section does not apply to the Proxy or to the Access Proxy.
For the relevant domain global groups that are created during domain preparation, Enterprise Edition servers and Standard Edition servers will give those groups membership on the local groups of a server during the activation procedure for the server. The following memberships are granted:
Members of RTCDomainGlobalServerAdmins are added as members of the RTC Local Administrators group as well as the Local Administrators group.
Members of RTCDomainUserAdmins are added as members of the RTC Local User Administrators group.
Members of RTCHSDomainServices are added as members of the RTC Server Local Group.
Database Permissions for an Enterprise Pool or Standard Edition Server
This section describes the permissions given on the DCOM RTC Store Interface (remote access to the User Database), as well as direct permissions on the User database and Configuration database. These permissions apply to an Enterprise Pool and its Enterprise Edition servers, as well as to the Standard Edition Server. These databases exist only for these two roles, so the information in this section does not apply to the Access Proxy or the Proxy.
These permissions are separate from those described in the earlier section Local Permissions (Access Proxy, Standard Edition Server, Enterprise Edition Server) because these permissions focus on database access and are not always local, as in the case of the Enterprise Pool. These permissions apply only to the Enterprise Pool and Standard Edition Server..
The Enterprise Pool stores its database on a remote Enterprise Pool Back-End computer with a SQL Server instance, which requires that database roles be given to the domain global groups to support remote execution.
The Standard Edition Server stores its database locally on an MSDE instance, which requires only that database roles be given to local groups for local execution.
The DCOM RTC Store Interface exists on the Standard Edition Server and on each Enterprise Edition Server. It is used to remotely access the MSDE instance in the Standard Edition case. It is also used to remotely access the Enterprise Pool SQL Server Instance.
Access Rights To The DCOM RTC Store Interface Class
Access rights to the RTC Store Interface class enable the service and administrators to remotely execute procedures on the user database. This interface is also a consistent way to authorize procedures on the user database.
In the Enterprise Pool case, there is an RTC Store Interface on each Enterprise Edition Server, and the permissions will be applied on each server. In the Standard Edition Server case, the permissions are applied on the local computer.
The access rights are stored in the following registry key:
HKEY_CLASSES_ROOT\AppID\{91BC037F-B58C-43cb-AD9C-1718ACA70E2F}\AccessPermission
The following permissions should be given on the RTC Store Interface:
Local Access permissions are given to RTC Local Administrators, RTC Local User Administrators, RTC Server Local Group, Local Systems account, and Domain Administrator.
Remote Access permissions are given to RTC Local Administrators, RTC Local User Administrators, RTC Server Local Group, Local Systems account, and Domain Administrator.
Local Launch permissions are given to RTC Local Administrators, RTC Local User Administrators, RTC Server Local Group, and Local Systems account.
Remote Launch permissions are given to RTC Local Administrators, RTC Local User Administrators, RTC Server Local Group, and Local Systems account.
Local Activation permissions are given to RTC Local Administrators, RTC Local User Administrators, RTC Server Local Group, Local Systems account, and Domain Administrator.
Remote Activation permissions are given to RTC Local Administrators, RTC Local User Administrators, RTC Server Local Group, Local Systems account, and Domain Administrator.
Note
Permissions are also set for the RTC Local Administrators, RTC Local User Administrators, and RTC Server Local Group groups on the registry keys for Machine Access Restrictions (MAR) and Machine Launch Restrictions (MLR). These permissions are set to handle requirements for Windows Server 2003 SP1.
Access Rights To The RTC User Database
Server Role and Access by the Service
A custom Server Role is created on the user database (stored in SQL Server of the Back-End Server for an Enterprise Pool and in MSDE for Standard Edition Server), which gives the relevant Enterprise Edition and Standard Edition Servers access to read the user database and to run relevant stored procedures. Specifically, the Server role is given all the permissions that are given to the custom Read Only Role (see below), as well as access to execute all external stored procedures required for server operations. The group also receives membership at setup in the db_ddladmin role.
For an Enterprise Pool case, RTCHSDomainServices is given membership in the Server role.
For a Standard Edition Server case, the RTC Server Local Group is given membership in the Server Role, because the Standard Edition Server is a single computer running MSDE instance.
RTC User and Server Administrators
For a general procedure that is executed by the RTC User and Server administrators on the user database, the authorization is always done consistently on the local server (in the Enterprise Pool case, via one of the Enterprise Edition Servers) in the WMI layer or in the DCOM RTC Store interface, depending on the procedure. Once authorized, the procedure accesses the user database by impersonating the service account that the local RTC server runs under.
The RTCDomainServerAdmins group in the Enterprise Pool case and the RTC Local Administrators in the Standard Edition Server case are also given membership in the custom Admin Role in the user database for maintenance operations. The Admin Role has membership in the custom ReadOnlyRole and the standard db_backupoperator role.
Local Administrators
Local Administrators are added by setup to the sysadmin group. Administrators can also use the Read Only Role to run various database tools listed above.
Access rights on the transaction log and database files
The administrator has full rights on transaction log and database files. For the folders that get created by Setup for these files (if they are created by Setup), administrators have full access , aud users have read access.
Read Only Role
A custom Read Only Role is created on the user database, which is most commonly used to run a variety of Live Communications Server database tools, including dbimpexp, dbanalyze, and dbreport. Specifically, the Read Only Role is given access to query two views (EndpointView1 and MonthlyRegisterUsageView). It can execute RtcQueyrEndpoints and can run a few specified stored procedures. The Read Only Role is also given access to execute stored procedures for the Address Book Server role.
The RTCABSDomainServices group in the Enterprise Pool case and RTC ABS Service Local Group in the Standard Edition Server case are given membership in this Read Only Role.
No other user accounts are given membership in the Read Only Role by default.
Backup and Restore
Db_backupoperator membership is required to run backup procedures such as the dbbackup tool provided in the resource kit. Restoring a database will require sysadmin permissions.
Access Rights To The RTC Configuration Database
A configuration database called RTCConfig is also created in MSDE (Standard Edition) or SQL (Enterprise Edition). This database is used most commonly to share settings across Enterprise Edition Servers in an Enterprise Pool case (stored in the Enterprise Pool Back-End SQL Instance), but the same design is used in Standard Edition Server but stored in the MSDEinstance instead of SQL.
The user administrators and service groups will generally need permissions to read from the database, while the Server Admin group will also need additional write and stored procedure permissions.
In the Enterprise Pool case, the RTCDomainServerAdmins (server read and write role), RTCDomainUserAdmins (server read only role), and the RTCHSDomainServices (database read-only role) are given membership in the respective custom database roles.
In the Standard Edition Server case, the RTC Local Administrators (server read and write role), RTC Local User Administrators (server read only role), and the RTC Server Local Group (server read only role) are given memberships in the respective custom database roles.
Permissions for an Archiving Scenario
The following permissions are relevant only if archiving is enabled. As described in the planning and deployment documentation, Live Communications Server 2005 with SP1 archiving involves deploying the Archiving Service and connecting the Archiving Agent available on each Live Communications Server (each Standard Edition Server, each Enterprise Edition Server of an Enterprise Pool, or a standalone Proxy Server) with the Archiving Service. The Archiving Service itself has several components, including a destination queue (MSMQ) that the Archiving Agent sends IM messages to. The Archiving Service then has a self-named archiving service component that reads from the destination queue and writes the messages into the final Archiving Database store.
RTCArchivingDomainService Group and the Archiving Service domain service account
When you activate an Archiving Service, you will select a domain service account, which will be given membership in the RTCArchivingDomainService Group. This group is used to give permissions
A custom Server Role is created on the archiving database to read, write, and run required stored procedures including those required in support of the usage summary table. Setup will add the RTCArchivingDomainService group (which the archiving domain service account is a member of) to this Server Role.
Access Rights To The RTC Archiving Database
A custom Server Role is created on the archiving database to read, write, and run required stored procedures including those required in support of the usage summary table. Setup will add the RTCArchivingDomainService group (which the archiving domain service account is a member of) to this Server Role.
By default, setup will not add any administrative privileges. These will have to be added manually.
Access Rights to the MSMQ Queue Used for IM Archiving
The RTC Archiving Agents group is granted the Send Message permission on the queue. The RTCHSDomainServices group is added to this local agents group, to give the archiving agent component on each Live Communications Server, the right to archive to the Archiving Service destination queue component. The archiving agent component of each Live Communications Server (available on Standard Edition Server, each Enterprise Edition Server, and a standalone Proxy Server) will always run under the domain service account of the Live Communications Server which is a member of RTCHSDomainServices group.
The RTCArchivingDomainService group (which the archiving domain service account is a member of), is given the following permissions on the queue:
Receive Message
Peek Message
Get Properties
Get Permissions
The RTC Archiving Service local group is granted the Read Message permission on the queue. The RTCArchivingDomainServices group is normally added to this local group, to give the archiving service component of the Archiving Service, the privilege to read the messages in the destination queue that were placed by each archiving agent of Live Communication Servers.
The RTCArchivingDomainServices group is normally given the Server role on the Archiving Back-End Database so that it can execute certain stored procedures.
The local Administrators group on the archiving server is given the following permissions on the queue:
Get Properties
Get Permissions
Take Ownership
The user account that ran Setup is given full control.
The permissions described earlier for the RTCArchivingDomainServices group will be different if you are deploying in specific scenarios for archiving forwarding proxies in either workgroup or unprepared domain modes. If you are deploying the Archiving Service in a workgroup mode, permissions normally given to the RTCArchivingDomainServices group will be given to the RTC Archiving Service local group. If you are deploying the Archiving Service in a domain that is not prepared for Live Communications Service 2005 SP1, the service account itself will receive permissions that are normally given to the Archiving Service.
Archiving Back-End Database Structure and Schema
The Archiving Back-End Database stores IM message archives and usage data. The following diagram illustrates the database tables that the Archiving Back-End Database uses to store this information. The table that follows the diagram describes the database schema (Table 23).
EMBED Visio.Drawing.11
Figure SEQ Figure \* ARABIC 3.Archiving Back-End Database structure
The following table describes the schema for the Archiving Back-End Database.
Table SEQ Table \* ARABIC 22.Archiving Back-End Database schema
Table NameColumn NameDescriptionusers userid(Identity column)useruriURI of the user that sent or received an instant message.computersid(Identity column)computerNetBIOS name of the home server that processed an instant message.contenttypesid(Identity column)contenttypeMIME content type of the message.messagesid (Identity column)dateDate and time at which the message was processed by a home server.fromidIdentifies the sender of an instant message (corresponds with userid in users table).toidIdentifies the recipient of an instant message (corresponds with userid in users table).contenttypeidIdentifies what the content type of the message is.cs_call_idUnique identifier for the IM session. Checksum calculated from call_id (used by Live CommunicationsServer only).computeridIdentifies the home server that processed an instant message (corresponds with id in computers table).bodyBody of an instant message.reserved1Column reserved for use, such as tracking the exporting of records.reserved2Column reserved for use.usagesummaryid (Identity column)dateDate and time at which the message was processed by a home server.fromidIdentifies the sender of an instant message (corresponds with userid in users table).toidIdentifies the recipient of an instant message (corresponds with userid in users table).cs_call_id Unique identifier for the IM session. Checksum calculated from call_id (used by Live CommunicationsServer only).Messages Number of messages sent.reserved1Column reserved for future use.reserved2Column reserved for future use.
Flat File Logging
Flat file logging is a feature introduced in Live Communications Server 2005 to simplify debugging and monitoring of the server. With this feature enabled, the server can create easily parsed text files that detail a variety of events, including the SIP (Session Initiation Protocol) messages processed by the server. Flat file logging provides:
A security audit trail.
Information to assist in troubleshooting configuration issues.
Sufficient raw information for producing reports on system usage.
Flat File Logging Events
The flat files generated by the server contain a variety of information. There are four configurable levels of logging. Each level of logging is designed to provide a specific type of information:
Level 1: Critical security related information.
Level 2: Information about client logons and session initiations, plus all information in Level 1.
Level 3: Information about presence changes and contact management, plus all information in Levels 1 and 2.
Level 4: Verbose information about every SIP message going through the server, plus all information in Levels 1, 2, and 3.
Leve1 1 logging is intended to be lightweight enough that it can be run continuously. Level 4 logging is extremely verbose and should be used only for a limited time for investigation of server issues. The log files that are generated by the server are intended to be regularly archived and then removed by an administrative process. The server does not automatically remove archived files.
The following table summarizes the content of the various logging levels which are provided.
Table SEQ Table \* ARABIC 23.Flat file logging levels
SIP MethodLevel 1Level 2Level 3Level 4INVITEXXXACKXXXCANCELXXXBYEXXXREFERXXXINFOXMESSAGEXSERVICEXXREGISTERXXXSUBSCRIBEXNOTIFYXBENOTIFYXNEGOTIATEXSIP HeaderLevel 1Level 2Level 3Level 4ToXXXFromXXXCall-IDXXXCSeqXXXContactXXXViaXXXRouteXXXRecord-RouteXXXExpiresXXXContent-TypeXXXContent-LengthXXXMax-ForwardsXXXAll other headersXXOther InformationLevel 1Level 2Level 3Level 4NT application eventserrorserrors, warningserrors, warnings, and informationerrors, warnings, and informationSecurityallallallallDNSnoneallallallConnectionseverity 1severity 1 and 2severity 1 and 2severity 1 and 2Diagnosticerrorserrors, warningserrors, warningserrors, warnings, and information
Flat File Logging Format
Flat file logging (FFL) generates log files in a well-defined, parsable format. All flat file logs contain two sections:
File Content Definition (FCD): Defines the format of the log data.
Log data: Zero or more records of data logged by the server.
The parser reads the FCD and, using the content definition it describes, interprets the data that follows. A valid log file always contains an FCD; it may or may not contain data. A log file containing no data is considered to be empty.
All FFL log files use UTF-8 character set encoding. In general, the content of the log is organized into lines separated by an ASCII carriage-return-line-feed sequence (CRLF). This convention permits FFL files to be viewed by any conventional text program, such as Windows Notepad. A log file may range in size from a few hundred bytes to a maximum size of 2 GB.
Structure of the File Content Definition
The FCD (file content definition) uses a tag/attribute structure that is similar, but not identical, to XML. FCD tags commence with the tag name and attributes:
CRLF
They terminate with the tag name preceded by a '/':
CRLF
An abbreviated form is also supported:
CRLF
Tags can be nested:
CRLF CRLF CRLF CRLF
The FCD always contains at least one tag, the siplog tag, and usually contains several. The following tables summarize the tags and their attributes that are supported by version 11 of the FCD.
Table SEQ Table \* ARABIC 24. FCD tags and attributes
TagDescriptionsiplogIdentifies an FFL log file and provides information about the version, server, and log content.Attribute:versionDescription:The FCD version. The current version is "1.1".Attribute:local-fqdnDescription:The fully-qualified domain name (FQDN) of the server. On an Access Proxy, the private network FQDN is used.Attribute:categoriesDescription:A list of logging categories that are enabled in this file. See below for a list of categories.AttributeProduct-buildDescriptionThe version number of the Live Communications Server component that provides the Flat File Logging feature (currently "SIPStack.dll").ExampleTagDescriptionlogtypeLog record definition. All log data is stored according to a log record; hence there must be at least one logtype tag in the FCD in order to store any data in the log.AttributenameDescription:Log record type name. The currently supported types are as follows:protocolSIP messageseventNT application eventssecurityData that may indicate a server is under attackconnectionData related to network connectionsDNSDatea related to DS Srv queries (Access Proxy only)diagnosticData for diagnosing server problemsExample:See tag example.TagDescriptionFieldA field within a log record. This tag is always nested within a logtype tag.Attribute:nameDescription:Name of the field.Example: this field is present in all log record types
The FCD ends where the log data begins, or at the end of the file, whichever occurs first.
Structure of the Log Data
The log data is stored in a format that is consistent with the logtype tags that are present in the FCD. Each log record starts and ends with a special delimiter, as follows:
$$begin_record CRLFLogType: SP logtype-name CRLFfield-name: SP server-data CRLFfield-name: SP server-data CRLF$$end_record CRLF
Any character that appears outside the $$ record delimiters is invalid and is ignored by the parser.
Each field name must appear in the FCD of the specified log record type. In general, a field may appear zero of more times in a given record, depending on the data available at the time. The "Date", however, is always present in all log record types and is always the first field stored. The format of the date field is as follows:
Date: date time
where date is of the form: YYYY/MM/DDand time is in 24-hour format and is of the form: HHMMSS
For example:
Date: 2004/08/20 22:11:54
denotes a log record that was stored in the file on August 20th, 2004, at 10:11:54 PM GMT.
The server data that appears to the right of a field name can contain any UTF-8 character except ASCII control characters (codes less than 0x20). Any control characters in the server data are transformed according to the following rules:
CR (0x0d) followed by LF (0x0a) is transformed to "\n"; (that is, '\' followed by 'n').
All other control characters, including isolated CR or LF characters, are transformed to a '?'.
There is no way to determine the original value of a control character that has been transformed to a '?' character.
Log Categories
The following log categories are supported by version 1.0 of the FCD and may be listed in the siplog categories attribute:
Table SEQ Table \* ARABIC 25 Log categories
CategoryDescriptionAckRefers to protocol log type records: enables logging of this SIP method.ByeCancelInviteInfoMessageNotifyNegotiateRegisterReferSubscribeServiceAllMsgsRefers to protocol log type records: enables logging of all SIP methods.UnroutMsgReservedEventErrorEnables logging of event log type records with a severity field of "Error".EventWarningEnables logging of event log type records with a severity field of "Warning".EventInfoEnables logging of event log type records with a severity field of "Information".SecurityEnables logging of security log type records.ConnSev1Enables logging of connection log type records with a severity field of "1" (most severe).ConnSev2Enables logging of connection log type records with a severity field of "2".DNSEnables logging of DNS log type recordsDiagErrorEnables logging of diagnostic log type records with a severity field of "Error".DiagWarningEnables logging of diagnostic log type records with a severity field of "Warning".DiagInfoEnables logging of diagnostic log type records with a severity field of "Information".OtherHdrsRefers to protocol log type records: enables logging of all SIP headers under thefield name "Other-Headers".MsgBodyRefers to protocol log type records: enables logging of the message body of selectedSIP methods under the field name "Message-Body".
Configuring Flat File Logging
You can configure flat file logging by using the Live Communications Server 2005 management console. If you prefer to automate the process, you can write a WMI (Windows Management Instrumentation) script. All settings available through the management console are also exposed in the WMI class MSFT_SIPTroubleShootingSetting.
You normally manage flat file logging on a per-server basis. Controls exist to limit the maximum size of the files that are created, as well as to specify the location where the files should be created. Logging is disabled by default and must be enabled by an administrator. The log files must be created in an existing directory, which is accessible by the account under which the Live Communications Server is running (for example, LcService).
By default, Microsoft Windows NT Application Event log events are not duplicated in the flat file log. The administrator may choose to duplicate this information by clicking the appropriate check box. This option is useful if the administrator prefers a single log file with all relevant information in a chronological order.
Using theManagement Console
Use the following procedure to configure flat file logging in the Live Communications Server 2005 management console :
To configure flat file logging by using the management console
Log on to an internal Live Communications Server computer.
Click Start, point to All Programs, point to Administrative Tools, and then click Live Communications Server 2005.
In the console tree, click the Forest node.
Expand subsequent nodes under the Domains node until you reach the domain where the logging server resides.
Right-click the name of the server on which you want to configure logging, and then click Properties.
On the Logging tab, select the Enable Logging check box.
In the Logging Level box, specify the appropriate level, 1 through 4. See Table 24 to decide what level is appropriate.
To specify that Windows NT application event log entries from Live Communications Server are to be copied to the flat file log, select Duplicate Application Event.
In the Log File Folder box, either type the name of the directory where the log file is to be created, or click Browse to browse for the directory.
Type a value in the Create new log when file size reaches box.
Either accept the default value or type a new value in the Create new log when file size reaches box. Acceptable values range from 1 Mb to 2047 Mb.
Either accept the default value or type a new value in the Stop logging when disk usage reaches box. Acceptable values range between 25 and 100.
Either accept the default value or type a new value in the Continue logging when disk usage drops below box. Acceptable values range between 0 and 100.
If you want to close the existing log file and create a new one, click Force Rollover Now. Regardless of whether you click Force Rollover Now, the current log file is always rolled over every day either at midnight or when the size of the current log file exceeds the value entered for Stop logging when disk usage reaches.
Click OK.
Using WMI
To allow scripting of automated actions, all of the settings exposed through the management console are also available through WMI. The following table summarizes these settings:
Table SEQ Table \* ARABIC 26. Logging parameters in MSFT_SIPTroubleshootingSetting WMI class
ParameterDescriptionTypeValidationEnableFileLoggingIf true, logging is enabled.BoolDefault is false (disabled)LogLevelLevel at which the server will log if logging is enabled.Enum1,2,3,4
Default is 1LogFileDirectoryThe directory in which log files are created.StringMust be a valid local file path (same validation as for SPL script path).
Default will be NULL and must set explicitly by the administrator.
The log file names will all be prefixed by lcssiplog.
NOTE: If this setting is empty or NULL, the logging mechanism will not log anything (an error will be reported in the Windows NT Application Event log)MaxFileSizeMaximum log file size in MB. When the log file reaches this size, the file is closed and a new log file is created.uint32Min is 1 MB
Default is 20 MB
Max is 2047 MBLastAdminRolloverTimestamp that signals to the SIP logging module when the administrator has selected to force log file rollover. This property should contain the current date and time specifying when the administrator selected this option from MMC StringEnableEventCopyingControls whether or not Windows NT Application Events are duplicated into the flat file by this logging mechanism.BoolDefault is false (disabled)LowWaterMarkForLowDiskSpaceSee setting definition below.uint32A percentage.
Min is 0
Default is 85
Max is 100
Must be less than the high water mark defined below.
The high level water mark in WMI should not be set higher than 90 percent. The low water mark should be at least 5 percent different (85 percent).
Registry Key
Under normal operation, level 2 logging logs the REGISTER requests sent by the client as part of the logon operation (and periodically re-sent as a way of verifying the connection between client and server). This traffic represents a large portion of the messages logged at level 2. If you are not interested in this specific traffic but would like to log the other information that is logged at level 2, it is possible to disable logging of the REGISTER request through a registry key on the server. As with all registry keys, this value should be modified with caution.
The registry key is FFLDisableRegisterAtLevel2 in System\CurrentControlSet\Services\RtcSrv\Parameters (DWORD interpreted as Boolean). The registry key changes the FFL behavior only if both of the two following conditions are met:
The registry key is present and nonzero.
The FFL logging level is 2.
Associated Tools for Flat File Logging
Two tools provided in the Resource Kit for Live Communications Server 2005 can be used in conjunction with Flat File Logging:
LCSError.exe translates the error codes in the FFL files into human readable strings.
SipView.exe reads and searches through large FFL files for specific events of interest.
For details, see the documentation in the Resource Kit.
Recommended Usage of Flat File Logging
All Access Proxies and Directors should use Flat File Logging level 1 all the time. Level 1 will log the critical security events for these servers, which are your first and second levels of defense against an external attack against your deployment. These log files should be archived periodically (daily or weekly) and regularly monitored either by script or in conjunction with another monitoring tool. such as Microsoft Operations Manager (MOM).
Messenger Policies
The Windows Messenger SIP Service Provider supports a number of specific Group Policy objects including Maximum Bandwidth policies and port range policies specific to the RTC Client functions.
To edit the Group Policies for Live CommunicationsServer
Copy RtcClient.adm from the \Server directory of the Live CommunicationsServer distribution media to the %windir%\inf folder.
Open Active Directory Users and Computers (dsa.msc).
Right-click the domain name, and then select Properties.
Click the Group Policy tab.
Select New, and then type in a name that will describe the policies, such as LiveServer Policies.
Highlight the new policy, and then click Edit.
Under Computer Configuration, select Administrative Templates.
From the Action menu, select Add/Remove Template.
Select Add, and then select RtcClient.adm from the list.
Click Close to return the Group Policy Object Editor. Policies for both Computers and Users are added and can be edited for the domain.
The Messenger policies described in the following table can be set for either the computer or its users, but the computer configuration overrides the users configuration. The policies are not installed initially; they take the default Not Configured or Disabled states. The default behavior is described in the following table. See HYPERLINK \l "_Messenger_Policy_Keys" Messenger Policy Keys for the specific location of the policies in the Registry.
Table SEQ Table \* ARABIC 27. Messenger policies
PolicyDefault StateDescription of Default BehaviorPrevent users from running WindowsMessengerDisabledMessenger is enabled.Prevent initial, automatic start of WindowsMessenger DisabledThis policy currently has no effect. Messenger will not auto-start regardless of the setting. Prevent connection to Microsoft Windows .NETMessenger ServiceDisabled.NET Messenger service can be used.Prevent connection to SIP Communications Service DisabledThe RTC Messenger service can be used.Prevent connection to Exchange Messaging Service DisabledThe Microsoft Exchange Instant Messenger service can be used.Prevent video calls DisabledEnabling this policy prevents the use of video from Messenger. (Note that video is not supported on Microsoft Windows 2000 clients.)Prevent computer-to-computer audio calls DisabledEnabling this policy prevents direct computer to computer audio calls.Prevent computer-to-phone audio calls DisabledEnabling this policy prevents computer-to-phone audio calls from Messenger. This policy is here for earlier versions and should not be used. Allow computer-to-phone callsNot ConfiguredEnabling this policy allows computer-to-phone calls. This policy has the opposite effect of Prevent computer-to-phone audio calls. This is the preferred method to set the policy.Prevent file transfer DisabledFile transfers are enabled.Prevent collaboration features DisabledApplication sharing and whiteboard features of Windows Messenger are enabled. On Windows 2000 computers, SP4 or later is required for collaboration feature support. Prevent Microsoft Windows NetMeeting EnabledNetMeeting is disabled in Messenger.Specify instrumentation Not ConfiguredIn the default, Not Configured state, the user controls the setting of instrumentation. Setting this policy to either enabled or disabled overrides any settings the user might have made. Enabling the policy enables the recording of user actions (instrumentation). Disabling this policy disables instrumentation. Prevent automatic update from .NET Messenger Service DisabledAutomatic update of Windows Messenger through the .NETMessenger service is enabled.Prevent Ink (Microsoft WindowsXP TabletPC Edition) in instant messagesNot ConfiguredInk messages are enabled in instant messages.
The Windows Messenger Live CommunicationsServer policies described in Table 29 can be set for either the computer or under users, but the computer configuration overrides the users configuration.
Table SEQ Table \* ARABIC 28. Messenger Live CommunicationsServer specific policies
PolicyInitial StateDescriptionRequire logon credentialsDisabledBy default, the users Windows logon credentials are used. When enabled, the user must explicitly provide Messenger logon credentials.Allow additional server DNS namesNot ConfiguredAllows WindowsMessenger to automatically detect and securely communicate with SIP servers that have non-standard fully-qualified domain names (FQDNs).Specify encryption for computer-to-computer audio and video callsNot ConfiguredBy default, audio and video calls can be either encrypted or unencrypted. When enabled, the policy can specify whether encryption being supported (the default behavior) is required or is disallowed. When disabled, encryption is supported but not required. Note: This is for WindowsXP only.Require SIP high-security modeDisabledBy default, WindowsMessenger can use UDP, TCP, or TLS for SIP communication, and NTLM or Kerberos for authentication. Outgoing peer-to-peer communication not is allowed. When enabled, TLS is required and peer-to-peer is disabled. (For more information see HYPERLINK \l "_Security"SIP Service Provider Security .)Allow storage of user passwordsNot ConfiguredBy default, users who do not log onto the domain can store passwords. When enabled, WindowsMessenger can store the users password when requested. When disabled, no passwords are stored. Specify transport and serverNot ConfiguredBy default, the user can either specify configuration or accept auto configuration. When enabled, the user must specify both the transport used and the server FQDN to determine the server FQDN and transport. When disabled, a DNS lookup is used.
Table SEQ Table \* ARABIC 29. RTC Client API Policies
PolicyInitial StateDescriptionLimit bandwidth for audio and video callsDisabledBy default, the maximum bandwidth available is used. When enabled, this policy allows setting the maximum bandwidth used for audio and video calls. Default value is 205 kilobits per second. The maximum is 100 Mbps. Specify dynamic port rangesDisabledBy default, the client application (for example, Windows Messenger) will use a randomly selected port between 1024 and 65535 for SIP signaling and media traffic. Enabling this policy makes it possible to specify minimum and maximum port addresses used for dynamic port allocation. Default is 7100 minimum and 7103 maximum for SIP traffic; 5350 minimum and 5353 maximum for media.Enable CRL (Certificate Revocation List) checkingChecking EnabledIf CRL checking is set to CheckingEnabled (the default), the client will try to obtain access to the CRL and, if successful, will check the servers certificate. If the policy is set to CheckingStrictlyEnforced, the client will establish a TLS connection only if the CRL is obtained and the server certificate is verified against it. If the policy is set to CheckingDisabled, the client will not attempt to check the server certificate before connecting.
Registry Keys
Important
This section contains information about the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, see the following article at http://support.microsoft.com
256986 Description of the Microsoft Windows Registry
Messenger Policy Keys
Tables 23 through 26 list the registry keys used by Windows Messenger 5.1 client. Keys are stored in both the User hive and the Machine hive, with the machine hive key taking precedence.
Additional User keys that are legacies from Messenger 4.6 are also honored. They reside in:
HKCU\Software\Microsoft\RTCIMSP
HKCU\Software\Policies\Microsoft\Messenger\Client\
HKLM\Software\Policies\Microsoft\Messenger\Client\
Table SEQ Table \* ARABIC 30.Messenger policy keys
KeyTypeDescriptionOptionsHKEY_CURRENT_USER\Software\Policies\Messenger\Client
HKLM_CURRENT_USER\Software\Policies\Messenger\ClientCEIP REG_DWORDControl the behavior of instrumentation (Customer Experience Improvement Program).0 = Let the user decide if instrumentation is enabled (default)1 = Turn on instrumentation and remove all UI references2 = Turn off instrumentation and remove all UI referencesCorpPC2PhoneREG_DWORDSpecifies which version of the dialer is be used.0 = Disable entry points regardless of DisablePC2Phone setting (default)1 = Entry points are available and bring up corp dialer (unless DisablePC2Phone setting = 1)DisableCollaboration
AppsREG_DWORDDisables access to AS and WB. Auto-declines invites to these.0 = DC is Enabled (default)1 = DC is DisabledDisableFileTransferREG_DWORDSpecifies if File Transfer can be used.0 = FT is Enabled (default)1 = FT is DisabledDisableInkIMREG_DWORDThis DWORD determines if the user can send and receive Ink IM.0 = Ink is Enabled (default)1 = Ink is DisabledDisableNMREG_DWORDDisable access to Netmeeting.0 = Entry points are visible and user can accept invitations (default)1 = Entry points are disabled and invitations are auto-declinedDisablePC2PCAudioREG_DWORDSpecifies if PC-to-PC audio calls can be made.0 = Audio is Enabled (default)1 = Audio is DisabledDisablePC2PhoneREG_DWORDSpecifies if PC-to-Phone calls can be made (removes entry points).0 = Phone entry points are enabled if CorpPC2Phone is set to 1 (default)1 = Phone entry points are disabled, regardless of the CorpPC2Phone settingDisableVideoREG_DWORDSpecifies whether video calls can be made.0 = Video is enabled (default)1 = DisabledPreventAutoRunREG_DWORDControls whether other applications can cause Windows Messenger to start automatically when user logs in.0 = Allows other applications to cause Windows messenger to start automatically when user logs in (default)1 = Prevents other applications from causing Windows Messenger to start automatically when user logs in PreventAutoUpdate REG_DWORDPrevents download of new versions of Messenger advertised by the .NET Service.0 = Allow autoupdate of Messenger client
1 = Block autoupdate of Messenger client (Default)PreventRunREG_DWORDControls whether the Messenger client is allowed to start at all.0 = Messenger can be started (default)1 = Messenger cannot be started
Table SEQ Table \* ARABIC 31.Windows Messenger 5.0 .NET GUID
KeyTypeDescriptionOptionsHKCU\Software\Policies\Microsoft\Messenger\Client\{9b017612-c9f1-11d2-8d9f-0000f875c541}
HKLM\ Software\Policies\Microsoft\Messenger\Client\{9b017612-c9f1-11d2-8d9f-0000f875c541}{.NET GUID}\DisabledREG_DWORDDisables connection to .NET Messenger Service and disables associated UI (including .NET Messenger display name and account settings).0 = Can connect (default)1 = Cannot connect
Table SEQ Table \* ARABIC 32.Windows Messenger 5.0 .Exchange GUID
KeyTypeDescriptionOptionsHKCU\Software\Policies\Microsoft\Messenger\Client\{83D4679E-B6D7-11D2-BF36-00C04FB90A03}
HKLM\Software\Policies\Microsoft\Messenger\Client\{83D4679E-B6D7-11D2-BF36-00C04FB90A03}{Exchange GUID}\DisabledREG_DWORDDisables connection to Exchange IM and the account settings user interface.0 = Can connect (default)1 = Cannot connectProxy Keys
The following are the Proxy Registry Keys supported by Live Communications Server 2005:
Table SEQ Table \* ARABIC 33. Proxy Registry Keys
KeyTypeDescriptionOptionsHKLM\System\CurrentControlSet\Services\RTCSRV\ParametersAUTHTimeoutSAIncompleteDWORDTimeout for incomplete Security Association (SA) - the client needs to complete the authentication handshake in this period of time.Min: = 1
Max: = 300
Default: = 30AUTHTimeoutKerberosDWORDTimeout for idle Kerberos SA--the server must receive or send a message (those operations indicate that the client is still active) from or to the client in this period of time.Min: = 1
Max: = 8*3600
Default: = 8*3600AUTHTimeoutNTLMDWORDTimeout for idle NTLM SA--the server must receive or send a message (those operations indicate that the client is still active) from or to the client in this period of time.Min: = 1
Max: = 8*3600
Default: = 8*3600AUTHTimeoutSAExpirationDWORDTimeout for SA expiration after this period the server forces the client to send again its credentials in order to renew its SA with the server.Min: = 1
Max: = 8*3600
Default: = 8*3600ProxyDefaultTCPDWORDShould use TCP as the default protocol.No: = 0
Yes: = 1
Default: = 1ProxyMaxConnTmoutDWORDMaximum timeout for establishing connections.Min: = 10000
Max: = 60000
Default: = 32*1000ProxyConnHighMarkDWORDNumber of establishing connections that will trigger the decrease of the timeout.Min: = 5000
Max: = 100000
Default: = 5000ProxyConnLowMarkDWORDNumber of establishing connections that will trigger the increase of the timeout.Min: = 1000
Max: = 100000
Default: = 1000ProxyMaxConnLifetimeDWORDMaximum lifetime of a connection in milliseconds.Min: = 30*60*1000
Max: = 0xFFFFFFFF
Default: = 24*60*60*1000TrustedNameTTLDWORDDefault maximum TTL in seconds for trusted server name resolution. Will retry name resolution after this interval unless DNS tells us to retry faster.Min: = 60
Max: = 0xFFFFFFFF
Default: = 30*60STACKHeadersLenDWORDThe maximum header length for an incoming message (in thousands).Min: = 1
Max: = 64
Default: = 64ThrottleQueueTimeLowMarkDWORDThe throttling low watermark for message processing time (in msec).Min: = 1000
Max: = 10000
Default: = 3000ThrottleQueueTimeHighMarkDWORDThe throttling high watermark for message processing time (in msec).Min: = 2000
Max: = 20000
Default: = 6000ThrottleQueueTimeOverloadDWORDThe throttling overload mark for message processing time (in msec).Min: = 3000
Max: = 30000
Default: = 15000ThrottleMaxClientQueueDWORDThe maximum number of messages allowed in the queue from single user connection even when not throttling.Min: = 1
Max: = MAXLONG
Default: = 10ThrottleMinServerQueueDWORDThe minimum number of messages allowed in the queue from trusted server connection even when throttling.Min: = 1
Max: = MAXLONG
Default: = 100NegotiateTimeoutDWORDThe timeout for the compression negotiation requests initiated by this server (in msec).Min: = 1
Max: = 120000
Default: = 5000DisableTlsOptimizationDWORDDisable peeking into TLS packet.Min: = 0
Max: = 1
Default: = 0EnableMessageBodyTracingDWORDEnable tracing message body.Min: = 0
Max: = 1
Default: = Dbg=1/Free=0
The New BENOTIFY Request
BENOTIFY (short for Best Effort NOTIFY) is a proprietary SIP method introduced by Microsoft in Live Communications Server 2005 to reduce unnecessary SIP signaling traffic on application servers. Unlike the NOTIFY method, BENOTIFY doesnt require a response. Applications that dont need a response for a NOTIFY requestsay, because they keep track of information synchronization at the application layercan enhance performance by enabling BENOTIFY. The feature is especially important for deployments with large numbers of clients per server.
A Live Communications Server 2003 client that is configured to acquire presence information for entries on the users Contact list sends a SUBSCRIBE request to a Live Communications Server home server. The server replies by sending the client a NOTIFY request every time presence changes for each contact on the list. The client responds to each NOTIFY request, which creates an unnecessary load on the server.
Because all Live Communications Server SIP communications are carried over reliable TCP connections, there is no need for the server to reply to every NOTIFY request. Therefore, client responses to all NOTIFY requests other than 481 (Call Leg/Transaction Does Not Exist) are useless. Yet NOTIFY responses generate more that 50 percent of the messages between client and server. In addition, if processing on the server temporarily stalls, responses to NOTIFY requests accumulate in socket and TCP buffers, thereby directly affecting the number of simultaneous users the server can support.
In Live Communications Server 2005, the server tracking presence issues a BENOTIFY request instead of a NOTIFY request only if the client has a single-hop connection to a server running Live Communications Standard Edition or Enhanced Edition. Communication between registration points inside an Enterprise pool usually use BENOTIFY, while notifications between registration points in different Enterprise pools and federated links use the standard NOTIFY request.
Both server and client take special precautions to clean up obsolete state information. When a client receives a BENOTIFY message with an unknown CALLID (thus mitigating the lack of a 481, Call Leg/Transaction Does Not Exist, response), it explicitly unsubscribes by sending a SUBSCRIBE with the header (Expires:0). Both the client and the server maintain sequential ordering of the transmitted information in order to discover and recover from potential losses in a timely way.
Supporting BENOTIFY
You can use a global setting to disable or enable BENOTIFY on the server. If enabled, when a client issues an OPTIONS request, the server indicates its support for BENOTIFY.
Client support for BENOTIFY is optional. A client that supports BENOTIFY adds the ms-benotify value to the Supported and Proxy-Require headers of the SUBSCRIBE message. Depending on local policy and whether the client has a single-hop connection, the server responds. Otherwise, the server doesnt echo the ms-benotify tag, and instead uses standard NOTIFY request on this dialog.
If a client indicates support for BENOTIFY, the server uses BENOTIFY to send presence information to the user. The client should be prepared to receive and handle regular NOTIFY messages for subscriptions to a list marked as best-effort. This is because some of the contacts in the list may reside on different servers, which may not support BENOTIFY.
If the client does not explicitly express support for BENOTIFY when sending SUBSCRIBE, the server automatically reverts to normal SIP NOTIFY behavior.
SIP Traffic Flow Through an Enterprise Pool
The two diagrams below illustrate the flow of SIP traffic through an Enterprise pool. Figure 4 shows how an Enterprise pool processes a REGISTER request from a client. Figure 5 shows how an Enterprise Pool processes IM traffic.
Figure SEQ Figure \* ARABIC 4. Path of Register request, authentication, and logon in a Live Communications Server 2005 Enterprise Edition Pool
EMBED Visio.Drawing.11
Figure SEQ Figure \* ARABIC 5. Instant message routing in a Live Communications Server 2005 Enterprise Edition Pool
Adding, Removing, and Modifying Performance Counters
You can add, remove, or modify performance counters displayed in the Live Communications Server 2005 management console by editing the file ServerPerfmon.xml, which is located at %localdrive%\Program Files\Common Files\Microsoft LC 2005, where localdrive is the system drive. As shown in the following code block, ServerPerfmon.xml lists the default performance counters installed for each server type:
Server types, or roles, are specified as follows:
where
EE = Enterprise Edition
SE = Standard Edition
AP = Access Proxy
PROXY = Proxy
ARCH = Archiving
Performance counters are specified as follows:
Each performance counter has two attributes, scaleFactor and path. Both attributes appear in the MMC (Microsoft Management Console) Performance Monitor.
Scale represents the visual scale of a counter in the Performance Monitor graphic display relative to that of other counters also being displayed. Each counter has a default scaleFactor that represents the scale at which the counter display is most likely to be useful, but this value can be adjusted as needed. The scaleFactor value is a power of 10. That is, a scaleFactor of 0 equals 100 or 1, 1 equals 101 or 10, and so on. Negative values are also valid.
Path represents the path to the performance counter.
You can use Performance Monitor to determine both the default scale and path of a performance counter.
To determine the scaleFactor and path of a performance counter
On the server where you want to modify the performance counters displayed in the Live Communications Server 2005 management console, click Start, select Run, and then type perfmon.
Right-click anywhere in the results pane, and then select Add Counters.
In the Add Counters dialog:
Click Use local computer counters.
Select a performance object from the Performance object list.
Select one or more counters from the list.
Click Add.
Click Close. The newly selected counter appears in the counter list.
In the counter list, click the name of the performance counter you have just added.
Note the value for that counter under in the Scale column. This value is the default scale for that counter. The corresponding scaleFactor can be calculated as follows:
If the scale is greater than zero, the scaleFactor is the number of zeroes to the left of the decimal point. For example, if the scale is 1000, the scaleFactor is 3.
If the scale is less than zero, the scaleFactor is the negative of the number of zeroes to the right of the decimal point. For example, if the scale is 0.0001, the scaleFactor is 3.
Right-click the counter, and select Properties.
On the Data property page, the path for each counter appears in the Counters list. Copy the appropriate path, omitting the initial backward slash (\). In other words, if the path in the Counters list is: \Processor( :T o t a l ) \ % P r o c e s s o r T i m e
t h e p a t h y o u w i l l a d d t o S e r v e r P e r f m o n . x m l w i l l b e : P r o c e s s o r ( :T o t a l ) \ % P r o c e s s o r T i m e
C l i c k O K , a n d e x i t P e r f o r m a n c e M o n i t o r .
T o a d d a p e r f o r m a n c e c o u n t e r t o t h e L i v e C o m m u n i c a t i o n s S e r v e r 2 0 0 5 m a n a g e m e n t c o n s o l e
O p e n S e r v e r P e rfmon.xml in Notepad or another XML text editor.
Beneath the appropriate server type, add a new element for the counter added in Performance Monitor, using the format:Using the example from step 9 in the previous procedure, the new counter element for the Processor Time counter would be as follows: