dmetzger

Das Hilfe- und Supportcenter in Windows Server 2003 hilft Dir weiter. Dort findet sich in den "Hilfethemen" der Artikel "Gegenüberstellung von Stubzonen und Weiterleitungen mit Bedingungen".

Dr.Melzer hat Recht. Ich ziehe mich dann mal zu diesem Lehrgang zurück: :D http://www.microsoft.com/germany/partner/trainings/license%5Ftrainings/licensingspecialist/onlinetest/default.mspx Bei der von mir erwähnten Raubkopie ging es tatsächlich um eine OEM-Version, also Kaliber Dell, HP, Acer...

Wie steht es mit ipconfig /dnsflush auf den Arbeitsstationen? Ich nehme an, die Einträge im DNS-Server selbst sind korrekt. Weshalb DHCP und nicht gleich fixe IP, wenn die Lease unendlich dauern soll? Das Problem mit dieser Einstellung ist, dass möglicherweise irgendwann alle IP-Adressen im Subnetz aufgebraucht sind, obwohl die Zahl der Arbeitsstationen geringer ist als die Zahl der zur Verfügung stehenden IP-Adressen, diese aber bei Nichtgebrauch vom DNS-Server nicht mehr freigegeben werden. Ich würde die Lease-Dauer auf die üblichen 8 Tage verringern und IP-Reservationen anlegen für Arbeitsstationen, die auf eine immerwährend gleiche IP angewiesen sind.

Helfen kann man nur, wenn jemand sich helfen lassen will. Hast Du schon darüber nachgedacht, ob einige Leute in diesem Board zwar ganz gewiss die Antwort kennen, aber vor einer Veröffentlichung zurückschrecken, weil damit auch Unfug getrieben werden kann? Hast Du auch schon darüber nachgedacht, dass das Hinzufügen einer Arbeitsstation zu einer Domäne grundsätzlich eine Angelegenheit für Administratoren sein sollte? Und ist Dir in diesem Board schon aufgefallen, dass das Thema Sicherheit hohen Respekt geniesst und wir uns ständig Gedanken machen, wie diese zu verbessern wäre? Und kannst Du Dir vorstellen, dass es dann viel, viel Überwindung bräuchte, vor Publikum einen Tipp abzugeben, der diesen Anstrengungen genau zuwiederläuft? Schau Dir zum Beispiel diesen vorzüglichen Beitrag von Gadget an: http://www.mcseboard.de/showthread.php?t=66853 Der hat zwar mit Deiner Frage nichts zu tun, aber er deutet auf eine Grundstimmung hier an Board hin. Hier wurden Dir bereits Ratschläge gegeben, die Du überdenken solltest. Aber zuvor solltest Du sie auch hören und akzeptieren. Das gehört hier zum Umgang.

Aufgrund von früheren Beiträgen von D.Melzer gehe ich davon aus, dass es noch immer ein lizenzrechtliches Problem ist, den Registrationsschlüssel einer bestehenden Installation zu ändern. Es gibt übriges auch im Examen 70-290 (oder war es 70-270?) eine entsprechende Frage, bei der es darum geht, dass man zwar den Lizenzschlüssel einer ordentlich gekauften Version, aber nur die Datenträger einer anderen hat. Antwort: Um Gottes Willen, ja nicht den anderen Datenträger verwenden, sondern sofort Microsoft um Ersatz für den originalen bitten. Ich würds also nicht tun und empfinde diese Meinung auch keineswegs als voreilig. Hier geht es ausschliesslich um Volumen-Lizenzschlüssel (OEM). Grund des KB-Artikels war, dass noch vor Erscheinen von XP mindestens eine raubkopierte Version (auch in Deutsch) in den Newsgroups zirkulierte. Der Urheber war meines Wissens ein Mitarbeiter eines taiwanesichen Herstellers (so wurde ich damals von Microsoft informiert). Nun ist es so, dass eine OEM-Version, wenn einmal im Umlauf, millionenfach verwendet werden kann, weil sie in diesem Fall nach der Installation nicht aktiviert werden musste. Die Folgen kann man sich ausrechnen. Mit SP1 für XP wurden dieser und andere Lizenzschlüssel - die mit Schlüsselgeneratoren erzeugt wurden - gesperrt, d.h. es waren keine weiteren Aktualisierungen des Betriebssystems mehr möglich resp. nur sehr eingeschränkt. Der KB-Artikel soll legitimen Nutzern von betroffenen OEM-Versionen helfen, wieder Aktualisierungen empfangen zu können. Voraussetzung ist natürlich ein ebenso legitimer Schlüssel von Microsoft, sonst funktioniert es nicht. Und es funktioniert auch nicht mit Einzelplatzversionen aus dem Media-Markt.

