For those that haven’t tried it, I’m happy to report that deploying OCS 2007 in a resource forest works very well. I had one little problem that I’ll address at the end, but first a few words about why you might go this route at all. There are a few reasons why people want to deploy OCS in a resource forest, one that I don’t always agree with, and one that I can’t argue with.
Fear of Schema Extensions
For some reason, lots of people are still worried about the schema extensions required by certain applications. And while I have never seen a schema extension go wrong (I’ve polled my co-workers and friends & none have ever witnessed it either, with any app, let alone an MS product) I still understand that it’s a big deal to mess with your production environment. So in general: the OCS schema extensions are safe, reliable, and have no history (that I know of) causing trouble. So rest assured, it’s supported and OK to do. However, if you just want to install OCS to test it out before deploying to a large organization, this makes sense to deploy in a non-production environment… Also, for a big organization doing a pilot – there really is no need to extend the schema for 100,000 users (and add to the size of the DB on your DCs) if you might not actually ever use OCS. So, yeah, not wanting to muck with the production schema… I can sometimes see how that could be a reason to use a resource forest. But if it’s just SchemaExtensionPhobia, take a look through the OCS AD guide – it gives all the detail on what the extensions do.
Resource Forest as a Way of Life
Some organizations may want to deploy in a resource forest because the parent company may be a holding company for several disparate companies, each managed by autonomous IT shops. In this case, you may not ever want to deploy an enterprise application to a global forest (or you may not even have a global account forest) and in this case, a resource forest allows you to establish Exchange and/or OCS in a central area and establish one-way trusts between your real forests and the OCS/Exchange Resource forest. Again, the OCS docs for doing this are really, really good and are must-reads if you are considering this scenario.
Ok, back to the the issue that I had. If you do have OCS in a resource forest, and you’ve followed the docs to the letter, most things will work right. Unfortunately for me, the one thing I couldn’t get to work right was small but important: no users could log in. Doh!
I kept getting errors in MOC saying that the username or password was wrong. I verified several different ways that this wasn’t the case. I even was able to log into Communicator Web Access with the username and password. It was just the MOC client that wouldn’t do the job. I scoured the web and didn’t find a whole lot of info, but thank goodness I came across one post from Tom Laciano a while back that had this advice:
Do not disable this for your domain or on domain controllers as this will have significant negative impact to the domain. I wanted you to disable it on the OCS server:
Open the OCS MMC – Navigate to the Enterprise or Standard Edtion level, select the pool (if SE this will be the FQDN of the server). Right click, select properties, front end properties and on the authentication tab select NTLM. The setting of Both NTLM and Kerberos won’t work for a domain joined system as it will choose Kerberos as it is more secure.
Unfortunately no one ever replied back and said "thanks that fixed it". I was desperate and tried it… Restarted the services and it worked.
