Cannot Connect to the Meeting: Live Meeting

Today I experienced some issues with Office Communicator 2007 R2 and Live Meeting 2007. First, Communicator was complaining about not being able to update the address book. Then, when I tried to start a meeting using Live Meeting (via the Meet Now function), I received the following error:

When I looked to find some hints to the “Live Meeting cannot connect to the meeting.” message online, all the posts were pointing to issues with trying to connect to an external meeting. I was trying to connect to my internal Office Communications Server.

I next tried to do a nslookup on the FQDN for the server and I received a reply message that it was a non-existing domain! Well, there’s your problem!

I took a look in DNS and the SIP entries for the service were all in tact, but the A record for the server in the Forward Lookup Zone was missing! I do not know why/how it was removed, but I quickly added it back and now all is well with OCS.

Office Communications Server 2007 Upgrade – Clients

Before upgrading our Office Communications Server 2007 (OCS) install to OCS R2, we pushed out the Office Communicator 2007 R2 client to our desktops. As with most software pushes, not everyone received the client successfully. Currently, there are four versions of the Communicator client connected to our R2 server:

UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)
UCCAPI/3.5.6907.9 OC/3.5.6907.9 (Microsoft Office Communicator 2007 R2)
UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)

The only one I couldn’t really figure out was the first one (2.0.6362.15). That client version only has one connection to the server. After looking at the rtc (dbo.Resource table) and rtcdyn (dbo.Endpoint table) databases, I discovered that it is the ForeFront for OCS Proxy account using this client.

The second in the list is the R2 Communicator 2007 client (UCCAPI/3.5.6907.0 OC/3.5.6907.0), without the April 2009 patch (KB 967673).

The third (UCCAPI/3.5.6907.9 OC/3.5.6907.9) is the R2 Communicator 2007 client with the April 2009 patch.

The fourth (UCCP/2.0.6362.0 OC/2.0.6362.0) is the R1 Communicator 2007 client (caused by the R2 client install failures).

[UPDATE] The May 2009 Communicator 2007 R2 hotfix rollup update upgrades clients to the following: UCCAPI/3.5.6907.9 OC/3.5.6907.22 (Microsoft Office Communicator 2007 R2)

Troubleshooting Microsoft Office Communicator 2007

I have recently been having some Address Book sync problems with Office Communicator 2007 R2. A couple things I wanted to share with anyone who cares to listen:

-When you turn on logging within Communicator, the logs are placed in your profile directory. So, at the root of your profile (i.e. for Windows XP, it would be: c:\documents and settings\%username%), open the Tracing folder. This is where the logs are created.

-When you start Communicator, it tries to download and make a local copy of the Address Book. The location of the address book copy is again located in the profile directory. So, for Windows XP, it would be: c:\documents and settings\%username%\local settings\application data\microsoft\communicator .

Office Communications Server 2007 R2 and NIC Teaming

I have been trying to install Office Communications Server (OCS) 2007 R2 Standard Edition for a few days now without success.

During the server install process (after the schema has been extended), a warning shows up in the activation logs of every role (Standard Edition Server, Web Components Server, Web Conferencing Server, Audio/Video Conferencing Server, Application Sharing Server, and Application Host).

The warning on the main Deployment Log states:

[0x03EC796D] Wizard was successful, but one or more warnings occurred during execution of the wizard. Please check the log file for more information.

The warning within each activation log states:

[0x03EC78E4] More than one DNS records are found for the pool FQDN. Please validate the pool’s DNS registration.

A note about the DNS Record Count: 3 is also in the log.

After trying for many hours to get this to work, the solution is simple, but it isn’t ‘nice’.
Office Communications Server 2007 does not support network interface controller (NIC) teaming. Sounds crazy, right? Good luck finding this little tidbit documented anywhere.

[UPDATE] I have been told (by a Microsoft rep) that Microsoft does support NIC teaming, but I haven’t found any documentation that points to the correct answer.

Exchange System Attendant Errors

I have recently been setting up a virtual network to get more experience in upgrading the applications listed below in the same environment. I am utilizing the following Microsoft products:

Windows Server 2008 domain controller (version: Server Core)
Windows Server 2003 application servers (possible upgrade to Server 2008 in the future)
Exchange (version: 2003 upgrading to 2007)
Live Communications Server (version: 2003 upgrading to OCS 2007)
Windows SharePoint Services (version: 2.0 upgrading to 3.0)
SharePoint Portal Server (version: 2003 upgrading to MOSS 2007)
SQL (version: 2005 upgrading to 2008)

The DC has two NICs, one is Local only and the second has external access. The first Application server has one NIC, local only.

Right now I am at the point where I have my DC setup and I have finished installing Exchange 2003 on the first Application server that will host LCS 2003 as well. However, after I rebooted, I encountered the following errors within the Windows Application Log:

Event ID: 1005
Source: MSExchangeSA
Type: Error
Body: Unexpected error The logon attempt failed ID no: 8009030c Microsoft Exchange System Attendant occurred.

Event ID: 1004
Source: MSExchangeSA
Type: Error
Body: Microsoft Exchange System Attendant failed to start

Event ID: 1005
Source: MSExchangeSA
Type: Error
Body: Unexpected error The clocks on the client and server machines are skewed. ID no: 80090324 Microsoft Exchange System Attendant occurred

Also there is a Kerberos (Event ID: 5) error in the Windows System log.

My first thought was that due to the 1005 errors, the Application server wasn’t getting its time from the DC. Since it was a Server Core implementation, I did miss something (oops!): I did not start the w32time service. So, I entered the following commands:
>net start w32time
>sc config w32time start= auto

Now that the service was started, I did a reboot of the Application server just to make sure everything was working well. Same errors.

Since the error stated the times were “skewed”, I checked the time on the DC (by just typing “time” at the cmd prompt) and Application server….they were the same. What now?
I tried a manual time sync on the Application server using the w32tm command. This told me that the time between the server and the DC (its time authority) was exactly 2 hours off. That raised a flag! Timezone!

I checked the timezone for the Application server and it was correct. I went to the DC and at the prompt I typed >control timedate.cpl and one of the only remaining GUIs in Server Core gave me my answer….the DC was using the wrong timezone.

I updated the timezone, rebooted the Application server, and the System Attendant started without any problems.

Now on to installing LCS.