OCS XMPP TLS Handshake Error FIX

Not your fault. Probably not even your certificates fault. Google has a bug. Essentially the bug is that anyone who ever created an account with Google Apps under their corporate email address using your domain in the near past prevents you from creating an XMPP channel with Google until they flip a bit. Mine was flipped after a lot of people got involved to 1) diagnose the issue and 2) figure out why Google wouldn't let us communicate with the XMPP gateway. The symptom is a TLS error on your Edge server to your OCS XMPP server. This is just a symptom of the above problem. Newer Google Apps accounts do not have this issue, but I found that we had four employees who had signed up using their work email to Google Apps in 2008. Google is going through all these domains and fixing the bug. Mine got fixed faster because I had someone on the Microsoft side pushing for me. To find out if you have users who have registered using your domain, guess what you have to do? Sign up using your domain account to Google Apps. You can then see "users". I only had four users who had signed up, but one was enough. I've since deleted their accounts after taking Admin control over our domain with Google Apps. Now if they want to use Google Apps, they go through me. In addition, as soon as Google flipped the bit, we were on. Full on presence and chat with Gmail users with our OCS R2 clients. Hope you find this and hope it helps.

The Nightmare before OCS R1 Cutover

High Level OCS R1 to OCS R2 migration path

Build R2 Server Infrastructure
I was able to do this in tandem with my R1 infrastructure with additional hardware and VM's - yes, I realize I am lucky that way.

I built every role for the R2 pool, moved myself to the pool, upgraded my client and played for weeks in the environment before I felt comfortable moving anyone else. I moved my team, my boss, and then a few poor souls who wouldn't mind getting kicked off during troubleshooting.

I had the most issues with CWA R2 running on 2K8 and getting ISA set up correctly for the web access, there are some posts in this blog on that. I even got an iPhone application working with CWA R2 although I can't recommend it (if you want to know more, contact me through this blog).

Move Users to R2 Pool
When I was ready to bite the bullet, and after having both environments up for a while validating client compatibility testing (R1 client > R2 pool etc), I moved every user to the R2 Pool a few weeks ago without any issues. I did not change the SRV records as I continued to use the R1 Edge servers. Essentially, the R1 front end server was acting like a director without officially being one.

Migrate to R2 Edge Services (move names, IP’s, dns, certs so all has same name/resolution).
I moved from two dedicated R1 Edge servers, one running the Access Proxy and Web Conferencing Role, and one running the A/V R1 Edge Role to an R2 Consolidated Edge.

Since we use Federation and PIC, I essentially had to cut over from R1 Edge to R2 edge. This was a huge pain in the rear Microsoft -thanks for this horrible migration “path”.

For the A/V edge, since I didn't use NAT in R1 but I am doing so for R2, I am used a new name, IP, DNS, Certificate etc for that role. This is an ok strategy and probably would work fine for web conf role also. It’s the provisioning that is in place for the Access Proxy that really requires you to move the names/certs over. Now that AOL and MSN no longer require a license, perhaps when Yahoo gets on board this will no longer be an issue for Wave14 migrations.

At the time of the edge cutover I changed out all the SRV records for each of my SIP domains to point to the new R2 Front End server.

Note: I had already cut over my ISA server rules to reflect R2 reverse proxy and CWA R2 rules pointing to the new R2 web access role. My R1 ISA rules were removed when I deactivated the R1 web access server.

Deactivate and decommission R1 servers/pool
The migration guide wants you to do this during migration - how about no, not a great idea. Once you deactivate, all your R1 bits are gone from AD. There is no way I am not having a fall back plan. Microsoft will just have to live with this.

The good news is after the successful Edge Cutover, once all roles were fully on R2 and everything was validated, I shut down my remaining R1 servers overnight to see if R2 complained. There were no issues. Deactivating took place on a weekend, every R1 role removed cleanly and R2 never once blinked an eye. Was I lucky? Probably.

In Process: Upgrade Client end points to new client/addons (this is in process and I will be HAPPY to share whatever I get out of this as I have had zero luck finding someone out there in the same situation).

This is probably the biggest pain point as it touches every client in the realm over slow links and remote clients around the globe. I will be utilizing our existing SCCM infrastructure and will need to uninstall all the existing software. To do this cleanly, it involves closing outlook, closing communicator, uninstalling the modules (in this case Outlook Conf Add-In, Office Communicator 2007, OC 2007 MUI, and the Live Meeting Console). Then reinstalling the 3 upgraded modules and relevant hotfixes. Plus I have a registry key I'll be throwing in for the Live Meeting portal (this gives me single sign on for Live Meeting Service).

We might also get the Group Chat client installed as well.

In addition, any users out there (who knows who they are?) that have multiple endpoints MUST be upgraded to R2 at the same time. Otherwise, the Communicator client freaks and basically breaks if an R1 client and an R2 client for the same user attempt to sign in. This is really going to help me find all those users with the COMO client manually installed years ago when we went to R1.

XMPP Gateway to Hell?

TLS Handshake errors your enemy? You are not alone.

I’ve tried both public and internal certs. I have a ticket open with MS - going on two weeks, and I'm on my fourth engineer, now at the senior level. I've requested certs from command line, IIS, OCS front end wizard, imported them in etc without success. The Edge server and XMPP server can telnet to each other over port 5061, I can telnet externally to my FQDN of the XMPP gateway over 5269. It looks perfect - yet won't work. If I receive a fix from the latest engineer I will post here. The only thing I haven't tried is to rebuild on Server 2003 instead of 2008 because I do not want to go backwards. If you inadvertently or for testing assign a certificate to the XMPP configuration and want to remove it, you need to uninstall XMPP and reinstall.

