Mino – The UC Guy

Microsoft Unified Communications Blog

Archive for the ‘Edge Server’ Category

OCS 2007 R2 Traffic Flow of protocols and ports used in each workload

Posted by Mino on January 27, 2010

You know that song saying “At last, my love has come along, My lonely days are over, And life is like a song, Ohhh at last” !!!

This is exactly how I felt when I saw the announcement today of Microsoft for the availability of the OCS traffic flow , Finally something official and no more rumors or some individual efforts .

You can Find it here

“This poster of Office Communications Server 2007 R2 describes the traffic flow of protocols and ports used in each workload. Communications Server 2007 R2 supports the following workloads: IM and Presence, Conferencing, Application Sharing, and Enterprise Voice. These filtered views can assist you in architecting your deployment of Communications Server 2007 R2. The different server roles are described along with server certificate requirements. Firewall and DNS configuration requirements are also described.”

Posted in A/V Edge Server, Consolidated Edge, Edge Server, OCS 2007 R2 | Tagged: , , , , , , , , , | 3 Comments »

Single certificate for OCS/Exchange/ISA usage

Posted by Mino on July 7, 2009

Any Post starting with this disclaimer means that this post was not written by me however I have liked it and added to my blog. I am also including the link to the original or similar post to provide credit to the original author.

http://www.unifysquare.com/blog/post/Single-certificate-for-OCSExchange-firewall-usage.aspx

Internal certificates work wonders for your Active Directory Domain Services members. For Unified Communications, where OCS and Exchange are going to be using the same ISA 2006 server as the firewall, utilizing a Subject Alternative Name (SAN) certificate for your edge configuration and your ISA configuration can save you time, management hassles, and possibly provide cost savings as well. For internal servers, an internal PKI is just fine, but for the public interface of your system, you should most likely be looking at using a public-sourced key such as Go-Daddy, Thawte, DigiCert, etc. OCS Federation, remote users, and Public Instant Messaging Connectivity (PIC) demand public certificates.

The following table shows the SAN names needed on a certificate to support the base OCS and Exchange functions on ISA 2006 – and I imagine that this certificate construction will work just fine on many other firewalls as well. The table comes from my test domain; you should replace my test domain with your own domain name.

Obtain a public SAN (UCC) certificate from your favorite provider, import the certificate into your OCS Edge server and your ISA server computer account Trusted Root Certificate store and then you can use one certificate for all these uses. This approach leaves you with only the one certificate to manage and renew, or, if life treats you badly, move to a new server.

 

 

SAN Name

Usage

Notes

1

SIP.domain.com

OCS Edge Server

IM, Presence, Federation, PIC

2

webconf.domain.com

OCS Edge Server

Web Conferencing

3

AV.domain.com

OCS Edge Server

A/V

4

revproxy.domain.com

ISA Reverse Proxy

Web Components

5

CWA.domain.com

ISA Web Listener

Communicator Web Access

6

DOWNLOAD.CWA.domain.com

ISA Web Listener

CNAME for CWA desktop sharing

7

AS.CWA.domain.com

ISA Web Listener

CNAME for CWA desktop sharing

8

MAIL.domain.com

ISA publisher

Outlook Anywhere, OWA, POP, IMAP

9

AUTODISCOVER.domain.com

ISA Web Listener

Autodiscover for outlook and OCS.

Posted in A/V Edge Server, Certificates, Communicator Web Access, Consolidated Edge, Edge Server, Good Articles take from Other Blogs, OCS & Exchange07, OCS 2007 R2 | Tagged: , , , , , , , , , , , , , , , , , , | 10 Comments »

OCS 2007 R2 Server Loses network connection on Server Startup

Posted by Mino on May 13, 2009

As strange as this might sound to you but this is the latest case I have faced which in the end appeared to be a known bug and Microsoft Premiere Support were able to solve it after 3 weeks of investigation

Setup

So you have OCS 2007 R2 implemented over Windows 2008 and the Backend is placed on SQL 2008 on windows 2008 server. The below roles are all implemented on windows 2008:

  • Front End 1
  • Front End 2
  • Mediation
  • Consolidated Edge not joined to the domain

Problem:

When you restart any OCS server you cannot remote access to that server again, the Ping over the server is lost and when you go and check the server you find the network is disconnected.

If you went through all of the OCS Server services you will find them all are in the mood of starting and it will take it like 10 minutes then it will fail to start .

If you set these OCS Services to manual start rather than Automatic then reboot. You will find that the server is functioning normally.

This is really a very strange problem and I never faced it before as I have already implemented the OCS on 2008 but I still up to this moment don’t know the symptoms that causes this problem to happen.

Solution:

– Set startup type for wmiApSrv to automatic

– Add dependency on RtcSrv to wmiApSrv

– Set startup type for RtcSrv to automatic

– Reboot

– RtcSrv is starting and running

– Set startup type for all Rtc* services to automatic

– Reboot

– All Rtc* services starting and running

 

