Un inconvénient à ajouter un UPN au lieu d'essayer de corriger notre nom de domaine AD?

Malheureusement, j'ai hérité d'un domaine Active Directory dont le nom est un nom DNS que la société ne possède pas - nous l'appellerons ABC.com. Je voudrais que ce soit quelque chose sous company.com à la place (selon la réponse de MDMarra sur la dénomination AD, j'utiliserais probablement ad.company.com car vous ne voulez jamais utiliser un nom DNS que vous utilisez pour autre chose), mais la dure exigence pour est maintenant en mesure de déplacer le courrier électronique vers Office 365 cette année et d'utiliser la synchronisation d'annuaire. Pour cela, il semble qu'au moins j'ai besoin d'un UPN correspondant à notre domaine de messagerie (company.com). Ok, le processus d'ajout d'un deuxième UPN semble assez simple . Le tester et déplacer les comptes jusqu'à ce qu'ils soient tous sur l'UPN souhaité semble assez raisonnable.

Y a-t-il un inconvénient à le faire? Le faucheur de la dette technique arrivera-t-il finalement si nous restons indéfiniment sur ce nom de domaine «non détenu» d'ABC.com?

Pour référence, nous avons une forêt unique, un domaine unique avec tout (forêt, niveau fonctionnel, tous les contrôleurs de domaine) au niveau 2012R2 et Exchange 2010 sur ce domaine. Il y a environ 150 utilisateurs et 450 ordinateurs dans AD (beaucoup d'automatisation dev / test). Alors que je nous ai navigué en toute sécurité de 2003 à 2012R2, je ne m'appellerais en aucun cas expert chez AD.

Il ne semble pas que les noms de domaine soient généralement conseillés, et puisque nous avons Exchange 2010 sur notre domaine, je ne pense pas que ce serait même une option.

Selon moi, je pourrais soit:

• ajoutez un deuxième UPN et terminez. Je peux gérer le fait d'avoir à définir manuellement l'UPN sur les choses que nous créons / ajoutons ...
• ajouter un deuxième domaine à la forêt, tout déplacer et toujours garder ce domaine racine hérité pour toujours que je ne peux pas supprimer
• créer une deuxième forêt, la forêt <-> trust de forêt, tout faire comme je le veux vraiment sur cette nouvelle forêt à partir de zéro ... déplacer tout, et finalement supprimer la forêt d'origine. Vraiment lent, très soigneusement, testé en avant et en arrière, et probablement à grands frais (au minimum en temps passé). Dans un monde de rêve, cela semble mieux, mais je ne suis pas sûr de pouvoir justifier une analyse de rentabilisation pour cela (à moins que quelqu'un ne déclare qu'une sinistre arrivée se produira).
• ??? autre chose à laquelle je n'ai pas pensé

Donc, une crise existentielle à propos de ne pas posséder le domaine que vous utilisez en interne - d'un point de vue Office 365, c'est bien. Office 365 se soucie de vérifier les domaines de messagerie que vous utilisez, pas votre domaine AD. Par conséquent, l'approche que vous avez adoptée en modifiant les UPN pour qu'ils correspondent aux adresses e-mail des utilisateurs est appropriée et correcte.

Maintenant, d'un point de vue purement AD, vous ne pourrez jamais obtenir un certificat tiers pour ce domaine DNS interne puisque vous ne le possédez pas. Cela peut ou non être un problème pour vous. Vous ne pourrez également jamais faire confiance à un autre domaine qui partage le même nom, donc dans le cas peu probable où vous fusionneriez avec la société qui possède ce domaine et qui utilisent également ce nom, vous aurez des cauchemars de migration. J'imagine que la probabilité de cela est proche de 0.

C'est beaucoup de travail et potentiellement très perturbant pour les utilisateurs finaux de renommer ou de migrer hors d'un domaine. À ce stade, je suis généralement d'avis que vous devez simplement quitter le domaine mal nommé, à moins que l'un de ces cas extrêmes ne vous cause de chagrin et assurez-vous de bien le faire lors de la prochaine remise des gaz :)