This process is unsupported. This process has only been tested in lab and in one production environment. If you try this, and it goes sideways on you, you are on your own. This process is unsupported, undocumented, and full of risk.
Scenario
You have OCS 2007 R2 and Lync 2010. You want to go to Lync 2013. You inherited the AD and the entire OCS/Lync environment from a previous regime. You have one AD forest with multiple child domains. You discover that the Lync Universal Groups are not in the default root domain container ou=users,dc=corp,dc=domain,dc=com. You may have discovered this when Forest Prep fails to run because it finds the universal groups in a child domain and dumps out with an error message about using enable-csforest with a –groupdomain attribute. See here. Or you may have discovered that a previous administrator installed the default universal groups into a child domain. And for a variety of business and technical reasons, you really want/need that specific child domain to go away. Oh, and both the R2 and the Lync 2010 are in production.
What to do now? If you manually run the enable-csadforest with a groupdomain attribute set to the existing child domain then remove that child domain, Lync will surely fail. But you need those universal groups to move. And UofG and UofB give you NOTHING. Talking to your peers will reveal that moving those universal groups is not supported. There is nothing in the documentation to provide guidance – other than to state that the groups belong up in the forest root domain.
I recently had this very scenario. And I had to move those groups. Here is what I did (more correctly, what we did).
And remember I have been very upfront about this being unsupported – don’t do this if you are not totally sure it will work for you – or if you are not confident in your skills to run through an entire implementation project from start to finish in a very short time frame to restore services.
Process
Back up your AD. You do this regularly already, right?! BTW, when was the last time you did a restore of that backup? A backup is only as good as its’ ability to be restored. Another great reason to run a lab.
Get management approval for a Plan B which involves services being out for xx days while things are nuked, scrubbed, and rebuilt. Prepare for throwing away the configuration container – in the case of my lab – this DN:
Go through all these groups and record all their memberships:
In my case, with R2 involved, services on the R2 servers were running as logins that belonged to the RTCcomponentUniversalServices groups. In addition, the RTCUniversalServerAdmins might have a few gems hidden in there.
Go to each server in the R2/Lync environment (including non-domain member Edge Servers) and make sure you know exactly how things are running and under what authority. Lync makes this easy – Network Services; R2 can be more problematic.
Go read up on ADMT. Active Directory Migration Tool for those of you who may not know. A great piece of kit. You can download it here. If you don’t have it already, download it, install it, play with it, lab out your actions.
Backup your user databases. If you have to rebuild from nothing, after you get your users restored, you can use DBIMPEXP to restore your users’ data. In my case, I got very lucky – the customer was willing to bake the entire mess if Plan A did not work out. So I got to skip this – I strongly suggest that you do not. You can read up on the R2 DBIMPEXP here. The Lync 2010 instructions are here.
If you have Lync 2010, then I suggest you run an export-csconfiguration and get that zip file to somewhere safe. If you need it, you can use it to just put things back together the way they were. You do have the entire system documented don’t you? If you have R2, then the same is needed, but it doesn’t really exist except in the above backup guidance for R2. I sure hope you know all your FQDN’s, IP’s, and have copies of all your certificates – especially the public certificates.
If you have Enterprise pools, then you need to go to the SQL server that hosts your databases and make SURE you record what database has what RTC group for login, and what rights. You are going to need this. While ADMT, with an intra-forest move, will retain SID history, the SQL server won’t magically change. So you will need to duplicate ALL the Lync/R2 perms that are listed per R2/Lync database. For example, in our case, global\RTCUniversalServerAdmins needed to change to corp\RTCUniversalServerAdmins. I got lucky – we had a killer DBA who scripted the entire thing. SQL does not need SID, it uses the UPN, looks up the account, and sees if matches what it has in its’ tables. Again, I think I got lucky on the SQL side, and I am sure I am not explaining this all that well. But take a look at this:
For this one database, there are three groups that need to change – again in my case from global\rtc* to corp\rtc* and don’t forget to look at the SQL security node and observe that the groups in question may have differing rights per database and per group.
SQL has two spots – the security node
and the users per database
You need to pay attention to both areas, security login and database user, and get the groups correct.
Go back and read about extending AD schema for Lync. Remember that you might be doing this step if you need to nuke that configuration container. Do this for Lync Forest Prep and Lync Domain Prep also. Just make certain you know. All three subjects are covered here.
OK. You got yourself documented, backed-up, SQL handled, ADMT installed. And you have all your actions mapped out, written down, recorded, and prepared. In my case we also prepared a somewhat detailed plan of what we were going to do in case Plan A failed, and the support we were going to need to make a whole new environment from scratch.
Make sure that ADMT is set to maintain SID history; for an inter-forest group move, it really should do that already, but you cannot be too safe. Then move the following groups using ADMT. Move them to ou=users,dc=domain,dc=com – your domain naming structure might be a bit different, but you get the idea. The default “users” OU in the forest root domain.
Make sure your SQL security logins and database rights are correct.
Patience. Wait for your AD to converge. In my case, it took a bit. Full convergence was about 16 hours, but the domains I was worried about took about 30 minutes.
Reboot your affected servers.
My environment came right up and was happy.
Remember what I said about this being unsupported.
YMMV
No comments:
Post a Comment