To set the RTCSrv service dependency you can use the registry to modify the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RtcSrv and modify the DependOnService to include the wmiApSrv.

Posted in Consolidated Edge, Edge Server, Front End Server, Miscellaneous, OCS 2007 Components, OCS 2007 R2, Uncategorized | Tagged: , , , , , | 8 Comments »

The OCS 2007 R2 Edge and NAT

Posted by Mino on March 4, 2009

Any Post starting with this disclaimer means that this post was not written by me however I have liked it and added to my blog. I will also include the link to the original or Similar post to provide credit to the original author.

https://blogs.pointbridge.com/Blogs/mcgillen_matt/Pages/Post.aspx?_ID=61

The proof was came last week when I was working with a client on an R2 edge server. This was the perfect test case because we had already tried NAT with R1 and, of course, it failed…

So we were going to try it again with R2 – same firewall and everything. As we went through the R2 Edge config, there was a little check box on the AV interface that said “This address will be NAT’d”. Sweet!

We checked the box…and… it failed .

We were kinda puzzled, but the OCS error logs came to the rescue. The error log showed that the edge server was “unable to resolve ‘av.customer.com’ – using 10.x.x.x instead”.

That’s exactly what I didn’t want: the internal IP being handed out. The helpful hint, though, is that the edge was trying to resolve the name “av.customer.com”. If you ask me, this is a bit odd. It would make more sense to me if OCS just had a parameter that said “external IP address of AV edge”. But apparently not – it just does a lookup on the AV edge FQDN.

The client was using split-brain DNS and didn’t have a record for av.customer.com in the internal DNS zone. So we added an A record. But listen up here: you want to add the PUBLIC IP for av.customer.com in your DNS – even if it’s an internal DNS server.

Apparently, this is the mechanism for the edge to figure out what IP to hand out to external clients for AV sessions.

 In summary:

  • Check the “use NAT” box in the AV edge configuration properties
  • Make sure your internal and external DNS A records for the AV edge server are configured with external addresses.

Big improvement over R1

Posted in A/V Edge Server, Common Errors, Edge Server, OCS 2007 R2 | Tagged: , , , , , , , , | 1 Comment »

OCS R2 Updates about the Firewall Requirements for External User Access

Posted by Mino on February 25, 2009

One of the main topics that has been giving me hard times when communicating with a firewall System Admin would be why would the OCS AV Edge Server need a Publicely routable IP , and how secure it is to open 10,000 ports  ( 50,000 – 59,999 ) TCP/UDP ?

usually we used to get Microsoft articles and explain more about the STUN protocol and why It cant work behind NAT and then how to secure the Edge .

But now with the R2 I have good good news for the Firewall Admin team  :

1- If you are implementing a Single Consolidated Edge Server then you can work with NAT IP rather than the publicely routable real IP which was required before . Only Only if this is a Single consolidated Edge

2- the 50,000 – 59,999 UDP/TCP ports which are required to be open , are only required if you are planning to have fedration with other orginizations . if there is no fedration in your plan then no need to open these ports .

I hope you are happy now Firewall Admin team  J

Firewall Requirements for External User Access

 

 Publicly Routable IP Address

In any location with multiple Edge Servers deployed behind a load balancer, the external firewall cannot function as a network address translation (NAT). However, in a site with only a single Edge Server deployed, the external firewall can be configured as a NAT.

If you do so, configure the NAT as a destination network address translation (DNAT) for inbound traffic—in other words, configure any firewall filter used for traffic from the Internet to the Edge Server with DNAT, and configure any firewall filter for traffic going from the Edge Server to the Internet (outbound traffic) as a source network address translation (SNAT). The inbound and outbound filters must map to the same public IP address and the same private IP address, as shown in the figure below.

The A/V Edge Service requires the port range from 50,000 through 59,999 to be open only for the sharing of audio/video with federated organizations.

  • If you will be federating with organizations that run Office Communications Server 2007 and earlier, you must open this port range for both RTP/TCP and RTP/UDP, and for both inbound and outbound connections.
  • If you will be federating only with organizations that run Office Communications Server 2007 R2, you need only to open this port range for RTP/TCP, only for outbound connections.
  • Otherwise, if you will not be sharing audio/video over a federated relationship, you can close this port range.

  dd441361_6b3a5ede-4253-4874-b096-2e969bf52626en-usoffice_131

Source : http://technet.microsoft.com/en-us/library/dd441361(office.13).aspx

Posted in A/V Edge Server, Common Errors, Consolidated Edge, Edge Server, Miscellaneous, OCS 2007 R2 | Tagged: , , , , , , , , , , | 1 Comment »

OCS 2007 Audio/Video bandwidth calculation

Posted by Mino on October 13, 2008

Medium Min High Quality
Data 56kbps 56kbps
Voice 50kbps 80kbps
Video 50kbps 350kbps
RoundTable (Conference video phone) 50kbps 350kbps

Note that the requirements are cumulative –

Data + Voice + Video =

56 + 50 + 50 = 156kbps (Minimum Quality)

