Elan Shudnow's Blog

General Overview

Media Bypass is an excellent new feature in Lync 2010, the successor to Office Communications Server (OCS) 2007 R2.  Currently, when an OCS Endpoint such as Communicator or Tanjay utilize Enterprise Voice, they must utilize RTAudio which an OCS Mediation Server must then transcode to G.711 which is the codec utilized on the Public Switched Telephone Network (PSTN).  This obviously adds an extra hop in your call increasing the chance for added latency and needless transcoding which can cause reduced call quality. It can even help reduce WAN traffic as a remote branch user can interact with their telephony equipment directly without having to traverse their WAN to communicate with the Mediation Server.
The big thing to keep in mind here, is that there are several things required to support Media Bypass.  These include:

• Supported Telephony Equipment (Voice Gateway, IP-PBX, Session Border Gateway at the Internet Telephony Service Provider (ITSP) for SIP Trunking
• Mediation Server Peer must be able to handle communication directly from clients.  Many ITSP’s support communication with its direct peer only (Mediaion Server).  Contact ITSP for more information.
• Clients must be able to route to the Telephony equipment it will be doing G.711 with.

Many of you will ask, “Well, if all my telephony equipment supports Media Bypass, can I just get rid of all my Mediation Servers?”  The answer to this, is… NO!  In OCS 2007 R1 and OCS 2007 R2, both the signaling and media flow went through a Mediation Server.  Now, the signaling still goes through the Mediation Server but the media will not when using Media Relay in the given location that has Media Relay enabled. So again, the signaling will still appear from the Mediation Server.

OCS 2007 R2 Topology

So in this case, let’s say you have one branch office and one main datacenter.  Both the main datacenter and the branch office have users in them. Let’s take a look at what a possible architecture would look like in OCS 2007 R2.

In OCS 2007 R2, let’s say we had HA requirements.  We’ve deployed the following:

• 2 Front End Servers
• 2 Mediation Servers (cannot put them on the Front End Servers)
• 2 Voice Gateways since Mediation Servers and Voice Gateways have a 1:1 relationship

Now in the above architecture, we see the users have to contact the mediation server(s) directly.  As stated earlier, this is because both Media and Signaling must flow through Mediation Servers.  Clients will communicate using Secure Real Time Protocol (SRTP) utilizing the RTAudio codec to the Mediation Server.  The Mediation Server will then transcode that to G.711 and then send G.711 to the Voice Gateways. For the client in the branch site, they must traverse the WAN to utilize the Mediation Servers in the Primary Site.  This is a big CON as you’re traversing the WAN making you prone to latency issues, quality issues, and network issues.

Lync Topology Improvements

Now let’s take the same topology and redo it with Lync topology improvements. Let’s take a look at both a voice non-resilient architecture and voice resilient architecture both utilizing Media Bypass.

Non-Resilient Voice Architecture using Media Bypass

The non-resilient voice architecture by itself looks much simpler.  The following are benefits of this architecture:

• Mediation Servers co-located on Front End Servers meaning less software/hardware procurement costs.  Keep in mind, having the Mediation Servers on the Front End is optional and in some cases, you may want dedicated Mediation Servers.  More on this in a future article for which I will provide a link here.
• Primary Site clients talking to voice gateways using G.711 meaning less voice latency and enhanced call quality due to the lack of need for transcoding from RTAudio to G.711
• Branch Site clients talking to a local voice gateway using G.711 meaning less voice latency, enhanced call quality, no need to traverse WAN, less chance for network failures in the WAN, and enhanced call quality due to the lack of need for transcoding from RTAudio to G.711.  Again, don’t forget, signaling still occurs through the Mediation Server in the Primary Site.  There is no Voice Resilience in this architecture and if the WAN link goes offline, the signaling is dropped and the call is disconnected.

This is most definitely a much better architecture than anything OCS 2007 R2 provides.

Voice Resilient Architecture using Media Bypass

As Lync is becoming a full fledged PBX (subjective statement, I know), Microsoft most definitely needed to provide Voice Resiliency.  Lync does indeed provide Voice Resiliency using any of the following:

• Survivable Branch Appliance (SBA) – Host between 25 and 1000 users at your branch site, and if the return on investment does not support a full deployment or where local administrative support is unavailable
• Survivable Branch Server (SBS) – Host between 1000 and 5000 users at your branch site, lack a resilient WAN connection, and have trained Lync Server admins available
• Full Fledged Deployment – If you have more than 5,000 users.

In the following Visio, we will be using an SBA.

We get the same benefits as the non-resilient voice architecture.  But in addition to that, we now have registrar pools for each location.  For a user located in the Primary Site, their Primary Registrar Pool will be the Registrar Pool belonging to the Primary Site. This user will not have a backup registrar configured as an SBA/SBS cannot act as a Backup Registrar.  For a Branch Site User, their Primary Registrar Pool will located in the Branch Site and their Secondary Registar Pool will be located in the Primary Site.  Keep in mind, these Registrar Pools are voice only.  A Branch Site user will still utilize the Lync Architecture (Front Ends, Directors, Etc.) located in the Primary Site for things like Instant Messaging, Web/Video Conferencing, presence, call forwarding settings, etc.

This SBA appliance contains a Mediation Server, a Registar, and a Voice Gateway.  This will allow you to do your signaling, media, and PSTN connectivity all from the Branch Site. Should this SBA fail or something happen to internet connectivity, the client can begin using the Registrar Pool on the Primary Site.  The user knows about this site through information provided in in-band provisioning from their SIP connection to their Front End Servers.

The capabilities you do or don’t have will depend on the equipment you are using.  For example, this resilient voice architecture will allow for outbound call connectivity.  But it will be up to the carriers to support inbound call failover.  Another example, is unless you have a full scale deployment in the Branch Site, other features will be unavailable such as:

Elan Shudnow :: Sep.27.2010 :: Lync 2010, OCS :: 193316 Comments »http%3A%2F%2Fwww.shudnow.net%2F2010%2F09%2F27%2Flync-2010-media-bypass-with-and-without-voice-resilience%2FLync+2010+Media+Bypass+with+and+without+Voice+Resilience2010-09-27+21%3A15%3A08Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1933

Yes, this is old news and there’s about 462 blog entries (ok, that’s a made up number, but there are a lot) about how to force Communicator 2007 R2 to do an Address Book (Galcontacts.db) update.  These blog entries will talk about the July 2009 update for Communicator 2007 R2 and how it introduced a random delay of 0-60 minutes for Communicator 2007 R2 to download an updated GalContacts.db to prevent the network from getting hammered by so many clients downloading an updated GalContacts.db all at the same time.  And yes, these blog entries also talk about a registry entry you can create called GalDownloadInitialDelay and creating a Dword set to 0 in order to force Communicator to do an instant update.

Some blog articles that talk about this include:

http://www.tincupsandstring.com/2009/12/01/forcing-address-book-download/

http://www.markc.me.uk/MarkC/Blog/Entries/2009/12/17_Force_Downloading_the_Address_Book_in_OCS.html

Now I’m sure you are asking yourself why I am creating this entry?  Is it just to repeat information that’s already out there?  Of course not!

So, Communicator 2007 R2 is a 32-bit (x86) application.  That registry entry works perfectly fine on x86 systems.  But, if you are running on a x64 system, it won’t.  Why?  Well, because when you run x86 applications on a x64 based system, it utilizes a system in Windows called Windows on Windows (WOW64).  WOW64 has its own section within the registry called Wow6432Node.

So let’s say we take the registry key for our Communicator x86 (Communicator x64 not available) and run it on an x86 system.  The following registry key works fine:

But let’s say we have an x64 system.  The above registry key will not work.  We need to utilize the WOW6432Node part of the registry.  The following registry key works for x64 systems:

Please make sure you back up your registry before making changes as making changes to the registry can be harmful to your system if not done properly.

Elan Shudnow :: Jan.20.2010 :: OCS :: 161618 Comments »http%3A%2F%2Fwww.shudnow.net%2F2010%2F01%2F20%2Fforcing-address-book-updates-in-communicator-2007-r2%2FForcing+Address+Book+Updates+in+Communicator+2007+R22010-01-21+02%3A22%3A18Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1616

OCS 2007 R2 Standard Edition Front Ends utilize SQL 2005 Express with SP2 for storing its databases.  Unfortunately, with SQL Express, you will have to backup using SQL Server Management Studio or find an automated way.  This article will detail the steps I utilize to make backing up easier and automated. For information on how to back up OCS, please see the Backup and Restoration Guide here.

The following data will ultimately need to be backed up:

1. Global Config
2. Pool Config
3. Machine Config
4. SQL Databases
5. Standard Edition File Shares

The first command specifies the /level to be global and pool.  The second command specifies the /level to be machine.  What we will do is create a batch file (.bat) and place both commands in this .bat and have them run against the server every 6pm using scheduled tasks.

Our Servername is SHUD-OCSFE01.  The folder to store the backups is C:\OCSBackup.  We’ll also be running the batch file from the C:\OCSBackup.  Because the folder which contains lcscmde.exe is not a part of the system variables, we’ll have to specify the entire path for lcscmd.exe. Taking this information into consideration, our two commands for our batch file will be:

After executing this .bat file, we can see the two files have been created.

SQL Databases

The following is the list of SQL Databases that an OCS Standard Edition Front End uses:

Because we are utilizing SQL Express, we will have to find some other method other than a backup agent to automate the backups. Much of the SQL Backup information is provided by the SQLDBATips Blog.  The following article I utilized is located here.

Create a file with the extension of sql in our OCSBackup folder.  Also, create a new folder called C:\Reports for script reporting. I created a file C:\OCSBackup\ocssqlbackup.sql with the following text:

exec expressmaint
@database      = ‘ALL_USER’,
@optype        = ‘DB’,
@backupfldr    = ‘c:\ocsbackup’,
@reportfldr    = ‘c:\reports’,
@verify        = 1,
@dbretainunit  = ‘days’,
@dbretainval   = 1,
@rptretainunit = ‘weeks’,
@rptretainval  = 1,
@report        = 1

exec expressmaint
@database      = ‘ALL_USER’,
@optype        = ‘LOG’,
@backupfldr    = ‘c:\ocsbackup’,
@reportfldr    = ‘c:\reports’,
@verify        = 0,
@dbretainunit  = ‘days’,
@dbretainval   = 1,
@rptretainunit = ‘days’,
@rptretainval  = 1,
@report        = 1

All of our OCS Databases are User Databases, not System Databases.  We can see this using SQL Server Management Studio which is not installed by default but can be downloaded from here.

Note: Keep in mind that we’re not using the default SQL Express instance of SQLExpress.  The OCS Front End Standard install will create and utilize an instance of RTC.

We now have our .SQL file created.  We’ll go ahead and create a new .bat file called ocssqlbackup.bat.  This batch file will run the following command:

This won’t work just yet.  You can see in the .SQL file, it’s calling the stored procedure “expressmaint.”  We need to create this stored procedure within SQL.  SQLDBATips has the vbscript code in order to do that here.  You take this code and save it as storemaint.sql.  Then run the following code:

Note: The website that shows these instructions specify the -S.\ as -S.\SQLExpress.  Again, we’re not using the SQLExpress instance, but rather the RTC instance.

You can delete the expressmain.sql file now.  This is a permanent change in our instance and we won’t need to run the expressmain.sql script again.

We should now be able to run our SQL backup batch file as our .sql command that specifies our databases and logs has been created and our batch file to call sqlcmd.exe to execute our .sql file has been created.

We can see our ocssqlbackup.bat file successfully runs and creates backups of our databases.

Scheduled Tasks

We obviously want to keep backing up our databases every night in case something goes wrong.  We’ll create two scheduled tasks.  One that runs ocsbackup.bat for our global, pool, and machine specific information.  And the other that runs our SQL Backups.

I am launching the Task Scheduler from Server Manager (I am using Server 2008 but you can access Task Scheduler on Windows 2003 by going to Control Panel).

Create a Basic Task and give it a name.  We’ll name this OCS Backup.  Click Next to Continue.

Specify how often you want the task to run.  I typically run it Daily. Utilize whatever method works best for your organization. Click Next to Continue.

Choose what time the Daily Task will run.  Again, choose whatever time works best for your organization. Click Next to Continue.

We’ll want to run the script.  Because of this, choose “Start a program.” Click Next to Continue.

Specify the path to our batch file. Click Next to Continue. Review the Settings and then Click Finish.

You can then forcefully run the Scheduled Task to ensure it runs.

Now don’t forget to create the second scheduled task to run the batch file for SQL Backups!

Your OCSBackup folder should look something like this after your scheduled tasks run and your data is backed up.

Backing up your data to a remote Backup Server

Now what good is having all this data backed up onto the OCS File System if OCS crashes?  No good!  We’ll still want to take your backup system and back up all these files including the OCS Standard Edition File Shares.  Now keep in mind that you will want to back up all of these files at some time after your batch files are set to run in Scheduled Tasks.  For example, my Scheduled Tasks are set to run at 8pm.  The batch files do not take long to run.  You can have your backup set to run at 8:30pm or 9:00pm.  Be sure to test and validate this is working as intended and you are getting successful backups.

The Standard Edition File Shares you will want to backup include:

So to sum it up, you will want back up all the above file locations and your OCSBackup folder.  Backing up your Reports folder is optional. But again, keep in mind you will want to run this file level backup after all your Scheduled Tasks are successfully run.

Elan Shudnow :: Jan.18.2010 :: OCS :: 158611 Comments »http%3A%2F%2Fwww.shudnow.net%2F2010%2F01%2F18%2Focs-2007-r2-standard-edition-front-end-automated-backups%2FOCS+2007+R2+Standard+Edition+Front+End+Automated+Backups2010-01-18+16%3A22%3A04Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1586

I ran into an issue where we had two OCS 2007 R2 Front End Servers behind an F5 Load Balancer.  We kept getting “This service is temporarily unavailable” from our Communicator Clients after we configured the Communicator 2007 R2 Response Group Tab.  For those that are unfamiliar with this tab, it is a web based extension to the Communicator interface that allows users to log in and out of groups.  For more information about the Response Group Tab, click here.

If we take a look at the F5 documentation for OCS 2007 R2 here, we see the following configuration requires for the Response Group Service (RGS):

What this is saying, is that our client will be connecting over 5071 TCP to our Load Balancer in order to communicate with the RGS.  This is incorrect!  5071 TCP is indeed used for Response Group Service communication, but this is only for Front End to Front End server communication.  The RGS has something called a matchmaking service.  The service on the client is just a website that communicates to the Load Balancer over port 443.  So, the million dollar question… Why do we get a service unavailable?

When you’re dealing with the RGS, each Front End Server has a Matchmaking service.  From the Technet Documentation:

Each Front End Server has a Match Making service, which is an internal service that is responsible for queuing calls and finding available agents. Only one Match Making service per pool is active at a time–the others are passive. If a Front End Server with the active Match Making service becomes unavailable, one of the passive Match Making services becomes active. The Response Group Service does its best to make sure that call routing and queuing continues uninterrupted. However, there may be instances when active calls are lost as a result of the transition. Any calls that are in transfer when the service transition occurs are lost. If the transition is due to the Front End Server going down, any calls currently being handled by the active Match Making service on that Front End Server are also lost.

The Match Making service is what utilizes 5071 TCP.  But as stated earlier, this is only for Front End Server to Front End Server communication.  Our Front End Servers need to be able to communicate with each other without traversing the load balancer.  This means that that each server must be able to contact DNS, get the IP of the other server, and then communicate with that IP over 5071.  This is key as to why we’re encountering the issue.

Sometimes, depending on the environment, servers behind load balancers will have multiple IPs assigned.  One for connectivity from the load balancer and another IP for other server operations such as management.  These Front End Servers had their default gateways set to the F5 and each Front End IP that was used for the F5 were on different segments.  The problem here is when one Front End tried to communicate to the other Front End, it would query DNS and get the IP and it would route to the F5.  The F5 would then route it back but the Front End Server saw it coming from the load balancer and think it’s an unauthorized server for RGS requests.  This is why Communicator would see the service as unavailable.

There are a few ways to fix this issue:

• Modify hosts file on each Front End Server so they are communicating to the correct IP which are on the same segment
• Rework your load balancing configuration so the Front End Servers only use 1 IP which is where the load balancer sends the traffic and have the Front End IPs be able to directly talk to each other.
• Modify DNS so all the traffic destined to the FQDN of the Front End Server would go directly to the Front End IP which is on the same segment as the other Front End IP.
• If you must keep both Front End Servers on separate subnets and have them route through the load balancer, if possible, modify the load balancer so the requests appear to be coming from the original host that sent the request instead of the load balancer.

When it comes down to it, you just need to make sure that when 1 Front End Server talks to another, it needs to appear that it is coming from the other Front End Server instead of the load balancer so that it is an authorized host for RGS requests over 5071 TCP.

Elan Shudnow :: Oct.19.2009 :: OCS :: 13073 Comments »http%3A%2F%2Fwww.shudnow.net%2F2009%2F10%2F19%2Focs-2007-r2-load-balancing-response-group-service-unavailable%2FOCS+2007+R2+Load+Balancing+-+Response+Group+Service+Unavailable2009-10-19+16%3A09%3A22Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1307

Read the Lync Server 2010 version of this article here.

There are several ways in which we can utilize Audio/Video streams in Office Communications Server (OCS) R2.   The same “should… but not verified” work the same in OCS 2007 R1.  There aren’t really any places out there that describe how the media session works in different circumstances.  For example, what servers and ports are utilized when doing Audio/Video through the Live Meeting 2007 client when connected to the On-Premise Web Conferencing feature in OCS 2007 R2?  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…

Media Ports and Restricting Amount of Ports Being Used

The first thing to understand is that in OCS 2007 R2, 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.  You can see what ports are used for OCS 2007 R2 here and here.  This port range is utilized mainly for users who are internal to the network.  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 Group Policy in both OCS 2007 R2  to limit the amount of ports that are being used.

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)

