By: Jeff Schertz
Posted:
June 9, 2010 at 10:25 AM
In a follow-up to some of the features I briefly mentioned in a previous article here is a more in-depth look at some additional new features currently in the CS ‘14’ beta software which have been covered in various presentations throughout TechEd 2010 this week. I’ve just scratched the surface with most of these topics, but it should help explain what some of the buzz-words like SBV, CAC, and Registrar mean.
Enterprise Voice Features
Site Resiliency
With the addition of a ‘Site’ component in Communications Server user services can now be balanced and protected against device and site failures by associating users with more than one location. Data Center and main office locations with full CS server deployments are defined as a Central Site while small and medium remote offices where a Survivable Branch Appliance (SBA) is installed is deemed a Branch Site. Each Enterprise Voice enabled user is then associated with a primary site and secondary, backup site automatically by virtue or simply registering with the primary site under normal conditions.
One of the new server components found in the Front-End server role is the Registrar. I will cover that component and the core changes involved in a later article, but for now it’s important to understand the Registrar service handles Communicator end-point login and connections to CS. This component lives on both a Front-End server role (both Standard Edition and Enterprise Edition) and on an SBA. When CS end-points perform automatic SRV lookup they can now leverage multiple response, ordered by priority, which now gives clients the ability to look for services on another host in the event the primary host is unreachable. This feature offers the ability to provide highly-available services to users leveraging a secondary pool in the same site or disaster recovery protection by using yet another pool in a different site.
For clients located in a branch office with the SBA configured as their primary registrar those users can be serviced by another pool in a central site in the event that the SBA fails. In the case of a WAN outage or loss of connection to the primary pool in the central site the branch office users are still signed-in to their Communicator client, but only Enterprise Voice features are available along with peer-to-peer communications between users in that ‘orphaned’ office location.
It is important to understand that the SBA is simply a registrar and not a full pool, only limited services are provided by the SBA, mainly with the intention of handling user registration and voice dialing features via the PSTN in that branch location.
Call Admission Control
Call Admission Control (CAC) is basically a fancy name for bandwidth management of voice call routing, which determines whether or not an audio or video session can (and should) be established based on taking real-time measurements of the network conditions. It is applied to media flow traversing LAN/WAN network segments but does not extend out to communications across the Internet or PSTN. The egress point of Communications Server (the Edge Server or the media gateway) is where the boundaries lie for CAC functionality.
CAC policies can be defined by administrators to set maximum values for total bandwidth for audio and video (independently) as well as the maximum possible bandwidth allocated to a single audio or video call (again, separate settings). In the scenario of a highly congested WAN link between two remote sites video calls may be disabled by CAC in order to prevent any poor communications experiences and provide users with the option to select alternative methods before ever having a ‘bad call’. And in the same scenario audio calls would automatically be routed via the PSTN if both locations have their own PBX or some other form of PSTN connectivity. Audio quality changes may be noticed at that point as RTA would be changed to G.711 for PSTN call routing, but the switchover is otherwise transparent to the users.
Mediation Server Bypass
This feature (also referred to simply as media bypass) offers bandwidth savings and can help improve call quality by reducing latency, removing transcoding, and minimizing the potential for additional packet routing problems to impact the communications.
Multiple Gateway Support
Unlike previous in versions of OCS where a mediation server could only be configured to communicate with a single gateway the Mediation Server role can now configured to handle multiple routes so many media gateways can be configured to route calls to the same Mediation Server. This can greatly reduce the amount of on-site hardware required in some distributed deployment scenarios.
Caller ID Manipulation
The Caller ID information can be customized on outbound calls placed by all users or any number of specific users or groups.
E911
Support for enhanced emergency services dialing is now provided by a combination of location services solutions which can be defined both by administrators and Communicator users themselves to provide proper location information in the event that a 911 call is placed from Communications Server.
Private Telephone Lines
A user (typically an executive) can now be configured with a second private telephone number which would not be listed anywhere in the directory for other users to browse and identify it. A special ring is associated with incoming calls directed to the private line number, and none of the advanced features (call forwarding, team ring, RGS, etc) are available. Private calls also do not adhere to Do Not Disturb presence rules and will always ring through to the user if they are signed-in. Outbound calls from teh user will still appear from their primary number, the private number will only be used to route inbound calls and thus further protect the number from becoming known to undesired users.
Common Area Phones
Because the Polycom CX700 (Tanjay) device has always required a user to sign-in it has never been a good solution for open areas and shared workspaces to provide telephony services. With CS ‘14’ come a host of new telephony end-points from various partners including Polycom and Aastra. Some photos of the latest Polycom devices can be seen on fellow MVP Mike Stacy’s blog.
These devices can register directly to Communications Server using a dedicated AD object and provide for, at minimum, voice services at all times. Additionally CS Enterprise Voice enabled users can log into some devices using a PIN, brining their number and presence over to the device until they either sign-out or a time-out period is reached in which the phone reverts back to the standard number.
Call Management
The Response Group Service contains a host of new features. Anonymous Calling allows agents to accept and place calls without showing their identity. Attendant Routing Method offers a configuration setting in which all RGS agents will receive an incoming call simultaneously, regardless of their current presence. The RGS management controls have been brought into the same tools as the rest of the CS components, the CS Shell (PowerShell) and CS Control Panel (CSCP). Richer IVR configurations and prompts provide more options to customize Response Group attendants.
The Announcement service has been updated to handle unassigned number routing rules so that if inbound calls to valid, but unassigned DIDs are routed to Communications Server the routing and response to those calls can be handled as desired instead of just dropping the calls or forwarding them all to a single primary number.
A Call Park feature has been added to allow users to put a voice call on hold and then pick it up on another endpoint without having to forward the call.
Outbound Route Translation
And saving the best for last (IMO) is a topic near and dear to my heart, normalization. As it is still best practice to design numbering plans and normalization rules to fully conform to RFC3966 standard (E.164 with the ‘+’ prefix) there will still exist the scenarios where the connected telephony system cannot handle some digits (as in the ‘+’) or the device cannot (or the administrators will not) allow changes to the numbering plans or rules.
In previous versions only the ‘+’ could be stripped off by the Mediation server just prior to leaving OCS, but that was it. With CS ‘14’ multiple rules can be added to further manipulate URIs just prior to routing to the gateway. This mean digits can be added, stripped, or replaced using RegEx patterns. This is very advantageous when dealing with Direct SIP deployments where no media gateway is available to provide additional number manipulation.
This single feature addition alone should be the last nail in the coffin of any Communications Server deployments in which RFC3966 complaint numbers are not utilized.
By: Jeff Schertz
Posted:
June 7, 2010 at 10:41 AM
Right now I’m down at TechEd 2010 in New Orleans, LA where the keynote address is in progress. Microsoft has now officially lifted the Non-Disclosure Agreement (NDA) on all features and content which will be coming in the next release of Communications Server, which is still dubbed ‘Microsoft Communication Server 14’. The ‘14’ refers to the internal Wave 14 codename which has been used since the birth of this iteration of code.
I’m going to try and provide a very brief feature overview while I have a few minutes between sessions and booth duty today, but look for some deeper reviews of the content in the coming days and weeks. In fact, if you are attending TechEd 2010 this week, stop by the UNC area of the Microsoft Yellow Section between 2:30PM and 5PM tomorrow or Wednesday and I can personally answer any questions you may have regarding the new feature set. I’ll also be at the booth during this evening’s reception.
New Server Features
Supported Operating Systems are listed as Server 2008 SP2 64-bit and Server 2008 R2 64-bit. Nothing new here.
Topology Changes
- Communications Servers Sites
- Geographical locations can be defined in CS as sites, as either a central or branch site.
- New Server Role Collocation Options
- The A/V Conferencing Front-End role can be separated on dedicated hardware, providing a single expanded scenario. Microsoft recommends separating the A/V conferencing workload from the rest of the consolidated Front-End servers in large deployment (10,000+ users). For the standard small/medium business deployment a single consolidated server can be ideal.
- The Mediation Server role can now be collocated on the Front-End server and is a recommended configuration unless utilizing SIP Trunking or Direct SIP scenarios. So deployments leveraging a media gateway can benefit from the reduced hardware costs of separate Mediation Servers .
- The Archiving and Monitoring Server roles can also be collocated with the Front-End server in smaller deployments.
- Survivable Branch Appliance (SBA)
- Many of these branch hardware devices have already been announced by some partners like Dialogic and Audio codes.
- Revamped Director Role
- The Director is now a separate role and isn’t just a stripped-down Pool server. It also uses SQL Express installed local and does not require a separate SQL back-end database, which previously caused deployment headaches due to the SQL database name conflicts with an existing Front-End database.
Management & Administration Tools
- New Management Tools
- The MMC-based management shell (LCSCMD) has been replaced by the Communication Server Management Shell which is a PowerShell based console similar to the Exchange Management Shell.
- The MMC-based management console has been replaced by the Communication Server Control Panel (CSCP) which is a Silverlight-based web interface, similar to the Exchange Server 2010 Control Panel (ECP).
- Roles-Based Access Control
- Again, taking a page from the Exchange Server 2010 book, another similar feature. We see yet some more ‘unification’ of the UC products here.
- Central Management Store
- Organization-wide configuration data for servers is now stored in a new schematized database, outside of the traditional Active Directory configuration and Domain containers as previous versions of LCS and OCS.
- Edge Server deployment is simplified by allowing the Central Management Store to push configuration data to workgroup Edge servers located in perimeter networks.
- DNS Load Balancing
- All SIP and media traffic will utilize standard DNS load balancing. HTTP traffic will still require hardware load balancers but moving the complicated media paths away from HLBs greatly simplifies the deployment ands= also expands the supportability to and HLB solution which can handle standard HTTP traffic.
- Server Draining
- When taking a server offline for maintenance active connections to it can be drained and moved to another node in the pool.
I need to run off to some CS sessions this afternoon, but in a later post I’ll review many of the new Client-side features and remaining Server-side features, like Enhanced Voice Resiliency, Call Admission Control, E911, Mediation Server Bypass, Call Park, Music on Hold.
By: Jeff Schertz
Posted:
May 17, 2010 at 1:03 PM
The purpose of this article is to serve as a lessons-learned addendum to the current primary resource for configuring OCS and GMail federation: the Communication Server team’s official blog post on the subject. Following the detailed steps in that article should get you to a working end-state, but if a specific deployment differs from the directions in any way, sometimes it is hard to tell which of the documented settings are recommendations and which are requirements. I will address each of the steps with additional details that should help explain the requirements and back-ends processes in a bit more detail.
Component Topology
Borrowing the diagram from Microsoft’s documentation, let us look at the different components:
- Gmail
- The Gmail cloud consistent of a farm of (at last count) 5 different GoogleTalk hostnames overlapped among 3 unique IP addresses. It’s not clear if three of the servers are sharing some type of load-balanced DNS/IP configuration or if some of the hostnames are actually redundant hosts. As with all things ‘cloud’ there isn’t much know about what’s actually inside it, but that is not important when configuring the OCS XMPP server. It is helpful to know the source traffic’s hostnames and IP address when troubleshooting.
- xmpp-server.l.google.com, 74.125.45.125
- xmpp-server1.l.google.com, 74.125.155.125
- xmpp-server2.l.google.com, 74.125.47.125
- xmpp-server3.l.google.com, 74.125.45.125
- xmpp-server4.l.google.com, 74.125.45.125
- Edge Server
- The normal Edge Server requirements still apply here, so the best practice deployment in a perimeter network with two interfaces on different TCP/IP networks is recommended. Let’s not start cutting corners here; don’t make me write yet another Edge Server article ;)
- XMPP Gateway
- A single Windows Server with no requirement of multiple network interfaces. A single interface can be used to handle both external (Gmail) and internal (OCS Edge) communications. But if your perimeter network configuration requires two interfaces to properly route traffic in a specific scenario, then 2 separate interfaces can be used and is supported.
- Network Address Translation is supported, and will be used in this example deployment. But by all means, if a public IP address needs to be assigned directly to an XMPP gateway server interface then communications will work just as well.
Communications Topology
Now we can take a closer look at the actual communication paths utilized end-to-end:
Following the example above, the communications steps for a Gmail user attempting to send an instant message to someone in our contoso.com example OCS organization:
- Any one server in the GoogleTalk farm will attempt to locate the contoso.com SIP domain services by looking for a specifically defined DNS Service Locator (SRV) record named _xmpp-server._tcp.contoso.com. This record would be configured to point to a DNS Host (A) record for the XMPP gateway’s public FQDN. This can be any name desired. It is recommended to use an A record in the same domain namespace as the SRV record, but this is not a requirement. (Apparently Strict DNS Naming is not required by the XMPP server.) The name xmpp.contoso.com is used in this example.
- The GoogleTalk server will then attempt a standard TCP connection to xmpp.contoso.com over port 5269. This is not a secured connection, so there are no certificate requirements on this first leg of communications. This connection is typically handled by an external firewall which is performing Network Address Translation (NAT).
- This request is routed by the firewall to the XMPP server’s single interface which is actively listening on 5269 on its only configured IP address (10.11.12.40). The connection continues to be unsecure.
- Once the XMPP gateway handles the request it will look at its SIP Configuration to locate an appropriate next hop, which would be configured as the Access Edge FQDN (sip.contoso.com). Based on the DNS configuration of the XMPP server it may be appropriate to configure a local HOSTS entry on the XMPP Server for the Access Edge FQDN to connect directly to the perimeter IP (10.11.12.33). If the public IP is resolved then the communications may fail; this traffic should not be routed outside the firewall and back in, it should stay within the perimeter network.
- The connection is established with the Access Edge server on it’s Federation listening port of 5061, over MTLS as a certificate is utilized for XMPP Server to Edge Server traffic. The XMPP server must connect to the Access Edge using the Federation port and NOT the internal Edge interface. This is one of the most common deployment mistakes: attempting to configure the XMPP server to communicate with the Edge server’s internal interface.
- For outbound traffic to GoogleTalk, the Edge Server simply treats the gmail.com SIP domain as any other federated domain. The configuration would denotes that traffic to gmail.com should be xmpp.jds.local in this example. For this portion of communications to properly function there are a few very important aspects to cover:
- Most importantly a certificate needs to be installed and configured on the XMPP gateway.
- This is only used for communications between the XMPP and Edge servers, NOT for any external communications with GoogleTalk servers. Thus an internal private CA can be used to request the certificate for the XMPP server, and any root/issuing CA certificates must be imported onto the XMPP server just as would have been done with the Edge server.
- An easy way to get a certificate on the XMPP server is to use the OCS Certificate Wizard on the Edge server (as the XMPP server does not include the wizard) and then just export and import the certificate with the private key to the XMPP server.
- Secondly, the certificate must be issued to the XMPP server’s exact hostname.
- The Microsoft configuration article linked at the top of this blog article discussed that the Primary DNS suffix of the XMPP gateway needs to be configured with something, as an FQDN is required here.
- What the article does not clarify is that XMPP server’s FQDN must utilize the actual server hostname; you cannot just select any secondary name for the XMPP server and configure the certificate, DNS resolution, and the Edge server’s Allow list entry to just anything. More simply stated: the XMPP server’s configured FQDN, certificate CN (or SAN entry) and the Edge server’s Allow list entry for gmail.com must all be set to the actual server’s fully qualified hostname. Because the XMPP server hands this name out during communications it is a hard requirement
- Lastly, if a single XMPP server FQDN configuration is attempted, instead of using separate private and public as in this example, then:
- Microsoft’s article states that the public FQDN could be used here instead, but the external firewall would need to be configured to allow outbound traffic from the Access Edge server to loop back into the firewall and then connect to the XMPP server over 5061. Normally only traffic destined to 5269 would be allowed in from the Internet.
- This configuration is least desirable as it is best practice to keep all XMPP<>Edge communications internal, just as discussed above in step #4. But since the leg of the communications is encrypted then routing it out to the Internet temporarily does not impose any additional security threat.
- The XMPP server uses the XMPP configuration to locate gmail.com services from it’s Allowed Domain List by resolving the known SRV record _xmpp-server._tcp.gmail.com. Currently the xmpp-server.l.google.com record is configured as the highest priority (set to the lowest value or 5 versus 20 for the other hosts). The XMPP server then connects to that host to complete the entire communication path.
- Success!
Caveats
There are a few items in the current implementation of the XMPP services which should be understood:
- Only a single SIP domain per OCS organization can be configured. This limitation comes from the fact that (1) the XMPP server configuration only has the ability to support a single OCS SIP domain for gateway services and (2) the Edge server Allow list can only point to a single next-hop for the gmail.com SIP domain. So even if multiple XMPP server instance were deployed to support each desired OCS SIP domain, the OCS organization’s single Access Edge server could only point to one of those XMPP servers. There is currently no workaround to this limitation, so typically only the primary SIP domain is configured XMPP services.
- Originally only gmail.com addresses were supported, but in January 2010 Microsoft released a hotfix for the XMPP server which adds support for the googlemail.com SIP domain as well. No configuration changes are necessary on the XMPP server itself after applying the update as it will automatically use the defined route to gmail.com for any communications destined for googlemail.com contacts. But additional configuration is required on the Edge server, as an additional entry must be added to the Allow list properties tab for googlemail.com to point to the same XMPP internal FQDN that was used for the original gmail.com entry.
Troubleshooting
As with anything OCS-related, know where the firewalls are and what traffic they are allowing/blocking. Nearly every deployment I have been involved with almost always has some blocked port, misconfigured policy rules, fat-fingered port number, or some other issue which prevents servers from communicating over the desired ports. If at any point you are struggling it is never a bad idea to eyeball the firewall polices and network diagrams one more time. Occasionally even the smallest mistake can completely prevent communications. For example, I once ran into an issue where OCS was configured to use lm.domain.com (as in Live Meeting) for one of the FQDNs but the hosting provider read the request to create an external DNS record as im.domain.com (as in Instant Messaging) due to the font that was used. In many sans serif fonts an uppercase ‘I’ looks identical to a lowercase ‘l”. < See what I mean?
To test connectivity to various service when testing traffic filtering rules, start with the following:
Name Resolution
Verify that lookup of the GoogleTalk servers is functioning:
C:\>nslookup -type=srv _xmpp-server._tcp.gmail.com
Non-authoritative answer:
_xmpp-server._tcp.gmail.com SRV service location:
priority = 20
weight = 0
port = 5269
svr hostname = xmpp-server2.l.google.com
_xmpp-server._tcp.gmail.com SRV service location:
priority = 20
weight = 0
port = 5269
svr hostname = xmpp-server1.l.google.com
_xmpp-server._tcp.gmail.com SRV service location:
priority = 20
weight = 0
port = 5269
svr hostname = xmpp-server3.l.google.com
_xmpp-server._tcp.gmail.com SRV service location:
priority = 5
weight = 0
port = 5269
svr hostname = xmpp-server.l.google.com
_xmpp-server._tcp.gmail.com SRV service location:
priority = 20
weight = 0
port = 5269
svr hostname = xmpp-server4.l.google.com
Verify that the XMPP server’s SRV and A records exist:
C:\>nslookup -type=srv _xmpp-server._tcp.contoso.com
Non-authoritative answer:
_xmpp-server._tcp.contoso.com SRV service location:
priority = 0
weight = 0
port = 5269
svr hostname = xmpp.contoso.com
C:\>nslookup xmpp.contoso.com
Non-authoritative answer:
Name: xmpp.contoso.com
Address: 12.34.56.78
Port Connectivity
Using telnet and netstat commands a number of test can be performed to validate end-to-end communications are correctly allowed. When using telnet to connect to specific ports if a blank window immediately appears that is an indication of a successful connection. A failed connection will be reported as ‘Connect failed’ after a few seconds. Be aware that return traffic needs to allowed for a successful connection, so often the return packets are accidently filtered by a firewall configuration causing this error.
From the XMPP server telnet to each of the GoogleTalk XMPP listenting ports to verify connectivity.
C:\>telnet xmpp-server.l.google.com 5269
C:\>telnet xmpp-server1.l.google.com 5269
C:\>telnet xmpp-server2.l.google.com 5269
C:\>telnet xmpp-server3.l.google.com 5269
C:\>telnet xmpp-server4.l.google.com 5269
Perform a similar test from an external host to verify inbound communications to the XMPP server:
C:\>telnet xmpp.contoso.com 5269
From the XMPP server test connectivity directly to the Access Edge service:
C:\>telnet edge.jds.local 5061
From the Edge server test connectivity directly to the XMPP server:
C:\>telnet xmpp.jds.local 5269
Active Connections
If all test appear to work but IM connections to or from gmail.com users is still not working, active connections can be searched for on the XMPP server to validate that the remote GoogleTalk servers are attempting to connect.
From the XMPP server search for active TCP connections to the XMPP listening port:
C:\>netstat –ano | findstr 5269
TCP 10.11.12.40:5269 0.0.0.0:0 LISTENING 1780
TCP 10.11.12.40:5269 10.11.12.40:62325 CLOSE_WAIT 1780
TCP 10.11.12.40:5269 33.99.141.69:37617 ESTABLISHED 1768
And to look for connections from the Edge server:
C:\>netstat –ano | findstr 5061
TCP 10.11.12.40:5061 0.0.0.0:0 LISTENING 1780
TCP 10.11.12.40:5061 10.10.10.50:3690 ESTABLISHED 3688
TCP 10.11.12.40:62329 10.11.12.40:5061 TIME_WAIT 0
By: Jeff Schertz
Posted:
March 31, 2010 at 7:20 AM
As promised, Microsoft has released supportability statements for various Communications Server versions when used with Server 2008 R2 hosts and domains. Yesterday two TechNet articles were released to address both scenarios.
Server 2008 R2 Domains
Previously no version of Communications Server was supported when deployed in an Active Directory environment using either forest/domain functional levels of Windows Server 2008 R2. Upgrading to or installing Windows Server 2008 R2 domain controllers would also cause problems with an existing LCS/OCS installation, preventing the later deploying of additional servers/pools.
With the release of the Knowledge Base Article 982020 there is now a documented and supported resolution for supporting Server 2008 R2 domains. Basically the ForestPrep deployment step must be reapplied in order to replace configuration information in Active Directory that was erroneously removed by the upgrade of AD to Server 2008 R2.
Server 2008 R2 Hosts
More importantly OCS has not functioned correctly, nor was supported, when installed on a Server 2008 R2 host. Various SSL-related changes in Server 2008 R2 prevented some conferencing features from working due to certificate errors.
But now Knowledge Base Article 982021 details a supported resolution in the form of installing a number of Windows Server and OCS patches, as well as changing some default security settings in the host OS.
By: Jeff Schertz
Posted:
March 16, 2010 at 11:52 AMI typically don’t repost links to existing documentation, but occasionally I run across items that are not too well known and I feel this is a prime example. Just when I though I had all of the OCS-related documentation stashed away in a folder I ran into an entire section on TechNet that contains some very detailed technical specifications for various Microsoft protocols used by Office Communications Server 2007 and 2007 R2. Microsoft Office Protocol Documents http://msdn.microsoft.com/en-us/library/cc307432.aspx For example, there are detailed PDF files on topics like the Address Book Service, A/V Edge Authentication, RTP Payload, ICE extensions, SIP, and SRTP to name just a few. If there is any communication protocol of OCS that you want to have a deeper understanding of then I highly recommend thumbing through these documents. Thanks to Rick Kingslan for bringing these to my attention. |
|
|
|
 |
|
|
|
 Senior ConsultantJeff Schertz is a senior consultant for PointBridge, focused on unified communications. He has over 10 years of experience in the IT industry ranging from family-owned businesses to global product dev... [more]
|
|
|
|
|
|
|