Category Archives: Microsoft

Lync RBAC with Child Domains Bug- Fixed in CU2

Prior to Lync Server CU2, if you attempted to create a custom Administrator Role to a child domain, with a user scope set to that child domain it would not work. Example Provided Below:

Contoso.com: Empty root domain

Site 1:Child1.contoso.com

1x Std Edition Front End w/ CMS

Site2: child2.contoso.com

1x Std Edition Front End

Lets say we wanted to create a custom admin role that gave an administrator in the CHILD2 domain to manage his users specifically in the CHILD2 domain. Assume In this scenario you would be logged into the CHILD1 domain with full admin permission on all domains, and CSAdministrator.

The cmdlet would look like this:

New-CSAdminRole –Idenetity Child2CSUserAdministrator –UserScopes “OU:ou=Users,dc=child2,dc=contoso,dc=com” –Template CSUserAdministrator

Before Applying CU2 you would receive the following error:

Set-CSAdminRole : Organization unity (OU) or container “ou=Users,dc=child2,dc=contoso,dc=com” does not exist. Specify a valid OU or container, and then try again.

Once you apply CU2 this error would go away and you would successfully be able to create the custom Admin Role.

Another similar issue with creating or modifying admin roles to have a use OU scope, is that they are Case Sensitive! The OU must be in the exact case as is seen in Active Directory. See the screenshot below for an example, in my lab, when trying to set an admin role with “users” instead of “Users” it fails, switching to “Users” succeeds.

clip_image002

Hope this helps!

Deploying DSCP QoS On Server 2003 R2 and Server 2008 R2

This is a brief post to summarize my experiences with deploying quality of service in a recent deployment.

In this engagement, the customer had existing OCS 2007 R2 infrastructure, these were running Server 2003 R2 with the latest service pack, and were running on HP hardware with Teamed NICS for redundancy, not load balancing.

When attempting to deploy packet tagging on the servers using the QoS Packet Scheduler and related policies, packets would not tag at all. When breaking the NIC Team packets would tag, and on any servers without a teamed NIC the same policies worked fine. This was identified as a known issue with 2003 R2 and Teamed NICS.

The good news, is that while we are upgrading to Lync Server 2010 their new servers are running Server 2008 R2 and on similar hardware with Teamed NICS. As of today we have tested QoS deployed using the packet scheduler and related policies and it does work with the Team.

Deploying a Lync SBA? Watch out for port 444 (Updated with more ports)

As Lync deployments start ramping up, we are starting to notice a few gotchas in documentation and deployments. One thing that has come up a couple of times is deploying a Lync SBA in a branch site with a firewall between the Datacenter and branch office.

The firewall ports required for the SBA are not well documented, particularly one that is very important to making the SBA Work.

Port 444 TCP is required for front end to SBA communications, below is the only documentation I have found on it so far in the CHM.

Front End Servers

Front-End service

444

HTTPS

TCP

Used for HTTPS communication between the Focus (the Lync Server component that manages conference state) and the individual servers.

This port is also used for TCP communication between Front End Servers and Survivable Branch Appliances.

 

I reviewed the Lync 2010 Workloads Poster and it is not showing this port as well. However, I have requested an update which we will hopefully see soon.

So, very important, open port 444 TCP between your Data Center and your Branch Office or users will not be able to register against the SBA. Reference of the ports can be seen below.

 

image

As a follow up, one of my colleagues pulled together the full list of firewall requirements for branch users. As many enterprises have firewalls between branch and central sites, this list becomes very important. Look for a workloads poster focused on firewalls from Microsoft soon, but hopefully this comes by then. Credit for this list goes to Peter Pawlak at UnifySquare:

SBA (ASM side) <-> Central Site Pool(s):

· TCP/5061 (both ways)

· TCP/444 (both ways)

· TCP/445

· TCP/448

· TCP/5062-5065

· TCP/5072-5073

· TCP/5076

· TCP/5080

(NOTE: I’m not 100% positive that ports in RED are really needed)

SBA -> Monitoring Server(s) (to support MSMQ)

· TCP/135

· TCP/389

· TCP/1801

· TCP/2101

· TCP/2103

· TCP/2105

SBA (ASM side) <-> Exchange UM servers

· TCP/5061

· UDP/<ExUM media port range>

SBA (ASM side) <-> Edge Server(s):

· TCP/5061

· TCP/5062

CMS servers -> SBA (ASM side) (for local config store replication)