Technisch geht es. Lizenzrechtlich ist es aber nicht erlaubt. Der Kunde wird die Neuinstallation schlucken müssen, ist aber immerhin besser als Gefängnis.

Wirkt darauf nicht die Default Domain Policy? @Lefg Du hast Recht. Nie wäre ich auf die Idee gekommen, Computer- oder Benutzerobjekte in den Standardcontainern zu belassen, und ich wenn auch nach dem Einrichten einer Domäne umgehend die Werkzeuge Redircomp.exe und Redirusr.exe an, um neu hinzugefügte Computer- respektive Benutzerobjekte sofort bestimmten OUs hinzufügen zu können. Die Standardcontainer sind also in der Regel leer. Nur hats mir die Frage, ob die Standarddomänenrichtlinie auf Objekte in den Standardcontainern wirkt, trotzdem keine Ruhe gelassen. Weder in den - noch vorhandenen - Examenbüchern noch im "Windows Group Policy Guide" des "Windows Server 2003 Resource Kit" fand ich eine abschliessende Antwort. Also habe ich es selbst ausprobiert, einen neu aufgesetzten Computer vor dem ersten Systemstart in CN=Computers verschoben und GPresult.exa ausgeführt. Das Ergebnis: CN=AH-WS03-XPP,CN=Computers,DC=Bitline,DC=local Zeit der letzten Gruppenrichtlinienanwendung: 19.07.2005 at 23:36:24 Gruppenrichtlinie wurde angewendet von: ah-dc01-sbs.Bitline.local Gruppenrichtlinienschwellenwert für langsame Verbindung: 500 kbps Angewendete Gruppenrichtlinienobjekte -------------------------------------- Small Business Server-Windows-Firewall Small Business Server-Remoteunterstützungsrichtlinie Small Business Server-Kontosperrungsrichtlinie Small Business Server-Domänenkennwortrichtlinie Default Domain Policy Also eindeutig: Alle domänenweiten GPO wirken auf den Standardcontainer "Computers". Die Empfehlung bleibt: Nie Computer- oder Benutzerobjekte in den Standardcontainern belassen. Nie die Standarddomänenrichtline ändern, von den wenigen Ausnahmen abgesehen (Kennwortrichtlinien, Kontosperrrichtlinien, Kerberos, Umbenennung Administratorkonto, Deaktivierung Gastkonto etc.). Und jetzt brüte ich über der Frage, weshalb denn Microsoft die beiden Standardcontainers nicht von Anfang an als richtige OUs installiert haben will. Vielleicht weiss da jemand, was Sache ist?

Versuchs mal so: - Computerobjekt in die korrekte OU verschieben (nicht in Standardcontainer"Computers"!) - Computer über Systemsteuerung aus der Domäne entfernen - Computerkonto in AD zurücksetzen - Computer der Domäne wieder hinzufügen

"Lassen wir mal das Thema Sicherheit weg, dafür sorge ich schon noch." Die beste Aussage, um als Admin durch eine verantwortungsvolle Geschäftsführung sofort entlassen zu werden.

In der OU für Domänencontroller haben nur DCs etwas zu suchen.

Der Standardcontainer "Computers" ist definitiv keine OU, sondern ein Container. Also: "cn=technik,CN=computers,dc=weiterstadt,dc=local" -reset

Die beiden von AD angelegten Standardcontainer "Users" und "Computers" sind keine Organisationseinheiten und lassen sich darum nicht mit Gruppenrichtlinien verbinden. Bemühe das nächste Mal zuerst die Boardsuche, bevor Du Fragen stellst. Dieses Thema wurde hier nämlich oft schon diskutiert. Ansonsten: Willkommen an Board!

