April 22 Update: New blog post about the decision tree on server team site - http://communicationsserverteam.com/archive/2009/04/13/409.aspx
Very important: (from the R2 help file)
If you decide to migrate your global settings to the Configuration container and you plan to migrate from a prior version of Office Communications Server to Office Communications Server 2007 R2, you must perform the global settings migration first. Once you upgrade to the Office Communications Server 2007 R2 Active Directory schema, you can no longer use this tool to migrate your global settings.
I have LCS 2005 SP1 in my topology so you can see the decision I will make from this flow chart – no change.
Quick update -
Because I knew of this requirement I never ran the Schema Prep as I didn’t want to get caught (also I didn’t have undo disks configured in VMs and didn’t want to restart (lazy)), the setup routine will notify you of this new requirement:
Edit January 14 2009
Fred was asking about the reason and apparent vague performance reasoning so let me post what is in the documentation for RTM and see if this is acceptable. Fred if this is still not acceptable email me direct so we can attempt a last minute change (no promises as I don't own the documenation effort but do communicate frequently with them).
With Office Communications Server 2007 R2, the recommended container for Office Communications Server global settings is the Configuration container, which is the default container. In previous versions of Office Communications Server, the default container was the root domain System container. Although storing global settings in the System container has advantages, such as faster replication and fewer replicated copies, in centralized topologies, this approach might not perform as well in geographically distributed topologies if root domain availability is insufficient. If you deployed Live Communications Server 2005 with Service Pack 1 (SP1) or Office Communications Server 2007 with global settings stored in the System container and experience performance problems, such as long service start time or long replication delays when you manage global settings, you can migrate from the System container to the Configuration container.
Aaron Tiensivu and I just did the System Container to the Configuration Partition migration last night in our production forest last night and it was successful. In our forest we also have contacts for users in our other forest which have them stamped with the OCS attribute so users in our forest will see them in the address book. We updated those contacts as well.
Another tip is that we were going to leave Step 7 (removing the System partition) there for a week or so to make sure everything was working fine. The services on the FE started fine but Mediation Servers were failing. Event viewer showed that there were duplicate objects in AD. So we decided to do an LDIFDE dump of the System Container to be safe and then removed it. Mediation Server started up just fine after.
So all in all, it was a success. Figured I would post those tips. Aaron Tiensivu blogged about our endeavor over at hit blog: http://blog.tiensivu.com/aaron/archives/1801-In-the-trenches-OCS-2007-R1-migration-of-global-settings-container-in-prep-for-OCS-2007-R2-upgrade-gotchas-and-workarounds-with-OCSMigrate.vbs.html
MS has provided no real explanation as to why they recommend this migration other than references to performance issues. its still not clear what the performance issues are and in what type of environment folks would most likely see the performance issues. What exactly is the performance issue with? the documentation indicates some impact to start/shutdown. I there any impact to IM/Archiving etc...? i see one quote related to root domain availability. Can you clarify what good root domain availability is? I think we need to get a better explanation, before running a script that has not backup process and touches every OCS/LCS user.
Fred, while I'm not an MS employee, I want to throw in my 2 cents here. I've never honestly been a fan of the System Partition. Now if you're in a single domain environment, having OCS in your System Partition isn't a really big deal.
The reasoning behind my statement is because the system partition is stored in your Domain Partition. This Domain Partition will replicate to every single Domain Controller. Because of this, your OCS Data is available in all cases.
Now if you are in a multi-domain environment, all domains are trusted due to the nature of transitive trusts. Now if your data is stored in the System Partition of your Root Domain, this data is NOT replicated forest wide. This means that in order to ensure the OCS data is always available, you need to ensure you have good connectivity to your forest root. Storing it in your forest root's System Partition allows you to reduce the bloat of your Configuration Partition thus reducing the amount of data that needs to be replicated across Domain Controllers in your environment.
But why would you want to take the risk of your OCS data not being available due to the network? One of the purposes of the Configuration partition is to ensure that all Domain Controllers are aware of the data. Because of this, I have always chosen the Configuration Partition because I knew that it was always the best option in my opinion to make sure network interruptions don't affect OCS data availability. And I always had a feeling that Microsoft would change their recommendations in the future and switch over to the Configuration partition. I guessed right. :)
Sorry for the long opinionated explanation.
Thanks Elan for your write up. This is right on target to why we recommend the Configuration container in R2. That said if you are running an OCS 2007 or LCs 2005 SP1 deployment with the OCS configuration in the System container, and you don't have any issues, there is no need to migrate it to the Configuration container.
BTW: We are talking here about the OCS/LCS configuration data, not the user data in AD.