Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
oui, ceux qui sont sur l'ancien domaine travaillent sur l'ancien. Ceux qui
Et ceux qui sont connectés avec (session verrouillé) reste t'il connecté ?
En fait, tout dépend du moment de la migration. Tant que tu ne fais pas de
Vi c'est sur le redémarrage est toujours dur, mais une fois reparti ca va
lol.
Le plus drole c'est que j'ai pensé aux question que je pouvais te poser a
mon retour lol.
Sinon je vais au plus simple, et en fonction de ce que tu me dit.
Autre chose, (avec la premiere méthode, plus simple en gros => A):
Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
Et ceux qui sont connectés avec (session vérouillé) reste t'il connecté ?
J'ai fait pas mal de test mais pas celui la !
Merci :o)Salut Reno,
les vacances se sont bien passées, mais dur de se remettre dans le bain
après :)
Quelle méthode prodiguée utilise tu? je suppose que tu parle de la
migration
en place où tu met à jour un BDC (etc...) Dans ces cas là, pas d'ADMT ou
autre effectivement (par contre tu embarque avec toi les vieilles DLL et
tous les vieux trucs NT4).
"Ma" méthode (donc avec ADMT) consiste en une restructuration. Elle est
plus
longue effectivement, mais permet de démarrer avec un domaine tout
propre,
et autorise la rationalisation de X domaine vers 1 seul.
Je te rassure, elle est aussi prodiguée par MS, simplement l'optique et
les
champs à englober ne sont pas les mêmes.
Fondamentalement, tu ne dois pas avoir de problèmes avec la méthode du CD
si
tu n'as qu'un seul domaine, et que tu n'es pas inquiété par le fait de
partir sur un domaine vierge puis alimenté par ADMT. Après, je te rassure
le
débat entre les fans de l'une ou l'autre des méthode dure depuis bien
longtemps maintenant :o)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Salut Jonathan,
J'espere que ta passé de bonne vacance :o)
Alors, pour migrer je n'utilise plus ta methode mais celle prodigué par
microsoft qui a mon sens est bcp plus simple, ce qui m'etonne c'est
cette
différence ?
En gros je me saire juste du CD 2003 pour la mise a jour alors que ta
methode nécéssite une mise en place beaucoup plus large, peut tu me
dire
pourquoi, si il y a des truc qui ne vont pas passer avec l'autre
methode ?
Merci et A +.
Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
oui, ceux qui sont sur l'ancien domaine travaillent sur l'ancien. Ceux qui
Et ceux qui sont connectés avec (session verrouillé) reste t'il connecté ?
En fait, tout dépend du moment de la migration. Tant que tu ne fais pas de
Vi c'est sur le redémarrage est toujours dur, mais une fois reparti ca va
lol.
Le plus drole c'est que j'ai pensé aux question que je pouvais te poser a
mon retour lol.
Sinon je vais au plus simple, et en fonction de ce que tu me dit.
Autre chose, (avec la premiere méthode, plus simple en gros => A):
Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
Et ceux qui sont connectés avec (session vérouillé) reste t'il connecté ?
J'ai fait pas mal de test mais pas celui la !
Merci :o)
Salut Reno,
les vacances se sont bien passées, mais dur de se remettre dans le bain
après :)
Quelle méthode prodiguée utilise tu? je suppose que tu parle de la
migration
en place où tu met à jour un BDC (etc...) Dans ces cas là, pas d'ADMT ou
autre effectivement (par contre tu embarque avec toi les vieilles DLL et
tous les vieux trucs NT4).
"Ma" méthode (donc avec ADMT) consiste en une restructuration. Elle est
plus
longue effectivement, mais permet de démarrer avec un domaine tout
propre,
et autorise la rationalisation de X domaine vers 1 seul.
Je te rassure, elle est aussi prodiguée par MS, simplement l'optique et
les
champs à englober ne sont pas les mêmes.
Fondamentalement, tu ne dois pas avoir de problèmes avec la méthode du CD
si
tu n'as qu'un seul domaine, et que tu n'es pas inquiété par le fait de
partir sur un domaine vierge puis alimenté par ADMT. Après, je te rassure
le
débat entre les fans de l'une ou l'autre des méthode dure depuis bien
longtemps maintenant :o)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
70ABFAE2-5B80-4097-BEE9-23D92105534E@microsoft.com...
Salut Jonathan,
J'espere que ta passé de bonne vacance :o)
Alors, pour migrer je n'utilise plus ta methode mais celle prodigué par
microsoft qui a mon sens est bcp plus simple, ce qui m'etonne c'est
cette
différence ?
En gros je me saire juste du CD 2003 pour la mise a jour alors que ta
methode nécéssite une mise en place beaucoup plus large, peut tu me
dire
pourquoi, si il y a des truc qui ne vont pas passer avec l'autre
methode ?
Merci et A +.
Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
oui, ceux qui sont sur l'ancien domaine travaillent sur l'ancien. Ceux qui
Et ceux qui sont connectés avec (session verrouillé) reste t'il connecté ?
En fait, tout dépend du moment de la migration. Tant que tu ne fais pas de
Vi c'est sur le redémarrage est toujours dur, mais une fois reparti ca va
lol.
Le plus drole c'est que j'ai pensé aux question que je pouvais te poser a
mon retour lol.
Sinon je vais au plus simple, et en fonction de ce que tu me dit.
Autre chose, (avec la premiere méthode, plus simple en gros => A):
Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
Et ceux qui sont connectés avec (session vérouillé) reste t'il connecté ?
J'ai fait pas mal de test mais pas celui la !
Merci :o)Salut Reno,
les vacances se sont bien passées, mais dur de se remettre dans le bain
après :)
Quelle méthode prodiguée utilise tu? je suppose que tu parle de la
migration
en place où tu met à jour un BDC (etc...) Dans ces cas là, pas d'ADMT ou
autre effectivement (par contre tu embarque avec toi les vieilles DLL et
tous les vieux trucs NT4).
"Ma" méthode (donc avec ADMT) consiste en une restructuration. Elle est
plus
longue effectivement, mais permet de démarrer avec un domaine tout
propre,
et autorise la rationalisation de X domaine vers 1 seul.
Je te rassure, elle est aussi prodiguée par MS, simplement l'optique et
les
champs à englober ne sont pas les mêmes.
Fondamentalement, tu ne dois pas avoir de problèmes avec la méthode du CD
si
tu n'as qu'un seul domaine, et que tu n'es pas inquiété par le fait de
partir sur un domaine vierge puis alimenté par ADMT. Après, je te rassure
le
débat entre les fans de l'une ou l'autre des méthode dure depuis bien
longtemps maintenant :o)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Salut Jonathan,
J'espere que ta passé de bonne vacance :o)
Alors, pour migrer je n'utilise plus ta methode mais celle prodigué par
microsoft qui a mon sens est bcp plus simple, ce qui m'etonne c'est
cette
différence ?
En gros je me saire juste du CD 2003 pour la mise a jour alors que ta
methode nécéssite une mise en place beaucoup plus large, peut tu me
dire
pourquoi, si il y a des truc qui ne vont pas passer avec l'autre
methode ?
Merci et A +.
j'envahi tellement tes nuits pour que tu penses aux questions à me poser au
retour? :)
Pour reprendre tes questions :Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
oui, ceux qui sont sur l'ancien domaine travaillent sur l'ancien. Ceux qui
sont sur le nouveau accèdent toujours à l'ancien en passant par la fonction
Sid history.Et ceux qui sont connectés avec (session verrouillé) reste t'il connecté ?
En fait, tout dépend du moment de la migration. Tant que tu ne fais pas de
translation de sécurité, il n'y a pas de problèmes.
En revanche, la translation devant passer sur les fichiers des
postes/serveurs pour modifier les Acl, ceux qui sont ouverts ne pourront pas
être modifiés (une trace reste dans les fichiers de log)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Vi c'est sur le redémarrage est toujours dur, mais une fois reparti ca va
lol.
Le plus drole c'est que j'ai pensé aux question que je pouvais te poser a
mon retour lol.
Sinon je vais au plus simple, et en fonction de ce que tu me dit.
Autre chose, (avec la premiere méthode, plus simple en gros => A):
Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
Et ceux qui sont connectés avec (session vérouillé) reste t'il connecté ?
J'ai fait pas mal de test mais pas celui la !
Merci :o)Salut Reno,
les vacances se sont bien passées, mais dur de se remettre dans le bain
après :)
Quelle méthode prodiguée utilise tu? je suppose que tu parle de la
migration
en place où tu met à jour un BDC (etc...) Dans ces cas là, pas d'ADMT ou
autre effectivement (par contre tu embarque avec toi les vieilles DLL et
tous les vieux trucs NT4).
"Ma" méthode (donc avec ADMT) consiste en une restructuration. Elle est
plus
longue effectivement, mais permet de démarrer avec un domaine tout
propre,
et autorise la rationalisation de X domaine vers 1 seul.
Je te rassure, elle est aussi prodiguée par MS, simplement l'optique et
les
champs à englober ne sont pas les mêmes.
Fondamentalement, tu ne dois pas avoir de problèmes avec la méthode du CD
si
tu n'as qu'un seul domaine, et que tu n'es pas inquiété par le fait de
partir sur un domaine vierge puis alimenté par ADMT. Après, je te rassure
le
débat entre les fans de l'une ou l'autre des méthode dure depuis bien
longtemps maintenant :o)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Salut Jonathan,
J'espere que ta passé de bonne vacance :o)
Alors, pour migrer je n'utilise plus ta methode mais celle prodigué par
microsoft qui a mon sens est bcp plus simple, ce qui m'etonne c'est
cette
différence ?
En gros je me saire juste du CD 2003 pour la mise a jour alors que ta
methode nécéssite une mise en place beaucoup plus large, peut tu me
dire
pourquoi, si il y a des truc qui ne vont pas passer avec l'autre
methode ?
Merci et A +.
j'envahi tellement tes nuits pour que tu penses aux questions à me poser au
retour? :)
Pour reprendre tes questions :
Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
oui, ceux qui sont sur l'ancien domaine travaillent sur l'ancien. Ceux qui
sont sur le nouveau accèdent toujours à l'ancien en passant par la fonction
Sid history.
Et ceux qui sont connectés avec (session verrouillé) reste t'il connecté ?
En fait, tout dépend du moment de la migration. Tant que tu ne fais pas de
translation de sécurité, il n'y a pas de problèmes.
En revanche, la translation devant passer sur les fichiers des
postes/serveurs pour modifier les Acl, ceux qui sont ouverts ne pourront pas
être modifiés (une trace reste dans les fichiers de log)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
D41ABF55-8586-481A-9C8A-8AE24B596461@microsoft.com...
Vi c'est sur le redémarrage est toujours dur, mais une fois reparti ca va
lol.
Le plus drole c'est que j'ai pensé aux question que je pouvais te poser a
mon retour lol.
Sinon je vais au plus simple, et en fonction de ce que tu me dit.
Autre chose, (avec la premiere méthode, plus simple en gros => A):
Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
Et ceux qui sont connectés avec (session vérouillé) reste t'il connecté ?
J'ai fait pas mal de test mais pas celui la !
Merci :o)
Salut Reno,
les vacances se sont bien passées, mais dur de se remettre dans le bain
après :)
Quelle méthode prodiguée utilise tu? je suppose que tu parle de la
migration
en place où tu met à jour un BDC (etc...) Dans ces cas là, pas d'ADMT ou
autre effectivement (par contre tu embarque avec toi les vieilles DLL et
tous les vieux trucs NT4).
"Ma" méthode (donc avec ADMT) consiste en une restructuration. Elle est
plus
longue effectivement, mais permet de démarrer avec un domaine tout
propre,
et autorise la rationalisation de X domaine vers 1 seul.
Je te rassure, elle est aussi prodiguée par MS, simplement l'optique et
les
champs à englober ne sont pas les mêmes.
Fondamentalement, tu ne dois pas avoir de problèmes avec la méthode du CD
si
tu n'as qu'un seul domaine, et que tu n'es pas inquiété par le fait de
partir sur un domaine vierge puis alimenté par ADMT. Après, je te rassure
le
débat entre les fans de l'une ou l'autre des méthode dure depuis bien
longtemps maintenant :o)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
70ABFAE2-5B80-4097-BEE9-23D92105534E@microsoft.com...
Salut Jonathan,
J'espere que ta passé de bonne vacance :o)
Alors, pour migrer je n'utilise plus ta methode mais celle prodigué par
microsoft qui a mon sens est bcp plus simple, ce qui m'etonne c'est
cette
différence ?
En gros je me saire juste du CD 2003 pour la mise a jour alors que ta
methode nécéssite une mise en place beaucoup plus large, peut tu me
dire
pourquoi, si il y a des truc qui ne vont pas passer avec l'autre
methode ?
Merci et A +.
j'envahi tellement tes nuits pour que tu penses aux questions à me poser au
retour? :)
Pour reprendre tes questions :Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
oui, ceux qui sont sur l'ancien domaine travaillent sur l'ancien. Ceux qui
sont sur le nouveau accèdent toujours à l'ancien en passant par la fonction
Sid history.Et ceux qui sont connectés avec (session verrouillé) reste t'il connecté ?
En fait, tout dépend du moment de la migration. Tant que tu ne fais pas de
translation de sécurité, il n'y a pas de problèmes.
En revanche, la translation devant passer sur les fichiers des
postes/serveurs pour modifier les Acl, ceux qui sont ouverts ne pourront pas
être modifiés (une trace reste dans les fichiers de log)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Vi c'est sur le redémarrage est toujours dur, mais une fois reparti ca va
lol.
Le plus drole c'est que j'ai pensé aux question que je pouvais te poser a
mon retour lol.
Sinon je vais au plus simple, et en fonction de ce que tu me dit.
Autre chose, (avec la premiere méthode, plus simple en gros => A):
Pendant la migration les utilisateurs peuvent ils toujours ce connecter au
domaine ?
Et ceux qui sont connectés avec (session vérouillé) reste t'il connecté ?
J'ai fait pas mal de test mais pas celui la !
Merci :o)Salut Reno,
les vacances se sont bien passées, mais dur de se remettre dans le bain
après :)
Quelle méthode prodiguée utilise tu? je suppose que tu parle de la
migration
en place où tu met à jour un BDC (etc...) Dans ces cas là, pas d'ADMT ou
autre effectivement (par contre tu embarque avec toi les vieilles DLL et
tous les vieux trucs NT4).
"Ma" méthode (donc avec ADMT) consiste en une restructuration. Elle est
plus
longue effectivement, mais permet de démarrer avec un domaine tout
propre,
et autorise la rationalisation de X domaine vers 1 seul.
Je te rassure, elle est aussi prodiguée par MS, simplement l'optique et
les
champs à englober ne sont pas les mêmes.
Fondamentalement, tu ne dois pas avoir de problèmes avec la méthode du CD
si
tu n'as qu'un seul domaine, et que tu n'es pas inquiété par le fait de
partir sur un domaine vierge puis alimenté par ADMT. Après, je te rassure
le
débat entre les fans de l'une ou l'autre des méthode dure depuis bien
longtemps maintenant :o)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Salut Jonathan,
J'espere que ta passé de bonne vacance :o)
Alors, pour migrer je n'utilise plus ta methode mais celle prodigué par
microsoft qui a mon sens est bcp plus simple, ce qui m'etonne c'est
cette
différence ?
En gros je me saire juste du CD 2003 pour la mise a jour alors que ta
methode nécéssite une mise en place beaucoup plus large, peut tu me
dire
pourquoi, si il y a des truc qui ne vont pas passer avec l'autre
methode ?
Merci et A +.
oki merci :o)
Bon Week-End :o)
oki merci :o)
Bon Week-End :o)
oki merci :o)
Bon Week-End :o)
Pas de soucis chef,
Vu l'heure qu'il est.... à tout à l'heure ;)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:oki merci :o)
Bon Week-End :o)
Pas de soucis chef,
Vu l'heure qu'il est.... à tout à l'heure ;)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
B71FE5AE-7E2A-4648-92D9-E9AAB4376DD6@microsoft.com...
oki merci :o)
Bon Week-End :o)
Pas de soucis chef,
Vu l'heure qu'il est.... à tout à l'heure ;)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:oki merci :o)
Bon Week-End :o)
Kikoo Jonathan :o)
Peut tu m'en dire un peu plus sur la translation de sécurité ?
Celle ci n'est faite seulement qu'avec ADMT ?
Merci encore :o)
Kikoo Jonathan :o)
Peut tu m'en dire un peu plus sur la translation de sécurité ?
Celle ci n'est faite seulement qu'avec ADMT ?
Merci encore :o)
Kikoo Jonathan :o)
Peut tu m'en dire un peu plus sur la translation de sécurité ?
Celle ci n'est faite seulement qu'avec ADMT ?
Merci encore :o)
Hello,
tout dépend de ce que tu appel "qu'avec". Tous les outils de migration
corrects savent le gérer (quest, NetIQ...)
En revanche, si tu cherche un script ou assimilé qui puisse le faire, je ne
suis pas sur que tu puisse en trouver un (du moins pas supporté)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Kikoo Jonathan :o)
Peut tu m'en dire un peu plus sur la translation de sécurité ?
Celle ci n'est faite seulement qu'avec ADMT ?
Merci encore :o)
Hello,
tout dépend de ce que tu appel "qu'avec". Tous les outils de migration
corrects savent le gérer (quest, NetIQ...)
En revanche, si tu cherche un script ou assimilé qui puisse le faire, je ne
suis pas sur que tu puisse en trouver un (du moins pas supporté)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
08E5F156-D1D0-465F-B102-FA95A7587479@microsoft.com...
Kikoo Jonathan :o)
Peut tu m'en dire un peu plus sur la translation de sécurité ?
Celle ci n'est faite seulement qu'avec ADMT ?
Merci encore :o)
Hello,
tout dépend de ce que tu appel "qu'avec". Tous les outils de migration
corrects savent le gérer (quest, NetIQ...)
En revanche, si tu cherche un script ou assimilé qui puisse le faire, je ne
suis pas sur que tu puisse en trouver un (du moins pas supporté)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Kikoo Jonathan :o)
Peut tu m'en dire un peu plus sur la translation de sécurité ?
Celle ci n'est faite seulement qu'avec ADMT ?
Merci encore :o)
Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
d'accord, avec la méthode 1 donc.
Oui, n'es crainte, les Sid seront migrés dans la foulée :)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
2E90F94F-2D55-4807-A9C9-9103E41C8091@microsoft.com...
Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
d'accord, avec la méthode 1 donc.
Oui, n'es crainte, les Sid seront migrés dans la foulée :)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
2E90F94F-2D55-4807-A9C9-9103E41C8091@microsoft.com...
Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
d'accord, avec la méthode 1 donc.
Oui, n'es crainte, les Sid seront migrés dans la foulée :)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
Seulement le pb dans cette histoire c'est apparemment le transfert des
autres
rôles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Tu as plus d'informations sur ce point spécifique ?
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
Change de formateur! Plaisanterie à part, je ne comprends pas bien cette
Salut Jonathan :o)
Je viens de suivre une formation AD 2003 et apparement Le plan de
migration
que j'avais etabli n'est pas bon:
But de la manip: Migration des DC NT vers 2003 Server dans le meme
domaine.
SOLO : PDC (Actuelle).
LEIA : BDC (Actuelle).
SRVMIGR : BDC supplémentaire servant a la migration.
PS: (Impossibilité d'installer NT sur les nouveaux serveurs, donc passage
obligatoire sur une machine intermédiere; Le nom du PDC : "SOLO" doit etre
gardé ainsi que tte les autres config de ce serveur)
=> plan de migration:
1) Ajout de SRVMIGR en BDC pour récupérer: Base SAM et enregistrements DNS
et WINS.
2) Le PDC SOLO bascule en BDC
3) Le BDC SRVMIGR bascule en PDC
4) Migration de SRVMIGR en 2003 AD
5) Arret de SOLO (NT)
6) Arret de LEIA (NT)
7) Réinstallation de SOLO et LEIA sur des serveurs plus performant en
2003.
Et Reconnection de SOLO et LEIA (Serveur 2003)
8) Installation d'AD sur SOLO et LEIA
9) Transfert du role PDC de SRVMIGR -> SOLO
10) Arret de SRVMIGR
Seulement le pb dans cette histoire c'est apparement le transfert des
autres
roles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
PB si j'utilise la méthode avec ADMT:
Les 2 PDC (Source et Destination) sont connecté en meme temp donc ne
peuvent
avoir le meme nom.
Comment puis je faire, j'ai l'impréssion d'etre coincé.
Merci :o)"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
d'accord, avec la méthode 1 donc.
Oui, n'es crainte, les Sid seront migrés dans la foulée :)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
Seulement le pb dans cette histoire c'est apparemment le transfert des
autres
rôles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Tu as plus d'informations sur ce point spécifique ?
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
Change de formateur! Plaisanterie à part, je ne comprends pas bien cette
Salut Jonathan :o)
Je viens de suivre une formation AD 2003 et apparement Le plan de
migration
que j'avais etabli n'est pas bon:
But de la manip: Migration des DC NT vers 2003 Server dans le meme
domaine.
SOLO : PDC (Actuelle).
LEIA : BDC (Actuelle).
SRVMIGR : BDC supplémentaire servant a la migration.
PS: (Impossibilité d'installer NT sur les nouveaux serveurs, donc passage
obligatoire sur une machine intermédiere; Le nom du PDC : "SOLO" doit etre
gardé ainsi que tte les autres config de ce serveur)
=> plan de migration:
1) Ajout de SRVMIGR en BDC pour récupérer: Base SAM et enregistrements DNS
et WINS.
2) Le PDC SOLO bascule en BDC
3) Le BDC SRVMIGR bascule en PDC
4) Migration de SRVMIGR en 2003 AD
5) Arret de SOLO (NT)
6) Arret de LEIA (NT)
7) Réinstallation de SOLO et LEIA sur des serveurs plus performant en
2003.
Et Reconnection de SOLO et LEIA (Serveur 2003)
8) Installation d'AD sur SOLO et LEIA
9) Transfert du role PDC de SRVMIGR -> SOLO
10) Arret de SRVMIGR
Seulement le pb dans cette histoire c'est apparement le transfert des
autres
roles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
PB si j'utilise la méthode avec ADMT:
Les 2 PDC (Source et Destination) sont connecté en meme temp donc ne
peuvent
avoir le meme nom.
Comment puis je faire, j'ai l'impréssion d'etre coincé.
Merci :o)
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
2E90F94F-2D55-4807-A9C9-9103E41C8091@microsoft.com...
Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
d'accord, avec la méthode 1 donc.
Oui, n'es crainte, les Sid seront migrés dans la foulée :)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
2E90F94F-2D55-4807-A9C9-9103E41C8091@microsoft.com...
Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
Seulement le pb dans cette histoire c'est apparemment le transfert des
autres
rôles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Tu as plus d'informations sur ce point spécifique ?
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
Change de formateur! Plaisanterie à part, je ne comprends pas bien cette
Salut Jonathan :o)
Je viens de suivre une formation AD 2003 et apparement Le plan de
migration
que j'avais etabli n'est pas bon:
But de la manip: Migration des DC NT vers 2003 Server dans le meme
domaine.
SOLO : PDC (Actuelle).
LEIA : BDC (Actuelle).
SRVMIGR : BDC supplémentaire servant a la migration.
PS: (Impossibilité d'installer NT sur les nouveaux serveurs, donc passage
obligatoire sur une machine intermédiere; Le nom du PDC : "SOLO" doit etre
gardé ainsi que tte les autres config de ce serveur)
=> plan de migration:
1) Ajout de SRVMIGR en BDC pour récupérer: Base SAM et enregistrements DNS
et WINS.
2) Le PDC SOLO bascule en BDC
3) Le BDC SRVMIGR bascule en PDC
4) Migration de SRVMIGR en 2003 AD
5) Arret de SOLO (NT)
6) Arret de LEIA (NT)
7) Réinstallation de SOLO et LEIA sur des serveurs plus performant en
2003.
Et Reconnection de SOLO et LEIA (Serveur 2003)
8) Installation d'AD sur SOLO et LEIA
9) Transfert du role PDC de SRVMIGR -> SOLO
10) Arret de SRVMIGR
Seulement le pb dans cette histoire c'est apparement le transfert des
autres
roles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
PB si j'utilise la méthode avec ADMT:
Les 2 PDC (Source et Destination) sont connecté en meme temp donc ne
peuvent
avoir le meme nom.
Comment puis je faire, j'ai l'impréssion d'etre coincé.
Merci :o)"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
d'accord, avec la méthode 1 donc.
Oui, n'es crainte, les Sid seront migrés dans la foulée :)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
Bonjour Reno,
en suivant le plan de migration n°1 (puisque tu ne désire pas restructurer
ton domaine vers un nouveau), tu peux choisir deux manières :
I- isolation du PDC, travail sur le BDC
1) Ajout de SRVMIGR en BDC pour récupérer: Base SAM et enregistrements DNS
et WINS.
2) isolation de SRVMIGR sur un réseau, afin qu'il ne puisse rien emettre
vers SOLO
3) promotion de SRVMIGR en PDC dans son coin
4) Migration en 2003 AD, éventuelles corrections quant aux GPO ou
permissions NTFS qui peuvent survenir après une migration in-place (google
est ton ami)
5) sur ce réseau isolé, ajout de machines du "vrai" domaine, afin de
vérifier les authentifications de différents utilisateurs, la création et
application de GPO, la validation de comptes ordinateurs.....
-> tu remarquera que jusqu'à maintenant tu as 2 domaines, qui pourtant sont
les mêmes. Ceci te permet pour le moment une continuité de service et éviter
les catastrophes. Maintenant le timing va être précis.
5) on débranche SOLO du domaine PUIS pour y coller SRVMIGR à la place
6) mis à part les ressources de solo qui ne sont pas disponibles, le reste
du domaine doit être accessible, si ce n'est peut être des messages
d'erreurs du fait de BDC NT dans un domaine 2003 natif, n'y prête pas
attention pour le moment.
7) upgrade de SOLO en 2003 (toujours dans son coin) puis rétrogradation en
serveur autonome OU
7') Réinstallation de SOLO en 2003 et ajout au domaine
8) mise à jour du BDC LEIA en 2003 puis rétrogradation en serveur membre
9) Post migration : transfert des rôles FSMO et GC
II- isolation d'un BDC (au cas où), travail sur le PDC
ici :
http://www.microsoft.com/downloads/details.aspx?FamilyIDé2cf6a0-76f0-4e25-8de0-19544062a6e6&DisplayLang=en.
Plus spécifiquement là :
http://www.microsoft.com/downloads/info.aspx?naF&p=3&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyIdé2cf6a0-76f0-4e25-8de0-19544062a6e6&u=http%3a%2f%2fdownload.microsoft.com%2fdownload%2fd%2fa%2f7%2fda767448-6875-489c-96e6-2003e036de6d%2f03_Chapter_2_NT4MigAD.docSeulement le pb dans cette histoire c'est apparemment le transfert des
autres
rôles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Tu as plus d'informations sur ce point spécifique ?Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
Change de formateur! Plaisanterie à part, je ne comprends pas bien cette
clause secrète et mystique qui empêcherait un domaine 2003 de fonctionner si
on supprime le premier DC. A le croire, il faudrait donc croiser les doigts
afin que le contrôleur ne tombe jamais en panne... pas très réaliste tout
ça.
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Salut Jonathan :o)
Je viens de suivre une formation AD 2003 et apparement Le plan de
migration
que j'avais etabli n'est pas bon:
But de la manip: Migration des DC NT vers 2003 Server dans le meme
domaine.
SOLO : PDC (Actuelle).
LEIA : BDC (Actuelle).
SRVMIGR : BDC supplémentaire servant a la migration.
PS: (Impossibilité d'installer NT sur les nouveaux serveurs, donc passage
obligatoire sur une machine intermédiere; Le nom du PDC : "SOLO" doit etre
gardé ainsi que tte les autres config de ce serveur)
=> plan de migration:
1) Ajout de SRVMIGR en BDC pour récupérer: Base SAM et enregistrements DNS
et WINS.
2) Le PDC SOLO bascule en BDC
3) Le BDC SRVMIGR bascule en PDC
4) Migration de SRVMIGR en 2003 AD
5) Arret de SOLO (NT)
6) Arret de LEIA (NT)
7) Réinstallation de SOLO et LEIA sur des serveurs plus performant en
2003.
Et Reconnection de SOLO et LEIA (Serveur 2003)
8) Installation d'AD sur SOLO et LEIA
9) Transfert du role PDC de SRVMIGR -> SOLO
10) Arret de SRVMIGR
Seulement le pb dans cette histoire c'est apparement le transfert des
autres
roles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
PB si j'utilise la méthode avec ADMT:
Les 2 PDC (Source et Destination) sont connecté en meme temp donc ne
peuvent
avoir le meme nom.
Comment puis je faire, j'ai l'impréssion d'etre coincé.
Merci :o)"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
d'accord, avec la méthode 1 donc.
Oui, n'es crainte, les Sid seront migrés dans la foulée :)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
Bonjour Reno,
en suivant le plan de migration n°1 (puisque tu ne désire pas restructurer
ton domaine vers un nouveau), tu peux choisir deux manières :
I- isolation du PDC, travail sur le BDC
1) Ajout de SRVMIGR en BDC pour récupérer: Base SAM et enregistrements DNS
et WINS.
2) isolation de SRVMIGR sur un réseau, afin qu'il ne puisse rien emettre
vers SOLO
3) promotion de SRVMIGR en PDC dans son coin
4) Migration en 2003 AD, éventuelles corrections quant aux GPO ou
permissions NTFS qui peuvent survenir après une migration in-place (google
est ton ami)
5) sur ce réseau isolé, ajout de machines du "vrai" domaine, afin de
vérifier les authentifications de différents utilisateurs, la création et
application de GPO, la validation de comptes ordinateurs.....
-> tu remarquera que jusqu'à maintenant tu as 2 domaines, qui pourtant sont
les mêmes. Ceci te permet pour le moment une continuité de service et éviter
les catastrophes. Maintenant le timing va être précis.
5) on débranche SOLO du domaine PUIS pour y coller SRVMIGR à la place
6) mis à part les ressources de solo qui ne sont pas disponibles, le reste
du domaine doit être accessible, si ce n'est peut être des messages
d'erreurs du fait de BDC NT dans un domaine 2003 natif, n'y prête pas
attention pour le moment.
7) upgrade de SOLO en 2003 (toujours dans son coin) puis rétrogradation en
serveur autonome OU
7') Réinstallation de SOLO en 2003 et ajout au domaine
8) mise à jour du BDC LEIA en 2003 puis rétrogradation en serveur membre
9) Post migration : transfert des rôles FSMO et GC
II- isolation d'un BDC (au cas où), travail sur le PDC
ici :
http://www.microsoft.com/downloads/details.aspx?FamilyIDé2cf6a0-76f0-4e25-8de0-19544062a6e6&DisplayLang=en.
Plus spécifiquement là :
http://www.microsoft.com/downloads/info.aspx?naF&p=3&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyIdé2cf6a0-76f0-4e25-8de0-19544062a6e6&u=http%3a%2f%2fdownload.microsoft.com%2fdownload%2fd%2fa%2f7%2fda767448-6875-489c-96e6-2003e036de6d%2f03_Chapter_2_NT4MigAD.doc
Seulement le pb dans cette histoire c'est apparemment le transfert des
autres
rôles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Tu as plus d'informations sur ce point spécifique ?
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
Change de formateur! Plaisanterie à part, je ne comprends pas bien cette
clause secrète et mystique qui empêcherait un domaine 2003 de fonctionner si
on supprime le premier DC. A le croire, il faudrait donc croiser les doigts
afin que le contrôleur ne tombe jamais en panne... pas très réaliste tout
ça.
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
AE3C4341-3A5E-4C0F-A410-4B0D065B44F4@microsoft.com...
Salut Jonathan :o)
Je viens de suivre une formation AD 2003 et apparement Le plan de
migration
que j'avais etabli n'est pas bon:
But de la manip: Migration des DC NT vers 2003 Server dans le meme
domaine.
SOLO : PDC (Actuelle).
LEIA : BDC (Actuelle).
SRVMIGR : BDC supplémentaire servant a la migration.
PS: (Impossibilité d'installer NT sur les nouveaux serveurs, donc passage
obligatoire sur une machine intermédiere; Le nom du PDC : "SOLO" doit etre
gardé ainsi que tte les autres config de ce serveur)
=> plan de migration:
1) Ajout de SRVMIGR en BDC pour récupérer: Base SAM et enregistrements DNS
et WINS.
2) Le PDC SOLO bascule en BDC
3) Le BDC SRVMIGR bascule en PDC
4) Migration de SRVMIGR en 2003 AD
5) Arret de SOLO (NT)
6) Arret de LEIA (NT)
7) Réinstallation de SOLO et LEIA sur des serveurs plus performant en
2003.
Et Reconnection de SOLO et LEIA (Serveur 2003)
8) Installation d'AD sur SOLO et LEIA
9) Transfert du role PDC de SRVMIGR -> SOLO
10) Arret de SRVMIGR
Seulement le pb dans cette histoire c'est apparement le transfert des
autres
roles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
PB si j'utilise la méthode avec ADMT:
Les 2 PDC (Source et Destination) sont connecté en meme temp donc ne
peuvent
avoir le meme nom.
Comment puis je faire, j'ai l'impréssion d'etre coincé.
Merci :o)
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
2E90F94F-2D55-4807-A9C9-9103E41C8091@microsoft.com...
Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
d'accord, avec la méthode 1 donc.
Oui, n'es crainte, les Sid seront migrés dans la foulée :)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" <reno@discussions.microsoft.com> a écrit dans le message de news:
2E90F94F-2D55-4807-A9C9-9103E41C8091@microsoft.com...
Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
Bonjour Reno,
en suivant le plan de migration n°1 (puisque tu ne désire pas restructurer
ton domaine vers un nouveau), tu peux choisir deux manières :
I- isolation du PDC, travail sur le BDC
1) Ajout de SRVMIGR en BDC pour récupérer: Base SAM et enregistrements DNS
et WINS.
2) isolation de SRVMIGR sur un réseau, afin qu'il ne puisse rien emettre
vers SOLO
3) promotion de SRVMIGR en PDC dans son coin
4) Migration en 2003 AD, éventuelles corrections quant aux GPO ou
permissions NTFS qui peuvent survenir après une migration in-place (google
est ton ami)
5) sur ce réseau isolé, ajout de machines du "vrai" domaine, afin de
vérifier les authentifications de différents utilisateurs, la création et
application de GPO, la validation de comptes ordinateurs.....
-> tu remarquera que jusqu'à maintenant tu as 2 domaines, qui pourtant sont
les mêmes. Ceci te permet pour le moment une continuité de service et éviter
les catastrophes. Maintenant le timing va être précis.
5) on débranche SOLO du domaine PUIS pour y coller SRVMIGR à la place
6) mis à part les ressources de solo qui ne sont pas disponibles, le reste
du domaine doit être accessible, si ce n'est peut être des messages
d'erreurs du fait de BDC NT dans un domaine 2003 natif, n'y prête pas
attention pour le moment.
7) upgrade de SOLO en 2003 (toujours dans son coin) puis rétrogradation en
serveur autonome OU
7') Réinstallation de SOLO en 2003 et ajout au domaine
8) mise à jour du BDC LEIA en 2003 puis rétrogradation en serveur membre
9) Post migration : transfert des rôles FSMO et GC
II- isolation d'un BDC (au cas où), travail sur le PDC
ici :
http://www.microsoft.com/downloads/details.aspx?FamilyIDé2cf6a0-76f0-4e25-8de0-19544062a6e6&DisplayLang=en.
Plus spécifiquement là :
http://www.microsoft.com/downloads/info.aspx?naF&p=3&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyIdé2cf6a0-76f0-4e25-8de0-19544062a6e6&u=http%3a%2f%2fdownload.microsoft.com%2fdownload%2fd%2fa%2f7%2fda767448-6875-489c-96e6-2003e036de6d%2f03_Chapter_2_NT4MigAD.docSeulement le pb dans cette histoire c'est apparemment le transfert des
autres
rôles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Tu as plus d'informations sur ce point spécifique ?Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
Change de formateur! Plaisanterie à part, je ne comprends pas bien cette
clause secrète et mystique qui empêcherait un domaine 2003 de fonctionner si
on supprime le premier DC. A le croire, il faudrait donc croiser les doigts
afin que le contrôleur ne tombe jamais en panne... pas très réaliste tout
ça.
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Salut Jonathan :o)
Je viens de suivre une formation AD 2003 et apparement Le plan de
migration
que j'avais etabli n'est pas bon:
But de la manip: Migration des DC NT vers 2003 Server dans le meme
domaine.
SOLO : PDC (Actuelle).
LEIA : BDC (Actuelle).
SRVMIGR : BDC supplémentaire servant a la migration.
PS: (Impossibilité d'installer NT sur les nouveaux serveurs, donc passage
obligatoire sur une machine intermédiere; Le nom du PDC : "SOLO" doit etre
gardé ainsi que tte les autres config de ce serveur)
=> plan de migration:
1) Ajout de SRVMIGR en BDC pour récupérer: Base SAM et enregistrements DNS
et WINS.
2) Le PDC SOLO bascule en BDC
3) Le BDC SRVMIGR bascule en PDC
4) Migration de SRVMIGR en 2003 AD
5) Arret de SOLO (NT)
6) Arret de LEIA (NT)
7) Réinstallation de SOLO et LEIA sur des serveurs plus performant en
2003.
Et Reconnection de SOLO et LEIA (Serveur 2003)
8) Installation d'AD sur SOLO et LEIA
9) Transfert du role PDC de SRVMIGR -> SOLO
10) Arret de SRVMIGR
Seulement le pb dans cette histoire c'est apparement le transfert des
autres
roles: Schema etc... via NTDSUTIL qui peut créer
une perte de données et un ralentissement du PDC.
Le formateur ma bien précisé que le premier DC 2003 installé ne doit pas
etre supprimé ou remplacé.
PB si j'utilise la méthode avec ADMT:
Les 2 PDC (Source et Destination) sont connecté en meme temp donc ne
peuvent
avoir le meme nom.
Comment puis je faire, j'ai l'impréssion d'etre coincé.
Merci :o)"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
d'accord, avec la méthode 1 donc.
Oui, n'es crainte, les Sid seront migrés dans la foulée :)
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"reno" a écrit dans le message de news:Non ce n'etait pas ce que je voulais dire.
En faite je voulais savoir si en métant a jour les serveur ce processus
etait automatique ou pas ?
Merci et bonne fin de journée :o)
