WolverineJR

Hallo an alle, Problem ist (zumindest bei uns) scheinbar gelöst. Mussten einfach die Option "Abstimmen" auf dem Bereich aktivieren. Dort waren dann so ziemlich alle 99'er IPs aufgelistet. Nach dem "Abstimmungs"-Lauf mussten dann die "abgestimmten" 99er-IPs noch im Lease-Bereich gelöscht werden (haben seltsame MAC-Adressen). Danach werden nun auch wieder IPs von vorn vergeben. Danke an alle für die Mühe!!

Ok. So habe ich es auch verstanden. Also ein simpler Check ("ping") auf die ersten vier IP-Adressen aus dem Bereich (99.1, 99.2, 99.3, 99.4) ergaben, dass diese nicht erreichbar sind. Dann gehe ich mal davon aus, dass diese Vermutung nicht zutrifft.

Das ist doch mal eine Idee. Wusste noch gar nichts von dieser Möglichkeit. Danke! Gibt es bei den MS-virtuellen Testlabs Einschränken bzgl. Anzahl der virtuellen Maschinen, Konfigurierbarkeit (Änderungen der Netzwekkonfig -> DHCP-Testumgebung) etc.? Und muss ich damit rechnen, wenn ich ein solches Testlab beantragt habe, dass mich danach ein Vertriebler einer MS-Partner-Firma kontaktiert? Um ehrlich zu sein, mir fällt spontan auch kein Grund mehr dafür ein, warum wir diese Zeitspanne gewählt haben. Vermutlich wollten wir dadurch "Leichen" im DHCP-Bereich vermeiden o.ä.. Was für einen Zeitraum würdest Du denn empfehlen? Den Standardwert? Werde deinen Einwand auf jeden Fall mit meinen Kollegen (und vor allem mit meinen Netzwerkkollegen) diskutieren. Danke! Da hab ich jetzt ein Verständnisproblem mit deiner Formulierung. Meinst Du damit die Adressen aus den Bereichen außerhalb der dynamischen Vergabe (also in unserem Fall alles außer dem 99'er-Bereich)? Oder willst Du damit sagen, dass alle IPs aus dem dynamischen Bereich (bei uns 99'er) ausschließlich nur über den DHCP vergeben werden?

Da gebe ich Dir recht. Von Experimenten an dem produktiven DHCP-Server möchte ich Abstand nehmen. Wenn das Teil nicht läuft, stehen ganz schnell einige Kollegen aus der Entwicklung und Produktion bei mir auf der Matte und fragen, warum ihre Systeme keine IPs beziehen. Und einen zweiten DHCP-Server ins Netz zu nehmen ist erfahrungsgemäß nicht empfehlenswert. Ich habe schon mit dem Gedanken gespielt eine virtuelle DHCP-Testumgebung aufzubauen in einem Host-Only-Netz. Um hier ein aussagekräftiges Testfeld zu betreiben, müssen aber mind. ein DHCP-Server und einige Testclients her. Den Aufwand wollte ich mir (bisher) nicht geben. Aber es führt wohl kein Weg daran vorbei.

Verstehe zwar nicht was Du meinst, aber dennoch Danke für eure Mühe!

Falls ja, müsste ich x-verschiedene Bereiche konfigurieren. Auf Verdacht will ich das nicht unbedingt machen.

Bei uns dürfen die dynamisch vergebenen IPs ausschließlich nur aus dem 99'er Bereich kommen (hat z.B. auch was mit unserer Firewall/Proxy-Konfig zu tun). In dem 99'er Netz dürfen auch keine Reservierungen vorkommen (organisatorische Gründe). Da wir ja (noch) dieses "tolle" /16'er Netz verwenden, sehe ich da sonst keine andere Möglichkeit. In unserer Umgebung muss ich doch den 99'er-Bereich mittels der beiden Ausschlußbereichen definieren. Sonst würden die dynamisch vergebenen IPs ja auch aus anderen Bereichen kommen (1, 2, 3 ... 254 - Bereich).

Die Adressen sind per MAC an eine IP gebunden. Eingetragen in der DHCP-Bereichskonfiguration unter "Reservierungen".

Dumme Frage: Wenn ich den Pool nur auf den dynamischen Bereich beschränke, funktionieren dann die statischen Reservierung noch? Hab mal einen Screenshot der Pooldefinition angehängt.

Meinst Du, dass eine Lease von 12h zu lang ist? Wie lang ist denn der Standardwert? Von Experimenten möchte ich Abstand nehmen, weil ich letzte Woche schon in dem Ausnahmebereich testweise Änderungen vorgenommen hatte. Das resultierte darin, dass überhaupt keine dynamischen IPs mehr vergeben wurden. Ich hatte halt gehofft, dass jemand sich die Definition des DHCP-Bereichs ansieht und gleich sagt "Aha! Hier liegt der Hund begraben!".