Note: Both clients must have these registry keys set in order for the modified port range to take effect.

You must have at least 40 ports open which is an IETF Interactive Connectivity Establishment (ICE) protocol requirement to ensure that Audio/Video port negotiation works for peer to peer while internal to the network.  ICE is a protocol that provides a mechanism for firewall or NAT traversal.  The RFC draft for this protocol can be found here.

Audio/Video Connectivity Scenarios

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.

Issue to be aware of in OCS 2007 R2 (not verified as an issue in Lync 2010)

Certain certificate vendors like to add www automatically to the CN of your certificate request with consent from the person requesting the certificate.

So for example, our certificate request for a regular certificate (non SAN) was CN=Servername.domain.com.  These vendors provided the following certificate:

• CN=Servername.domain.com
• SAN=www.Servername.domain.com

Now this is where you can run into an issue when doing peer to peer and falling back to the internal Edge NIC or when one person is on the Internet and one person is internal while using Communicator.  Some certificate vendors like to assign a www as a SAN name to your regular (non-SAN) cert.  So if you requested a CN of Servername.domain.com, these vendors will automatically add www in front of your CN.  This messes up peer to peer audio/video negotiation.

This is important to remember when getting a 3rd party certificate for the Internal Edge NIC.  It is not supported to have anything other than a CN for this certificate.  The reason why is ICE negotiation will not work properly.  Because the www.servername.domain.com will be there as a SAN, the client will be provided the www.servername.domain.com name for ICE connectivity to the internal Edge NIC which will obviously fail.  Because of this, the scenarios above which utilize the Internal Edge NIC will fail.  To recap, the following two scenarios end up using the Internal Edge NIC:

