[tweetmeme source=”stalehansen” only_single=false]I had a problem at a customer site with Live Meeting that external users could not join the meetings. External and anonymous users got the same message. Internal Live Meeting was working just fine and so did Communicator externally.
The EDGE server gave the following Event ID:
- Source: OCS Web Conferencing Edge Server
- Event ID: 41993
- Level: Error
- Description: Failed to process data received from the client
That did not tell me much so I checked the Front End server. It had the following Event ID:
- Source: OCS Data MCU
- Event ID: 41059
- Level: Error
- Description: Failed to connect external users because the download URL is invalid.
It was now clear to me that the external web farm FQDN had to be wrong so I checked the Meeting Settings at pool level. The “External URL for meeting content download” was empty. Also the addressbook URL was empty. I decided to set the external web farm FQDN and found a way using lcscmd. After using lcscmd as described below external Live Meeting users could connect just fine. With the below steps I was able to set the external webfarm FQDN.
NOTE: PoolName in an Enterprise Edition deployment is the full FQDN name like ocspool01.domain.local. In a Standard Edition deployment you only need the Front End Server name like ocs-server and do not use FQDN
Step 1. Check current settings
To check the current URLs configured for these services, you can use LCSCMD.exe, and run the following:
Lcscmd /web /action:ListWMISettings /poolname:poolName
To retrieve the settings, check out the created html in the location provided after the command
Step 2. Update External URL
To update the external URL, you need to run the following command:
Lcscmd /web /action:updatepoolurls /externalwebfqdn:WebfarmFQDN /poolname:poolname
Step 3. Check the settings again
Rerun the line stated in Step 1 to check your settings again, and check the created html file:
Lcscmd /web /action:ListWMISettings /poolname:poolName
To clear the external URL in one step, just run the following:
Lcscmd /web /action:clearpoolexternalurls /poolname:poolName
For more information, check the following link: http://support.microsoft.com/kb/938288
Thanks to: http://www.pro-exchange.eu/modules.php?$1&name=News&file=article&sid=971
To update internal URL, see how to here: http://mikestacy.typepad.com/mike-stacys-blog/2009/04/updating-the-ocs-r2-internal-urls.html
[tweetmeme source=”stalehansen” only_single=false] This post has been rewritten and moved here https://msunified.net/2010/06/22/exchange-2010-rtm-and-sp1-owa-integration-with-ocs-2007-r2/
[tweetmeme source=”stalehansen” only_single=false]On several OCS 2007 Enterprise installations this patch was not that easy to install when you are using SQL 2008 backend database. Here’s what I had to do to install this patch
To apply the hotifx, you must have the following software installed.
- OCS administration tools
- MS SQL Native Client
- If you decide to install SQL 2008 Client Tools, SQL 2005 Service Pack 2 (SP2) Backward Compatibility must also be installed.
- To install the SQL 2005 Service Pack 2 (SP2) Backward Compatibility you need to download and install
- Microsoft SQL Server 2005 Management Objects Collection
- Microsoft SQL Server 2005 Backward Compatibility Components
- Finally run the patch with the following command when on a OCS Enterprise deployment
- OCS2009-DBUpgrade.msi POOLNAME=poolname
If the installation failes check Scott Oseychik’s post about SQL won’t allow update here: http://blogs.msdn.com/scottos/archive/2009/08/21/installation-of-ocs-2007-r2-hotfix-package-969834-may-fail-if-sql-settings-have-been-changed.aspx
View the full technical article here: http://support.microsoft.com/kb/969834
MVP Lee Desmond posted a great post about the November updates for Office Communications Server 2007 R2. Check it out here: http://www.leedesmond.com/weblog/?p=607
Check out the latest Nov 2009 updates released for the different Office Communications Server 2007 R2 server roles as described in KB968802. This applies to both the Standard and Enterprise Editions.
A very important and welcome addition to assist the patch management process is the “Cumulative Server Update Installer” (ServerUpdateInstaller.exe) delivered as part of this release. Instead of having to determine and manually applying the relevant patches to the various R2 server roles, this tool relieves the administrator from those tedious chores by applying all updates for the appropriate server role in just one click. You can also use this tool on the command line with the switches /silent, /forcereboot and /extractall.
If not already present, you shoud also apply the update* for the Office Communications Server 2007 R2 Back-end Database (KB969834).
Download for the updates (.msp), executable (.exe) and installer (.msi) can be obtained here.
Here is a good guide on how to install the updates: http://blogs.technet.com/ucspotting/archive/2009/11/26/3296447.aspx
Doug over at DMTF has written an excellent article about what do for OCS single sign on when internal domain and sip domain does not match. When split brain DNS is no option you can create two dns zones for the SRV records only. Here is an excerpt from his blog. View the full blog post here: http://blogs.technet.com/dougl/archive/2009/06/12/communicator-automatic-configuration-and-split-brain-dns.aspx
To implement this for Contoso, we would create a zone “_sipinternaltls._tcp.contoso.com” and zone “sip.contoso.com.” Notice that these are two zones – not two records in one “contoso.com” zone. A zone is a name resolution boundary in the hierarchical DNS namespace. By configuring the internal DNS server to be authoritative only for these two names, clients will continue resolving other names in the contoso.com domain as they always have.
Coincidentally, over on his blog, Geoff Clark has just suggested the same thing. He describes the problem and suggests the same solution but shows a method of creating the zone on a Windows DNS server via the DNS management console. Unfortunately, there is a limitation in the management console that is not present in the underlying Windows DNS implementation. This limitation required Geoff to create the zone as “_tcp.contoso.com” when what we would really like is a zone named “_sipinternaltls._tcp.contoso.com.”
This limitation in the user interface can be resolved by creating the zones and the records using the Dnscmd command line tool. For Contoso, here are the required commands:
dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 sip.contoso.com.
dnscmd . /zoneadd sip.contoso.com. /dsprimary
dnscmd . /recordadd sip.contoso.com. @ A 172.16.45.12
Of course, you’ll need to make the appropriate changes for your environment. If you are not running the command on your Windows DNS server, you will need to replace the first dot with your server name. You may also prefer a different zone type than “dsprimary.” If so, change the zoneadd commands appropriately. I doubt that your pool’s IP address is the same as my example but, if you have followed me this far, you already know what to change there.
October 24 Update – The MS09-56: Vulnerabilities in CryptoAPI could allow spoofing article has been updated with a Known Issues section and FIX for the LCS and OCS product. That article is the authorized content as it requires the proper groups to coordinate and confirm the data published.
Microsoft has released official information that is indeed a problem with OCS and LCS systems. Check out the updated article with known issues here: MS09-56: Vulnerabilities in CryptoAPI could allow spoofing
I didn’t discover this one, so I’m just the messenger passing word on – KB 974571 (part of Patch Tuesday today – specifically related to Crypto-API/ASN1) will make OCS think it is an evaluation version that has expired. Uninstall KB 974571 and OCS works again. You will want to apply the KB once an updated patch, or an updated patch for OCS becomes available. Originally documented here.
The issue is currently being escalated, but until a fix can be found, delaying the install of KB974571 is recommended. Check here for updates: http://communicationsserverteam.com/archive/2009/10/14/632.aspx
Thanks to Aaron Tiensivu for the heads up: http://blog.tiensivu.com/aaron/archives/1905-For-now,-hold-off-on-installing-KB-974571-on-OCS-2007-R2-servers-and-possibly-R1.html
Jeff Schertz has a great discussion about what ports to use when deploying the CWA server role in this post: http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=80
Here’s a summary
During the deployment of an OCS Communicator Web Access Server there is a setting that is not covered in much detail in the documentation: the Communication Server Listening Port. No default or suggested value is given. This port is used by the Communicator Web Access Server to listen for inbound communications from other OCS servers. When an additional Virtual Web Server is added to the same host, as is common when both Internal and External types are setup on the same server, the new virtual site’s listening port must be on a different port then what the initial site is configured for. The post goes on to discuss how to alter the ports. Head over to see the full post.
There is no requirement on what port is used, except that it can’t already be in use on the host server. Therefore an idea might be to use 6051 and 6052 as suggested in a comment in the post.
MVP Elan Shudnow wrote a thorough post on Audio/Media Negotiation.
There are several ways in which we can utilize Audio/Video streams in Office Communications Server. While this article is based off of 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 his post at: http://www.shudnow.net/2009/08/29/office-communications-server-2007-r2-audiomedia-negotiation/
I encountered a problem where I could not install Monitoring Server Report Pack. I was running the install from the Monitoring Server against a back-end SQL 2008 server. The error message I got was like this:
Could not connect to server:
Failure [0xC3EC7A20] Failed to install the QoE Monitoring Server report pack
I found that there are three possible resolutions:
- Make sure you are using https:// for the reportserver URL
- Check that you are not behind a proxy server
- Double check that “Automatically detect settings” is not selected under Internet Options->Connections->Lan Settings i IE
- Add the account that is being used for Office Communications Server 2007 QoE Monitoring Server installation as a system administrator on the SQL Server report server.
- To do this, follow these steps:
- Start Report Manager.
- Open Microsoft Internet Explorer 6 or a later version of Internet Explorer.
- In the Internet Explorer address bar, type the Report Manager URL. By default, the URL is https://ComputerName/reportserver
- Click Site Settings.
- Click Configure site wide security.
- Click New Role Assignment.
- In Group or user, type the account in the following format: domain\account
- If you are using forms authentication or custom security, specify the user or group account in the format that is correct for your deployment. Assign the System Administrator role to the account, and then click OK to apply changes.
- After the account is added to the report server as a system administrator, restart Office Communications Server 2007 QoE Monitoring Server setup to complete the installation.
The resolution for me was that I was behind a proxy without knowing it. Therefore it is wise to double check proxy settings.
I have also encountered this error when the reporting services resides on a server with Server 2003. Apparently the max request bytes allowed was set to low to allow OCS to install the report pack. Here is how you resolve that.
- Add the following registry key with the following value:
- Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
- Value: DWORD “MaxRequestBytes”
- set it to 1048576 (1MB). (This number can be raised or lowered depending on the situation)
- Stop the SRS Windows Service. (SQL Reporting Services Service)
- From a cmd prompt run “net stop http” then “net start http”
- You may have to start the www publishing service manually
- Try the OCS installation again.