or

56 + 80 + 250 = 386kbps (High Quality)”

Here are some calculations I have used. however the 300KBps is only video stream single direction.  Bidirectional video consists of two streams..

The following formula can provide rough bandwidth consumption estimates for conferencing with Audio / Video.

Note:  Calculation results will be displayed in Mbps

CC = Concurrent Conferences

PPC = Participants Per Conference

 

Conference Type

Bandwidth Consumption Mbps

Audio with Application Sharing

(((CC * PPC)*14KBps)+((CC *PPC)*90KBps))*10^-3

Audio and Video

(((CC * PPC)*14KBps)+((CC *PPC)*600KBps))*10^-3

Another OCS 2007 Audio Bandwidth Calculation

Audio Codec
Frame Size [ms]
Codec payload bit rate
[bits / sec]
Total payload bit rate
[bits / sec]
Actual bit rate
[bits / sec]
Without
redundancy
With
redundancy
RTAudio@16KHz
20
24000
29000
45000
74000
RTAudio@16KHz
40
24000
26500
34500
61000
RTAudio@16KHz
60
24000
25666
31000
56667
RTAudio@16KHz
20
18000
21000
37000
58000
RTAudio@16KHz
40
18000
19500
27500
47000
RTAudio@16KHz
60
18000
19000
24333
43333
RTAudio@8KHz
20
8800
11800
27800
39600
RTAudio@8KHz
40
8800
10300
18300
28600
RTAudio@8KHz
60
8800
9800
15133
24933

Posted in A/V Edge Server, Consolidated Edge, Edge Server, Miscellaneous | Tagged: , , , , , , | 7 Comments »

A/V edge server doesn’t work from outside, and external users have problem using audio/video

Posted by Mino on October 13, 2008

 AV edge server requires external interface  that has a public IP address that can route onto the Internet, This Edge interface requires that its traffic to and from its Edge interface be routed with no NAT applied.

you have to assign A/V external interface with a public IP address(no NAT) and connect to check the issue.
The Edge external adapter should have three (publicly routable) IP addresses — access, a/v, and web conf, and in that case, you should want default gateway on external interface pointing to your ISP

If the access, WebConferening Edge server have internal IP and using NAT
while A/V Edge server uses public routable IP address, it will rises
problems in this configuration. If we have defined two gateways in the
routing table, when internet request is coming, we unable to route it to
the correct gateway and it will cause problem. Thus we can only configure
one gateway in this configuration.

To workaround this issue, please either assign another two public IP
addresses for Access and Web Conferencing Edge servers, or install the A/V
Edge server in a separate server.

If the issue persists,  perform the following steps to test the issue:
1. Make sure necessary ports are open correctly
Policy Rules
Local Port: 443 TCP (STUN/TCP)
Direction: Inbound and outbound STUN/TCP media communications
Remote Port: Any
Local IP: The internal IP address of the A/V Edge Server
Remote IP: Any IP address

Local Port: 5062 TCP (SIP/MTLS)
Direction: Outbound (For authentication of A/V users)
Remote Port: Any
Local IP: The internal IP address of the A/V Edge Server.
Remote IP: Any IP Address

Local Port: 3478 UDP (STUN/UDP)
Direction: Outbound (for internal users to send media to external users)
Remote Port: Any
Local IP: The internal IP address of the A/V Edge Server
Remote IP: Any IP Address
Note: If you are using ISA Server as your firewall, you must configure the
rule for send/receive

Following ports should be opened for A/V edge server external interface.
Local Port: 443 TCP (STUN/TCP)
Direction: Inbound (for external users access to media and A/V sessions)
Remote Port: Any
Local IP: The external IP address of the A/V Edge Server
Remote IP: Any IP Address

Local Port Range: 50,000-59,999 TCP (RTP /TCP)
Direction: Inbound/Outbound (for media transfer)
Remote Port: Any
Local IP: The external IP address of the A/V Edge Server. This IP address
must be a publicly routable IP address.
Remote IP: Any IP Address

Local Port: 3478 UDP (STUN/UDP)
Direction: Inbound (for external users connecting to media or A/V sessions)
Remote Port: Any
Local IP: The external IP address of the A/V Edge Server
Remote IP: Any IP Address
Note: If you are using ISA Server as your firewall, you must configure the
rule for send/receive

Local Port Range:  50,000-59,999 UDP (RTP/UDP)
Direction: Inbound/Outbound (for media transfer)
Remote Port: Any
Local IP: The external IP address of the A/V Edge Server. This IP address
must be a publicly routable IP address.
Remote IP: Any IP Address

2. Check the global setting
a. On the Front End Server, open Office Communications Server 2007.
b. In the console tree, right-click the Forest node, click Properties, and
then click Global Properties.
c. Click the Edge Servers tab.
d. Check the A/V Edge Servers, the listed value is ocsedge2007 with port
5062.

Posted in A/V Edge Server, Common Errors, Consolidated Edge | Tagged: , , , , , , , , | 4 Comments »