• One user internal to the network and one user external to the network
• Internal users attempting to do peer to peer (media ports being closed) and falling back to the Internal Edge NIC

There are a few ways to fix/workaround the problem:

• Use a Windows PKI implementation for Internal Edge NIC
• Deal with the SAN name but use a CNAME for www.servername and redirect that to the servername HOST/A record using Internal DNS to do this as you are dealing with the Internal Edge NIC.
• If the vendor doesn’t add www to their SAN certs, you can get a SAN cert only with the CN filled out
• Go with a different vendor that doesn’t automatically add www to their regular certificates.

Elan Shudnow :: Aug.29.2009 :: OCS :: 120355 Comments »http%3A%2F%2Fwww.shudnow.net%2F2009%2F08%2F29%2Foffice-communications-server-2007-r2-audiomedia-negotiation%2FOffice+Communications+Server+2007+R2+Audio%2FMedia+Negotiation2009-08-29+22%3A27%3A30Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1203

The guidance around where to create your pool and why can be quite confusing.

If you look at the OCS R1 requirements for deploying an Enterprise Pool, it tells you the following:

• If you are using a 32-bit version of SQL Server, log on to your Office Communications Server Back-end Database server as a member of the Domain Admins group.
• If you are using a 64-bit version of SQL Server, create the pool by using a computer with a 32-bit processor, such as the computer that you plan to use as the Front End Server. Log on to the 32-bit processor computer as a member of RTCUniversalServerAdmins and Domain Admins group and with user rights to create and modify SQL Server databases.

