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!!

Moin,

 

 

ich meine damit die Adressen aus dem DHCP-Scope, die der DHCP-Server aus irgendeinem Grund überspringt, statt sie zu vergeben. Vielleicht werden die ja in Wirklichkeit benutzt und sind nicht frei.

 

Gruß, Nils

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.

Richte Dir doch ein virtuelles Testlab ein oder "mißbrauche" einfach ein TechNet Virtual Lab, in dem mindestens ein Server und einige Clients enthalten sind. Dann kannst Du das in Ruhe austesten.

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?

Moin,

 

 

um dazu noch kurz was zu sagen: In den meisten Umgebungen ist von derart kurzen Lease-Dauern abzuraten. Insbesondere, wenn ihr sowieso ein Lastproblem habt.

 

Ein DHCP-Client wird im laufenden Betrieb nach 50% der Lease-Dauer seine Lease erneuern. Das ist dann Unicast, aber eben Traffic. Bedeutet bei euch: alle sechs Stunden, also mindestens einmal pro Arbeitstag für die meisten Rechner (in vierstelliger Zahl). Nun hat der Client allerdings auch schon beim Hochfahren seine Lease erneuert ...

 

Sollte der DHCP-Server nicht geantwortet haben, dann versucht der Client nach 87,5% der Lease-Dauer erneut eine Verlängerung per Unicast. Nur wenn das nicht erfolgreich ist, verwirft er seine Lease am Ende von deren Dauer und führt ein neues Broadcast-Discover durch. Wenn ihr ohnehin Last im Netz habt, würde ich nicht ausschließen, dass das bei euch häufiger passiert. Und das alles für vermutlich zum größten Teil stationäre Clients, die ohnehin dauerhaft eine IP-Adresse brauchen und in der Regel auch immer dieselbe vom Server erhalten.

 

Kurze Lease-Dauern haben neben der Netzwerklast noch einen weiteren Nachteil: Die automatische DNS-Registrierung kann dadurch aus dem Tritt geraten, insbesondere wenn auf den (Windows-) DNS-Servern das Scavenging (Entfernen veralteter Einträge) aktiv ist. Hier muss man die Scavenging-Intervalle und die Lease-Dauern aufeinander abstimmen, was mit Lease-Dauern unterhalb von 24 Stunden eigentlich gar nicht geht und mit Dauern unter drei Tagen nicht sinnvoll konfigurierbar ist.

 

Wenn es also nicht wirklich einen zwingenden Grund für kurze Lease-Dauern gibt, solltet ihr die deutlich verlängern.

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!

Könnt ihr sicher ausschließen, dass die Adressen, die der DHCP-Server nicht dynamisch vergibt, in Benutzung sind?

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?

Tscha, in Handlungsmöglichkeit erscheinst Du sehr eingeschränkt. Eine Neukonfiguration ist wohl nicht möglich derzeit. Ob sinnvoll, einen weiteren DHCP zu installieren und zu konfigurieren auf einem anderen Server, so rein experimental?

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.

Du schlägst Dich mit Randbedingungen herum, die nicht wirklich nachvollziehbar sind...

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

Ob das in mehrere Bereiche aufteilbar ist?

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).

Was verstehst Du unter statischen Reservierungen? Sind die Adressen fest eingetragen an den Teilnehmern oder kommen die Adressen doch dynamisch vom DHCP und sind an dem per MAC und IP reserviert, eingetragen unter Reservierungen?

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

Meine Frage, Gedanken also, warum wird der Pool nicht gleich festgelegt auf xxx.xxx.99.1 - xxx.xxx.99.254? Wozu sollen die Ausschlüsse also (noch?) gut sein?

Dumme Frage: Wenn ich den Pool nur auf den dynamischen Bereich beschränke, funktionieren dann die statischen Reservierung noch?

Noch eine Frage, sind eventuell Start IP und End IP in der Konfiguration so festeglegt, das der Start an der hohen Adresse beginnt?

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.

Ich meine, die zu reservierenden Adressen sollten sich im Pool befinden, nicht im Anschluss.

Kannst Du mir mal ein Beispiel geben?

Aber läuft der Bereich tatsächlich voll? Wechseln die Teilnehmer die Adressen oder kommen und gehen ständig Teilnehmer?

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?

Weil der TS-User evtl. in einer Gruppe ist, die nicht ins Sysvol schreiben darf?

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??

Warum machst Du denn sowas???

 

Leg eine andere Freigabe an und lass dort reinschreiben.

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.

ist diese Aussenstelle seine eigene Domäne im einem Forest oder lediglich ein AD-Standort einer bestehenden Domäne?

Die Außenstelle ist eine eigene Domäne

ist diese Aussenstelle seine eigene Domäne im einem Forest oder lediglich Beachte dazu folgenden Artikel:

 

Yusuf`s Directory - Blog - Einen Server mit rücksichern des System State zum DC stufen

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.