· TCP/4443

· TCP/444

· TCP/445

Branch Clients -> SBA (ASM side):

· TCP/5061 (client->SBA)

· TCP

· UDP/<media port range> (assumes no media bypass)

Branch Clients <-> SBA (GW side):

· UDP/<media port range> (assumes media bypass will be used)

Branch Clients -> Central site Pool (must be pool in site associated with Branch site)

· TCP/8057 (and TCP/8058 if using Lync’s legacy data conf service)

· TCP/5061 (to allow failover to backup central site)

· TCP/<app share conf MCU port range>

· UDP/<A/V conf MCU port range>

Branch Clients -> Central site Pool Web service HLB VIP (pool in site associated with Branch site)

· TCP/443

· TCP/80 (needed by Lync PE devices)

Branch clients <-> Clients & Mediation servers/services in other sites

· UDP/ <media port range>

· TCP/<media port range>

Branch clients <-> Edge servers (running media relay)

· UDP/3478

· UDP/ <media port range>

· TCP/443

· TCP/<media port range>

Branch clients -> Exchange UM servers

· UDP/<ExUM media port range>

Branch clients -> Exchange CAS servers (for EWS)

· TCP/443

Using OCS 2007 R2 CWA with Lync Server 2010

At this time, there are going to be a few scenarios where you may need to deploy the R2 version of Communicator Web Access with Lync Server 2010. The core reason here, is that the RTM Version of Lync Server 2010 contains a feature on the front end called Lync Web App. Eventually, Lync Web App will become a full featured web client, however, today it is only used for users to join online meetings from the web. There is no ability to access Lync Web App from a URL and sign-in, or use it as a instant messaging too. This is planned to be released SP1 of the product, that timeframe is unknown right now.

To fill this gap, customers will have to deploy the OCS 2007 R2 CWA role, which can register against a Lync Server 2010 Pool. This post will show you how to configure OCS 2007 R2 CWA to work in your Lync Server 2010 environment.

 

Preparing the Environment

The most important piece of information in this blog, is that the Schema Prep for OCS 2007 R2 must be run in the environment before the Lync Server 2010 Schema Prep, or you will not be able to install the R2 version of CWA. If this is a deployment where there have not been prior installs of OCS 2007 R2, you will need to obtain this media, and run that Schema Prep before your Lync deployment starts, so it is very important to plan for this in your design/planning phase of your project.

Also, to get straight to the point for this blog, I am going to assume you have prepared the schema in the correct order, have your Lync Server 2010 environment online, and have already installed the CWA Role on a server. I will walk through creating the virtual directory, as well as integrating it with your Lync environment.

Use this Deployment Guide to install and configure the CWA role

Creating the OCS 2007 R2 Virtual Web Server

One you have the CWA role installed, and a valid certificate installed on the server, you must configure the virtual web server that clients will access.

I will walk you through the process for creating an External web server, however the same process applies for the Internal web server. The difference being the types of authentication allowed, external allows forms, where as internal also allows NTLM authentication.

Login to your R2 CWA server, and open the Communicator Web Access Admin Console

image 

Once in the admin console, right click on your server and choose Create Virtual Web Server

image

Navigate through the setup wizard, choose only your Web Server Type, in my case I am choosing External. Make sure to select a valid HTTPS certificate when prompted.

When you get to this section, Specify IP Address and Port it is important to note that this is the IP and listening port for your web server, not the communication between Lync and your CWA server, we will get to that next.

image

After entering a description for your virtual web server, the most important part of this wizard is the Specify a Listening Port section. This port defines what this application will listen on, and communicate with your Lync front end on. Because of the change in ports between OCS R2 and Lync, previously used values like 5070, or 5071 as you will see in older blog posts of mine do not work. You must pick a port that is not being used by an application currently. For my example I am using 4790.This can be any port, as long as your Lync front end and this server can communicate on that port.

image

Next, define your next hop pool, choose the appropriate Lync pool as your next hop and leave the port to default 5061.

image

Complete the wizard and start the virtual server.

Your settings should look similar to this

image

Now that you have completed this, you will need to make Lync aware of this server.

