J'ai deux contrôleurs de domaine en Windows 2003R2, sur l'un tourne un
dhcp, adresses dynamiques et réservations.
Ma question est comment peut-on synchroniser un 2e dhcp sur le 2e
contrôleur?
Pour l'instant ce que je fais c'est que tous les soirs j'exporte par
script les paramètres des réservations du dhcp actif vers l'autre
contrôleur, me disant qu'en cas de problème je n'aurai qu'à importer ces
paramètres et activer une 2e plage dynamique disjointe de la première.
A priori ça devrait marcher mais le pb c'est que je dois être là en cas
de problème. Quelle autre solution pour que ça marche sans rien avoir à
faire?
"Youri Ligotmi" a écrit dans le message de news:496cebba$0$20324$
Bonjour à tous
J'ai deux contrôleurs de domaine en Windows 2003R2, sur l'un tourne un dhcp, adresses dynamiques et réservations. Ma question est comment peut-on synchroniser un 2e dhcp sur le 2e contrôleur? Pour l'instant ce que je fais c'est que tous les soirs j'exporte par script les paramètres des réservations du dhcp actif vers l'autre contrôleur, me disant qu'en cas de problème je n'aurai qu'à importer ces paramètres et activer une 2e plage dynamique disjointe de la première. A priori ça devrait marcher mais le pb c'est que je dois être là en cas de problème. Quelle autre solution pour que ça marche sans rien avoir à faire?
merci d'avance
YL
Bonsoir,
une solution consiste à répartir l'étendue DHCP sur les 2 serveurs DHCP, et
garder les 2 serveurs DHCP actifs.
Par exemple, si tu as 100 périphériques DHCP, tu actives de 10 à 109 sur
SRVDHCP1 et 110 à 209 sur le SRVDHCP2.
Donc, si nécessaire, agrandir la taille du réseau utilisé pour couvrir les
besoins.
"Youri Ligotmi" <yl@free.fr.invalid> a écrit dans le message de
news:496cebba$0$20324$426a34cc@news.free.fr...
Bonjour à tous
J'ai deux contrôleurs de domaine en Windows 2003R2, sur l'un tourne un
dhcp, adresses dynamiques et réservations.
Ma question est comment peut-on synchroniser un 2e dhcp sur le 2e
contrôleur?
Pour l'instant ce que je fais c'est que tous les soirs j'exporte par
script les paramètres des réservations du dhcp actif vers l'autre
contrôleur, me disant qu'en cas de problème je n'aurai qu'à importer ces
paramètres et activer une 2e plage dynamique disjointe de la première.
A priori ça devrait marcher mais le pb c'est que je dois être là en cas de
problème. Quelle autre solution pour que ça marche sans rien avoir à
faire?
"Youri Ligotmi" a écrit dans le message de news:496cebba$0$20324$
Bonjour à tous
J'ai deux contrôleurs de domaine en Windows 2003R2, sur l'un tourne un dhcp, adresses dynamiques et réservations. Ma question est comment peut-on synchroniser un 2e dhcp sur le 2e contrôleur? Pour l'instant ce que je fais c'est que tous les soirs j'exporte par script les paramètres des réservations du dhcp actif vers l'autre contrôleur, me disant qu'en cas de problème je n'aurai qu'à importer ces paramètres et activer une 2e plage dynamique disjointe de la première. A priori ça devrait marcher mais le pb c'est que je dois être là en cas de problème. Quelle autre solution pour que ça marche sans rien avoir à faire?
merci d'avance
YL
Lognoul Marc [MVP]
Bonjour,
Ce lien détaille les 3 possibilités les plus communément utilisées: http://technet.microsoft.com/en-us/library/cc776899.aspx. Celle de Thierry y figure.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" wrote in message news:496cebba$0$20324$
Bonjour à tous
J'ai deux contrôleurs de domaine en Windows 2003R2, sur l'un tourne un dhcp, adresses dynamiques et réservations. Ma question est comment peut-on synchroniser un 2e dhcp sur le 2e contrôleur? Pour l'instant ce que je fais c'est que tous les soirs j'exporte par script les paramètres des réservations du dhcp actif vers l'autre contrôleur, me disant qu'en cas de problème je n'aurai qu'à importer ces paramètres et activer une 2e plage dynamique disjointe de la première. A priori ça devrait marcher mais le pb c'est que je dois être là en cas de problème. Quelle autre solution pour que ça marche sans rien avoir à faire?
merci d'avance
YL
Bonjour,
Ce lien détaille les 3 possibilités les plus communément utilisées:
http://technet.microsoft.com/en-us/library/cc776899.aspx. Celle de Thierry y
figure.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" <yl@free.fr.invalid> wrote in message
news:496cebba$0$20324$426a34cc@news.free.fr...
Bonjour à tous
J'ai deux contrôleurs de domaine en Windows 2003R2, sur l'un tourne un
dhcp, adresses dynamiques et réservations.
Ma question est comment peut-on synchroniser un 2e dhcp sur le 2e
contrôleur?
Pour l'instant ce que je fais c'est que tous les soirs j'exporte par
script les paramètres des réservations du dhcp actif vers l'autre
contrôleur, me disant qu'en cas de problème je n'aurai qu'à importer ces
paramètres et activer une 2e plage dynamique disjointe de la première.
A priori ça devrait marcher mais le pb c'est que je dois être là en cas de
problème. Quelle autre solution pour que ça marche sans rien avoir à
faire?
Ce lien détaille les 3 possibilités les plus communément utilisées: http://technet.microsoft.com/en-us/library/cc776899.aspx. Celle de Thierry y figure.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" wrote in message news:496cebba$0$20324$
Bonjour à tous
J'ai deux contrôleurs de domaine en Windows 2003R2, sur l'un tourne un dhcp, adresses dynamiques et réservations. Ma question est comment peut-on synchroniser un 2e dhcp sur le 2e contrôleur? Pour l'instant ce que je fais c'est que tous les soirs j'exporte par script les paramètres des réservations du dhcp actif vers l'autre contrôleur, me disant qu'en cas de problème je n'aurai qu'à importer ces paramètres et activer une 2e plage dynamique disjointe de la première. A priori ça devrait marcher mais le pb c'est que je dois être là en cas de problème. Quelle autre solution pour que ça marche sans rien avoir à faire?
merci d'avance
YL
Youri Ligotmi
Lognoul Marc [MVP] a écrit :
Bonjour,
Ce lien détaille les 3 possibilités les plus communément utilisées: http://technet.microsoft.com/en-us/library/cc776899.aspx. Celle de Thierry y figure.
Merci, j'ai regardé, c'est quand même un peu usine à gaz tout ça. Je me demande pourquoi ils n'ont pas pensé à mettre la base dhcp dans un dfs en réplication.
Lognoul Marc [MVP] a écrit :
Bonjour,
Ce lien détaille les 3 possibilités les plus communément utilisées:
http://technet.microsoft.com/en-us/library/cc776899.aspx. Celle de
Thierry y figure.
Merci, j'ai regardé, c'est quand même un peu usine à gaz tout ça.
Je me demande pourquoi ils n'ont pas pensé à mettre la base dhcp dans un
dfs en réplication.
Ce lien détaille les 3 possibilités les plus communément utilisées: http://technet.microsoft.com/en-us/library/cc776899.aspx. Celle de Thierry y figure.
Merci, j'ai regardé, c'est quand même un peu usine à gaz tout ça. Je me demande pourquoi ils n'ont pas pensé à mettre la base dhcp dans un dfs en réplication.
Lognoul Marc [MVP]
J'adhère complètement à cette remarque, c'est un feedback que j'ai déjà remonter vers le team DHCP.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" wrote in message news:496f5b2d$0$20325$
Lognoul Marc [MVP] a écrit :
Bonjour,
Ce lien détaille les 3 possibilités les plus communément utilisées: http://technet.microsoft.com/en-us/library/cc776899.aspx. Celle de Thierry y figure.
Merci, j'ai regardé, c'est quand même un peu usine à gaz tout ça. Je me demande pourquoi ils n'ont pas pensé à mettre la base dhcp dans un dfs en réplication.
J'adhère complètement à cette remarque, c'est un feedback que j'ai déjà
remonter vers le team DHCP.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" <yl@free.fr.invalid> wrote in message
news:496f5b2d$0$20325$426a74cc@news.free.fr...
Lognoul Marc [MVP] a écrit :
Bonjour,
Ce lien détaille les 3 possibilités les plus communément utilisées:
http://technet.microsoft.com/en-us/library/cc776899.aspx. Celle de
Thierry y figure.
Merci, j'ai regardé, c'est quand même un peu usine à gaz tout ça.
Je me demande pourquoi ils n'ont pas pensé à mettre la base dhcp dans un
dfs en réplication.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" wrote in message news:496f5b2d$0$20325$
Lognoul Marc [MVP] a écrit :
Bonjour,
Ce lien détaille les 3 possibilités les plus communément utilisées: http://technet.microsoft.com/en-us/library/cc776899.aspx. Celle de Thierry y figure.
Merci, j'ai regardé, c'est quand même un peu usine à gaz tout ça. Je me demande pourquoi ils n'ont pas pensé à mettre la base dhcp dans un dfs en réplication.
GG
Bonjour,
Merci, j'ai regardé, c'est quand même un peu usine à gaz tout ça. Je me demande pourquoi ils n'ont pas pensé à mettre la base dhcp dans un dfs en réplication.
Ce n'est pas dans les tables de la loi Internet : les RFC et si il y a migration des DHCP vers des plateformes Unix là pour de bon MS va se faire allumer. Il y a des spécifications dans les RFC qui limitent MS si leurs systèmes se veulent encore respecter les RFC. -- Cordialement. GG. http://forums.sbsfr.org/ un livre sur SBS http://livresbs.sbsfr.org/
Bonjour,
Merci, j'ai regardé, c'est quand même un peu usine à gaz tout ça.
Je me demande pourquoi ils n'ont pas pensé à mettre la base dhcp dans
un dfs en réplication.
Ce n'est pas dans les tables de la loi Internet : les RFC
et si il y a migration des DHCP vers des plateformes Unix
là pour de bon MS va se faire allumer.
Il y a des spécifications dans les RFC qui limitent MS
si leurs systèmes se veulent encore respecter les RFC.
--
Cordialement.
GG.
http://forums.sbsfr.org/
un livre sur SBS http://livresbs.sbsfr.org/
Merci, j'ai regardé, c'est quand même un peu usine à gaz tout ça. Je me demande pourquoi ils n'ont pas pensé à mettre la base dhcp dans un dfs en réplication.
Ce n'est pas dans les tables de la loi Internet : les RFC et si il y a migration des DHCP vers des plateformes Unix là pour de bon MS va se faire allumer. Il y a des spécifications dans les RFC qui limitent MS si leurs systèmes se veulent encore respecter les RFC. -- Cordialement. GG. http://forums.sbsfr.org/ un livre sur SBS http://livresbs.sbsfr.org/
GG
Bonjour,
MS s'est fait descendre pendant des années car ses logiciels étaient propriétaire et qu'ils ne respectaient les RFC, maintenant qu'ils les respectent on ne va pas leur dire de ne pas les respecter. Et DNS et DHCP serveur et client sont assez bien encadrés dans les RFC on ne peut pas faire n'importe quoi.
-- Cordialement. GG. http://forums.sbsfr.org/ un livre sur SBS http://livresbs.sbsfr.org/
Bonjour,
MS s'est fait descendre pendant des années car ses
logiciels étaient propriétaire et qu'ils ne respectaient
les RFC, maintenant qu'ils les respectent on ne va pas
leur dire de ne pas les respecter.
Et DNS et DHCP serveur et client sont assez bien
encadrés dans les RFC on ne peut pas faire n'importe
quoi.
--
Cordialement.
GG.
http://forums.sbsfr.org/
un livre sur SBS http://livresbs.sbsfr.org/
MS s'est fait descendre pendant des années car ses logiciels étaient propriétaire et qu'ils ne respectaient les RFC, maintenant qu'ils les respectent on ne va pas leur dire de ne pas les respecter. Et DNS et DHCP serveur et client sont assez bien encadrés dans les RFC on ne peut pas faire n'importe quoi.
-- Cordialement. GG. http://forums.sbsfr.org/ un livre sur SBS http://livresbs.sbsfr.org/
Youri Ligotmi
GG a écrit :
Bonjour,
MS s'est fait descendre pendant des années car ses logiciels étaient propriétaire et qu'ils ne respectaient les RFC, maintenant qu'ils les respectent on ne va pas leur dire de ne pas les respecter. Et DNS et DHCP serveur et client sont assez bien encadrés dans les RFC on ne peut pas faire n'importe quoi.
Merci pour toutes vos réponses. En réfléchissant à ma remarque (table dhcp dans un dfs) je me dis que ce serait aussi usine à gaz : à chaque requête d'un client le serveur avant de répondre devrait d'abord forcer une réplication, si pendant de temps un ou plusieurs autres serveurs font de même ça deviendrait vite le bordel. Je vais en rester à mon export quotidien avec démarrage manuel du second dhcp en cas d'arrêt du premier (je réfléchis quand même à un démarrage automatique).
GG a écrit :
Bonjour,
MS s'est fait descendre pendant des années car ses
logiciels étaient propriétaire et qu'ils ne respectaient
les RFC, maintenant qu'ils les respectent on ne va pas
leur dire de ne pas les respecter.
Et DNS et DHCP serveur et client sont assez bien
encadrés dans les RFC on ne peut pas faire n'importe
quoi.
Merci pour toutes vos réponses. En réfléchissant à ma remarque (table
dhcp dans un dfs) je me dis que ce serait aussi usine à gaz : à chaque
requête d'un client le serveur avant de répondre devrait d'abord forcer
une réplication, si pendant de temps un ou plusieurs autres serveurs
font de même ça deviendrait vite le bordel.
Je vais en rester à mon export quotidien avec démarrage manuel du second
dhcp en cas d'arrêt du premier (je réfléchis quand même à un démarrage
automatique).
MS s'est fait descendre pendant des années car ses logiciels étaient propriétaire et qu'ils ne respectaient les RFC, maintenant qu'ils les respectent on ne va pas leur dire de ne pas les respecter. Et DNS et DHCP serveur et client sont assez bien encadrés dans les RFC on ne peut pas faire n'importe quoi.
Merci pour toutes vos réponses. En réfléchissant à ma remarque (table dhcp dans un dfs) je me dis que ce serait aussi usine à gaz : à chaque requête d'un client le serveur avant de répondre devrait d'abord forcer une réplication, si pendant de temps un ou plusieurs autres serveurs font de même ça deviendrait vite le bordel. Je vais en rester à mon export quotidien avec démarrage manuel du second dhcp en cas d'arrêt du premier (je réfléchis quand même à un démarrage automatique).
Lognoul Marc [MVP]
Bonjour,
Vous pouvez sans problème utiliser un dump (via netsh) plus fréquent (toutes les 4 heures voire toutes les heures). Sinon, la solution idéale, c'est le clustering... Qui à ma connaissance, est même supporté sous VMWare ESX à partir d'une version récente.
Prudence avec l'import et le démarrage automatique...
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" wrote in message news:4970a16a$0$21380$
GG a écrit :
Bonjour,
MS s'est fait descendre pendant des années car ses logiciels étaient propriétaire et qu'ils ne respectaient les RFC, maintenant qu'ils les respectent on ne va pas leur dire de ne pas les respecter. Et DNS et DHCP serveur et client sont assez bien encadrés dans les RFC on ne peut pas faire n'importe quoi.
Merci pour toutes vos réponses. En réfléchissant à ma remarque (table dhcp dans un dfs) je me dis que ce serait aussi usine à gaz : à chaque requête d'un client le serveur avant de répondre devrait d'abord forcer une réplication, si pendant de temps un ou plusieurs autres serveurs font de même ça deviendrait vite le bordel. Je vais en rester à mon export quotidien avec démarrage manuel du second dhcp en cas d'arrêt du premier (je réfléchis quand même à un démarrage automatique).
Bonjour,
Vous pouvez sans problème utiliser un dump (via netsh) plus fréquent (toutes
les 4 heures voire toutes les heures).
Sinon, la solution idéale, c'est le clustering... Qui à ma connaissance, est
même supporté sous VMWare ESX à partir d'une version récente.
Prudence avec l'import et le démarrage automatique...
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" <yl@free.fr.invalid> wrote in message
news:4970a16a$0$21380$426a74cc@news.free.fr...
GG a écrit :
Bonjour,
MS s'est fait descendre pendant des années car ses
logiciels étaient propriétaire et qu'ils ne respectaient
les RFC, maintenant qu'ils les respectent on ne va pas
leur dire de ne pas les respecter.
Et DNS et DHCP serveur et client sont assez bien
encadrés dans les RFC on ne peut pas faire n'importe
quoi.
Merci pour toutes vos réponses. En réfléchissant à ma remarque (table dhcp
dans un dfs) je me dis que ce serait aussi usine à gaz : à chaque requête
d'un client le serveur avant de répondre devrait d'abord forcer une
réplication, si pendant de temps un ou plusieurs autres serveurs font de
même ça deviendrait vite le bordel.
Je vais en rester à mon export quotidien avec démarrage manuel du second
dhcp en cas d'arrêt du premier (je réfléchis quand même à un démarrage
automatique).
Vous pouvez sans problème utiliser un dump (via netsh) plus fréquent (toutes les 4 heures voire toutes les heures). Sinon, la solution idéale, c'est le clustering... Qui à ma connaissance, est même supporté sous VMWare ESX à partir d'une version récente.
Prudence avec l'import et le démarrage automatique...
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" wrote in message news:4970a16a$0$21380$
GG a écrit :
Bonjour,
MS s'est fait descendre pendant des années car ses logiciels étaient propriétaire et qu'ils ne respectaient les RFC, maintenant qu'ils les respectent on ne va pas leur dire de ne pas les respecter. Et DNS et DHCP serveur et client sont assez bien encadrés dans les RFC on ne peut pas faire n'importe quoi.
Merci pour toutes vos réponses. En réfléchissant à ma remarque (table dhcp dans un dfs) je me dis que ce serait aussi usine à gaz : à chaque requête d'un client le serveur avant de répondre devrait d'abord forcer une réplication, si pendant de temps un ou plusieurs autres serveurs font de même ça deviendrait vite le bordel. Je vais en rester à mon export quotidien avec démarrage manuel du second dhcp en cas d'arrêt du premier (je réfléchis quand même à un démarrage automatique).
Youri Ligotmi
Lognoul Marc [MVP] a écrit :
Bonjour,
Vous pouvez sans problème utiliser un dump (via netsh) plus fréquent (toutes les 4 heures voire toutes les heures). Sinon, la solution idéale, c'est le clustering... Qui à ma connaissance, est même supporté sous VMWare ESX à partir d'une version récente.
Prudence avec l'import et le démarrage automatique...
C'est ce que je fais : un dump avec netsh, c'est vrai que je pourrais le faire plus fréquemment, mais je ne change pas mes réservations aussi souvent, pour ce qui est de l'adressage dynamique, quand je change de serveur je change de plage, pas de risque de conflit. J'hésite avec le démarrage auto, le démarrage manuel permet de vérifier que l'import est correct avant de lancer (et aussi de changer de plage dynamique).
Lognoul Marc [MVP] a écrit :
Bonjour,
Vous pouvez sans problème utiliser un dump (via netsh) plus fréquent
(toutes les 4 heures voire toutes les heures).
Sinon, la solution idéale, c'est le clustering... Qui à ma connaissance,
est même supporté sous VMWare ESX à partir d'une version récente.
Prudence avec l'import et le démarrage automatique...
C'est ce que je fais : un dump avec netsh, c'est vrai que je pourrais le
faire plus fréquemment, mais je ne change pas mes réservations aussi
souvent, pour ce qui est de l'adressage dynamique, quand je change de
serveur je change de plage, pas de risque de conflit.
J'hésite avec le démarrage auto, le démarrage manuel permet de vérifier
que l'import est correct avant de lancer (et aussi de changer de plage
dynamique).
Vous pouvez sans problème utiliser un dump (via netsh) plus fréquent (toutes les 4 heures voire toutes les heures). Sinon, la solution idéale, c'est le clustering... Qui à ma connaissance, est même supporté sous VMWare ESX à partir d'une version récente.
Prudence avec l'import et le démarrage automatique...
C'est ce que je fais : un dump avec netsh, c'est vrai que je pourrais le faire plus fréquemment, mais je ne change pas mes réservations aussi souvent, pour ce qui est de l'adressage dynamique, quand je change de serveur je change de plage, pas de risque de conflit. J'hésite avec le démarrage auto, le démarrage manuel permet de vérifier que l'import est correct avant de lancer (et aussi de changer de plage dynamique).
Lognoul Marc [MVP]
Si vous effectuez un dump complet (configuration + état des leases), le risque de conflit est très faible, soit les leases alloués dans l'interval du dernier backup.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" wrote in message news:4970a5f2$0$20713$
Lognoul Marc [MVP] a écrit :
Bonjour,
Vous pouvez sans problème utiliser un dump (via netsh) plus fréquent (toutes les 4 heures voire toutes les heures). Sinon, la solution idéale, c'est le clustering... Qui à ma connaissance, est même supporté sous VMWare ESX à partir d'une version récente.
Prudence avec l'import et le démarrage automatique...
C'est ce que je fais : un dump avec netsh, c'est vrai que je pourrais le faire plus fréquemment, mais je ne change pas mes réservations aussi souvent, pour ce qui est de l'adressage dynamique, quand je change de serveur je change de plage, pas de risque de conflit. J'hésite avec le démarrage auto, le démarrage manuel permet de vérifier que l'import est correct avant de lancer (et aussi de changer de plage dynamique).
Si vous effectuez un dump complet (configuration + état des leases), le
risque de conflit est très faible, soit les leases alloués dans l'interval
du dernier backup.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" <yl@free.fr.invalid> wrote in message
news:4970a5f2$0$20713$426a74cc@news.free.fr...
Lognoul Marc [MVP] a écrit :
Bonjour,
Vous pouvez sans problème utiliser un dump (via netsh) plus fréquent
(toutes les 4 heures voire toutes les heures).
Sinon, la solution idéale, c'est le clustering... Qui à ma connaissance,
est même supporté sous VMWare ESX à partir d'une version récente.
Prudence avec l'import et le démarrage automatique...
C'est ce que je fais : un dump avec netsh, c'est vrai que je pourrais le
faire plus fréquemment, mais je ne change pas mes réservations aussi
souvent, pour ce qui est de l'adressage dynamique, quand je change de
serveur je change de plage, pas de risque de conflit.
J'hésite avec le démarrage auto, le démarrage manuel permet de vérifier
que l'import est correct avant de lancer (et aussi de changer de plage
dynamique).
Si vous effectuez un dump complet (configuration + état des leases), le risque de conflit est très faible, soit les leases alloués dans l'interval du dernier backup.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Youri Ligotmi" wrote in message news:4970a5f2$0$20713$
Lognoul Marc [MVP] a écrit :
Bonjour,
Vous pouvez sans problème utiliser un dump (via netsh) plus fréquent (toutes les 4 heures voire toutes les heures). Sinon, la solution idéale, c'est le clustering... Qui à ma connaissance, est même supporté sous VMWare ESX à partir d'une version récente.
Prudence avec l'import et le démarrage automatique...
C'est ce que je fais : un dump avec netsh, c'est vrai que je pourrais le faire plus fréquemment, mais je ne change pas mes réservations aussi souvent, pour ce qui est de l'adressage dynamique, quand je change de serveur je change de plage, pas de risque de conflit. J'hésite avec le démarrage auto, le démarrage manuel permet de vérifier que l'import est correct avant de lancer (et aussi de changer de plage dynamique).
