locked
Migration d'un controleur de domaine unique vers un domaine existant RRS feed

  • Question

  • Bonjour,

    Dans le cadre d'une restructuration de service, je souhaite reunir deux domaines distincts:

    Domaine A: un seul DC 2003 R2
    Domaine B: trois DC, deux 2003 R2 et un 2008.

    A terme, je souhaite que le controlleur de domaine (A) devienne un controlleur de domaine supplémentaire dans le domaine B.
    Mes predecesseurs ont eu la bonne idée d'apeller leurs serveurs "SERVEUR", du coup je me retrouve avec deux ordinateurs nommés SERVEUR dans chaque domaine respectif.

    Il existe d'ores et déjà une relation d'approbation entre les deux domaines.
    Mon plan est d'utiliser ADMT pour migrer les utilisateurs du domaine A vers le domaine B, retrograder le controlleur de domaine (A), le renommer, puis le promouvoir en tant que controlleur de domaine supplémentaire sur le domaine B.

    Est-ce que cela parait convenable ? Y-a-il une solution plus simple à laquelle je n'ai pas pensé ?

    Cordialement,
    Ozy de Jong.

     

    mardi 25 septembre 2012 08:57

Réponses

  • Bonjour,

    A ma connaissance la soltuion que vous avez opté est la meilleur et le chemin unique pour transférer les objets d'un domaine vers un autre domaine différents via l'outil AMDT, puis si vous désirez rendre le contrôleur du domaine A membre du domaine B, vous devrez le retrograder et le rejoindre au nouveau domaine ,faites attention dans chaque étape au paramêtres DNS pour se communiquer au domaine cible.


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    mardi 25 septembre 2012 09:27
  • Bonjour,

    Il ne s'agit pas d'une migration Exchange 2003 vers 2010. Les utilisateurs du domaine A s'authentifient via un proxy HTTPS sur Exchange 2010 dans le domaine B. Ils y ont déjà un compte utilisateur qui ne sert qu'a Exchange. L'idée est d'attacher les boîtes à lettres Exchange vers les comptes nouvellement importés avec ADMT après suppression des comptes existants.

    Enfin, pour la petite précision: J'ai reussi a recréer mon problème des relations d'approbations en virtuel. En effet, avoir deux serveurs du même nom dans deux domaines différents crée énormément de problèmes, mais en même temps il fallait s'en douter.

    Pour compléter le post si quelqu'un a le même problème que moi, j'ai été un peu vilain pour faire marcher la relation d'approbation en plus du problème de time drifting. J'ai temporairement coupé le VPN vers le serveur DC du même nom dans le domaine B et mis en l'adresse IP du serveur du domaine A dans le lmhost du FSMO du domaine B.

    C'est pas beau, mais ça a le mérite de marcher.
    Après une fois la migration terminée, je remettrai le VPN et le contrôleur repliquera les différences.


    Administrateur Windows & Linux caffeinomane :)

    jeudi 27 septembre 2012 16:43
  • Bonjour,

    Je vous remercie de votre réponse. Je n'ai plus qu'a espérer que l'opération réele sera aussi simple que la théorie...

    Cordialement.


    Administrateur Windows & Linux caffeinomane :)

    Bonjour,

    Il suffit de vérifier la configuration DNS pour authoriser la communication entre les deux domaines: Voici ce lien :Inter-forest Migration prerequisites and preparations

    Vous pouvez trouvez plusieurs guide pour atteindre votre objective, je vous propose de consolter ce thread qui peut vous offrir des lies utils:

    Advise on Performing an Interforest Migration for a 34K User, 400 Forest Environment Using ADMT 3.2


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    mardi 25 septembre 2012 14:34
  • ok , maintenant j'ai compris votre besoin.

    Je confirme le démache dont vous avez pensé pour associer les boites à lettres aux nouveaux utilisateurs, il suffit de déconnecté les boites de lettre en question et les réattacher au nouveau utilisateur créé après la migration du compte:

    Se connecter à une boîte aux lettres


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    • Marqué comme réponse Florin Ciuca jeudi 4 octobre 2012 07:23
    jeudi 27 septembre 2012 17:01

