IM an Expert - Lync 2010 Logon Issue

Think configuring IM an Expert is next-next-next? Think again. I thought IM an Expert had some value and I'd like to see it work. Ok, a challenge. Better yet, one taken without support options because this is a free tool download. The config file is interesting. Better understand your Lync environment and what they are asking for, and take note of how to mask your username/passwords in clear text from the deploy guide if that is a concern. I had two issues. The first was getting the bot to talk to the three databases you create, which I located on my Lync backend database server. Permissions were not an issue as I could manually connect, even though the IM an Expert logs were showing an access denied. Came across this helpful advice.

To get around the logon issue use the setting below:

A couple of things go with this change through. This sets the authentication method for access to the SQL database to ‘integrated authentication’. The other alternative is to create a user and grant that user permissions within SQL which we already have had a issue with.

Besides the config change to the xml file You’ll also have to add the Network Service with permissions to the SQL databases, and then change the identity of the AppPool in IIS to Network Service to get it working.

This immediately solved the SQL connection/"Logon" issue for me.

However, I had another self-induced issue.

I was able to get the bot running successfully, but whenever I launched an IMExpert chat, my link to set up my profile failed. This was me and IIS7 misbehaving. Once I had the default website setup with an internal cert for 443 - all was well.

We've got a few profiles set up and tested successfully. Not sure it is what the people want, but since it provided a challenge, I had to prove it could work.

Hope this helps someone else that is curious out there.

OCS XMPP fix it

Really nice blog about OCS XMPP - If you are like me and your OCS XMPP gateway lives in the DMZ, and your DMZ hosts have generic names that are not indicative of what lives on them for basic security purposes, make sure your SRV records, Certificate and HOSTNAME all match. Hard requirement for the gateway. I tried to trick it out and failed. Ended up going way out of our DMZ convention to end up with a host name that matched my cert name. Working great.

http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=91

Lync - the new OCS

Starting to look at RC for Lync. So far so good. Not happy about the rebranding after spending almost two years socializing the idea with our user base on OCS and Live Meeting, but we'll live. Moving fast once source hits on the new environment and will post here with the road bumps.

Notes:

Lync clients cannot talk to an OCS R2 server - so as before, push client updates last once your pool is in place and your users migrated. Client readiness from a prerequisite perspective and training will be issues that can't be ignored. Prep your clients now.

Schema updates - if you haven't already - wait for the RTM version as there will be schema changes from RC to RTM.

Office Communications Server 2007 R2 Workload Architecture Poster

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=af2c17cb-207c-4c52-8811-0aca6dfadc94

This poster of Office Communications Server 2007 R2 describes the traffic flow of protocols and ports used in each workload. Communications Server 2007 R2 supports the following workloads: IM and Presence, Conferencing, Application Sharing, and Enterprise Voice. These filtered views can assist you in architecting your deployment of Communications Server 2007 R2. The different server roles are described along with server certificate requirements. Firewall and DNS configuration requirements are also described.

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.