.local Active Directory Domain Rename - IntRAforest or IntERforest Migration
I've currently have a Native 2008 flat - Single AD Domain, Single Forest setup. We have approximately 20 locations with 1000 users with approximately 85-90% of the workforce being remote (i.e. their workstations don't see the corporate network more than 1 or twice a year). The domain is a .local domain (company.local). We have both Exchange 2010 and Lync 2010 on premise. AD servers are mostly 2008 R2 machines with a couple of 2008 machines. Workstations are all Windows 7. There are 10 or so SMTP / UPN / SIP Domains.
My understanding is that Public SSL Providers will not issue SSL certs for .local domains beginning in 2015. We're currently utilize Lync 2010 which is pretty reliant on SSL Certs. We've also just subscribed to Office365 and looking to kill our on premise Exchange and move to the cloud. Since we have exchange in the Forest, a Domain Rename is not an option. I'm thinking I need to do an INTER-FOREST migration to a new Single Forest/Single Domain to get rid of the current .Local domain. I'm also thinking that this needs to be done prior to our move to Office365. I'm planning on using Dirsync and ADFS with Office365.
I was planning on using ADMT to migrate to the new forest, stand up a temporary Exchange in the new forest, migrate users to the temporary exchange and then migrate a 2nd time to Office365. There would need to be a coexistence period between the new and old forest so that accounts from either forest could access each others resources during the migration which I'm thinking will take a few months. I was going to take this time and start from scratch with everything in the new domain (new SharePoint, Exchange, SQL, etc.) to make sure it was done right. Only user accounts and groups would be migrated over.
However, the INTRA-Forest scenario just popped into my mind. I would create a new child domain (company.com) in the EXISTING AD Forest (company.local), migrate the stuff over to the new child domain. This would leave a .local root domain, but the child AD domain where everything is would be a "real" .com (or .net what ever) domain. This seems to be a lot simpler at 1st glance than a INTRA-Forest migration. Can someone give me some insight to this? Any issues with a empty .local root domain?
My understanding is that Public SSL Providers will not issue SSL certs for .local domains beginning in 2015. We're currently utilize Lync 2010 which is pretty reliant on SSL Certs. We've also just subscribed to Office365 and looking to kill our on premise Exchange and move to the cloud. Since we have exchange in the Forest, a Domain Rename is not an option. I'm thinking I need to do an INTER-FOREST migration to a new Single Forest/Single Domain to get rid of the current .Local domain. I'm also thinking that this needs to be done prior to our move to Office365. I'm planning on using Dirsync and ADFS with Office365.
I was planning on using ADMT to migrate to the new forest, stand up a temporary Exchange in the new forest, migrate users to the temporary exchange and then migrate a 2nd time to Office365. There would need to be a coexistence period between the new and old forest so that accounts from either forest could access each others resources during the migration which I'm thinking will take a few months. I was going to take this time and start from scratch with everything in the new domain (new SharePoint, Exchange, SQL, etc.) to make sure it was done right. Only user accounts and groups would be migrated over.
However, the INTRA-Forest scenario just popped into my mind. I would create a new child domain (company.com) in the EXISTING AD Forest (company.local), migrate the stuff over to the new child domain. This would leave a .local root domain, but the child AD domain where everything is would be a "real" .com (or .net what ever) domain. This seems to be a lot simpler at 1st glance than a INTRA-Forest migration. Can someone give me some insight to this? Any issues with a empty .local root domain?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Public certificate authorities are already denying requests which include invalid Top Level Domains (like .local) as it has to do with the expiration date, not the request date. See this blog article for more details:
http://blog.schertz.name/2013/01/lync-server-certificate-cliff
I would simply deploy an internal Enterprise Windows CA (if you do not already have one) and assign private certificates to the internal Lync server roles, saving the public certs for external resources only (your Edge and Reverse Proxy servers).