If you look at the OCS R2 requirements for deploying an Enterprise Pool, it tells you the following:

• If you are using a 64-bit version of SQL Server, log on to your Office Communications Server Back-end Database as a member of RTCUniversalServerAdmins and DomainAdmins group.
• If you are using a 32-bit version of SQL Server, create the pool by using the computer that you plan to use as the Front End Server. Log on to this computer as a member of RTCUniversalServerAdmins and Domain Admins group and with user rights to create and modify SQL Server databases.

As you can see, it’s a complete 180 between R1 and R2.  To make it easier to digest, here’s an easier format to see what you should do:

OCS R1 with SQL 32-bit – Create Pool on SQL
OCS R1 with SQL 64-bit – Create pool on OCS FE

OCS R2 with SQL 32-bit – Create Pool on OCS FE
OCS R2 with SQL 64-bit – Create Pool on SQL

The reason why it’s a complete 180 is because Microsoft wants you to run the installer on the native platform of the installer.  OCS R1 is 32-bit so you always want to run the installer on a 32-bit machine.  OCS R2 is 64-bit so you always want to run the installer on a 64-bit machine.

But the million dollar question is, is it really necessary to run it from the Backend?  Does that mean you have to insert your OCS CD, install .Net Framework, Visual C++, etc….  Well, you could, but you  can use LCSCMD to configure your pool instead.  LCSCMD is on your CD and you can just open a cmd prompt, navigate to your cd-rom, and run the LCSCMD command with the appropriate settings to configure your pool without needing to install at the tools the installer GUI would require.  LCSCMD would also bypass the requirement from running the installer on the same processor platform (x86/x64.) You can refer to the following article here for information on how to use LCSCMD to create an Enterprise Pool.

