Read the Office Communications Server 2007 R2 version of this article here.
There are several ways in which we can utilize Audio/Video streams in Lync Server 2010. If you have read my Office Communications Server 2007 R2 article, you will see the first part of this article will show that the methods in which you restrict ports and the amount of flexibility in Lync Server 2010 has vastly changed. You will also see that the second half of this article is identical to Office Communications Server 2007 R2 as the method in which clients connect is identical.
There aren’t really any places out there that describe how the media session works in different circumstances for Lync Server 2010. For example, what servers and ports are utilized when doing Audio/Video through legacy clients or Lync 2010 based clients. How do we configure Lync Server 2010 to restrict port usage for various modalities? How can we configure this for legacy clients? How can we configure this for native Lync Clients? How about when you do a peer to peer with both users being internal to the network? How about both users being external to the environment and connecting through the Edge? How about when you do a peer to peer with one user being internal and one user being external? Want to know? Read on…
Update 07/15/2012: As of 07/15/2012, several (not all) parts of the article that refer to QoS concepts have been removed from this article. This article focuses on all dynamic port ranges regardless of whether or not it would be required for QoS. For specific requirements on what is required for QoS and how to enable QoS itself, please see the following article I wrote on QoS here.
Media Ports and Restricting Amount of Ports Being Used
The first thing to understand is that in Lync Server 2010, when a user attempts to activate any type of audio and/or video, they first attempt a peer to peer session. The ports utilized here are TCP/UDP 1024-65535. At least that’s what the documentation says as you can see here. This actually isn’t entirely true. If you do a Get-CSConferencingConfiguration you will actually see that they’re not using that entire range. It’s just that it’s supported to utilize that entire range. The ports that are actually utilized by default start at 5350. Later in this article, when we take a look at Set-CSConferencingConfiguration, we take a look at the default ports.
If you want users to utilize peer to peer audio while internal to the network, you must ensure that this port range is open even if users are in different sites. But what if you don’t want this entire port range open between your sites? You can utilize in-band provisioning to limit the amount of ports that are being used. This is very different than how it was configured in OCS 2007 R2. OCS 2007 R2 utilized Group Policies to set these options whereas in Lync, it uses Client Policies which in turn, provide Lync clients settings via in-band provisioning. You can read up on how Client Policies work on my previous article here.
In order to allow Lync to push the information on port restrictions to client’s, you must first enable Lync Server to do so by running the following command:
Legacy Clients
When migrating to Lync Server 2010, you can use Lync 2010 Client or the Office Communicator 2007 R2 Client. When utilizing the OCS 2007 R2 infrastructure, you would use Group Policy to configure Media Port restrictions.
These two settings include:
- PortRange/MaxMediaPort
- PortRange/MinMediaPort
The above group policy settings modify the following three registry keys:
- HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\Enabled REG_DWORD 1
- HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MaxMediaPort REG_DWORD 40039 (for example)
- HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MinMediaPort REG_DWORD 40000 (for example)
In Lync Server 2010, there is an equivalent property that provides this Media Port Range restriction to legacy clients. The Lync Server 2010 PowerShell cmdlet used is Set-CSConferencingConfiguration. So let’s take the above command and make sure that when upgrading to Lync Server 2010, Lync Server 2010 provides the legacy clients the same port restrictions:
The above command will set the starting Media (audio/video/etc.) port to 40000 and allow the next consecutive 40 ports to be used for media. This will be the equivelant of 40000 as the MinMediaPort and 40039 as the MaxMediaPort. Again, this should be within the supported 1024-65535 range as mentioned earlier in this article.
Configuring Native Lync Clients Dynamic Port Ranges
Lync now has the ability to utilize different in-band provisioning settings for several different modalities; not just Audio/Video. The following are modalities you can separately configure port ranges for:
- Application Sharing:Set-CSConferencingConfiguration -ClientAppSharingPort <beginning of port range (5350 by default)> -ClientAppSharingPortRange <extent of port range, at least 40 (40 by default)>
- Audio:Set-CSConferencingConfiguration -ClientAudioPort<beginning of port range> -ClientAudioPortRange <extent of port range, at least 20 (40 by default)>
- Video:Set-CSConferencingConfiguration -ClientVideoPort <beginning of port range> -ClientVideoPortRange <extent of port range, at least 20 (40 by default)>
- File Transfer:Set-CSConferencingConfiguration -ClientFileTransferPort <beginning of port range> -ClientFileTransferPortRange <extent of port range, at least 20 (40 by default)>
- Dynamic SIP (Client Side SIP Ports):Set-CSConferencingConfiguration -ClientSIPDynamicPort <beginning of port range> -ClientSIPDynamicPortRange <extent of port range, at least 20 (40 by default)>
As you can see, the first 4 modalities above are all set to have a default starting port of 5350 and use 40 ports. This is the recommended configuration and allows you to restrict all modalities to 40 ports which would the equivalent of what the configuration in OCS 2007 R2 would look like. It’s just now, you have more granularity should you decide the need to do so. You can certainly utilize a larger port range as needed or even use different port ranges for different modalities. Key thing to remember here is that in order to support QOS for clients, each modality needs to have a separate port range.
Note: For immediate application of these settings, service restarts are required.
Configuring Server Dynamic Port Ranges
By default, on a server, Audio and Video are already unique. Application Sharing is not. If Application Sharing QOS is not required, there is no need to change Application Sharing to utilize a unique port range.
For a Front End Server or a stand-alone A/V Conferencing Server:
For a Mediation Server:
For an Application Server:
For an Edge Server:
You can also configure dynamic port ranges for the Web Server functionality. This will not be beneficial from a QOS standpoint but rather will be beneficial if you want to restrict the ports down to a certain range. For example, if you wanted to lock your firewall down. The command for a Web Server would be:
Audio/Video Connectivity Scenarios
The following list contains a list of media connection scenarios in Lync Server 2010. I do not talk about Media Bypass as I have written a previous article on it. In short, Media Bypass allows Lync 2010 client endpoints to communicate to a gateway via G.711 directly instead of sending the media to a Mediation Server. For more information on Media Bypass, please view my other article here.
Two Users Internal to the Network (media ports open)
When these two users are internal , they will attempt peer to peer. Because they can successfully connect to each other, they utilize peer to peer media. This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server. Because these users connect directly to each other for media, they have no need to connect to the Edge.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Audio/Video through the Web Conferencing Server
When users are connected through On-Premise Web Conferencing and activate Live Meeting (when internal or external… doesn’t matter), they are connecting directly through the Front End’s Conferencing MCU’s. Because of this, even when it’s two users, the user’s are still connecting to the Front End MCUs. If both user’s are external, they still connect through the Front End MCUs but are proxied through the Edge Server.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Two Users Internal to the Network and Any Users External to the Network
As previously stated, any time you have more than two users, peer to peer is no longer utilized and users always connect directly to the MCU on the Front End Servers. This means that both users internal to the network will connect to their Front End server(s) and the external user will connect to the Front End server as well utilizing the Edge Server for proxying to the Front End. There is absolutely no peer to peer connectivity in this situation.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Two Users on the Internet
When these two users are external , they will attempt peer to peer. Because they can successfully connect to each other, they utilize peer to peer media. This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server. Because these users connect directly to each other for media, they have no need to connect to the Edge for Audio/Video. You will still see the user connected to the Access/Edge over port 443 and/or 5061 (if these are your remote access port and federation port if you are using federation). When users are connected through On-Premise Web Conferencing and activate Live Meeting, they are connecting directly through the Front End’s Conferencing MCU’s. The Front End will have a certificate that contains the Pool Name and will/can contain SAN names for additional SIP domains that you may contain. Because of this, SAN names are supported on Front End Servers.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Two Users Internal to the Network (media ports closed)
When these two users are internal , they will attempt peer to peer. During their ICE negotiation, as previously stated, they will know the Internal Edge NIC in case their peer to peer connectivity fails. Because they fail to connect to each other, they will connect to the internal Edge NIC over either UDP 3478 or TCP 443. ICE has a mechanism where it will test a lot of candidates to see where connections should be made. ICE will test UDP 3478 and TCP 443 in parallel and if UDP 3478 works, the client will receive UDP 3478 due to it having less overhead. If UDP 3478 does not work, the client will receive TCP 443.
If you anticipate on blocking ports between your users, make sure your Edge Server can scale high enough to deal with the amount of Audio/Video connections it will be handling. To block one of your sites from doing peer to peer with other sites, block the peer to peer port range (discussed at the beginning of this article) from that site and block that site from communicating over UDP 3478 and TCP 443 to the Edge Server. This will prevent clients from doing any type of media communication from user’s outside of their own site. If you want to allow them to do peer to peer for users in some sites, modify the firewall ACLs accordingly for those sites.
Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
One User External and One User Internal
When one user is internal and one user is external , they will attempt peer to peer but not in the same sense as in two internal users. The external user will hit TCP 5061 to the Access Edge Server and will be provided with either UDP 3478 or TCP 443 for the Audio/Video Edge. As stated earlier, UDP 3478 is preferred even if the connection test for TCP 443 and UDP 3478 were successful in testing. If you attempt a telnet edgeserver.domain.com over the Internet, telnet will fail to connect. This is because telnet uses TCP. You can do a netstat -an to see your server listening on UDP 3478 and utilize a different program such as netcat which can attempt telnet to UDP by using netcat -u host 3478. More information on netcat here.
Moving on… we see that the user will connect to the A/V Edge over UDP 3478 or TCP 443, but what about the internal user? Because this is technically peer to peer, the internal user will NOT connect to the MCU on the Front End but will instead connect directly to the A/V Edge Server’s Internal NIC over UDP 3478 or TCP 443 as well. The Front End A/V MCU will not be used in this scenario. When you add a 3rd person to the conversation, the external user will connect to the Front End Server’s A/V MCU in which the A/V Edge will proxy this data for the user, and the internal users will connect to the Front End A/V MCU instead of the Internal Edge NIC.
Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.
Note: The red arrow signifies a successful media connection only. The diagram does not reference any other signaling such as SIP.
Thanks a lot! It's very helpful article!
Hi Elan,
Thanks for the interesting article on port ranges and media negotiations. In our application, we would like to force all internal to internal calls to use the Lync Edge relay instead of direct peer to peer (i.e. host candidates) media communications. If necessary, we have a managed sip plugin running on the front end that can manipulate the SIP/SDP signaling. How do we block the peer to peer media connection? Please let me know the detailed steps required to force internal to internal calls to the Lync Edge server. If changes or settings are required on the lync client, is there a method for pushing those changes from a central Lync or AD configuration system?
Your advice is much appreciated.
Thanks,
Aaron
This article is great. I do have a question about connectivity scenarios that have more than one pool and more than one edge.
We have 3 Edge and 3 Pools and I am not 100% sure on how the data flows when 2 or more of the users are hosted on different pools or using 1 of 3 Access Edge systems.
Here is one example (many more possible scenarios): External User connects to Edge A and joins a Lync Meeting hosted on Pool B. Would the Internal Interface on Edge A send that data directly to Pool B?
Thanks,
Pete
SIP always goes from the Edge to its next hop. However, Media always goes direct to the shortest path. So the Edge A would send media directly to Pool B. Edge A would talk to Pool A (if Pool A is Edge A's next hop), Pool A would proxy the traffic to Pool A if the conference or user is on Pool A for authentication., and then the media will go direct.
If Pool B is in another site with its own Edge B, part of the proxy from Pool A to Pool B will find the External AV FQDN for Pool B and have the external user talk to the AV FQDN that belongs to Edge B and the external user will start talking to Edge B. This is what enables regional/worldwide deployments to ensure AV is as local as possible no matter what Edge you may initially hit for authentication.
This is an excellent article, makes understanding the traffic flow much easier.
Hello Elan
Interesting articles, is there any way of marking the internal (peer to peer) traffic for internal QoS reasons or limiting the port ranges?
I see lots of facilities to enable QoS on server to client traffic but as the large majority is going to be client peer to peer how do you limit the ports and/or mark the network traffic?
Hello Again
Well scratch that question as I found the answer in the very next article….. super!!
Hi Elan,
Do you have any guidance as to how to determine how many client media ports Lync needs within an environment?
We're looking at limiting all client media ports within a particular range (shared, non QoS) and the recommended is 40 ports. However what's the limitations of setting this to 40 and when would it make sense to have more than 40 ports configured? Do you recommend a higher number of client media ports than 40 by default?
hi Elan
may you tell me what happens if i have two users on internet and they cannot send media to each other ? there is a policy which do not let it to happens.however when users on internet try to have Meetings they have no problem,the only problem is the p2p Calls.may you guide me how to force the p2p media goes form Edge Servers ?
If 2 users on the internet cannot do media to each other, they should automatically be able to fallback to using the Edge Server as the relay. If this is not working, I suspect there's some kind of misconfiguration with the environment from an audio/video standpoint. When clients authenticate remotely, their ICE SDP candidate list will contain their private IP, their public IP, and the Edge Server's relay list. You can see what is in the SDP candidate list via SIPStack traces and look for the Invite and 183 messages for candidates.
Thanks Elan for the Clear Answer.i could find the ICE Candidates and determine right settings for that.
i have a question yet,we have a customer project that includes two separate sites and on each Site deployed Lync with External Access(Edge,RP),what happens when a user homed and logged in on Edge of Site A wants to have a Conference with Users homed and logged in on Edge Site B,again there is no Direct Client Connectivity. I know Focus will be Created on Site A Front End, but how Remote users of Site B Connect to this Focus ? by Connecting to Site A Edge External IP or their Site Edge (Site B) proxies Connections to Site A Front End Servers ?
hi Elan
may you please read this and let me know your opinion ? http://social.technet.microsoft.com/Forums/en-US/…
Elan,
I read your post, and thank you for it. My problem is that I have 2 users connect to VPN, and audio works, IM works, but video chat doesn't work. So, what's your suggestion? I enabled logging, but the error I get in Application log is 480 Temporarily Unavailable
ms-diagnostics: 13012;reason="No Routable Endpoints.";
There is very little guidance on the number of ports required for each modality. If you have a very large deployment of lync, say 60,000 users do you need to allow for a bigger port range to be available? If so how would this be estimated? Client has strict security requirements abd doesn't want to open large chunks of high tcp ports.
Any help would be appreciated.
The closest information you will find on this is by taking a look at the following article: http://technet.microsoft.com/en-us/library/dd5722…
It talks about the number of ports used in the different phases of communication.
So if one person is external and one is internal does av.contoso.com need to be resolvable from the internal client subnet to the external up of av.contoso.com?
Nope. Internal users use the internal edge FQDN or the internal edge Pool FQDN if using an edge pool.
I just reviewed the post I submitted. I was a victim of a failed copy and paste :-) . I meant to say "I have enabled ClientMediaPortRangeEnabled and confirmed the client is using the restricted port range for media connections. Thus I am confident the configuration is being pushed to the Lync client"
Thanks for reaching out to Microsoft.
I am trying to restrict the range of ports , used by the Lync client , for SIP-TLS connections. However, I do not see it using the range TCP Port 7100 – 7102 as it is configured to by default.
Has anyone else seen this behaviour and have a solution?
Is it a Bug?
Are the settings ClientSipDynamicPort and ClientSipDynamicPortRange only used by the client for SIP connections and not SIP-TLS connections?
FYI I have enabled ClientSipDynamicPortRange and confirmed the client is using the restricted port range for media connections. Thus I am confident the configuration is being pushed to the Lync client
Hey Michael, I reached out to Microsoft on this as nobody seems to have a clue about what exactly this setting does. I have received a response but the individual I spoke with is reaching out to a few different teams for confirmation so stay tuned.
Hi Elan,
Great Post. Does this mean i do not need to open Port range 50000-59000 on my External firewall ? Will this change mean i now need to open 5350-5389 port range(Besides the other standard ports) and External to Internal Media flow will work?
I m asking this is because my customer is hesitant to open 50000-59000 on the firewall and wants to know if this change would mean opening only those 40 ports on external firewall.
First of all, 50000 + 10000 = 60000 not 59000. Second of all, because 50000 is a port, that means it's 50000-59999 not 50000 to 59000. 5350 has nothing to do with the 50K port range. 50K port range is a/v for peer to peer in most situations. 5350 starting port is just an example of a locking down peer to peer communication. Different scenarios.
Also, I already give the example on how to lock down the Edge 50K port range in my article.
Set-CsEdgeServer -Identity: <FQDN of Edge Server (Single Edge) or FQDN of Edge Pool> -MediaCommunicationPortStart <beginning of port range, default 50000> -MediaCommunicationPortCount <number of ports, default 10000>
Great article !
Could you please explain similar scenario but with two sites connected with WAN, with separate FE servers but only one Edge Server in one of this two sites. Especially, how does the multi conferencing traffic goes ?
Exioo,
Are both Front End Servers part of the same pool? So you have to keep in mind that when you're doing a conference, there's something called a Focus that gets created on the Pool. If the creator of the meeting is on Pool 2, then the focus gets created on Pool 2. Because the Focus is on Pool 2, all attendees will connect to Pool 2. Therefore, Pool 2 will connect directly to the Edge Servers. And if the focus was created on Pool 1, Pool 1 needs to talk to Edge Servers. As you can see, depending on the scenario, both Pools need to be allowed to be able to talk to the Edge Server because a Focus can be created on both Pools depending on how you have your users distributed across the Pools.
Hope that helps.
Soder, if you have specific issues with the Microsoft Lync 2010 Resource Kit, please let us know on the DrRez blog or at [email protected]. The book was a year in the making with 15 cross-team authors, all of them Lync SMEs. The good news is that it's online and we can thus still revise it as gaps or errors surface. We welcome all feedback!
Hi Elan,
We do have an OCS edge in our environment – migrating to LYNC. All users are now in the LYNC pool but we haven't migrated the edge yet. We see a similar issue, where one internal user on the main LAN tries to audio call (no Enterprise voice) another user who is on a remote site connected via VPN. The call fails with "call disconnected due to network issues". There is no NAT applied to the remote site. I don't know if this was a problem before migration as the users on the remote site didn't use OCS.
Even before migration we saw the same error when our users were external and connecting via VPN. When VPN'ed we still allow traffic to the internet so it is not exclusive. IF the user drops their VPN they can connect, then re-enable the VPN. It seems to me that the ICE negotiation works so far as the initial ringing, but the accept call doesn't return.
I've looked through the client/server and firewall logs, and am having difficulty finding the cause as there are no obvious errors.
Regards,
James.
Sounds like firewall rules to the VPN segment are blocked. Peer to Peer audio calls will use ports 1024-65535 TCP/UDP. VPN segments to FE for Conferencing should have 49152-57500 open for MCU Audio/Video/Conferencing.
Hi,
we don't have lync edge in our environment, we only have lync front end server. we have some VPN users. one VPN user can call internal user and vice versa. but one VPN user not able to call the other VPN user, "call disconnected due to network issues" will occur. all ports opened in firewall and lync front end server.
what could be the issue in our scenario
Regards
Asha
Addendum: the 2 geographical sites have a VPN connection between, and the 2 conflicting subnets are translated via Network Address Translation (NAT)
hi soder
i have a similar Topology Like you and wanted to know how you managed this ?
Additional clarification:
Long story:
I am in the process of implementing a Lync system, where the 2 clients cannot talk directly: the reason is unprofessional network design led to conflicting IP subnet assignnent at the 2 sites. So the only possible solution that the 2 internal users coming from 2 different subnets, which look identical by means of network address and subnet mask, but belong to 2 different geographical location must talk to the internal IP of edge, and edge will relay the RTP packets between the 2.
Question:
if the external IP of the edge is NATed, does this single fact invalidate the possibility, that the 2 internal clients will have RTP flow via the internal edge, or not?
If I were to configure the A/V conferencing server to use the minimum number of ports for each modality as shown in this example below what side effects, if any, would occur?
Set-CsConferenceServer -AudioPortStart 49152 -AudioPortCount 128 -VideoPortStart 57501 -VideoPortCount 128 -AppSharingPortStart 57630 -AppSharingPortCount 4
Would it impact the number of concurrent conferences hosted on a server or impact the number of concurrent attendees that could attend a conference or other similar issues?
What is the corralation between the number of ports available for a modality and the number of concurrent users that can consume a given modality?
For example, you should alloate X number of audio ports on the A/V conferencing server in order to host 200 concurrent audio conferencing users in one or many concurrent meetings.
..even the 2011 July doc package!
Elan: if you accept the challenge (Nexthop/DrRez topic) you should definitely go through all the commands, as I feel they are very buggy documented / lack of proper explanation why they are needed and how they need to be implemented. That is the reason of the technical documentation, right?
I have ran all the associated commands listed above on my development copy of Lync server and I cannot get the Lync client to stop opening port 62000 when I sign-in. I am missing a registry entry for the Lync clients? Or am I missing commands that will limit the login/iM'ing to my specified 10000 port I opened?
I am having this same issue. My Lync clients are opening ports in the range I assigned to A/V (57501-65543) when signing into Lync. This makes it a problem with the QoS settings since the client policy says to mark all packets on the client side with a source range of 57501-65543 to AF41. So basically I am prioritizing a bunch of traffic that doesn't need to be prioritized.
Addendum3: http://social.technet.microsoft.com/Forums/en-US/…
in this technet forum you are discussing "Set-CSwebserver" as well! You did not include this detail here!
Updated article to include Set-CSWebServer.
Addendum2: Appsharing requires minimum 128 ports as well! (4 is not enough)
Set-CSConferencingConfiguration used to say 4. I’m sure of this! Looks like they updated the documentation and therefore, I have updated my article.
Just 1 more addendum: you NEED the identity parameter for the "Set-CsConferenceServer" command (maybe for mediation server as well, didnt check that one yet)
Updated article with -Identity parameters. Thanks for the suggestions.
Great article Elan! I would forward the paycheck to you instead of the guys at Redmond Lync documentation team. I am even skeptical about the technical level of the Resource kit chapters, for some reason I feel I will not see such well collected and explained content in those documents (which raises the question: where the hell should I look for those, if even the resource kit fails to meet the expectactions for high quality – accurate and not incorrect – level 400 details)
Hi Elan!
Great article! Can you please explain the media negotiation process for incoming calls from PSTN?
We run into very interesting situation with Lync randomly routing calls through edge server or front end. Can you please explain why Lync uses such behaviour and is there any way to exclude edge from this process?
Good idea. I'll add something like that early next week. Basically, it's PSTN > PBX > Lync Mediation (Or Gateway to Lync Mediation). Then it's Lync Mediation to Lync User. If the user is internal, then it's Lync Mediation to to user. If the user is external, it's Lync Mediation to internal Edge NIC and then the external user will connect to external Edge.
Thanks for reply.
well, seems that reality is a bit different. We have Lync Standard with dedicated mediation server that connects to PSTN through Audiocodes Mediant 1000. We have something like call center, 8-10 operators that sitting in the internal network, they all are members of response group. The call flow is quite high – something like 150 incoming call per hour. And we have call recording solution based on Live-PA Lync Call Recording. This thing has some troubles with recording the calls that comes through edge server. And in fact we first saw that some calls are not recorded properly, then we invistigated the situation and fund out that Lync randomly routes the calls throught Edge server. And for now we absolutely don't understand why Lync uses edge to route media for some calls.
Maybe you could bring some light into this situation?
Hi Elan…
Kudos for the great article! Are you interested in recrafting it slightly to appear on the NextHop blog?
There is high interest in this topic from several folks on our team, and you have covered it admirably.
Would love to feature yourarticle and add you to our list of respected contributers. (http://blogs.technet.com/b/nexthop/p/contributors.aspx) Please email me.
All the Best…DrRez
Hi Elan,
the info is very helpful, actually i just used it to my current solution. What I provided to security team for the port numbers that we are going to used are External user <–> Internal user with above port numbers. P-2-P works fine but not conferencing. I found the conferencing is still using unlimited port numbers from External user to FE servers. Any idea how to restrict the conferencing to be used same ports?
Jason
Same question here!! Just realised how painful will it be to them to connect through a remote server and not been able to do a peer to peer connection.
Also curious about Harish's scenario, as all our branch offices connect via edge over the wan/ssl. Will these users be able to get p2p with each other, and with others in other branch offices?
thanks,
Wes
Hi Elan,
Your information is very helpful. However I have a question. What if two external users are behind the same firewall and Public NAT connecting to Lync Edge. The example is where a branch office has no WAN connectivity to the Datacenter and instead connects to the corporate Lync environment over the internet to Edge. Would A/V Media still be Peer to Peer?
Thanks for your help.
Harish
hello Mr Elan, i found no place where to contact you, so i leaved here a comment sorry,
am a regular reader of your blog, my name is nassim, and currently i'm about to start demployment of a new project
around MS Exchange 2010, for this reason i am hoping to get in touch with you in order to get
some help for it,
here's the material i have to install:
– 2 Mailbox Servers (With logs and Database isolated in as SAS storage connected to the servers).
– 2 CAS & Hub Servers (the two roles in the same server).
– 2 edge Transport Servers (With queue Databases/logs in SAS storage connected).
– 2 Domain controllers.
– All servers with 2 NICs.
well i need to know what's the best deployment method i have to use,
where to use DAG and where to not ?
pls can you provide me an exmple of IP adresseing between them ? and where to place each server?
and everything you see important on that design;
Thanks in advance for your help.
Happy new year.
Sounds like you need to hire a consultant for a design. I am not comfortable with the limited information you have provided to start recommended what you should do for a deployment. This would require an in depth design to ensure you have a proper design.
nice article, but I dont understand how(command or regfile) disable peer-to-peer sesssion between Lync 2010 cluents, I want all session by FE server. thnks.
Impossible to make Peer to Peer conversations go through the Front End. You can disable Peer to Peer but not force them go to through Front End.
If the Peer to Peer has been disabled, how will they communicate then?
Hi,
as far as I know peer to peer conversations flow forcibly through the Front-End if you enable archiving for the users. This is the only method to enable the Archiving Service to capture IM traffic.
I am on RTM, I see only command Set-CsConferenceServer (not Set-CsConferencingServer)
AME
Set-CsConferenceServer
SYNOPSIS
Modifies the properties of an A/V Conferencing Server (also known as a Conference Server). The Conferenc
e Server provides audio and video (A/V) capabilities to your conferences.
SYNTAX
Set-CsConferenceServer [-Identity <XdsGlobalRelativeIdentity>] [-AppSharingPortCount <UInt16>] [-AppShar
ingPortStart <UInt16>] [-AppSharingSipPort <UInt16>] [-AudioPortCount <UInt16>] [-AudioPortStart <UInt16
>] [-AudioVideoSipPort <UInt16>] [-Confirm [<SwitchParameter>]] [-DataPsomPort <UInt16>] [-EdgeServer <S
tring>] [-Force <SwitchParameter>] [-ImSipPort <UInt16>] [-MeetingPsomPort <UInt16>] [-PhoneSipPort <UIn
t16>] [-VideoPortCount <UInt16>] [-VideoPortStart <UInt16>] [-WhatIf [<SwitchParameter>]] [<CommonParame
ters>]
Get-CsAdminRole | Where-Object {$_.Cmdlets -match "Set-CsConferenceServer"}
Thanks Sachin. I looked at an RC server. It appears they updated the commands in RTM. Updating post now.
very good article, nice to know about port range configuration using in-band provisioning, it seems that server port range needs below command, it says -Clientaudioport instead of below, should it be – AudioPortStart? This is configuration server side. It says minimum 40 is required but it will drastically reduce call capacity on server side, that is my assumption.
For a Front End Server:
Set-CsConferencingServer -AudioPortStart <beginning of port range> -AudioPortRange <extent of port range, at least 20> -VideoPortStart <beginning of port range> -VideoPortRange <extent of port range, at least 40> -AppSharingPortStart <beginning of port range> -AppSharingPortRange <extent of port range, at least 4>
For a Mediation Server:
Set-CsMediationServer -AudioPortStart <beginning of port range> -AudioPortRange <extent of port range, at least 20> -VideoPortStart <beginning of port range> -VideoPortRange <extent of port range, at least 40>
For a stand-alone A/V Conferencing Server:
Set-CsMediationServer -AudioPortStart <beginning of port range> -AudioPortRange <extent of port range, at least 20> -VideoPortStart <beginning of port range> -VideoPortRange
There's an error. Look on a server at those 2 commands. For Set-CSConferencingServer, it has -ClientAudioPortStart and -ClientAudioPortRange. It's the MediationServer one that doesn't have the -Client piece added to it. The documentation is bugged.
Just made one more change. Verified with Microsoft that the A/V Conferencing Server command should actually be:
Set-CsConferenceServer -Identity ConferencingServer:<poolname> -AudioPortStart <beginning of port range> -AudioPortRange <extent of port range, at least 20> -VideoPortStart <beginning of port range> -VideoPortRange <extent of port range, at least 20>
While configuring QoS i discovered that the documentation is incorrect:
Set-CsConferencingServer -AudioPortStart <beginning of port range> -AudioPortRange <extent of port range, at least 20> -VideoPortStart <beginning of port range> -VideoPortRange <extent of port range, at least 40> -AppSharingPortStart <beginning of port range> -AppSharingPortRange <extent of port range, at least 4>
Front End Server command should actually be:
Set-CsConferenceServer -Identity ConferencingServer:<poolname> -AudioPortStart <beginning of port range> -AudioPortCount <extent of port range, at least 20> -VideoPortStart <beginning of port range> -VideoPortCount <extent of port range, at least 40> -AppSharingPortStart <beginning of port range> -AppSharingPortCount <extent of port range, at least 4>
Elan,
Do you know specifically what the ClientSipDynamic port range is used for? I have configured this setting in my lab environment and I do not observe the clients using this port range. Any additional info would be appreciated.
Regards,
Jamie
No idea, I've been wondering the same thing. I'll see if I can ping one of the OCS guys at MS and see if he knows.
Hello Elan,
how can I ask you a question about autodiscover mechanism ?
I see a post on your blog.