Ja, und ich habe auch was gelernt! Danke vielmals, das ist ein guter Tag.

Hallo xtragood Bin hier grad im Urlaub und habe bloss einen PDA zur Verfügung, es dauert darum manchmal etwaa länger. Ich wende Offline-Dateien stets nur im Zusammenhang mit Ordnerumleitungen (servergespeicherte "Eigene Dateien") an, nie mit Netzlaufwerken. Deshalb habe ich keine Erfahrung, wie sich Offline-Dateien hier verhalten. Ich kann mir aber vorstellen, dass dies möglicherweise nicht wirklich funktioniert, da ja Netzlaufwerke dem PC ein lokales Laufwerk vorgaukeln - und warum soll der PC von etwas, das er als lokal erkennt, Nochmals ene lokale Kopie anlegen? Nur so ein Gedanke, lasse mich in diesem Punkt gerne belehren.

Schon probiert was passiert, wenn Du einen Client nach vielleicht einer Stunde herunterfährst? Je nach Einstellung werden die Aktualisierungen im Hintergrund auf die Clients kopiert und beim Herunterfahren installiert. Das wird dann auch im Bestätigungsdialog angezeigt ("Updates installieren und herunterfahren").

Wie siehts mit den Einstellungen für die Synchronisation aus? Alle Inhalte automatisch, oder nur geöffnete Dateien?

Mein Tipp: Ich lasse W2K3-Server und SBS 2003 im Kontext des Druckeroperators laufen. Alle Dienste funktionieren tadellos, auch Antivirenprogramme, der Druckeroperator kann nur an Druckern und Druckaufträgen herumfummeln, hat aber im Notfall dss Recht, den Server neu zu starten.

Wurde hier schon mehrmals diskutiert. Ein SBS 2003 MUSS technisch und lizenzrechtlich der erste DC einer neuen Doänenstruktur sein, mit allen FSMO-Rollen. AD ist deshalb zwingend, auf den Exchange darfst du verzichten, den im SBS-Paket enthaltenen aber auch nicht auf einer anderen Maschine installieren.

Ich stehe ebenfalls hinter der Spruch-zu-Kennwort-These. Was zum Beispiel bedeutet das Kennwort "1%von2K=20"? Ganz einfach: "1 Prozent von 2000 gleich 20". Hier noch ein Link zur Prüfung de Kennwortsicherheit: https://passwortcheck.datenschutz.ch/check.php So, und jetzt gehts auf zu einer Wanderung im Appenzellerland mit meinem älteren Sohn. Schönen Sonntag allerseits!

@Kerstel Du darfst auch unsere Boardsuche bemühen. Zu Begriffen wie Ordnerumleitung, servergespeicherte Profile und NTFS-Berechtigungen (Freigabe-Berechtigungen nicht vergessen!) gibt es verschiedenste Beiträge mit wiederkehrenden Erläuterungen. Auch die in W2K3 eingebaute Hilfe beschreibt ausgezeichnet die Erstellung serveegespeicherter Profile. Weiters hilfreich ist der Blick in die Ereignisanzeige. Deren relevante Einträge könnten auch uns unterstützen, Dir zu helfen. Und: Lefg hat absolut Recht. Der Admin hat nichts zu suchen in den Nutzerprofilen oder Ordnerumleitungen. Im Notfall kann er den Besitz übernehmen. Bis dahin sind persönliche Nutzerprofile privat und vertraulich.

In der Default Domain Policy sollten ausschliesslich die Kennwortrichtlinien konfiguriert und darüber hinaus keine Änderungen vorgenommen werden. Es ist übrigens so, dass alle Änderungen an den beiden Default Policies bei einer AD-Aktualisierung (Upgrade von Windows 2000 auf Windows 2003) automatisch mit den neuen Standardeinstellungen überschrieben werden. Ausgenommen sind bloss individuelle Kennwortrichtlinien. Das wird auch beim Upgrade auf Longhorn so sein. Schon aus diesem Grund sollten abweichende Richtlinien nicht über die Default Policies verteilt werden - die ganze Arbeit wäre plötzlich futsch. Aus meiner Praxis meine ich, dass aber auch die Default Domain Policy nicht auf Objekte in den beiden genannten Container wirkt. Ich komme immer wieder in Firmen vorbei, deren Kennwortrichtlinien und Softwareverteilung nicht greifen. Die Computer- und Nutzerobjekte sind in diesen Fällen immer in "Users" und "Containers" enthalten. Nach dem Alegen von OUs und dem Verschieben der Objekte (Hinweis: Redircomp.exe und Redirusr.exe für die zukünftige Einbindung neuer Computer und Nutzer anwenden) sind die Probleme behoben. AD legt ja bei seiner Installation für die DCs auch gleich eine richtige OU (Domaincontrollers) an, damit die Default Domain Controllers Policy umgehend wirken kann.

