active directory - Any downside to adding a UPN instead of trying to correct our AD domain name?

itemprop="text">

Unfortunately I inherited an Active
Directory domain whose name is a DNS name the company does not own - we'll call it
ABC.com. I would like it to be something under company.com instead (per href="https://serverfault.com/a/473530/17708">MDMarra's answer on AD naming
I'd probably use ad.company.com since you never want to use a DNS name you use for
anything else), but the hard requirement for now is to be able to move email to Office
365 this year and using Directory Synchronization. For that, it looks like at a minimum
I need a matching UPN to our email domain (company.com). Ok, href="https://support.office.com/en-us/article/How-to-prepare-a-non-routable-domain-such-as-local-domain-for-directory-synchronization-e7968303-c234-46c4-b8b0-b5c93c6d57a7"
rel="noreferrer">the process for adding a second UPN seems simple enough.
Testing it and moving accounts over until they are all on the desired UPN seems
reasonable enough.

Is there any
downside to just doing this? Will the technical debt grim reaper eventually arrive if we
stay on this 'non-owned' domain name of ABC.com indefinitely?

For reference, we have a single
forest, single domain with everything (forest, functional level, all DCs) at 2012R2
level and Exchange 2010 on this domain. There are around 150 users and 450 computers in
AD (lots of dev/test automation). While I've safely navigated us from 2003 forward to
2012R2, I would by no means call myself an expert at
AD.

It doesn't look like domain renames are
generally advised, and since we have Exchange 2010 on our domain I don't believe it
would even be an option.

As I see it, I could
either:

• add a second UPN
  and be done. I can deal with having to manually set the UPN on things as we create/add
  them...


• add a second domain to the forest, move
  everything over, and always have this legacy root domain forever that I can't
  remove



• create a second forest, forest
  <-> forest trust, do everything the way I really want it on this new forest from
  the ground up...move everything, and eventually remove the original forest. Really slow,
  really carefully, tested forwards and back, and probably at great expense (at a minimum
  in time spent). In a dream world this seems best, but I am not sure I can justify a
  business case for this (unless someone states a grim reaper arrival will
  occur).


• ??? something else I haven't thought of
  

itemprop="text">

class="normal">Answer

So,
existential crisis about not owning the domain you're using internally aside - from an
Office 365 perspective this is fine. Office 365 cares about verifying the email domains
that you have in use, not your AD domain. So the approach that you've taken by changing
the UPNs to match the users' email addresses is appropriate and
correct.

Now, from a purely AD perspective, you
will never be able to get a third party certificate for that internal DNS domain since
you don't own it. This may or may not be an issue for you. You'll also never be able to
make a trust with another domain that shares the same name, so in the unlikely event
that you merge with the company that owns that domain and they are also using that name,
you'll have migration nightmares. I'd imagine the probability of this is somewhere close
to 0.

It's a lot of work
and potentially very disruptive to end users to rename or migrate out of a domain. At
this point, I'm typically of the opinion that you should just leave the poorly named
domain unless one of those edge cases is causing you heartache and just make sure you
get it right on the next go-around :)