Das Urmel

Hi nehmen wir doch mal die Bibel für das SMB-Signing. LAN Manager - ich weiss nicht mehr wie es per Default eingestellt ist, aber in den Sicherheitsoptionen / Domainrichtlinien und DomainDC-Richtlinien LAN Manager Authentifizierungsebene, da LM und NTLM wohl zulassen, damit die OS-halben noch mitkommen. :) Kommst nun klar? :)

Uffz :) schon lange her. Ins AD aufnehmen - wird wohl nicht gehen, Maschinen nicht. SMB Signing am DC / Servern Clients wohl abdrehen und sicherstellen das LANman Hasch ebenfalls bleibt. Viel Glück ;)

Kohn sagte Klar doch, aber es schadet in einer gemixten Umgebung nicht, Dinge explizit festzulegen? Scope (NBios) habe ich auch bewusst nicht erwähnt.

Du must der Firewall beibringen, die von dir gewünschten Ports zu deinen Servern durchzulassen.

Warum so umständlich? Eigenschaften deine DFÜ-Verbindung - Abbauen nach IDLE-Time in Sekunden. Sollte das nicht reichen?

Ich würde DHCP Option 44 deine NBS Server der Priorität nach DHCP Option 45 deine NBTServer dito {damit NBT over TCP an} DHCP Option 46 Knotentyp 0x8 [ Wins Suchen, wenn nicht verfügbar dann Broadcast] An QOS würde ich nicht rumfummeln. Drehe niemals zuviel auf einmal an diversen Optionen, du wirst dann nie wissen welche dir was gebracht hat. Dann fragen wir natürlich auch später ob du RL-Zonen hast, ob dein Wins revers auflösen soll (besser wäre das) Übrigens wäre aus meiner Sicht ein Wins bei den DCs und einer im Clientsegment des 48iger Switch besser, eine Optimierung die man sich aber für später aufheben kann - nie zuviel auf einmal.

Das ist so richtig.

Moin wenn es integriert ist, keine Chance.

@Rossi mir scheint du verkomplizierst die Dinge. 50 Clienst bedeuten nicht das Limit einer Broadcast Domain. Weitere Segmentierung mit VLANs bringen was an Performance {daran leidet er ja offfensichtlich} Aber so sagte xtragood Browsing Probleme hat er, das ist nun endlich ganz ganz klar. {und wieder bewahrheitet sich- möglichst vollständige Angaben erleichtern vieles} :mad: Und Dreh- und Angelpunkt der Probleme ist der 48iger Switch. Browsing = WINS Und eben Browsing geht normalerweise nicht über einen Switch, der ist eine natürliche Grenze und das hat auch seinen Grund, kann er ja auch nen HUB dazwischenhängen, dann gäbe es das Problem nicht. Da liegt also das Problem. Browsingproblemen über Switche hinweg begegnet man imho mit WINS, in gemischten Umgebungen sowieso. Oder hat jemand eine bessere Idee, ausser weiter zu segmentieren :rolleyes:

netstat -aon zeigt mehr an. ansonsten tcpview sysinternals. :)

Fehlerhafte Einträge in IRPStacksize resultieren bisher in einer Fehlermweldung die besagt, der Server hat zuwenig Speicher. Ist das bei dem OP - welcher denn nun zwei Fragesteller abwechselnd - der Fall?

Da kann man in gewissen Grenzen dann Realtek 8139 nehmen, auch so ein pseudo Standard. :)

Nein, es stammt dann nur von W2K und zwar vom lokalen OS.. Lass es doch so wie es ist, es stört nicht, tut nicht weh und braucht sogut wie keinen Platz. Stolpert deine BakupSW drüber, schließe das Verzeichnis doch einfach aus, du brauchst es eh nicht für die Wiederherstellung. ;)