Found this on OCS Guy's blog: good tool, especially to help me through my R1 to R2 migration:
http://www.digicert.com/help/

OCS R2 Monitoring Server SQL Reporting Services Configuration Issues

I installed the OCS R2 Monitoring Server role on Server 2008 x64 with SQL 2008 SP1 and had a few issues until I realized installing SQL reporting services is not enough, you must then launch Reporting Services Configuration Manager. Never having installed Reporting Services, let alone on SQL 2008, I learned a few lessons.

Make sure you have installed IIS and Message Queuing prior to installing SQL (yeah, basic I know). Also, request and accept a certificate into your cert store for web services with the FQDN of the server where you will be hosting the reporting services URL. You will need this for Reporting Services configuration as well as for IIS. It is easier to have it during the install.

Having installed reporting services but not configured it, I ran the deploy Monitoring Server Reports with the error that it could not find the Report Server URL.

To resolve:

I deactivated the OCS Monitoring server and waited for replication. (note: I did not uninstall the Monitoring server files)
I uninstalled SQL 2008 Reporting Services
I verified IIS and MSMQ were installed
I requested a web cert (internal PKI) with the FQDN of the hosting server and installed into the cert store.
After a reboot I reinstalled SQL 2008 Reporting services.
I launched Reporting Services Configuration from program files and was asked to set or verify the following:

1. Service Account (runs the report service)
2. Web Service URL for port 80 and 443 (url to access the report server) - URL's look likes this by default:

http://%servernamefqdn%:80/ReportServer
https://%servernamefqdn%:443/ReportServer

OCS Requires https, which is why you need the certificate.


3. Database (for report server content and application data) - I asked it to use an existing database called report server.

4. Report Manager URL (url to access report manager)

http://%servernamefqdn%:80/Reports
https://%servernamefqdn%:443/Reports


5. SMTP settings (for report server e-mail)
6. Execution Account (low privileged account for report data)

After running through the configurations above, I made note of the URL in the config manager and reran the OCS Monitoring Server activation wizard and rebooted.

It still failed, but this time with a different error, stating the Reporting Services had not been initialized. Earlier errors stated it could not find https:// url reporting services was looking for by default.

After reading a lot of msdn and technet articles on initializing a reporting server and frankly not understanding most of it, I went back into Reporting Services Configuration > Database and instead of using an existing database, created a new one called reportserver1. If you want to follow the articles about encyrpting and decrypting keys etc, just search initializing sql databases and you'll find your way.

After pointing to a "new" database, I was then able to "initialize" the report server.

I reran the Deploy Monitoring Server Reports and finally it was sucessful.

Most of the above could have been avoided had a figured out I need to configure reporting services before running the OCS Wizard - live and learn. And today I learned about reporting services.

Forefront for OCS causes URL text conversion error

I am currently running an R1 pool and an R2 pool side by side during a migration. It was decided we would use Forefront for OCS on the R2 pool to appease the security guys. During testing we discovered that although the client filtering tools were set identically on each pool, when sending a url from an R2 client/pool to an R1 client/pool or R1 to R2, the URL failed to send with the following error:

_http://www.microsoft.com/technet/security/bulletin/MS09-034.mspx
The following message was not delivered to Doe, John. More details (ID:400)
_http://www.microsoft.com/technet/security/bulletin/MS09-034.mspx

This only occurred when crossing pools. R2 to R2 client/pool worked fine, R1 to R1 client/pool also worked fine and correctly converted the URL to text.

When working correctly it appears like this:

Your hyperlink has been converted to text - to use copy and paste to a browser
_http://www.microsoft.com/technet/security/bulletin/ms09-034.mspx

After reviewing logs from both pools and both clients it was determined that Forefront for OCS was blocking the transfer. Disabling Forefront for OCS did not resolve the issue, stopping Forefront services caused the OCS front end service to stop (ah, security). Uninstlaling Forefront resolved the above. Luckily I have not gone production with R2 yet. I currently have a case open with MS and will post results here as obviously I will need to be running Forefront for OCS when R2 goes production.

Creating all your OCS Certs? Few hundred dollars....Completing all your DNS entries? Couple hours....Getting your Networking Team to do your firewall NATS? Priceless.

OCS R2 Consolidated Edge design

After a lot of dns, certificate and design questions, I ended up deploying a consolidated R2 Edge server and ISA server. Here is what the final configuration looks like, including protocols/ports that need to be opened, what certificates where. Hope someone finds this helpful. Please note: the names and IP's have been changed to protect the innocent.

OCS R2 Communicator Web Access

Web Access URL different than host name of your web access server...Server 2008 x64 OCS R2 CWA. I had a gotchya, had to edit the SPN of the service account being used for CWA to include the url for CWA.

In ADSI Edit, default naming context (2k8 domain), locate service account, properties, locate servicePrincipalName > add value http/%url% of cwa site if different than host name.

For example:
SPN was http/$hostname$
added
http/cwa.domain.com

Manually sync OCS Address Book

Useful for name changes, account changes. Be careful of the overhead on the server. Normally this is scheduled by default once a day at 1:00am. If you need to manually sync the address book run:

C:\Program Files\Microsoft Office Communications Server 2007 R2\Server\Core>ABServer.exe -syncnow
Triggering Address Book Server synchronization pass - successful.
You might have to wait up to 5 minutes for it to actually complete.

Users may need to exit communicator and log back in order to affect changes. I've had mixed results with this actually working.

First post

New site dedicated to Unified Messaging OCS, OCS R2 migration, 2008 x64 OCS issues and resolutions - I will be posting here as I migrate from production OCS R1 to OCS R2.