Hi, wir verwenden ein /16-Netz aus... "historischen Gründen". Wir sind bereits auch dabei dieses "Monster" in mehrere geroutete Netze umzustellen. Aber bei mehr als 1000 Clients dauert das. Und das Broadcast-Thema ist uns mehr als bekannt. :( Und den "99"-Bereich waren wir gezwungen zu verwenden, weil die davor liegenden Bereich bereits verwendet werden (statische Einteilung nach Gebäuden, Abteilungen etc.). Der "99"-Bereich war so ziemlich der nächst-freie Bereich in unserem /16-Netz. Kannst Du mir mal ein Beispiel geben? Ganz pragmatisch betrachtet kann ich sagen, dass wir hier in letzter Zeit hin und wieder den Fall hatten, dass Clients keine dynamische IP-Adresse bekamen, weil die letzte IP aus dem Bereich vergeben war (xxx.xxx.99.254) (Die Leasedauer ist in dem Bereich auf 12 Stunden eingestellt).

Hi, folgendes Problem: Wir haben einen DHCP-Server (Windows 2012R2) mit folgender Adresspool-Konfiguration: Adressbereich für Verteilung: xxx.xxx.0.1 - xxx.xxx.255.254 Von Verteilung ausgeschlossener Bereich: xxx.xxx.0.1 - xxx.xxx.98.255 Von Verteilung ausgeschlossener Bereich: xxx.xxx.99.255 - xxx.xxx.255.254 Da wir sehr stark mit DHCP-Reservierungen arbeiten und auf gewisse IP-Ranges angewiesen sind, wollen wir damit einen IP-Range festlegen, welcher für die dynamische Vergabe zuständig ist. Bei uns also xxx.xxx.99.1 - xxx.xxx.99.254 Nun haben wir das Problem, dass die dynamisch vergebenen IPs immer am Ende des Ranges anfangen. Es wird also NIE die IPs aus dem Bereich xxx.xxx.99.1 bis xxx.xxx.99.230 vergeben. Die ersten IPs werden im Bereich von xxx.xxx.99.240 vergeben. Da der DHCP-Server anscheinend nur so "intelligent" ist immer nur höhere IPs als die zuletzt vergebene zu vergeben, sind wir ständig der Gefahr ausgesetzt, dass der dynamische IP-Bereich "vollläuft" (obwohl noch über 230 IPs eigentlich frei sind!). Hat hier irgendjemand eine Idee oder hat jemand das selbe Problem? Danke!

Vielen Dank für die Links! :thumb1:

Servus, bei uns in der ActiveDirectory-Domäne (W2k3 SP2) werden die Benutzeranmeldenamen anhand von zentral vergebenen Kurzzeichen vergeben. Diese Kurzzeichen sind 2 oder 3 Stellen lang und setzen sich aus einer alphabetischen Kombination von Vor- und Nachnamen zusammen. Hat bisher auch ohne Probleme funktioniert. Jetzt haben wir aber einen neuen Mitarbeiter bekommen, der das Kurzeichen (und somit auch den Benutzeranmeldenamen in der Domäne) "con" bekommen hat. Dieser Benutzer hatte das Problem, dass immer nur ein temporäres Profil auf den Domänen-PC's angelegt wurde wenn er sich anmeldete. Andere Benutzer konnten sich auf den selben PC's ohne Probleme anmelden (wir haben nur lokal gespeicherte Profile in der Domäne). Nach tagelanger Suche und Logging der Anmeldung etc. sind wir auf das Problem gestoßen... das Kurzzeichen "con" ist Bestandteil des guten alten DOS-Befehls "copy con". Dadurch kann beim Anmelden auch das Default-Profil nicht kopiert/angelegt werden. Nun meine Frage: Gibt es irgendwo eine offizielle Liste (am besten von MS) welche solche "Problemfälle" aufzeigt? Also AD-Anmeldenamen welche man vermeiden sollte? Weil im nachhinein dies zu ändern (bei uns in der Organisation) ist nicht trivial (in AD schon... aber nicht in allen restlichen Systemen bei uns). Danke!

Hallo Allerseitz, hab' hier ein etwas "exklusives" Problem. Bei mir in der Firma gibt es ein paar Tablet-PC's auf denen XP läuft und welche in der ADS sind. Die PC's sind so eingestellt, dass diese sich automatisch mit einem best. User in der Domäne anmelden, wenn sie gestartet werden (der Grund: an den Tablet-PC's sind keine Tastaturen angeschlossen). Nun müssen sich einige Kollegen per RDP auf die Kisten verbinden um dort Updates zu fahren. Logischerweise wird der aktuelle User dadurch abgemeldet. Zwar haben wir den Kollegen gesagt, dass Sie per "shutdown.exe" die Maschine durchbooten sollen, wenn sie fertig sind. Nur leider wird das sehr oft vergessen und nur abgemeldet. Somit stehen die anderen Kollegen direkt an den Tablet-PC's an der Anmeldemaske und können nicht arbeiten. Nun wollte ich Schlauberger per GPO in den Benutzerbereich beim Abmelden eine Batch-Datei reinlegen, in der "shutdown -r -t 0" drinnensteht, damit beim Abmelden auf jeden Fall ein Neustart durchgeführt wird. Funzt leider nicht. Hat jemand eine Idee wie ich das Problem lösen kann? Vllt. gibt es ja auch eine Möglichkeit, dass beim Abmelden automatisch sich ein best. User wieder anmeldet?

