We have ~60 cross-forest 1-way incoming trusts. We allow the 1-way incoming because we have the authoritative identities & this model permits some autonomy, while greatly limiting the complexity. 2-way cross-forest trusts can get complex quickly, especially as the number of them increases.
You end up with folks who don't quite understand the desired architecture giving bad advice, people with user accounts in both domains, a crazy mishmash of groups (and you grow even more annoyed at AD group types), and you might even have folks start talking about selective authentication which would add another layer of complexity. On the flip-side, it avoids the one-time cost of merging domains. But I think the technical debt isn't worth avoiding that one-time cost. From: [email protected] [mailto:[email protected]] On Behalf Of Ryan Shugart Sent: Thursday, August 13, 2015 8:08 AM To: [email protected] Subject: [adgpo] RE: domain migrations Brian: Thanks a lot, this is some pretty thorough documentation and has given me a few things to think about. Once I get a copy of this company's DC and get it and one of ours stood up in a lab environment I'll be able to do some more playing and I'm sure then have a much better idea what I'm getting myself into with this. On a similar note, how does everyone feel about cross-forest domain trusts? Since we are a single domain single forest, and this company we'll be integrating is a single domain single forest, I've contemplated setting up a cross forest trust with their existing domain and calling it good, but I'm getting a lot of pushback from management on this for a reason I don't fully understand yet, so was wondering if there was something there I was missing. Ryan From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Brian Arkills Sent: Wednesday, August 12, 2015 10:12 AM To: [email protected]<mailto:[email protected]> Subject: [adgpo] RE: domain migrations I think it all depends on what you need and what you can afford. Most of those formerly Quest products are super awesomely nice, but when I've looked at buying them, I couldn't because they were based on a pricing model based on the number of users in your AD. For large research universities such as the UW, that kind of pricing model doesn't work at all, even with educational discounts. We have the same issue with Azure AD premium. :( I've used ADMT to help departments with dozens of domain migrations. The most exciting was a double domain migration in a single weekend to facilitate "keeping" the same DNS & netbios name but get out of a shared forest. It covers the basics and there are a few issues but in my experience you can work around those. http://www.netid.washington.edu/documentation/assistedMigration.aspx is our documentation which is specific to the UW environment, but there are quite a few general tips in there that are likely useful. See the section that begins with "Here are some known gotchas" to quickly jump to those general tips. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Carneiro, Smita A. Sent: Wednesday, August 12, 2015 8:07 AM To: '[email protected]' <[email protected]<mailto:[email protected]>> Subject: [adgpo] RE: domain migrations Many more features. The MS consultant we had in at the beginning of the process recommended it too. I think that says a lot :) ADMT is pretty bare-bones compared to DMM. Smita From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ryan Shugart Sent: Wednesday, August 12, 2015 10:57 AM To: [email protected]<mailto:[email protected]> Subject: [adgpo] RE: domain migrations Good information, thanks. Can you share why you went with the Dell migration tool over Microsoft's ADMT? Ryan From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Carneiro, Smita A. Sent: Wednesday, August 12, 2015 5:42 AM To: '[email protected]' <[email protected]<mailto:[email protected]>> Subject: [adgpo] RE: domain migrations We will be doing a migration to a greenfield environment in the coming months, and plan on using the Dell Migration Manager tool. We have a large AD and migrating all the applications will be a challenge. That is where we hope to see the real value of the tool. Communicating with the different areas on campus - our AD is very decentralized - is a very important part of this process. We talked to them got their input and redesigned our logical structure to meet their needs better. We also built a test environment that is a replica of the greenfield environment that will be built, and have let interested parties get in to test. If you have to pick the most important process, I would say it is communication. And make sure you have a good project manager. Smita From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ryan Shugart Sent: Tuesday, August 11, 2015 4:26 PM To: [email protected]<mailto:[email protected]> Subject: [adgpo] domain migrations Hi: I'm interested in hearing from anyone who has performed an AD migration, such as as part of an acquisition or similar. In the past when we've acquired companies, the environments have been small enough that we were just able to recreate all of their accounts in our domain manually and then disjoin the machines from their old domain and join them to ours. Going forward, though, I've been asked about better ways of doing this, such as exploring domain trusts and migration tools. We're currently a single-forest single-domain shop, so I know there's going to be a lot of things to think about going forward that we haven't had to think about before (local VS global VS universal groups, etc.) I was just curious to hearing from people who have done this before as to what is a common way this is done in the real world as I start exploring. Thanks. Ryan Ryan Shugart LAN Administrator MiTek USA, MiTek Denver 314-851-7414 MiTek Holdings, Inc., 2011-2014, All Rights Reserved ________________________________ This communication (including any attachments) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