As you will find in the OCS 2007 R2 to Lync Server 2010 Migration Guide, you must merge your Legacy (OCS 2007 R2 components in to your Lync Topology.

Configuring Lync Server 2010

Now that we have our CWA server configured, we must make the Lync topology aware of this server. To do so, we will merge the legacy topology in to our Lync topology. This is possible through PowerShell using the Merge-CSLegacyTopology cmdlet, however I will be using the GUI.

Before completing this task, you must install the OCS WMI Backwards Compatibility tool, this can be found on the install media, called ocswmibc.msi

First, navigate to your Lync front end and open the Topology Builder.

If you already have coexistence with a R2 environment you will be very familiar with this process, and you will also see the BackCompatSite listed.

image

Right click where it says Lync Server 2010 and choose Merge 2007 or 2007 R2 Topology

image

In this post, I am assuming there are no R2 pools, and we are just importing the CWA server and web site. Because of that, you will actually leave the wizard blank when it asks for servers. This wizard will connect to servers in your environment and pull configuration data out of WMI, and input them into this BackCompatSite that will reside on the CMS. This is the major change from OCS 2007 R2 to Lync, is what used to be in WMI, is now in the CMS. You can find plenty of resources to get into more detail about that on Nexthop.

image

image

image

Verify the setting selected in the wizard, and choose Next to merge your legacy topology.

Everything should complete, choose Finish and you will now see your new site.

image

Expand BackCompatSite and expand TrustedApplicationServers for this blog post, we are concerned only with the trusted application servers, this is where your CWA, and other R2 server roles like group chat will appear.

image

Once you have verified that your R2 CWA server appears correctly, right click where it says Lync Server 2010 and choose Publish Topology.

image

 

Once you have published your topology, we will have one last step to verify our web server was imported correctly.

Open the Lync Server Management Shell and run the following command: Get-CSTrustedApplication

This command will return trusted applications that are associated with Trusted Application Servers and Trusted Application Pools in your environment, you may have many depending on your topology. However the two we are looking for, involve CWA.

Your output should return something similar to below:

image

I have crossed out my server names, however there should be the FQDN of your CWA server where I have marked.

The two entries represent the external facing web site that users hit, as well as the port that is used to communicate with the Lync front end, as you can see highlighted below, the port you assigned should be listed there.

image

You should now be able to login to CWA as a Lync Server 2010 user! If you run into issues, make sure to check out this blog relating to the SPN error related to CWA service accounts in R2.

http://theucguy.wordpress.com/2009/03/27/communcator-web-access-r2-error-0-1-492/

Also, make sure that your CWA server is on the latest release of OCS 2007 R2 patches which can be found here:

http://technet.microsoft.com/en-us/office/ocs/ee695846.aspx

 

I hope this helps you extend CWA capability to your Lync users, if you have any issues please contact me via the comments and I will try to help you the best I can.

Error When Installing UM Role on Exchange 2010 SP1

11/12/2010 12:31:24.0997] [2] Active Directory session settings for ‘install-umservice’ are: View Entire Forest: ‘True’, Configuration Domain Controller: domaincontrollerfqdn, Preferred Global Catalog: “domaincontrollerfqdn”, Preferred Domain Controllers: ‘{ domaincontrollerfqdn }’
[11/12/2010 12:31:24.0997] [2] Beginning processing install-UMService
[11/12/2010 12:31:26.0012] [2] [WARNING] An unexpected error has occurred and a Watson dump is being generated: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:26.0012] [2] [ERROR] There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:27.0668] [1] The following 1 error(s) occurred during task execution:
[11/12/2010 12:31:27.0668] [1] 0.  ErrorRecord: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:27.0668] [1] 0.  ErrorRecord: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
   at Interop.NetFw.INetFwRules.Add(NetFwRule rule)
   at Microsoft.Exchange.Security.WindowsFirewall.ExchangeFirewallRule.Add()
   at Microsoft.Exchange.Configuration.Tasks.ManageService.Install()
   at Microsoft.Exchange.Management.Tasks.UM.InstallUMService.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()

 

When running the wizard to add the UM role to your Exchange 2010 Sp1 server, you may have this error appear in the install wizard:

ErrorRecord: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)

If you take a look at the Exchange setup log, it is trying to add firewall rules, and fails, and kills the install. If your windows firewall service is not running, you must start it.  Re run the installation with windows firewall running, and all is fine Smile

Powershell Script to create new user, enable for Exchange, UM and Lync Server

I created this powershell for our internal onboarding process, figured I would share it with the masses.

I think there are a couple good takeways from this script, it remotes into Exchange 2010 and Lync Server 2010 Powershell sessions, so nothing except Powershell 2.0 is required on the client side, which is standard with Windows 7. It also shows how you can simultaneously use Exchange and Lync powershell commands in the same script to get things done.