Jetzt kläre mal ab, zu welchem Server das Problem besteht. []Der Server am 48-Port Switch, []die oder einer der Server am Giga-Switch? []Oder besteht das Problem nur aus dem anderen Stockwerk? Ich denke du must mit deiner Beschreibung präziser werden, wir kennen dein Netz nicht, alles was du sagst ist Basis für Überlegungen, und genau nur das. Davon abgesehen - die kürzeste Strecke zuerst prüfen, also taperst du mit einem Client an den 48er Switch, hängst den dran und prüfst das Verhalten. Mal so überlegend: 50 Clients laufen an dem 48er Switch mit jeweils 100MBit auf und wollen zum Server, oder sonstwohin. Machen das nur 10 gleichzeitig, dann muss der Switch schon eine Backboneleistung von 1GBit minimum haben, sonst hast du gleich Congestions oder er dropt sogar. Wenn du oben aufmerksam gelesen hast, der angesprochene Server - ist er kein DC fragt mal am DC nach, also mehr Verkehr als die reine Anzahl der Clients. Mit derartigen einfachen Überlegungen gehst du an das Problem heran, schaust in die Doku des Switches und stellst fest, was der maximal leisten kann. Der GigaSwitch wird sicher nicht den Engpass darstellen, wohl aber wiederum der daran angeschlossene 100.er kann den Bereich ebenso einschränken. Du wirst dir u.U. mal mit nem Netzwerkmonitor das geschehen betrachten müssen, möchtest du verwertbare Informationen haben, notfalls auch durch einen Dienstleister. Vile Glück & Erfolg - den wirst du imho sicher brauchen. ;)

Ja, installiere den RDP-Client auf W2K { damit greift ihr doch auch auf den TS zu}

Am einfachsten ist es, du schaust in den Ordner rein. Findest du mehr als ein Tracking.log, dann war der Verursacher sicher XP.

In dem Fall wohl ein verpatztes OEM Setup mit Fremdtools?

*seufz* Prüfe welche Version von Powerchute das ist, gleich kleiner 6.22, dann ist es dein gesuchtes Problem Dann gehe zu Powerchute und informiere dich über einen Update. Seit dem 27.07.2005 gibt es das Problem. Googlesuche apc und die Einträge erschlagen dich, hier im Board übrigens auch.

Gelbe Gefahr hat wieder zugeschlagen :o Entweder du nimmst die Verzeichnisse aus dem Scan raus, oder du nimmst den Norton generell vom SBS runter. Warum läuft der überhaupt da drauf?

@PAT ich hätte es ebenso gemacht, ISBN gesucht; gelistet / verfügbar und gut ist. Cat hat mal Ihre Krallen tiefer wühlen lassen :D was noch besser ist. @Finanzamt Nun, wer im Glashaus sitzt. ;) Wenn du daherkommst, wie der Nick vermuten läßt, auch da gibt es Werke an die ein Normalo nicht ohne weiteres herankommt. Gibt auch noch andere Bereiche und es hat schon seinen Sinn.

Erstmal das was lefg meint :) Dann die Frage: auf dem DC ist APC Powerchute drauf und die beiden Dienste APC PBE Agent und Server hängen im gestartet? Das sollte dringend mal vor weiterer Suche geklärt werden.

Auch Clients fragen beim zuständigen DC nach, darf der Besucher das was er da gerade möchte. Auch nur einfacher Blick in den Ordner - Frage an DC - ACL genehmigt, DC sagt..mom - schlage nach.. Da kommt wohl DNS, WINS, Kerberos, Trusts und Standorte in Betracht. GPO - bezüglich SMB und eventuell ipsec spuckt da mit rein, mal leger gesagt. TCP-WindowsSize im lokalen Netz - eigentlich weniger, das handeln alle modernen Clients ab NT4 zuverläßig aus und fix. Check doch mal im Segment, an einem Server nahe der DCs, dann den Bereich erweitern bis du auf das Problem stösst. Was wäre wenn der Backbone zu den DCs mal streikt, überlastet ist? Es gibt da so viele Möglichkeiten, angefangen von den im Netz aktiven Protokollen, deren Priorität, Inplace Migrated Server / DC oder nicht, Anzahl der Clients, Browsercongestions, die Anzahl der Quellen ist schon recht hoch um als nicht eingeweihter da punktgenau ne Antwort zu haben.

Mal kurz überflogen das Thema. im LAN LMHOSTS, nicht HOSTS Wenn es sich wie ich vermute um eine NT4 Domain handelt, dann installiere einen WINS. Der sollte auch an allen Clients eingetragen sein.

Hast du eine VollwertCD {kein mageres Recovery} Auf der CD zum Home den Ordner ValueAdd\msft\ntbackup suchen. dort dir ntbackup.msi installieren, das NTbackup taucht dann unter Zubehör, Systemprogramme auf. Sichern kannst du Remote nur Daten von einem anderen Systen. Vom Lokalen System wird dir via Systemstate anklicken auch die Reg, Systemfiles etc gesichert. Das geht über VSS - auch natürlich im laufenden Betrieb. Nur eben nicht Remotesysteme so sichern das geht nicht..

Du greifst mit einer XP Maschine permanent drauf zu? Schau an der Box mal nach.