Sieht nicht so aus. Ich werde aber nun über eine eigenständige Freigabe gehen. Danke für Eure Hilfe! :thumb1:

Das geht... verstehe ich aber nicht. Warum kann ich von einem Terminalserver nicht in den SYSVOL-Bereich reinschreiben und von einem 08/15-Client mit dem gleichen User kann ich es??

Hat sich angeboten. Wüsste auch nicht, was dagegen sprechen sollte. Ich probiere es mal mit einer eigenen Freigabe und sag Bescheid.

Hi, ich habe bei mir in der W2k3-SP2 - Domäne folgendes Problem. Für das Loggen des An- und Abmelden der User an Domänen-Maschinen habe ich eine GPO erstellt, in welcher im Benutzerbereich bei "Windows-Einstellungen->Skripts->Anmelden" und "...->Abmelden" jeweils ein Batch-Skript abgearbeitet wird, welches in ein Verzeichnis der SYSVOL-Freigabe reinschreibt (Dateien nach Useranmeldenamen benannt). Das funktioniert auch soweit wunderbar. Nur habe ich nun das Phänomen, dass bei einem W2k3-SP1-Terminalserver (Mitglied in der Domäne) das Logging nicht stattfindet. Wenn ich das Debugging für den Anmeldeprozess auf dem Terminalserver einschalte, sehe ich auch, dass die GPO korrekt abgearbeitet wird. Wenn ich nun aber auf dem Terminalserver das Batchskript per Hand ausführe, bekomme ich folgenden Fehler: Die Konfigurationsinformationen konnten vom Domänencontroller nicht gelesen werden. Mit dem Computer kann keine Verbindung hergestellt werden, oder der Zugriff wurde verweigert. Hat jemand eine Idee für mich?

Das ist möglich. Haben wir im Einsatz. Voraussetzung sind Vertrauensstellungen zwischen der jeweiligen zugreifenden Domäne und der Domäne, in welcher der Samba-Server integriert ist. Dadurch kannst Du Objekte aus der zugreifenden Domäne am Samba-Server anwenden.

Hi, kennt jemand eine Möglichkeit mittels einer ADS-Gruppenrichtlinie den einen SNMP-Trap-Empfänger + Community zu setzen? Mit den Standard-ADM-Files kann ich nur den Hostnamen/die IP-Adresse des Trap-Empfänger setzen. Nicht aber den Community-Namen.

Die Außenstelle ist eine eigene Domäne Werde ich gleich tun. Danke!

Servus MS-Profis! Bei einem unserer Außenstellen ist gestern Nacht der AD-Server abgeraucht. Grund bisher unbekannt. Zwei Kollegen sind bereits unterwegs um sich der Sache anzunehmen. Nun stehen wir eventuell vor dem Problem, dass der AD-Server neu aufgesetzt werden muss. Leider gibt es (oder besser gesagt "gab es" :( ) in der Aussenstelle nur diesen einen Server. Wir haben regelmäßig (1x im Monat) eine Sicherung per "ntbackup" u.a. den SystemState-Bereich des Servers gesichert. Jetzt meine Frage: Wenn es zum Worst-Case kommen sollte, und der Server komplett neu aufgesetzt wird, kann das ADS mittels der erwähnten Sicherung 1:1 wieder hergestellt werden? Und falls ja, wie wäre der genaue Vorgang hierfür? Wäre das der von MS beschriebene Weg für einen "AD Nonauthoritative Restore"? Also Reboot der neu-aufgesetzten Maschine, mit F8 unterbrechen, "Directory Services Restore Mode", Login mit "dcpromo"-Account, ntbackup ausführen und restoren? Vielen Dank im Voraus!! P.S.: Es handelt sich hierbei um einen W2k3 SP1 - Server

Hab den Fehler gefunden. Musste von der "Master"-Domäne den Schema-Master wählen. Dann klappts auch mit dem Nachbarn! :D

hmm... jetzt hab ich folgendes Problem. wenn ich, egal auf welchen der beiden Domäncontroller, den Befehl <W2k3-SP1-R2-CD2>:\CMPNENTS\R2\ADPREP\adprep.exe /forestprep eingeben, bekommen ich folgenden Fehler: Adprep hat ermittelt, dass der angemeldete Benutzer kein Mitglied der folgenden Gruppen ist: Gruppe "Organisations-Admins" und Gruppe "Schema-Admins". [status/Folgen] Adprep wurde angehalten, ohne Änderungen vorzunehmen. [benutzeraktion] Überprüfen Sie, ob der zurzeit angemeldete Benutzer ein Mitglied der Gruppen "Or ganisations-Admins", "Schema-Admins" und "unser.DNS.Suffix\Domänen-Admins" ist. Ich finde nirgends die Gruppen "Organisations-Admins" und "Schema-Admins". Habe den Befehl als Domänen-Administrator ausgeführt.