Category Archives: OCS 2007 R2
I am currently investigating an issue I have internally, and have heard someone else having on the Technet forums: http://social.technet.microsoft.com/Forums/en-US/ocsconferencing/thread/f9512694-c298-4951-b6d6-0d240ccd0397
The issue is that when in a communicator conference call, you cannot send DTMF tones to a PSTN participant. The scenario is as follows:
- Communicator call, or communicator conference call is initiated
- User invites a PSTN number to that conference call
- PSTN number requires DTMF tones, whether it is a conference bridge, or an attendant menu, could be various situations
- No DTMF is received by the PSTN number.
So far, I have been able to confirm a couple of things. This happens with CS2010 as well as OCS 2007 R2. Internally we use a Dialogic DMG2120 gateway, and I have confirmed that I do not see DTMF on the gateway’s SIP side from OCS.
I am using this post to hopefully get some partners and customers to try this scenario, and see if they have the same issue. I would find it hard to believe that this is a bug in OCS/CS2010 that Microsoft has not addressed, but I am hoping to find a common configuration among people experiencing this issue so we can maybe narrow it down.
Typically this is a gateway issue, however like I said, I have not seen any DTMF come from OCS to the gateway when in the conference call.
Please respond in the comments with a brief description of your OCS setup and gateway/SIP trunk, and if you experience this issue or not.
It is identified in the above article. AVMCU does not support DTMF Relay. Thanks to the commenter!
In my previous post I outlined configuring Forefront TMG 2010 to publish the OCS 2007 R2 web components. Please see that post for basic installation instructions and network configurations.
In this post, I will outline publishing Communicator Web Access (CWA) to the internet using Forefront TMG 2010.
DNS Records and Certificate Requirements
First lets cover the new DNS records and certificate entries required for communicator web access. With the addition of desktop sharing to CWA, additional DNS records and certificate entries are required to provide that functionality.
The following DNS records are required for CWA:
CWA Desktop Sharing
CNAME to cwa.domain.com
CWA Desktop Sharing
CNAME to cwa.domain.com
Your certificate will need to have all of the names above on it.
In my environment I have the following certificate information:
Common Name: cwa.winxnet.com
Subject Alt Name(s): as.cwa.winxnet.com download.cwa.winxnet.com
CWA Web Site Configuration
In my example I have two web sites configured on the CWA server. One for internal access and one for external access. When you create virtual servers for CWA you have two options for site types, Internal and External. The only difference is authentication type. Internal sites will let you choose NTLM authentication, which allows for simple access from inside the corporate network on domain joined machines. External sites will use Forms-Based Authentication, or Custom Authentication. Custom authentication can be used to perform two factor authentication with services like RSA or other smart card/pin authentication methods.
In our example our Internal site will be a standard internal site listening on port 443. Our external site however will run on port 4443, and we will perform bridging with the forefront TMG server to give users access to this site.
I will outline creating the external web server, assuming an internal web server has been configured listening on port 443.
First, open the Communicator Web Access management console, this is separate from the OCS 2007 R2 primary admin console, but is included when you install the admin tools on any machine.
Right click on the server name and choose Create Virtual Web Server.
At the next window, this is where you will choose your web server type, choose External.
The next window allows you to choose your authentication types. If you were using a third party authentication method you would specify it here. Although it says in the description that the built in windows integrated and forms-based authentication will be used, the external web site will only allow Forms-Based Authentication.
The next window confirms those authentication settings, notice NTML is grayed out.
The next screen has you specify an SSL certificate to be used with the https requests. You can choose HTTP if you are using an SSL Accelerator device, but you cannot use CWA over HTTP without such a device.
Choose the certificate you created with all the necessary name entries and hit Next
The next screen has you specify the IP address and port the web site will listen on. If you have an additional IP address you can use port 443 with a separate IP than your internal server. In our example, I will be using a single IP address and utilizing bridging with Forefront TMG, so I will enter the port as 4443.
On the next screen, enter a name to identify the external web site such as CWA External.
The next screen has you specify a port to listen to OCS traffic. This is seperate from the web site listening settings. This port is really important if you are collocating OCS Services, or even in this case where we have multiple CWA virtual servers on the same server. This port really does not matter, as long as it does not conflict with another port on the same server used for OCS Traffic. In my case I am entering 5071, my internal server listens on 5070.
At the next screen you must specify a Next Hop Pool, this drop down will display all the pools in your environment and allow you to choose a pool and listening port. In my case our poolname is ocs.winxnet.com.
Hit Next twice to confirm your settings for the new virtual server, the wizard will create the virtual directory and start the web site for you. As with all of the OCS installations, a log is available at the end for success and failure.
Now review your two sites, a screenshot of how the site summary should display is below.
Now that the OCS configuration is complete, we will configure Forefront TMG Web Site Publishing rules to allow traffic to your CWA services.
Forefront TMG 2010 Configuration
My last post reviewed networking configurations for this Forefront server. You can get away with a single External/DMZ IP address for all of these services if you have a single certificate with all of the names. In my case I have multiple certificates, so another IP address will need to be assigned to the DMZ network card on my Forefront TMG 2010 server.
Once you have added your external IP address, and imported the certificate used on your web server; (See my last post for instructions on both of these steps). We will now create the web site publishing rule for CWA.
Right click on Firewall Policy and choose New->Web Site Publishing Rule.
For a rule action, choose Allow. Hit Next
For the Publishing Type choose Publish a single web site or load balancer. Hit Next.
For Server Connection Security choose Use SSL to connect to the published Web server or server farm. Hit next.
For your internal site name, you will want to specify the same Internal/External site name, whatever is the common name on your certificate, in my case it is cwa.winxnet.com.
If you cannot resolve the name correctly from the TMG server, or want to specify a different computer to connect to for that name, you can do so by specifying a computer name or IP Address.
Once you have made the necessary entries, hit Next.
For internal publishing details, under path type /* to allow all sub directories required by CWA. Hit Next.
Under Public Name Details enter the public name for your site, and hit Next. In my case it is cwa.winxnet.com.
On the next page to specify a web listener, choose New.
In the new web listener wizard first page, enter a name for the listener like CWA.
For Client Connection Security choose Require SSL secured connections with clients.
On the Web Listener IP Address page, select the check box next to External, highlight external and choose Select IP Addresses… On this next page, specify the IP address you set aside for CWA.
Hit Next, on the next page for Listener SSL Certificates, highlight the IP Address selected on the last page and choose Select Certificate… Choose your valid certificate and choose Select. Hit Next.
For Authentication settings, choose No Authentication.
Because we chose No Authentication, we have no SSO options, just choose Next.
Review the settings for your listener and hit Finish.
With your listener selected from the drop down menu, hit Next.
For Authentication Delegation choose No Delegation, but client may authenticate directly. Hit Next.
Leave the default settings for User Sets and hit Next.
On the next page, select Test Rule to verify all rule settings are correct. If the result is OK, hit close, then select Finish.
Make sure to Apply your settings to the Forefront TMG server before continuing.
If you had a separate IP address for you internal site, and your external site you do not need to do the next step. This next step will configure bridging to direct our user request to port 4443 for this external virtual server.
Right click on your CWA rule and choose Properties.
On the Properties page, select the Bridging tab.
Where it says Redirect requests to SSL port, enter port 4443, or whatever port you specified during your website configuration. Hit OK.
Again, apply your changes before continuing.
You can test the rule again from the Properties page. Simply open the Properties page for the rule and Test Rule will be an option there. If the test returns OK, continue to test your site from a computer outside the network.
Testing and Known Issues
You can test access to this site from Internet Explorer outside the network, you should simply be able to specify the https:// URL of your site, and TMG 2010 will handle bridging the request to the correct virtual server on the CWA server. You can also use CWA for access to a great IPhone OCS App called iDialog by Modality Systems.
A very common known issue for CWA configurations is receiving the error Cannot sign in because your computer clock is not set correctly or your account is invalid. (Error Code: 0-1-492)
This is an easy fix, and has to do with Service Principal Name (SPN) settings for the CWA Site.
To fix this issue, simply add the correct SPN to your CWA Service Account. This is the account specified during CWA installation to run the service.
You can modify this setting using ADSI Edit, and looking for the attribute servicePrincipalName.
Other than those two instances, this configuration is pretty straight forward and just works.
The reverse proxy installation can be confusing if you have never done it before. In this scenario I will be standing up a new server to replace my ISA 2006 SP1 Server. I will create all of the rules from scratch and walk through the installation.
The most important part of this reverse proxy setup is the networking configuration. It is recommended to have at least two network interfaces on the TMG server, in my case we have a network card in the DMZ with public IP addresses and one on the internal network. Depending on your actual network configuration this could be different.
An important thing to note is that in windows you can have multiple network interfaces on different networks, but not multiple default gateways. Because of this, we need to choose an adapter with the default gateway, and one without any gateway, using manual routes to get to internal resources. In most scenarios it would be ideal to assign the default gateway to your internet facing NIC, this is because it is impossible to enter manual routes for all possible internet traffic. The internal or DMZ NIC typically has no gateway, but we will assign persistent routes for the internal networks.
In my case, the NIC is directly on the internal network, so servers can communicate directly on the same subnet with no routing needed. However, I will show you how to configure these routes for another internal network to simulate the need to route. In an edge server configuration you will need routes for the desktops as well as servers, so it is important to know how to do it.
In my situation, the address spaces involved will be as follows:
Server LAN: 10.117.117.0
Desktop LAN: 10.1.2.0
DMZ: Public IP addresses
Because my TMG server has a NIC directly on the 10.117.117.0 network I do not need a route for that network, but in order to talk to the 10.1.2.0 network, I will need persistent routes. To see the route setup on your server:
Open a command prompt as administrator
Type Route Print and hit enter
Your output should resemble something like the picture above. Note the 10.117.117.0 network has routes directly on that link, and the default gateway is set to our public interface.
To add a route to the 10.1.2.0 network type the following at the command prompt and hit enter:
route add –p 10.1.2.0 MASK 255.255.255.0 10.117.117.2
Where 10.117.117.2 is the router on your network.
If you see OK! after you hit enter, the command took succesfully.
This means any requests for that network are in the route table, and are to go to 10.117.117.2, which will happen via the 10.117.117.106 interface, or our Internal interface.
This is a fairly basic network configuration, in most environments it will be more complex and involve more subnets. However hopefully this gives you a good idea of how to setup the network in your environments.
Before I get started, the diagram below will show the basic environment as it relates to the reverse proxy and my OCS Pool.
Update the server with the latest patch levels, and then launch the TMG Install. You will get a screen prompting you to Perform Updates, Run the Preparation Tool, or Run Installation Wizard.
Select Run Preparation Wizard. This Wizard will add the server role required for TMG to operate on the server. As you click through the installer you will have to choose a type of installation, choose Forefront TMG services and management for a complete install.
Let the wizard run, it will install all roles and services needed. When completed you will be presented with a screen that shows Success or Failure, Click Finish and Launch the TMG Installation Wizard.
The installation wizard will have a few defaults to accept, and then you will be asked to choose your internal network ranges. Choose Add, then choose Add Adapter. Select the Internal network interface on the server. If you previously entered persistent routes you will notice those subnets show up as being associated with that adapter as well.
Hit OK twice and your window should look something like this:
The address ranges should reflect your DMZ adapter address and any internal networks you will be routing to.
Hit Next twice to acknowledge the services that will be restarted during the install. The next page will notify you that forefront will create rules to allow domain traffic to domain controllers listed
If this information looks correct, hit Next, then Install and let the installation complete.
The installation will take some time to complete, but once it is done you should see this screen, click Finish to launch the configuration wizard.
The initial configuration wizard will then launch. Note: You can import ISA 2006 XML configuration files to this if you do not wish to recreate your rules. I am going to start from scratch however to show the whole configuration process.
Run the wizard to configure network settings. This setup is an Edge Firewall configuration. Choose Edge and click next.
Choose your internal network adapter to be associated with the LAN. You may also enter routes here, I am not sure if this makes the previous routes entered not needed, but I will do more testing and update the blog if that changes.
The next step is to define Deployment Options which chooses your license information, and update settings. I will not cover that in this post.
Once you launch the TMG Console, you will notice a somewhat familiar interface with a whole lot of new features.
OCS Website Publishing Rules
Before starting with any OCS rules you should import the public certificates for your OCS Web Farm.
You should have a standard SSL certificate with a common name that matches the External Web Farm FQDN you specified during setup, or that name should reside on a UCC certificate. Either way, you must import that certificate into the Local Computer store with a valid Private Key before it can be used with ISA.
To do so, open the certificates MMC.
Right click on the Personal certificates store and choose All Tasks –> Import
Hit Next, then Finish. Your certificate should now be ready for use with ISA.
For OCS, we are simply concerned with Firewall Policies, there are a lot more features to TMG 2010, which I hope to cover at a later date.
Select Firewall Policies, and choose Publish Web Sites from the tasks pane on the right
Hit Next, for the path enter /* to allow all traffic to the pool for the various services.
Choose the radio for Specified IP Addresses on the forefront TMG Computer in the selected network.
Select the IP address that will your web farm FQDN dns A record points to, and choose Add so it shows in the selected IP addresses column.
Highlight the IP address and choose Select Certificate…
The next page will show you the valid certificates installed to the local computer personal store on your server. Choose the certificate for your OCS web Components and choose select.
Hit Next twice, choose Finish to complete the listener configuration, you will be brought back to the web site publishing wizard with the new listener selected.
Hit Next, for authentication delegation choose No Delegation, but client may authenticate directly.
Make sure you hit Apply to actually commit the rule.
Now that this rule has been configured and you have an external DNS A record pointing to your External Web Farm FQDN, your users should be able to access the OCS web components remotely.
In the next post I will outline configuring TMG 2010 for Communicator Web Access.
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.
I do not have any details on the exact cause of the issue at this point, but I recently did an OCS 2007 R2 deployment on Server 2008 R2. We followed the general instructions located on TechNet to install the OCS services on 2008 R2, but ran into an issue when performing user moves from LCS to OCS.
Not a lot of information in the errors, but pointed to a connectivity issue between the LCS server and the new OCS server.
The fix for this issue is to install the admin tools on a 2003 Server, once the admin tools were installed on a 2003 sever in the environment, the moves were successful. I am working on finding the exact cause, but I am betting it is related to the bullet item for admin tool compatibility issues listed on the 2008 R2 support page. Will update when I have more information.
During a recent group chat server installation, the wizard failed with a very cryptic error message after specifying the Lookup Service account. We also got the same message for the Channel Account configuration.
The error message looked like this:
A Google search turned up nothing, and a quick query on the formicary hosted UC Community Group Chat Channel didn’t have any immediate answers. Bryan Childs was able to point me in the right direction looking for the log on as service permissions on the box.
The customer in question had PCI requirements where service accounts are denied the right to logon interactively, if not they had to change the passwords on those accounts during their regular intervals for user accounts. This setting was the culprit. Once removing the policy denying the service account interactive login rights we were able to proceed with installation. I did notice that during the installation it grants those accounts the log on as service rights on the local box, not sure how related these settings are.
Anyways, seems the group chat errors are pretty generic, this may not even be strictly for this issue, however wanted to get the information out there.
New batch of updates available for the server and client side for OCS 2007 R2.
So far so good, I will update this blog post over the weekend after I patch all of our servers.
Links below for Server and for Client. Biggest fix seems to be the annoyance with the CWA Dial In Conferencing Page and PIN number issues:
978373 The Dial-in Conferencing Settings page in Office Communicator Web Access 2007 R2 prompts you to enter a PIN that is at least 5 digits even if the PIN length policy is set to use a PIN that is less than 5 digits
Server Side Updates: http://support.microsoft.com/?kbid=968802
Communicator Client: http://support.microsoft.com/kb/978564
Just an update from running the updates over this past weekend. Everything seems to work just fine, your front end server may not prompt for a reboot, but I would advise rebooting. A couple people have reported some issues with group expansion. My fix was to cycle the application pool in IIS,however a reboot is suggested.
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)
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!
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
· 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.
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.
OCS 2007 R2 Schema Prep Failure “failure occurred attempting to check the schema state. please ensure active directory is reachable"
A customer called in today with an issue preparing their OCS 2007 R2 environment. The customer had previously started installation on a 2008 R2 server, and started over with a 2008 R1 server. They had only completed the Active Directory Preparations prior to starting over. The issue was when they started on the server they were unable to see the schema prep, they were receiving this error in the install GUI:
A few interesting things here, the machine is joined to the domain, I could contact all domain controllers, I could modify the schema using the schema MMC snapin. However, the OCS install run via command line or GUI would not contact active directory.
Through some quick googling I found that the installer queries the SRV records for contacting the PDC in active directory. This SRV record is:
After pointing to a DNS issue, the customer realized their server was pointing to a public DNS server, not an active directory integrated server, which did not have the SRV records needed to perform these tasks. Once the DNS server was changed, the installer read the Active Directory Preparation as Completed and you could do a proper nslookup on those SRV records
It has been a while since I have had a post over here, guess you can blame the holiday season as well as the busy beginning of the year at Winxnet. Anyways, I have been working with PSS on an issue with external live meeting through the edge for quite some time now, and with that has been lots of performance monitor collection, after clicking through all of the different collectors multiple times, I decided to create some templates to have for future use and wanted to share them. Its nothing special, no awesome script or anything complicated, but a very basic tool that may be useful to anyone going forward.
Above is a link for access to these files on my sky drive. If you have any issues accessing these please leave a comment or contact me via email and I will get them to you.
They are very easy to use, once downloaded, open Reliability and Performance Monitor from either your Front End or Edge Server…
Expand “Data Collector Sets” and right click on the User Defined folder. Choose New->Data Collector Set
Name the collector set whatever you would like and make sure to choose Create from a template.
Click next to access the next page in the configuration wizard. Choose Browse and locate the XML file you downloaded containing the template information. Once you select that file the page should look like this:
The next two screens will ask you where to save this file, I would suggest a drive with plenty of space as these can get very large depending on the amount of traffic on your server and how long they are running.
When you are ready to collect data simply right click on the set you created and choose start.
Once you are ready to analyze data, or send to Microsoft PSS for data analysis you simply choose stop, and you will have a file in the location you specified. Microsoft PSS uses a tool called PAL(Performance Analysis of Logs) which is an open source application written by a Microsoft employee. This tool can be found here: http://www.codeplex.com/PAL If you are feeling up to performing some of your own analysis this is a great tool to use. I may try to post some more detailed information on using this tool soon.
The templates included in my link include the following Counters:
All <LC: > Counters
Hopefully soon I will have a new post describing the fix for this strange live meeting issue, until then, Enjoy!