But, that doesn’t really explain why it is recommended running it on the Backend. After talking with Ken Alverson from Microsoft about this, I learned a few things.  The reason they recommend to create the pool on the SQL Server is to minimize the possibility of firewall/permissions from interfering.  The Create Pool requires access to both SQL as well as WMI.  You can technically open up all the ports to SQL as well as WMI and run Configure Your Pool from your OCS Server.  This is what I did but instead of opening it completely, I  ran Network Monitor to determine what ports to open.  You could also disable your Windows Firewall on your SQL Server to ensure access to your SQL Server.  Never disable the firewall service on Server 2008 as this disrupts proper communication.  Either turn the firewall off or go into the advanced firewall in the administrative tools and open everything up.

So in short, you have the following options with OCS R2:

1. Turn off firewall on SQL (don’t disable firewall service) and install from OCS Server (lowers security but easiest to do.)  After the pool is created, you can re-enable your firewall as long as you follow the OCS documentation (installation guide for Enterprise Edition) and open the necessary ports.)
2. Allow SQL Ports and WMI to traverse SQL Firewall (more secure than #1 but less easy to do)
3. Run Create Pool from SQL Server via the GUI Installer (more secure than #1 and #2 but not an option I like due to it installing GUI prerequisites)
4. Run Create Pool from LCSCMD via the CD which will install a SQL prerequisite I believe (most secure option but requires knowledge of the LCSCMD command.)  You can refer to the following article here for information on how to use LCSCMD to create an Enterprise Pool.

I would appreciate if readers can make a quick comment on what method you use.

Elan Shudnow :: Jun.01.2009 :: OCS :: 10989 Comments »http%3A%2F%2Fwww.shudnow.net%2F2009%2F06%2F01%2Fcreate-pool-run-on-ocs-or-sql-server%2FCreate+Pool+-+Run+on+OCS+or+SQL+Server%3F2009-06-02+00%3A54%3A15Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D1098

Welcome to Part 2 of this article series. In Part 1, we started off by preparing our servers in preparation for OCS Group Chat Installation. We created our services, created our SQL Database, and assigned permissions.

In this Part, I will go over the installation of our Group Chat Server and Administrative Tools.

Part 1

Part 2

Group Chat OCS 2007 R2 Server Installation

When installing OCS R2 Group Chat  and running the setup executable, you will be asked to install several pieces of software to prepare the environment.

You will be asked to install the Microsoft Visual C++ 2008 Redistributable. Click Yes to Continue.

You will then be asked to install the Microsoft .NET Framework 3.5. Click Yes to Continue.

You will then be asked to install the Microsoft Unified Communications Managed API 2.0 Core Redist 64-bit version.  Click Yes to Continue.

Once Microsoft Unified Communications Managed API 2.0 , you will be presented with the Welcome screen which will begin the installation process.  Click Next to Continue.

The next screen is the licensing screen.  Make sure you fully read the entire agreement!  Once you have done so (and I know you will, right?) Click Next to Continue.

Enter your Username and Company information. Click Next to Continue.

Enter the installation path you want the binaries installed to. Click Next to Continue.

When the feature screen appears, you have 2 choices which are both selected at the same time.  Keep in mind, that you must disable one of the options.  You cannot have both the Chat Server and the Compliance Server collocated on the same box.  Make sure the Chat Server is selected and the Compliance Server is not selected.  We will be installing the Compliance Service in the next Part.  Click Next to Continue.

Confirm your installation.  Click Next to Continue.

Installation is ready to proceed.  Click Next to Continue.

During the installation, you will see the Server Configuration wizard appear.  Because we chose the Chat Server to be installed, you will see three Server/Service roles being installed:

• Lookup Server
• Channel Server
• Web Service

Click Next to Continue.

We now want to specify what SQL Instance we want to use.  One thing to keep in mind is to take a look at the collocation technet article to see how databases can be collocated on the same SQL box.  You can find this article here.  You can see the following databases can be on the same SQL Box:

• Archiving database
• Monitoring database
• Group Chat database
• Compliance database (for Group Chat)

One thing to keep in mind here, is that for each database, it requires its own instance.  In the case of Group Chat database and the Compliance Database, the Compliance Database can be a dedicated database or it can be the same database as the Group Chat database.  In Part 2, we will be using the Group Chat database as the Compliance database.

As you may recall from the OCS R2 Enterprise article series here, we’re using a SQL 2008 x64 Back End.  Make sure port 1433 is allowed inbound.  Instructions on how to do this are documented in that article series.

Specify your Server\Instance and Database.  As stated, I’m just using the default instance for everything since it’s a lab.  Specify your settings accordingly.  Click Next to Continue.

The next screen will just notify you that your databases are empty and that it will create the schema information.  Click Next to Continue.

We will want to specify a Super User.  It’s pretty obvious what this user is.  It’s essentially the Administrator account in AD.  The first time you create AD, you will log in with the Administrator account and start creating other Administrator accounts from there.  The Super User is the same thing.  Because this is a lab, I am using the Administrator account to manage everything.  So in the User name field, I specified my Administrator account and clicked Add. Click Next to Continue.

Specify the name of your pool and the MTLS Certificate that will be used by your Group Chat Server.  You will need to create this certificate beforehand by using LCSCMD, CertSRV website for an internal CA, or using the OCS Administrative Tools.  Click Next to Continue.

Remember I said the Lookup Service is the one service that will be utilized across all Group Chat Servers and that it also needs to be SIP Enabled?  Well now is the time to enter in the Lookup Service credentials and SIP information. Click Next to Continue.

Do the same for your Channel Service. Click Next to Continue.

On the next screen, we’ll be asked for our Compliance settings.  Because this is the first Group Chat Server and we have not yet deployed our Compliance Server, we’ll leave these settings blank and re-visit the configuration later.  Click Next to Continue.

Specify the  directory that will be used for uploads to the Web Service.  You will want to use a UNC path, especially if you’re using multiple Group Chat Servers.  I created a shared folder called WebService.  You will need to ensure your Channel Service has read/write to this share (both Share and NTFS permissions.) Click Next to Continue.

Review your settings. Click Finish to Continue. When finished installing, Click Close.

You will want to ensure that Anonymous Authentication is enabled in IIS on your MGCWebService directory in your Default Web Site.  After doing so, you will want to use your Channel Service account as the credentials used for Anonymous Authentication.  It doesn’t have to be the Channel Account, but just an account that has RTCComponentUniversalServices permissions because the account needs to access the file repository and Message Queuing.

Group Chat OCS 2007 R2 Administrative Tools

As most of the other client and administrative tools installations, I won’t go over the installation procedures as they’refairly straightforward.  So go ahead and install the Administrative Console.  I have installed it on our SHUD-PG1 Server which is the server we installed the Group Chat Server on.

Once installed, go to Start > Programs > Microsoft Office Communications Server R2 > Microsoft Office Communications Server R2, Group Chat Administration Tool

Once you open it, Group Chat Administration will always be set to do an Automatic Logon and use the existing signed on account.

You may have trouble getting this part to work properly.  This is my 2nd time installing and getting Group Chat to work so I’ve went through the pain to get everything to work properly and seamlessly off the bat.  The trick is, during Group Chat installation, you gave it a super user.  You’ll want this to be your Administrator account you’re using to install Group Chat and the system that you will be loading the Administration Tool.  Only a super user can load up the Administrative Tool.  So if you set your Administrator account that you log onto which is also SIP enabled as the Super User, and are logged onto that account when loading up Administrative Tool, everything will just work.

If Automatic Configuration does not work, you can set the Account to Manual Configuration and manually configure the account to use for log-on, DC to use, etc…

You can now create new Chat Rooms on the left, add new Super Users, Chat Room Managers, etc..

Summary

Well folks, that is all for Part 2 of this article as well as the 2 part article series.  Hopefully it helps you plan and deploy Group Chat.

Elan Shudnow :: Mar.18.2009 :: OCS :: 94247 Comments »http%3A%2F%2Fwww.shudnow.net%2F2009%2F03%2F18%2Foffice-communications-server-2007-r2-group-chat-deployment-part-2%2FOffice+Communications+Server+2007+R2+Group+Chat+Deployment+-+Part+22009-03-19+03%3A42%3A05Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D942