Ich hab gerade 20 000 Anschläge Fachartikel zu Antivirensoftware von G Data (AVK), F-Secure, McAfee und Kaspersky verfasst; erscheint Ende Juli und wird auch online abrufbar sein (Link folgt dann). Geprüft wurde alles, von Einzelanwender über Small Business bis zu Enterprise. Mein Eindruck ist, dass die Produkte dieser 4 Hersteller alle überzeugen und sich die Schutztechnik der Firmen-Clientversionen vorwiegend durch die Schnittstelle zu zentralen Verwaltungswerkzeugen von den Heimanwenderversionen unterscheidet. Auch Heimanwender bekommen also hervorragende Produkte . In meiner internen Produktionsdomäne läuft alles zentral verwaltet auf F-Secure (Dateiserver, Exchange, Clients, Desktop-Firewalls etc.). In einer zweiten Produktionsdomäne im Perimeternetz laufen die McAfee-Enterpriseprodukte, und zwar ebenfalls zentral verwaltet. Wer eine Zentralverwaltung fürs nicht kommerzielle Heimnetz ohne Domäne sucht und mindestens drei PCs hat, sollte mal ein Auge auf AVK WLAN Security für 169 € werfen. Das Ding ist sicher, kinderleicht und enthält eine beliebige Zahl von Privatnutzerlizenzen im selben Haushalt. Wer nur eine Lizenz braucht, bekommt bei allen vier Herstellern sichere Komplettpakete.

Hast Du nach der Einrichtung von AD neue Organisationseinheiten für Nutzer und Computer eingerichtet? Auf die standardmässigen Container "Users" und "Computers" wirken keine Gruppenrichtlinien.

Die Folgen dieser Dumps ist, dass man zertifiziert, aber keine Fachkraft ist. Pech für die Kunden, die von solchen Leuten betreut werden, und eine Beschädigung der gesamten Branche.

@checkms Die externe NIC müsste eine dynamisch zugewiesene IP haben, je nach Provider. Die interne ist 192.168.0.1. Das ist bei ICS der Standard. Entsprechend bekommen die ICS-Clients dynamisch IP-Adressen im Subnetz 192.168.0.0/24 zugewiesen. @xtragood Vielleicht liegt genau hier das Problem. Wenn der Mitarbeiter eine feste IP in diesem Bereich hat, kann es durchaus geschehen, dass der DHCP-Miniserver auf der NIC 192.168.0.1 dem Mitarbeiter ganz zufällig die gleiche Adresse zuteilen will. Das gibt dann natürlich Probleme, d.h. kein Internet mehr. Im schlimmsten Fall pröbelst Du dann stundenlang an dr Firewall herum, obwohl diese gar nicht das Problem ist. Erkennst Du aber nicht, weil ebenso zufällig in diesen Minuten eine neue IP zugeteilt wird, alles in Butter scheint und Du glücklich bist, weil Du die Ursache gefunden zu haben meinst - bis irgendwann in naher oder ferner Zukunft wieder der gleiche Adressenkonflikt passiert, weil auf dem DHCP-Miniserver natürlich keine Reservationen eingetragen sind. Also: Mitarbeiter soll die IP in Zukunft dynamisch beziehen. Das erleichtert auch den Wechsel von Netz zu Netz. Gleichzeitig definierst Du auf der McAfee Firewall, gebunden an die interne NIC des Notebooks, den gesamten Adressbereich 192.168.0.0/24 als vertrauenswürdig. Und dann schauen wir mal. Ach, und hier nochmals was zum Thema: http://support.microsoft.com/kb/309642/en-us