A couple of disclaimers:

I am in no way advanced at powershell scripting, so nothing fancy here.

This was developed specifically for my internal needs, you will probably have to add/remove variables and requirements.

http://cid-389bd51b03b1f8f9.office.live.com/embedicon.aspx/Public/UserSetupScriptGeneric.ps1

 

Script is above, any freedback is appreciated, if you improve on this at all, I would love to see it as well.

OCS 2007 R2 Cumulative Updates- September 2010

So, if you recall, the July updates were pulled due to some issues with response groups. Today, the OCS team has released two September updates, one for the Response group, and one for web components.

Check this link here for all information and download links for the updates.

http://support.microsoft.com/kb/968802

Reference: Setting Event Log Levels for Exchange UM

Exchange 2007 and Exchange 2010 allow you to configure different event logging levels for all Exchange services.

I commonly have to enable more detailed Exchange UM logging on UM servers to troubleshoot call flow issues, so here is a quick reference of how to do this.

First off, here is the technet reference to doing this for all services:

http://technet.microsoft.com/en-us/library/bb201670(EXCHG.80).aspx

In Exchange 2007, you must do this through Powershell, Exchange 2010 however is available right in the Exchange MMC.

For Exchange 2007:

Start by opening your Exchange Management Shell

The following powershell commands are required for the Exchange UM services

set-eventloglevel -identity “MSExchange Unified Messaging\UMWorkerProcess” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMCore” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMManagement” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMService” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMClientAccess” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMCallData” -level Expert

In Exchange 2010 the same powershell commands will work, however, if you are more comfortable with the UI, you can do it directly in the Exchange MMC.
First open the Exchange Management Console
Expand your On-Premise Organization and select Server Configuration

Select your UM server from the list of available servers, and you will notice on the right hand side, under Actions for that server you will have Manage Diagnostic Logging Properties


Select Manage Diagnostic Logging Properties and you will be prompted with a full list of services on your Exchange server to manage. Expand MSExchange Unified Messaging, for each service you wish to raise the level, select that service, and then select the option for whatever level you wish to enable. Expert is typically a good level to have if dealing with UM.
Once you have configured all of your service levels, choose configure. This will basically execute the Powershell commands listed above and confirm Completion.

Install the OCS Enterprise Edition Backend Database in Separate Forest

So the title of this post sounds kind of crazy, and you may be asking yourself, WHY???

Well, internally we have two networks and two separate forests connected over a gigabit fiber link. These locations are in two separate buildings in the city. One is in our office, and one is in our hosted data center.

Without diving too deep into our network setup, the point is, we have a SQL server in our office that is currently being decommissioned, and it holds the OCS R2 Enterprise Pool backend. In our data center, we have a very nice SQL 2008 server to move all the databases to.

To sum things up, this does indeed work, at least in our situation. It is important to note that it is not supported nor recommended as I have only tested basic functionality, and done no performance testing. Also, we have a full two way trust between these forests, so permissions were not an issue.

In the end, we decided not to do it because we rely too heavily on OCS as our complete UC platform, and did not want to risk any performance issues.

If this is something you absolutely must do, it does in fact work.

Alternative to RCC With Cisco and OCS 2007 R2

Often I run into customers that want Remote Call Control with their current phone system as an integration architecture with OCS 2007 R2. Personally I see the benefit to remote call control in LCS, and OCS 2007 R1, but not with the R2 release, and especially with Wave 14 so close. Many times I have had to explain the different scenarios, and why I think a different architecture is a better way to approach this. Today I had to develop this information for a Cisco Call Manager implementation, and wanted to have a reference point, as well as share my thoughts on the subject.

To give a brief background, the customer wanted RCC with Cisco, they currently have an OCS infrastructure in place, and wanted to add the RCC functionality to that environment. In order to do this, they would need to upgrade to Call Manager 7, which is the very first reason to not go any further with the RCC architecture in my opinion. If you are investing in the Microsoft Unified Communications technology stack, there is no reason to dump more money into another UC product along side it.

As a summary, here is a description of what RCC is… Credit goes to this blog post http://blogs.technet.com/jkunert/archive/2008/07/30/voice-scenarios-with-ocs-2007.aspx

This is a description from the R1 release of OCS 2007 but still holds true today.

Remote Call Control (RCC)

Overview

