Sujet épineux... Je ne crois pas que "prévoir" des reboots soit une bonne idée. On n'est plus tout à fait à la "belle époque" de NT4 où les drivers d'impression, IIS et autres process bouffaient la mémoire et autres ressources système à tire larigot... Si les performances du serveur se dégradent, il serait bon de vérifier ce qui cause ces problèmes et de s'attaquer à leur résolution plutôt que de rebooter jusqu'à la prochaine fois.
En revanche, prévoir l'application mensuelle des patches de sécurité (en plus de l'application ponctuelle des patches critiques) me paraît de bon aloi, et de toute façon le serveur redémarrera à cette occasion :-).
Jacques
"Thierry DEMAN [MVP]" wrote in message news:
Alni wrote:
Bonjour à tous,
Un 2000 Serveur AD qui assume les roles suivant : -Emulateur PDC -DNS -DHCP -Serveur Exchange
Quelle devrait être la périodicité de reboot ?
Merci.
PIII 1Ghz 640Mo Ram
Salut,
programmer un reboot mensuel (notamment pour Exchange) n'est pas une mauvaise idée.
=> Il vaut mieux un bon reboot planifié (mensuel) qu'un plantage inattendu au plus mauvais moment !
Sujet épineux... Je ne crois pas que "prévoir" des reboots soit une bonne
idée. On n'est plus tout à fait à la "belle époque" de NT4 où les drivers
d'impression, IIS et autres process bouffaient la mémoire et autres
ressources système à tire larigot... Si les performances du serveur se
dégradent, il serait bon de vérifier ce qui cause ces problèmes et de
s'attaquer à leur résolution plutôt que de rebooter jusqu'à la prochaine
fois.
En revanche, prévoir l'application mensuelle des patches de sécurité (en
plus de l'application ponctuelle des patches critiques) me paraît de bon
aloi, et de toute façon le serveur redémarrera à cette occasion :-).
Jacques
"Thierry DEMAN [MVP]" <tdemanNOSPAM@NOSPAMfree.fr> wrote in message
news:eaTuiVw8DHA.3112@tk2msftngp13.phx.gbl...
Alni wrote:
Bonjour à tous,
Un 2000 Serveur AD qui assume les roles suivant :
-Emulateur PDC
-DNS
-DHCP
-Serveur Exchange
Quelle devrait être la périodicité de reboot ?
Merci.
PIII 1Ghz
640Mo Ram
Salut,
programmer un reboot mensuel (notamment pour Exchange) n'est pas une
mauvaise idée.
=> Il vaut mieux un bon reboot planifié (mensuel) qu'un plantage inattendu
au plus mauvais moment !
Sujet épineux... Je ne crois pas que "prévoir" des reboots soit une bonne idée. On n'est plus tout à fait à la "belle époque" de NT4 où les drivers d'impression, IIS et autres process bouffaient la mémoire et autres ressources système à tire larigot... Si les performances du serveur se dégradent, il serait bon de vérifier ce qui cause ces problèmes et de s'attaquer à leur résolution plutôt que de rebooter jusqu'à la prochaine fois.
En revanche, prévoir l'application mensuelle des patches de sécurité (en plus de l'application ponctuelle des patches critiques) me paraît de bon aloi, et de toute façon le serveur redémarrera à cette occasion :-).
Jacques
"Thierry DEMAN [MVP]" wrote in message news:
Alni wrote:
Bonjour à tous,
Un 2000 Serveur AD qui assume les roles suivant : -Emulateur PDC -DNS -DHCP -Serveur Exchange
Quelle devrait être la périodicité de reboot ?
Merci.
PIII 1Ghz 640Mo Ram
Salut,
programmer un reboot mensuel (notamment pour Exchange) n'est pas une mauvaise idée.
=> Il vaut mieux un bon reboot planifié (mensuel) qu'un plantage inattendu au plus mauvais moment !
Sujet épineux... Je ne crois pas que "prévoir" des reboots soit une bonne idée. On n'est plus tout à fait à la "belle époque" de NT4 où les drivers d'impression, IIS et autres process bouffaient la mémoire et autres ressources système à tire larigot... Si les performances du serveur se dégradent, il serait bon de vérifier ce qui cause ces problèmes et de s'attaquer à leur résolution plutôt que de rebooter jusqu'à la prochaine fois.
En revanche, prévoir l'application mensuelle des patches de sécurité (en plus de l'application ponctuelle des patches critiques) me paraît de bon aloi, et de toute façon le serveur redémarrera à cette occasion :-).
Jacques
Salut Jacques,
c'est effectivement un sujet difficile...
Le problème est que, dans les entreprises, il y a souvent trop d'intervenants et de modifications de configuration.... => Si les reboots sont trop espacés, on ne peut même plus savoir quelle est la modification qui a généré tel ou tel problème ou supprimé tel fichier.
Dans le cas d'un reboot planifié, il faut aussi planifier les personnes pour suivre le démarrage et régler les problèmes éventuels.
Sujet épineux... Je ne crois pas que "prévoir" des reboots soit une
bonne idée. On n'est plus tout à fait à la "belle époque" de NT4 où
les drivers d'impression, IIS et autres process bouffaient la mémoire
et autres ressources système à tire larigot... Si les performances du
serveur se dégradent, il serait bon de vérifier ce qui cause ces
problèmes et de s'attaquer à leur résolution plutôt que de rebooter
jusqu'à la prochaine fois.
En revanche, prévoir l'application mensuelle des patches de sécurité
(en plus de l'application ponctuelle des patches critiques) me paraît
de bon aloi, et de toute façon le serveur redémarrera à cette
occasion :-).
Jacques
Salut Jacques,
c'est effectivement un sujet difficile...
Le problème est que, dans les entreprises, il y a souvent trop
d'intervenants et de modifications de configuration....
=> Si les reboots sont trop espacés, on ne peut même plus savoir quelle est
la modification qui a généré tel ou tel problème ou supprimé tel fichier.
Dans le cas d'un reboot planifié, il faut aussi planifier les personnes pour
suivre le démarrage et régler les problèmes éventuels.
Sujet épineux... Je ne crois pas que "prévoir" des reboots soit une bonne idée. On n'est plus tout à fait à la "belle époque" de NT4 où les drivers d'impression, IIS et autres process bouffaient la mémoire et autres ressources système à tire larigot... Si les performances du serveur se dégradent, il serait bon de vérifier ce qui cause ces problèmes et de s'attaquer à leur résolution plutôt que de rebooter jusqu'à la prochaine fois.
En revanche, prévoir l'application mensuelle des patches de sécurité (en plus de l'application ponctuelle des patches critiques) me paraît de bon aloi, et de toute façon le serveur redémarrera à cette occasion :-).
Jacques
Salut Jacques,
c'est effectivement un sujet difficile...
Le problème est que, dans les entreprises, il y a souvent trop d'intervenants et de modifications de configuration.... => Si les reboots sont trop espacés, on ne peut même plus savoir quelle est la modification qui a généré tel ou tel problème ou supprimé tel fichier.
Dans le cas d'un reboot planifié, il faut aussi planifier les personnes pour suivre le démarrage et régler les problèmes éventuels.
J'ai tendance à penser qu'une entreprise n'a que la disponibilité de service qu'elle mérite :-). Je m'explique: si une entreprise laisse son (ses) serveur(s) entre les mains de nombreuses personnes, qui peuvent installer/désinstaller des choses à longueur d'année voire ouvrir des sessions localement pour lire leur mail ce qui fait faire l'économie d'un poste de travail, je crois que la priorité d'une telle entreprise n'est pas d'avoir un service hautement disponible. Sa priorité est de faire des économies, ou de veiller à la bonne entente entre les employés et à ce qu'aucune susceptibilité ne soit froissée. C'est tout à fait respectable, mais dans ce cas-là qu'on ne demande pas aux outils informatiques de faire des miracles.
Les entreprises qui depuis des décennies (bientôt des siècles :-)) utilisent des mainframes pour gérer leur informatique savent ce que c'est de mettre en place une gestion rigoureuse de son système d'information: dédier des équipes au pupitrage, à la maintenance, à l'administration, à l'ingénierie, etc. Garder la trace de toutes les modifications faite dans les configurations système ou applications. Documenter les problèmes rencontrés et les solutions apportées. Etc.
Ce n'est pas tant les outils qui assurent la fiabilité du service que la façon dont on s'en sert.
Jacques
"Thierry DEMAN [MVP]" wrote in message news:
Jacques Barathon [MS] wrote:
Sujet épineux... Je ne crois pas que "prévoir" des reboots soit une bonne idée. On n'est plus tout à fait à la "belle époque" de NT4 où les drivers d'impression, IIS et autres process bouffaient la mémoire et autres ressources système à tire larigot... Si les performances du serveur se dégradent, il serait bon de vérifier ce qui cause ces problèmes et de s'attaquer à leur résolution plutôt que de rebooter jusqu'à la prochaine fois.
En revanche, prévoir l'application mensuelle des patches de sécurité (en plus de l'application ponctuelle des patches critiques) me paraît de bon aloi, et de toute façon le serveur redémarrera à cette occasion :-).
Jacques
Salut Jacques,
c'est effectivement un sujet difficile...
Le problème est que, dans les entreprises, il y a souvent trop d'intervenants et de modifications de configuration.... => Si les reboots sont trop espacés, on ne peut même plus savoir quelle est
la modification qui a généré tel ou tel problème ou supprimé tel fichier.
Dans le cas d'un reboot planifié, il faut aussi planifier les personnes pour
suivre le démarrage et régler les problèmes éventuels.
J'ai tendance à penser qu'une entreprise n'a que la disponibilité de service
qu'elle mérite :-). Je m'explique: si une entreprise laisse son (ses)
serveur(s) entre les mains de nombreuses personnes, qui peuvent
installer/désinstaller des choses à longueur d'année voire ouvrir des
sessions localement pour lire leur mail ce qui fait faire l'économie d'un
poste de travail, je crois que la priorité d'une telle entreprise n'est pas
d'avoir un service hautement disponible. Sa priorité est de faire des
économies, ou de veiller à la bonne entente entre les employés et à ce
qu'aucune susceptibilité ne soit froissée. C'est tout à fait respectable,
mais dans ce cas-là qu'on ne demande pas aux outils informatiques de faire
des miracles.
Les entreprises qui depuis des décennies (bientôt des siècles :-)) utilisent
des mainframes pour gérer leur informatique savent ce que c'est de mettre en
place une gestion rigoureuse de son système d'information: dédier des
équipes au pupitrage, à la maintenance, à l'administration, à l'ingénierie,
etc. Garder la trace de toutes les modifications faite dans les
configurations système ou applications. Documenter les problèmes rencontrés
et les solutions apportées. Etc.
Ce n'est pas tant les outils qui assurent la fiabilité du service que la
façon dont on s'en sert.
Jacques
"Thierry DEMAN [MVP]" <tdemanNOSPAM@NOSPAMfree.fr> wrote in message
news:OHUBGq68DHA.2924@tk2msftngp13.phx.gbl...
Jacques Barathon [MS] wrote:
Sujet épineux... Je ne crois pas que "prévoir" des reboots soit une
bonne idée. On n'est plus tout à fait à la "belle époque" de NT4 où
les drivers d'impression, IIS et autres process bouffaient la mémoire
et autres ressources système à tire larigot... Si les performances du
serveur se dégradent, il serait bon de vérifier ce qui cause ces
problèmes et de s'attaquer à leur résolution plutôt que de rebooter
jusqu'à la prochaine fois.
En revanche, prévoir l'application mensuelle des patches de sécurité
(en plus de l'application ponctuelle des patches critiques) me paraît
de bon aloi, et de toute façon le serveur redémarrera à cette
occasion :-).
Jacques
Salut Jacques,
c'est effectivement un sujet difficile...
Le problème est que, dans les entreprises, il y a souvent trop
d'intervenants et de modifications de configuration....
=> Si les reboots sont trop espacés, on ne peut même plus savoir quelle
est
la modification qui a généré tel ou tel problème ou supprimé tel fichier.
Dans le cas d'un reboot planifié, il faut aussi planifier les personnes
pour
suivre le démarrage et régler les problèmes éventuels.
J'ai tendance à penser qu'une entreprise n'a que la disponibilité de service qu'elle mérite :-). Je m'explique: si une entreprise laisse son (ses) serveur(s) entre les mains de nombreuses personnes, qui peuvent installer/désinstaller des choses à longueur d'année voire ouvrir des sessions localement pour lire leur mail ce qui fait faire l'économie d'un poste de travail, je crois que la priorité d'une telle entreprise n'est pas d'avoir un service hautement disponible. Sa priorité est de faire des économies, ou de veiller à la bonne entente entre les employés et à ce qu'aucune susceptibilité ne soit froissée. C'est tout à fait respectable, mais dans ce cas-là qu'on ne demande pas aux outils informatiques de faire des miracles.
Les entreprises qui depuis des décennies (bientôt des siècles :-)) utilisent des mainframes pour gérer leur informatique savent ce que c'est de mettre en place une gestion rigoureuse de son système d'information: dédier des équipes au pupitrage, à la maintenance, à l'administration, à l'ingénierie, etc. Garder la trace de toutes les modifications faite dans les configurations système ou applications. Documenter les problèmes rencontrés et les solutions apportées. Etc.
Ce n'est pas tant les outils qui assurent la fiabilité du service que la façon dont on s'en sert.
Jacques
"Thierry DEMAN [MVP]" wrote in message news:
Jacques Barathon [MS] wrote:
Sujet épineux... Je ne crois pas que "prévoir" des reboots soit une bonne idée. On n'est plus tout à fait à la "belle époque" de NT4 où les drivers d'impression, IIS et autres process bouffaient la mémoire et autres ressources système à tire larigot... Si les performances du serveur se dégradent, il serait bon de vérifier ce qui cause ces problèmes et de s'attaquer à leur résolution plutôt que de rebooter jusqu'à la prochaine fois.
En revanche, prévoir l'application mensuelle des patches de sécurité (en plus de l'application ponctuelle des patches critiques) me paraît de bon aloi, et de toute façon le serveur redémarrera à cette occasion :-).
Jacques
Salut Jacques,
c'est effectivement un sujet difficile...
Le problème est que, dans les entreprises, il y a souvent trop d'intervenants et de modifications de configuration.... => Si les reboots sont trop espacés, on ne peut même plus savoir quelle est
la modification qui a généré tel ou tel problème ou supprimé tel fichier.
Dans le cas d'un reboot planifié, il faut aussi planifier les personnes pour
suivre le démarrage et régler les problèmes éventuels.
