L'intervalle par défaut pour le transfert des listes browse mises à jour entre le domain master browser et les master browsers, est de 12 minutes. Le white paper Microsoft « MS Windows NT Browser » (http://www.microsoft .com/technet/treeview/default.asp?url =/technet/prodtechnol/winntas/deplo y/prodspecs/ntbrowse.asp) indique que l'intervalle de mise à jour de liste entre des
Construire et maintenir une liste browse (3)
browsers est de 15 minutes.
Toutefois, j’ai supervisé mon réseau,
qui inclut un domaine NT et un domaine
Win2K AD avec Windows .NET
Enterprise Server (Win.NET Enterprise
Server – auparavant Win2K Advanced
Server) bêta 3, Win2K AS, NT Server,
Win2K Pro systems, et XP Professional
Edition (tous agissant comme des
browsers dans un réseau multisegment).
La trace des paquets a confirmé
l’intervalle de 12 minutes.
Sur des réseaux IP, le service
Computer Browser utilise les deux
protocoles TCP et UDP. Un master
browser et le domain master browser
se transfèrent mutuellement des listes
browse dans le cadre d’une session
NetBIOS sur TCP/IP (NetBT) pour une
communication très fiable. Toutes les
autres communications utilisent UDP,
un protocole IP sans connexion qui ne garantit pas la livraison des paquets.
Pour être plus précis, ces communications
UDP utilisent une implémentation
du protocole CIFS (Common
Internet File System) qui est ellemême
une version améliorée du protocole
de système de fichiers SMB
(Server Message Block).
Comme rien ne garantit la bonne livraison
des datagrammes du browser,
il peut arriver que certains datagrammes
ne parviennent pas au service
Computer Browser en cas de forte
activité du réseau ou du serveur. De ce
fait, de multiples intervalles d’annonce
sont parfois nécessaires pour transmettre
correctement des informations
mises à jour. Comme la livraison des
datagrammes est imparfaite, le service
Computer Browser ne supprime les
anciennes informations de la liste
browse qu’une fois que le navigateur
n’a pu recevoir des datagrammes provenant
d’un ordinateur source pendant
trois intervalles d’annonce successifs.
Si un ordinateur qui s’arrête de
manière propre et ordonnée annonce
l’arrêt au master browser, un système qui s’arrête inopinément reste dans la
liste browse de son master browser
pendant 36 minutes. Comme jusqu’à
36 minutes de plus peuvent s’écouler
avant qu’un backup browser sur un
autre segment de réseau obtienne une
liste browse mise à jour, un ordinateur
pourrait rester dans la liste browse
d’un autre segment de réseau jusqu’à
72 minutes après son arrêt.
Pour bien régler les problèmes, il
faut comprendre le principe de fonctionnement
du service Computer
Browser. (Pour une explication plus
détaillée du service Computer
Browser, voir le Windows 2000 Server
TCP/IP Core Networking Guide,
« Appendix I – Windows 2000 Browser
Service » à http://www.microsoft.
com/technet/prodtechnol/windows
2000serv/reskit/tcpip/part4/tcpappi.
asp.) Dans un futur article, je décrirai
les outils et les procédures vous permettant
d’aller au coeur des problèmes
que vous risquez de rencontrer avec le
service Computer Browser.
Téléchargez cette ressource
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- IA : ne déléguez pas votre cœur de métier à une boîte noire
- Identité de l’IA : 4 priorités pour anticiper plutôt que subir la régulation
- Sauvegarder les données ne suffit plus : il faut refonder le poste de travail
- Cybermalveillance : 2025, seuil franchi pour les victimes comme pour les cybercriminels
Articles les + lus
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
À la une de la chaîne Tech
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