Also this voice scenario was already available in OCS 2007 predecessor Live Communications Server 2005 SP1. The users OC client does not act as a soft phone, does not need an audio or audio/video device connected to the PC and the user is not able to make or receive phone calls by using her/his PC. This is not a VoIP scenario!

User experience

In this scenario, an OCS 2007 user has a PBX or IP PBX phone with an extension (e.g. 1212) standing on her/his desk. In addition to that, Office Communicator (OC) 2007 is installed on the user’s PC.

In the office

On an incoming call the user’s PBX phone rings as well as that she/he receives an incoming call notification (pop-up window) on the bottom right of her/his PC screen, showing the Calling Party Number (Caller ID, phone number of the person who called) and also the caller’s name (if OC could resolve the phone number to a name by matching the phone number against Active Directory or Outlook contacts). The user is able to accept the call by picking up the receiver of the PBX/IP PBX phone or by clicking on the pop-up window for the incoming call on her/his PC. In both cases, media (voice stream) will stay on the PBX/IP PBX and there will be no VoIP connection to OC! The user does not need an audio device for telephony connected to her/his PC.

At home/on the internet

If the user receives an incoming call to her/his office number while being connected to the company’s IT environment over the internet (e.g. at home), the users PBX/IP PBX phone will ring in the office (what she/he most likely will not be able to hear J) as well as that she/he can see the pop-up window generated by OC on her/his PC. Accepting the call by clicking on the pop-up window will result in this scenario that the phone in the office will activate the speaker phone, but the user is not able to use her/his PC to talk to the caller. No VoIP connection through the internet is established! (However, the user can redirect an incoming call to her/his mobile phone and can pick up the call this way while working remotely.)

How it works in a nutshell

A CSTA Gateway (GW) needs to be installed between OCS 2007 and the PBX/IP PBX. Some PBX/IP PBX systems come with a CSTA interface natively so there is no need for an additional GW. Between OCS and the PBX/IP PBX call control commands will be sent, packed into a SIP INFO message that uses a long-lasting SIP dialog between OCS and the CSTA GW. The CSTA GW converts these call control messages into a format that the PBX/IP PBX understands. A CSTA GW is not a media GW so voice cannot be converted by a CSTA GW from a TDM (Time Division Multiplexing) or PSTN protocol to VoIP! OC can only control the functions of the PBX/IP PBX phone.

 

With a Cisco integration, we would actually be able to do direct sip as long as the following software requirements are met on the Cisco side:

  • Cisco Unified Communications Manager Release 7.0(2)
  • Cisco Unified Presence Release 7.0(3) with E.164 patch for RCC

One of the key features of the Microsoft OCS Platform is the ability to have not only integrated IM and Voice calling, but also conferencing, all within the same application, and all available through a single click. Any communication can be escalated to a conference by inviting PSTN or VOIP participants at any time. When you introduce the remote call control scenario this is no longer available. A Key thing to point out is that a user in this scenario cannot make or receive calls using communicator, they still must use the Cisco phone in all scenarios, which virtually eliminates the remote worker benefits of OCS.  Below is the list of other limitations taken from the Cisco Documentation on this configuration:

Features Not Supported

· Microsoft OC logon from two locations

· Call Forwarding

· Location Based

· Phone Settings

· Conferencing through remote call control

Limitations

· Conferencing: OCS 2007 R2 does not support call conferencing through remote call control. Conferencing is available in IP Phone

only or OC only call scenarios.

· Call forward setting on IP phone: Call forward setting made on the Cisco IP phone (desktop), using its soft key button or the Cisco

UCM phone configuration page, is not reflected by the Microsoft OC GUI. As of Microsoft OCS 2007 release, this feature is not

supported. The Microsoft OC can override any call forward setting manually configured on the IP Phone and vice versa.

· Call Forward Setting from OC: Call forward setting from the OC through remote call control (RCC) fails on the IP Phone when the IP

Phone is initially configured with an E.164 DN. If the IP Phone is reconfigured to a non-E.164 DN then back to the E.164 DN, the

call forward setting from OC through RCC will work. This is a known issue on Cisco UCM 7.0(2) and has been documented in

CDETS CSCsy62620 to be fixed in a future release.

· Do Not Disturb (DND): DND is an unsupported feature with respect to CUP integration. Thus, any OC client with DND feature

enabled, will still have any received calls routed to its controlled IP Phone.