Toutes les réponses

  • Bonjour,

    A ma connaissance la soltuion que vous avez opté est la meilleur et le chemin unique pour transférer les objets d'un domaine vers un autre domaine différents via l'outil AMDT, puis si vous désirez rendre le contrôleur du domaine A membre du domaine B, vous devrez le retrograder et le rejoindre au nouveau domaine ,faites attention dans chaque étape au paramêtres DNS pour se communiquer au domaine cible.


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    mardi 25 septembre 2012 09:27
  • Bonjour,

    Je vous remercie de votre réponse. Je n'ai plus qu'a espérer que l'opération réele sera aussi simple que la théorie...

    Cordialement.


    Administrateur Windows & Linux caffeinomane :)

    mardi 25 septembre 2012 14:11
  • Bonjour,

    Je vous remercie de votre réponse. Je n'ai plus qu'a espérer que l'opération réele sera aussi simple que la théorie...

    Cordialement.


    Administrateur Windows & Linux caffeinomane :)

    Bonjour,

    Il suffit de vérifier la configuration DNS pour authoriser la communication entre les deux domaines: Voici ce lien :Inter-forest Migration prerequisites and preparations

    Vous pouvez trouvez plusieurs guide pour atteindre votre objective, je vous propose de consolter ce thread qui peut vous offrir des lies utils:

    Advise on Performing an Interforest Migration for a 34K User, 400 Forest Environment Using ADMT 3.2


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    mardi 25 septembre 2012 14:34
  • Bonjour,

    Bon c'est un peu pire que ce que je pensais.
    La relation d'approbation entre les deux domaines ne fonctionne pas pour la raison suivante:

    La vérification du canal sécurisé (CS) sur le contrôleur de domaine \\SERVEUR.domaineA du domaine domaineA vers le domaine domaineB a échoué avec l'erreur : Accès refusé.
    La réinitialisation du canal sécurisé (CS) sur le contrôleur de domaine \\SERVEUR.domaineA du domaine domaineA vers le domaine domaineB a échoué avec l'erreur : Accès refusé.
    La réinitialisation du canal sécurisé (CS) sur le contrôleur de domaine \\annexappserv.domaineB du domaine domaineB vers le domaine domaineB a échoué avec l'erreur : Aucun serveur d'accès n'est actuellement disponible pour traiter la demande d'ouverture de session.

     J'immagine que j'ai droit à ce problème d'approbation parce que dans chaque domaine il y a un serveur nommé SERVEUR et que donc un compte d'ordinateur ne peut être crée.

    Du coup je ne vois plus qu'une solution... Rajouter un 2eme contrôleur de domaine au domaine A configuré en catalogue global (que je nommerai TEMPDC ici)... Lui transférer les rôles FSMO, depromouvoir SERVEUR.domaineA. Créer une relation d'approbation entre le domaineA et le domaineB, transférer les utilisateurs & comptes d'ordinateur avec ADMT, puis dépromouvoir le TEMPDC du domaine A et promouvoir SERVEUR en tant que contrôleur de domaine dans le domaine B.

    Tout cela commence à me sembler complèxe pour le bénéfice de temps que je comptais en espérer.
    Je vais tout de même me permettre de faire un P2V des deux contrôleurs de catalogue global des domaines A & B, puis tenter l'opération sous forme de machines virtuelles sous Hyper-V. Si tout cela me semble concluant, je tenterai l'expérience IRL.


    Administrateur Windows & Linux caffeinomane :)


    jeudi 27 septembre 2012 13:25
  • Bonjour,

    Attention la conversion P2V des contrôleur de domaine est une action non recommandé, pour savoir les bonne pratique pour administrer les service active directory dans une environnement virtuelle veuillez consulter ce lien :Les bonnes pratiques pour l’administration des services active directory dans un environment virtuel .

    Je te recommande de suivre la procédure que vous avez suivi dés le début pour éviter le problème d'USN rollback causé par le P2V des contrôleur de domaine.


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    jeudi 27 septembre 2012 13:40
  • Bonjour,

    La virtualisation me servirait juste pour tester. Une fois le test éffectué les deux machines virtuelles disparaitront et je ne comptais pas faire de V2P après. Etant donné que je vais virtualiser uniquement le FSMO du domaine B et l'unique GC du domaine A, je ne risque pas d'avoir un problème d'USN antérieur.

    De toute manière j'ai avancé, il semblerait que la relation d'approbation fonctionne bien maintenant (sur les serveurs physiques).
    A priori il s'agissait d'un problème aussi simple que la synchronisation de temps entre les deux domaines.

    Il me reste plus qu'a virtualiser, puis lancer l'opération ADMT pour tester.

    Un dernier détail m'obsède. Les utilisateurs du domaine A disposent déjà d'un compte dans le domaine B, qui ne sert qu'a l'accès au serveurs Exchange du domaine B. Si je supprime les comptes utilisateurs du domaine B (qui sont des duplicatas du domaine A), je pense rattacher ensuite les boîtes à lettres orphelines aux comptes utilisateurs importés avec ADMT du domaine A. Cela semble raisonnable ?

    Encore merci.


    Administrateur Windows & Linux caffeinomane :)

    jeudi 27 septembre 2012 14:54
  • Bonjour,

    La virtualisation me servirait juste pour tester. Une fois le test éffectué les deux machines virtuelles disparaitront et je ne comptais pas faire de V2P après. Etant donné que je vais virtualiser uniquement le FSMO du domaine B et l'unique GC du domaine A, je ne risque pas d'avoir un problème d'USN antérieur.

    De toute manière j'ai avancé, il semblerait que la relation d'approbation fonctionne bien maintenant (sur les serveurs physiques).
    A priori il s'agissait d'un problème aussi simple que la synchronisation de temps entre les deux domaines.

    Il me reste plus qu'a virtualiser, puis lancer l'opération ADMT pour tester.

    Un dernier détail m'obsède. Les utilisateurs du domaine A disposent déjà d'un compte dans le domaine B, qui ne sert qu'a l'accès au serveurs Exchange du domaine B. Si je supprime les comptes utilisateurs du domaine B (qui sont des duplicatas du domaine A), je pense rattacher ensuite les boîtes à lettres orphelines aux comptes utilisateurs importés avec ADMT du domaine A. Cela semble raisonnable ?

    Encore merci.


    Administrateur Windows & Linux caffeinomane :)

    Bonjour,

    jetez un coup d'oeil sur ce thread qui contient des liens et des recommandations qui peuvent vous aider et guider à réaliser votre projet :Migration Exhange 2003 vers exchange 2010 de domaine différents


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton


    jeudi 27 septembre 2012 15:16
  • Bonjour,

    Il ne s'agit pas d'une migration Exchange 2003 vers 2010. Les utilisateurs du domaine A s'authentifient via un proxy HTTPS sur Exchange 2010 dans le domaine B. Ils y ont déjà un compte utilisateur qui ne sert qu'a Exchange. L'idée est d'attacher les boîtes à lettres Exchange vers les comptes nouvellement importés avec ADMT après suppression des comptes existants.

    Enfin, pour la petite précision: J'ai reussi a recréer mon problème des relations d'approbations en virtuel. En effet, avoir deux serveurs du même nom dans deux domaines différents crée énormément de problèmes, mais en même temps il fallait s'en douter.

    Pour compléter le post si quelqu'un a le même problème que moi, j'ai été un peu vilain pour faire marcher la relation d'approbation en plus du problème de time drifting. J'ai temporairement coupé le VPN vers le serveur DC du même nom dans le domaine B et mis en l'adresse IP du serveur du domaine A dans le lmhost du FSMO du domaine B.

    C'est pas beau, mais ça a le mérite de marcher.
    Après une fois la migration terminée, je remettrai le VPN et le contrôleur repliquera les différences.


    Administrateur Windows & Linux caffeinomane :)

    jeudi 27 septembre 2012 16:43
  • ok , maintenant j'ai compris votre besoin.

    Je confirme le démache dont vous avez pensé pour associer les boites à lettres aux nouveaux utilisateurs, il suffit de déconnecté les boites de lettre en question et les réattacher au nouveau utilisateur créé après la migration du compte:

    Se connecter à une boîte aux lettres


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    • Marqué comme réponse Florin Ciuca jeudi 4 octobre 2012 07:23
    jeudi 27 septembre 2012 17:01
  • Bonjour,

    Malheureusement ce n'est pas aussi simple que sur papier.
    Je viens de migrer un compte utilisateur de test, et après raccordement de la boîte à lettres déconnectée de son ancien compte dans le domaine cible, je ne peux pas accéder à sa boîte via OWA.

    J'ai biensur verifié qu'il est possible de se logguer avec ce compte, cela fonctionne.
    J'ai également comparé deux comptes utilisateurs (un existant et un migré) avec LDP, cela me semble tout à fait correct.
    Enfin, si je donne les droits d'accès à mon compte administrateur, je peux ouvrir la boîte à lettres via OWA.

    Il s'agirait donc bien d'un problème avec le compte importé via ADMT.

    Ci-joint le détail de l'erreur... Je continue à chercher.

    Request
    Url: https://mail.monserveurexchange.tld:443/owa/lang.owa
    User host address: 80.14.256.256
    Exception
    Exception type: Microsoft.Exchange.Data.Storage.ConnectionFailedTransientException
    Exception message: Cannot open mailbox /o=mon organisation/ou=exchange administrative group (fydibohf23spdlt)/cn=recipients/cn=utilisateurmigré.
    Call stack
    à Microsoft.Exchange.Data.Storage.ConnectionCachePool.OpenMailbox(String serverDn, String userDn, String mailboxDn, Guid mailboxGuid, Guid mdbGuid, Object identity, ConnectFlag connectFlag, OpenStoreFlag openStoreFlag, CultureInfo cultureInfo, String clientInfoString, Boolean secondTry) à Microsoft.Exchange.Data.Storage.ConnectionCachePool.OpenMailbox(String serverDn, String userDn, String mailboxDn, Guid mailboxGuid, Guid mdbGuid, Object identity, ConnectFlag connectFlag, OpenStoreFlag openStoreFlag, CultureInfo cultureInfo, String clientInfoString, Boolean secondTry) à Microsoft.Exchange.Data.Storage.ConnectionCachePool.OpenMailbox(String serverDn, String userDn, String mailboxDn, Guid mailboxGuid, Guid mdbGuid, Object identity, ConnectFlag connectFlag, OpenStoreFlag openStoreFlag, CultureInfo cultureInfo, String clientInfoString) à Microsoft.Exchange.Data.Storage.MailboxSession.Initialize(LogonType logonType, ExchangePrincipal owner, DelegateLogonUser delegateUser, Object identity, OpenMailboxSessionFlags flags) à Microsoft.Exchange.Data.Storage.MailboxSession.CreateMailboxSession(LogonType logonType, ExchangePrincipal owner, DelegateLogonUser delegateUser, Object identity, OpenMailboxSessionFlags flags, CultureInfo cultureInfo, String clientInfoString) à Microsoft.Exchange.Data.Storage.MailboxSession.Open(ExchangePrincipal mailboxOwner, WindowsPrincipal authenticatedUser, CultureInfo cultureInfo, String clientInfoString) à Microsoft.Exchange.Clients.Owa.Core.OwaWindowsIdentity.CreateMailboxSession(ExchangePrincipal exchangePrincipal, CultureInfo cultureInfo) à Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchLanguagePostLocally(OwaContext owaContext, OwaIdentity logonIdentity, CultureInfo culture, String timeZoneKeyName, Boolean isOptimized) à Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchLanguagePostRequest(OwaContext owaContext) à Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.PrepareRequestWithoutSession(OwaContext owaContext, UserContextCookie userContextCookie) à Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.InternalDispatchRequest(OwaContext owaContext) à Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchRequest(OwaContext owaContext) à System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() à System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
    Inner Exception
    Exception type: Microsoft.Mapi.MapiExceptionLogonFailed
    Exception message: MapiExceptionLogonFailed: Unable to open message store. (hr=0x80040111, ec=1010) Diagnostic context: Lid: 18969 EcDoRpcExt2 called [length=667] Lid: 27161 EcDoRpcExt2 returned [ec=0x0][length=124][latency=3] Lid: 23226 --- ROP Parse Start --- Lid: 27962 ROP: ropLogon [254] Lid: 17082 ROP Error: 0x3F2 Lid: 26937 Lid: 21921 StoreEc: 0x3F2 Lid: 27962 ROP: ropExtendedError [250] Lid: 1494 ---- Remote Context Beg ---- Lid: 26426 ROP: ropLogon [254] Lid: 4740 StoreEc: 0x80070005 Lid: 30409 StoreEc: 0x80070005 Lid: 19145 StoreEc: 0x3F2 Lid: 23241 StoreEc: 0x3F2 Lid: 32186 Lid: 8620 StoreEc: 0x3F2 Lid: 1750 ---- Remote Context End ---- Lid: 26849 Lid: 21817 ROP Failure: 0x3F2 Lid: 26297 Lid: 16585 StoreEc: 0x3F2 Lid: 32441 Lid: 1706 StoreEc: 0x3F2 Lid: 24761 Lid: 20665 StoreEc: 0x3F2 Lid: 25785 Lid: 29881 StoreEc: 0x3F2 
    Call stack
    à Microsoft.Mapi.MapiExceptionHelper.ThrowIfError(String message, Int32 hresult, Int32 ec, DiagnosticContext diagCtx) à Microsoft.Mapi.ExRpcConnection.OpenMsgStore(OpenStoreFlag storeFlags, String mailboxDn, Guid mailboxGuid, Guid mdbGuid, MapiStore msgStorePrivate, String& correctServerDn, ClientIdentityInfo clientIdentityAs, String userDnAs, String applicationId, CultureInfo cultureInfo) à Microsoft.Mapi.ConnectionCache.OpenMapiStore(String mailboxDn, Guid mailboxGuid, Guid mdbGuid, ClientIdentityInfo clientIdentity, String userDnAs, OpenStoreFlag openStoreFlags, CultureInfo cultureInfo, String applicationId) à Microsoft.Mapi.ConnectionCache.OpenMailbox(String mailboxDn, Guid mailboxGuid, Guid mdbGuid, WindowsIdentity windowsIdentityAs, String userDnAs, OpenStoreFlag openStoreFlags, CultureInfo cultureInfo, String applicationId) à Microsoft.Exchange.Data.Storage.ConnectionCachePool.OpenMailbox(String serverDn, String userDn, String mailboxDn, Guid mailboxGuid, Guid mdbGuid, Object identity, ConnectFlag connectFlag, OpenStoreFlag openStoreFlag, CultureInfo cultureInfo, String clientInfoString, Boolean secondTry)

    Administrateur Windows & Linux caffeinomane :)



    samedi 13 octobre 2012 11:37
  • La suite... LDP n'étant pas assez complet, j'ai commencé à comparer deux utilisateurs importés (un dont l'accès à Exchange fonctionne, l'autre non) avec ADSIEDIT.

    L'attribut msDS-ExchMailboxSecurityDescriptor comportait une entrée de type "DENY" en plus des autres entrées sur l'utilisateur qui ne fonctionnait pas.

    Il m'a fallu comparer les droits d'accès entre les deux boîtes mail avec la commande

    Get-MailboxPermission -Identity "userquimarchepas"

    puis enlever l'entrée de trop avec

    Remove-MailboxPermission -Identity "userquimarchepas" -User "Userquiaunaccessdenied" -AccessRights FullAccess -InheritanceType All

    Le reéxecution de Get-MailboxPermission semble indiquer que l'entrée de type Deny existe toujours, meme après un cache flush avec

    net stop MSExchangeIS && net start MSExchangeIS

    Mais en tout cas l'accès à la boîte à lettres est retabli.

    PS: j'avais testé de rajouter l'utilisateur lui même dans "gerer l'accès total" de EMC (en plus de l'entrée SELF ce qui est normalement un doublon), et cette solution la fonctionne aussi mais c'était pas très propre...


    Administrateur Windows & Linux caffeinomane :)



    samedi 13 octobre 2012 11:54