Velius

Darauf bezog sich, obwohl Norton Ghost ja die Heimanwender Version ist, meine Aussage. Zu LSR und Datenbanklen hab ich gelesen, dass es bereits mit VSS interagiert. Somit ist das Stoppen der Dienste kein Problem mehr; man sollte den Snap-Shot einfach nicht bei hoher Last ausführen.

Stimme Blub voll zu. Genau deswegen wurde AD als Multi-Master Modell entworfen. Auch Datenbanken wie SQL oder EX sollte man mit Vorsicht behandeln. Acronis selbst weisst darauf hin, die Datenbank Dienste während dem Snap-Shot kurzeitig zu stoppen. Zu Ghost (Corp Edition) kann ich nur sagen, dass das Produkt auch nicht auf Server ausgelegt ist, aber trotzdem bestens funktioniert, vorausgesetzt, man kennt sich mit der Parametrisierung und all den Tücken rund um das Imaging aus. cheers Velius

Laut MS nicht: Microsoft Windows Server 2003 TCP/IP Implementation Details cheers

Bleib cool ;) du bist doch derjenige der Ausfallend wird und es nichtmal bemerkt. So, alles andere ist pure Zeitverschwendung :cool: @Buzzer Hat da Jemand was anderes Behauptet? Das steht auch so im TCP/IP Whitpapaer von MS. Na und, ist es deswegen weniger RFC konform? Wohl nicht! Schalt mal NBT ab und es geht trotzdem noch. P.S.: Ach Urmel, vielleicht interessiert es dich, dass diese Verwaltungsprogramme, ich denke einfach mal, dass du diese meinst, auch ohne Netzumgebung funktionieren, wie z.B. Veritas BE (einige Virenscanner übrigens auch) ;)

Hi Hr_Rossi Ich hab den Wiki Artikel auch gelesen und IMHO ist er nicht ganz korrekt und auch irreführend. Fakt ist, das der TCP/IP Ptotokoll Stack im Windows zwar von MS entworfen wurde, dieser aber an allen gängigen RFCs anlehnt. NetBEUI wurde dazumal von IBM entworfen und von MS und, wenn ich recht erinnere auch Novell, weiterentwickelt. NetBEUI und NBT (NetBIOS over TCP/IP) haben nur die Schnittstelle, als NetBIOS gemeinsam. NetBEUI und TCP/IP sind aber eingenständige Protokolle, oder besser gesagt Protokollstappel (deswegen auch "Stack"). Gruss Velius P.S.: NetBEUI ist nicht routing fähig, TCP/IP schon.

Oh Backe..... *tränenflies* NetBEUI hat mit NetBIOS over TCPIP, oder auch NBT genannt nicht annähernd so viel gemeinsam, wie du glaubst, aber ich lass dich mal im Glauben....

Was schwafelst du da eigentlich? Und überhaupt, hast du mal deine eigenen Threads gelesen?? :suspect: Will mal wissen wer das verstehen soll..... Ausserdem entscheide immer noch ich oder ein MOD was zum Thema passt. ;)

BTW: Das ein Foresttrust nicht mit DNS Auflösung geht ist auch sehr logisch, denn ein Forest ist die höchste DNS Grenze. Wenn man zwei Forests hat und eine Vertrauenstellung etablieren möchte, wonach sollte dann der eine, bzw. der andere Forest auflösen können.... :suspect: Klar wäre das wohl technisch mit einer sekundären oder einer Stub-Zone lösbar, aber da wird's schon Gründe geben dafür wieso man das nicht gemacht hat. P.S.: Off-Topic: Na ja, solange diese Frage gestellt wird und noch irgendwelche Ungereihmtheiten vorhanden sind wird es wohl clashen zwischen uns. :p :D

...und ich würde sagen etwas weniger als meistens, aber na ja, lassen wir das mal. :D P.S.: NetBIOS aktiviert aber kein WINS ist doch erst recht Schwachsinn, oder seh ich das falsch. :suspect:

Hi Kohn Alle MVPs in eheren, aber meiner Meinung nach sollte jeder die Fakten erst sammeln, und dann erst seine Meinung bilden, unabhängig davon was Jemand zu wissen glaubt. Das ist quasi mein Berufsstolz, sonst hätt ich auch gleich Sachbearbeiter oder so werden können, obwohl das jetzt nicht als Beleidigung zu verstehen sein sollte, lediglich als klischeehafte Vorstellung. Gruss Velius P.S.: Auch MVPs sind Menschen ;) und bei uns gibt es Locations mit laufenden DNS only, also NBT deaktiviert(!) Konfigurationen. Klar läuft die Netzwerkumgebung nicht mehr, aber wer braucht die schon, vor allem wenn der User die nicht (mehr) kennt..... ;)

:rolleyes: :rolleyes:

Kann man so nicht sagen. Das ist eine Frage der Konfiguration, und default ist der Verkehr zwischen NBNS Server (NetBIOS Name Server = WINS) und NBNS Client unicast. NT 4.0 Kann nicht ohne NetBIOS! Wenn kein WINS vorhanden ist, dann wird gebroadcastet was das Zeug hält, und dass verursacht Netzlast.

Man kann das nicht verallgemeinern - man muss das von Fall zu Fall abklären. Auch ein EX muss nicht zwingend einen WINS Service haben. Am betsne einfach mal das Board abklappern, da gibt's genügend Threads dazu.

Huii.... *rotwerd*.....aber Moment, gibt's hier noch einen anderen Velius??? :mad: :D :D :D

Wieso, kennst mich doch gar nicht :D

Ja, so wie ich zum Beispiel.... :suspect: :cool:

Frauen was beibringen, ist das nicht ein wiederspruch in sich? :D *duckwech*

Klar....Denkfehler :p :D

Wechselrahmen und ein paar Festplatten kann auch nicht schaden....wenn man nicht gleich einen anderen Rechner kaufen will. :D

Du hats den Thread nicht richtig gelesen.... :wink2: Erstell auf dem Top-Level eine neue OU und bilde darin deine Organisation/Hirarchie ab.

Sollte das nicht klappen aufgrund des OU Designs, dann kann man als letzte Möglichkeit noch auf Delegierung/Richtlinien Filterung zurückgreiffen. Da kann man dann nur dieser Gruppe "Richtlinie übernehmen" erteilen. Allerdings sollte man sparsam mit solchen Einstellungen umgehen. Gruss Velius Edit: @MacBoon Genau damit machst du aber die Richtlinien am unübersichtlichsten!

Eigentlich spricht nichts dagegen. ;)

zum Thema PPTP gibt es auch schon ausführliche Diskussionen ob gut oder schlecht. Einfach mal die Boardsuche bemühen. ;)

Ich würde es einfach halten: Wenn eine Tunnelfilterung erwünscht ist, beispielsweise wenn man sicherstellen will, dass sich andere Programme wie Viren und dergleichen nicht über unbenötigte Ports "fortpflanzen" können, dann würde ich auf RPC over HTTPS setzen. Voraussetzung ist aber OL2K3. Mit der Boardsuche findest du mehr heraus. :wink2:

Oh man..... :rolleyes: :wink2: Das mit den Ports verstehst du völlig falsch. Die Ziel- Ports werden vom TCP/IP Stack verwendet, nicht etwa um verschiedene Clients zuzuweisen, sondern um die gewünschte Anwendung, wie etwa SMTP, anzusteuern. Ohne die Zielport angabe wäre der Stack nicht in der Lage zu erkennen, an welche Anwendung das Packet gerichtet ist. Die RPC-Calls sind insofern speziell, weil ausgehen vom RPC Endpoint-mapper Port 135 eine "entfernte Prozedur" ausgeführt wird. Der Computer wird sozusagen aufgefordert, etwas auszuführen und nicht wie bei anderen Protokollen zur Ausführung "gezwungen" (aktiv/passiv). Je nach Anforderung kann der Port aber dynamisch zugewiesen werden, da es, so denke ich mal, zu viele Prozeduren gibt, um diese einem bestimmten Port zuweisen zu können. Jeder RPC-Call hat auch deswegen eine RPC-UID, die in etwa so aussieht f5cc5a18-4264-101a-8c59-08002b2f8426. Im Falle von MS kann man diese Calls aber auf einen bestimmten Port festlegen, nachteil dabei ist aber, dass der Port frei sein muss und möglichst auch nicht bereits reserviert sein darf. Siehe auch: RPC: Remote Procedure Call Protocol Specification Version 2 Ist das jetzt etwas klarer?