· Multiple Point of Presence (MPOP): As of the CUP release 6.0(1), the MPOP feature where a Microsoft OC user is logged in from

more than one location is not supported by CUP. Support for this feature affects other interoperability features between the Cisco

CUP and the Microsoft OCS. The affected features include basic placement and teardown of calls and locations-based call forwarding.

These features are inherent to MPOP and without support for this feature, the user experiences loss of device and call control when

logged in multiple locations.

· Transport Layer Security (TLS) connection between CUP and OCS: this feature was not tested in this release.

As you can see, you quickly start to lose a lot of the functionality of OCS. I will stress that the above is strictly related to Cisco, and may not be completely accurate for other RCC Scenarios.

The other option, and most optimal solution in my opinion can be most closely referred to as a standard Enterprise Voice Scenario. Really, it is the cheap way of doing remote call control.

Last year I had multiple voice deployments which had to provide interop between OCS and the existing PBX, mostly Avaya and Cisco systems. A key requirement of all of these deployments was the ability to pilot OCS functionality but also have access to their old phone for use. The architecture we used to provide this can be seen below. We had to make a connection between the OCS environment and the PBX, whether it was a Sip trunk to cisco, or a PRI connection via media gateway to the other systems. From there we have two options for routing incoming/outbound calls for OCS enabled users.

The first scenario is where the PBX controls the call routing. All PRIs, or SIP trunks come directly into the PBX, from there you have routing rules to route certain numbers over a trunk to OCS. This can be accomplished by setting routing rules at the PBX level, or simply forwarding your PBX Desk phone to your OCS extension, which will route it over to the OCS Trunk. It is important to note that in both scenarios you are configured for different extension on the PBX and OCS. Where your “real” extension goes depends on how you wish to route/forward calls. Regardless, any DID numbers, or existing extensions are still usable, it’s just a matter of getting the call there. In this scenario for example, you may have “fake extension” in OCS, and when your existing extension is rung, your cisco phone forwards the call to your OCS extension, in the PBX this new block of OCS extensions is configured explicitly to route over that new trunk, this is the simplest way to make this connection happen with the least amount of changes on the existing PBX environment.

The other scenario lets OCS control the call routing. In this scenario all PSTN calls destined for OCS Enabled users go directly to OCS. This can be more difficult to implement at first, but once it is in place, it provides a very smooth transition. This can be accomplished from a direct SIP trunking connection to an OCS mediation server, or a PRI/POTS connection from a provider, into a media gateway, which then sends the calls on to the OCS mediation server. It is possible to move all incoming PRI connections to a media gateway, which would then control all calls. From there that media gateway can send to the PBX or OCS. In the Cisco world, this could actually be a 2800 or 3800 series ISR. To some people this is a bit scary to hear at first, but really, your current PRI lines come into some sort of gateway device as it is, this would provide the same functionality. The gateways used are by companies like Dialogic and NET with great experience doing this for years for traditional PBX systems, so it is more than reliable. From here, there is also a trunk setup to the PBX to route extension dialing, as well as for simultaneously ringing the legacy PBX phone.  In both scenarios the voicemail can be sent to exchange unified messaging or back to the PBX voicemail system. When OCS has no answer, it can make this choice. The PBX will be smart enough when the call comes back and is tagged with no answer, to send it directly to voicemail instead of creating an endless ringing loop.

In scenario two, if the media gateway takes all PSTN calls in, it will have some basic routes on it. Routes that control sending OCS enabled users to the mediation server, and then a default route which will send everything to cisco. Basically, if you had 5 users enabled for OCS. You would have a rule on the gateway that had 1000-1005 with a destination of the mediation server. The second route would be * (any) with a destination of the PBX. This takes the load of modifying PBX configuration.

In this specific scenario, the media gateway could be a dialogic/NET device, or simply the PRI interface on the Cisco ISR.

It is important to note that with both of these scenarios you have full functionality of both systems at any given time. You can use your cisco phone to make and receive calls, or your OC client to make and receive calls. You can also take advantage of all conferencing, and other advanced functionality that OCS has to offer like remote access.

CiscoEVScenario

There may be some things that need clearing up in this, and I am open to some feedback, but this is really what I have been going off as a reference point for myself with these deployments. Another important factor is the retirement of Dual Forking and RCC in Wave 14 of OCS set to be released this year, existing OCS 2007 R2 implementations will be supported, however new deployments will not. This has made some companies forget about RCC implementations all together.