bigthe

Um genau zu sein war es das ARP Caching durch CISCO Switches verursacht. Auf einigen CISCO Switches war das sog. IPDT aktiviert. 

Auf den Switches konnte ich mittels  "ip device tracking probe delay <seconds>"  und 10 Sekunden das verzögern das es keinen Konflikt mit Windows DAD gibt.

Eventuell werden wir später das IPDT komplett ausschalten.

Am 29.12.2022 um 08:41 schrieb cj_berlin:

Moin,

 

9 von 10 Mal, dass ich das Verhalten (außerhalb groß angelegter Migrationen, wo das normal ist) gesehen habe, war das ARP Caching auf Switchen oder Routern die Ursache.

Das war es. Doppeltes ARP. Problem gelöst.

vor 4 Minuten schrieb speer:

Läßt sich feststellen welche MAC Adresse hinter den Bad Addresses steckt? Somit liese sich der Gerätetyp feststellen. Möglicherweise sind dies keine Windows Clients.

Was macht den das Gerät mit der IP: 172.24.42.12?

Es sind Windows Clients.

Das Gerät mit der IP ist eine von mir erstellte VM in einem Scope um das Problem zu analysieren.

vor 26 Minuten schrieb NorbertFe:

Ohne ein paar mehr Infos wird’s schon schwierig. Sind da evtl. Wlan clients dabei die mit Mac adress Anonymisierung ankommen? Ich würd ja einfach mal die lease Time auf 3 oder 4 Tage stellen.

Welche Infos benötigst du?

Nein, die WLAN scopes sind nicht betroffen.

Die lease time zu verändern wird das Problem leider nicht lösen. 

Naja dann laufen wir in Gefahr keine freien IPs zu haben. Weil immer mehr Bad adresses dazu kommen. Klar die löschen sich auch nach der lease time von 8 Tagen.

Das Problem ist aber nicht das, sondern warum kommen die Bad adresses. In einem 22er Netz haben wir nach ca. 2 Wochen ca. 60 Bad adresses.

Jeder Tipp dazu wäre ich sehr dankbar.

LG und einen schönen Abend euch.

Händisch die Bad Adresses aus der DHCP Konsole bzw den Scopes gelöscht

Richtig, sind beide so konfiguriert.

Hallo Norbert,

Konflikterkennungsversuche ist auf 1 gestellt. Die Logs sind allerdings zu gross um sie hier hochzuladen, deswegen habe ich nur den Auszug, was mir auffiel, eingestellt.

Die Leases sind default auf 8 Tage gestellt. Es sind ziemlich grosses Scopes und wir laufen auch nicht in Engpässe, wenn wir alle zwei Wochen manuell löschen.

Ohne Change kann ich das auch ohne weiteres nicht ändern.

Hallo,

das würde in meinem Fall über Rogue Server bzw. Wireshark auffallen, das es mehrere DHCP Server im Netz gibt.

Guten Morgen in die Runde,

ich hoffe ihr hattet ein paar angenehme Feiertage und es geht euch gut.

Ich bin seit ein paar Monaten in einer neuen Firma und habe dort eine Aufgabe zugewiesen bekommen. Und zwar geht es um DHCP Bad Adresses.

Wir haben aktuell zwei DHCP Server im Failover konfiguriert. Diese schauen auf ca. 60 verschiedenen Scopes. Wir haben seit 4 Wochen nun dieses Bad Adress Problem auf 8 dieser Scopes. Konfiguration habe ich mit Angehangen

Ich habe bereits in einem betroffenem Scope nach unautorisierten DHCP Servern gesucht und nur unsere zwei DHCP-Server gefunden, weiter habe ich mit Wireshark im betroffenem Scope die NIC überprüft und das Verhalten bei IP /release und /renew und auch nichts ungewöhnliches festgestellt (Abb. unten).

Ich bin aktuell etwas ratlos und hoffe ihr könnte mir weiterhelfen.

LG

auszug DHCP Logs.txt

Hallo,

danke für den Tipp.

Ich habe es jetzt doch über eine für mich passende GPO geregelt.

User Configuration\Administrative Template\System  custom User interface und habe dort meinen Google Chrome mit Kioskmodus hinterlegt.

Soweit so gut. Wenn Benutzer zb. mit ALT+F4 Google schließen, dann haben diese einen schwarzen Bildschirm. In diesem Falle suche ich eine GPO die Windows Neustartet oder abmeldet, wenn der Benutzer die Anwendung schließen sollte. 

Hallo,

ich hätte gern den Windows Start verzögert bis die Anwendung (Google Chrome) geladen ist. Die Anwendung startet im Kiosk Modus, wenn der Benutzer sich anmeldet. Ich möchte nicht das der Benutzer den Desktop sieht und wartet bis der Browser startet sondern nachdem er sich eingeloggt hat einfach nur den Browser sieht.

Ist sowas überhaupt möglich, habe nichts gefunden. Habt ihr eine Idee oder Erfahrung dazu?

MfG Robin

Okay danke! Dann kann das Thema geschlossen werden.

Ein schönen Tag euch!

Also das Problem:

Starting test: DFSREvent
         Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse
         vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.

Habe ich gelöst, es waren im Netzwerkadapter die DNS IPs vertauscht.

Die Anmeldeskripte werden nun auch angenommen.

Das Problem das auf dem DC01, der die DFSR Migration durchgeführt hat, der SYSVOL_DFSR exsistiert ist irritiert mich etwas. Ist das schlimm? Ich habe vorsorglich die FSMO Rollen auf den DC02 übertragen der einen ganz normal  SYSVOL Ordner hat.

Der alte Server war kein 2000er, sondern ein 2008R2, sry

Die Replizierung scheint zu funktionieren, denn ich habe die geänderten Anmeldescripte auch auf dem DC02.

Zitat

wie bist du denn von einem DC unter Windows 2000 Server zu einem DC auf Windows Server 2016 gekommen? Und wie/wann wurde die Migration von FRS auf DFS gemacht?

Das hat ein Kollege damals gemacht. Wie kann ich nicht sagen.

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\Administrator.DTZ>dcdiag

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = DC01
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Standardname-des-ersten-Standorts\DC01
      Starting test: Connectivity
         ......................... DC01 hat den Test Connectivity bestanden.

Primärtests werden ausgeführt.

   Server wird getestet: Standardname-des-ersten-Standorts\DC01
      Starting test: Advertising
         ......................... DC01 hat den Test Advertising bestanden.
      Starting test: FrsEvent
         ......................... DC01 hat den Test FrsEvent bestanden.
      Starting test: DFSREvent
         Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse
         vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
         ......................... DC01 hat den Test DFSREvent bestanden.
      Starting test: SysVolCheck
         ......................... DC01 hat den Test SysVolCheck bestanden.
      Starting test: KccEvent
         ......................... DC01 hat den Test KccEvent bestanden.
      Starting test: KnowsOfRoleHolders
         ......................... DC01 hat den Test KnowsOfRoleHolders bestanden.
      Starting test: MachineAccount
         ......................... DC01 hat den Test MachineAccount bestanden.
      Starting test: NCSecDesc
         ......................... DC01 hat den Test NCSecDesc bestanden.
      Starting test: NetLogons
         ......................... DC01 hat den Test NetLogons bestanden.
      Starting test: ObjectsReplicated
         ......................... DC01 hat den Test ObjectsReplicated bestanden.
      Starting test: Replications
         ......................... DC01 hat den Test Replications bestanden.
      Starting test: RidManager
         ......................... DC01 hat den Test RidManager bestanden.
      Starting test: Services
         ......................... DC01 hat den Test Services bestanden.
      Starting test: SystemLog
         ......................... DC01 hat den Test SystemLog bestanden.
      Starting test: VerifyReferences
         ......................... DC01 hat den Test VerifyReferences bestanden.

   Partitionstests werden ausgeführt auf: ForestDnsZones
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... ForestDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: DomainDnsZones
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... DomainDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Schema
      Starting test: CheckSDRefDom
         ......................... Schema hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Schema hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Configuration hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: DTZ
      Starting test: CheckSDRefDom
         ......................... DTZ hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... DTZ hat den Test CrossRefValidation bestanden.

   Unternehmenstests werden ausgeführt auf: DTZ.Suhl
      Starting test: LocatorCheck
         ......................... DTZ.Suhl hat den Test LocatorCheck bestanden.
      Starting test: Intersite
         ......................... DTZ.Suhl hat den Test Intersite bestanden.

C:\Users\Administrator.DTZ>

Guten Morgen,

ich hänge mal wieder an einem Problem. Und zwar habe ich eine alte DC Struktur repliziert, dazu die fsmo rollen übertragen etc. Danach habe ich einen zweiten neuen DC hinzugefügt

Alles läuft soweit, der alte Server wurde sauber abgelöst.

Alter DC war ein Windows 2000

1.DC Windows Server 2016 nur SYSVOL_DFSR vorhanden

2.DC Windows Server 2019 SYSVOL vorhanden

Jetzt wollte ich die Anmeldescripte anpassen und habe festgestellt, dass es keinen SYSVOL Ordner gibt, sondern nur einen SYSVOL_DFSR. Dazu gibt es auch keine Freigabe, die Clients können sich das Anmeldeskript nicht holen.

Eventlog:

Warnung DFSR 5014

Der DFS-Replikationsdienst beendet die Kommunikation mit Partner DC02 für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen.
 
Weitere Informationen:
Fehler: 9036 (Zum Sichern oder Wiederherstellen angehalten)
Verbindungs-ID: A00E799B-D7C3-4335-A990-39C9CF05BCA3
Replikationsgruppen-ID: D12D2921-6E83-49C1-AAC3-DE08DCAE8466

Ich habe etwas im Netz gesucht aber nichts Passendes gefunden und hoffe Ihr habt wieder einen guten Tipp für mich.

VG und einen schönen Tag euch!

Mir ging es jetzt auch eher darum zu sagen das es der MX Eintrag funktioniert. Die Frage war dann halt in dem Zuge schnell gestellt.

Danke trotzdem!

Hi,

vor 1 Minute schrieb NorbertFe:

Mir ist immer wieder unklar, wie man als Kunde zu solchen Hostern wechseln kann. :/ 

Ich kann dir grade nicht folgen. Was genau meinst du? SMTP Banner?

Guten Morgen,

danke erstmal für die Ratschläge.

Ich habe es heute nochmal getestet und siehe da nun funktioniert es!

Jetzt möchte ich das nächste Problem angehen und zwar wird mir bei Test des Mailservers angezeigt

"Reverse DNS does not match SMTP Banner"

Habt ihr dafür auch eine Lösung?

Nochmal das Thema Edge Transport Server:

Ist das zwingend notwendig, diesen zu installieren und ihn dann in eine DMZ zu bringen?

Ich rede von kleinen Umgebungen mit 10-20 Postfächern

Grundsätzlich verstehe ich die Idee und sehe das auch so! Wenn ich aber bedenke was die Kunden für Ressourcen dafür benötigen damit man ein sicheres System herstellen kann verstehe ich nun warum dann eher Office 365 oder Exchange Online fociert wird. Dann ist wohl ein Exchange on Premises wohl nicht für kleine Unternehmen geeignet?

Ich wünsche euch ein schönes we!

VG Robin

C:\Users\Administrator>nslookup -q=MX *.de
Server:  localhost
Address:  127.0.0.1

*.de
        primary name server = dc01.*.de
        responsible mail addr = hostmaster.*.de
        serial  = 275
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

Was ich habe in meiner subdomain:

A Record der auf meine öffentliche IP verweist

A Record für das autodiscover der auf meine öffentliche IP verweist

MX Record der auf mail.*.de verweist

TXT Record für SPF

TXT Eintrag mit dem Wert vom ISP (rDNS)

DKIM

DMARC wollte ich später noch hinzufügen

Lt. Debouncer ist alles mit meinem rDNS Record in Ordnung!

Wie gesagt habe auch keinerlei Mail Probleme 

Hi,

C:\Users\Administrator>nslookup -q=MX mail.*.de
Server:  localhost
Address:  127.0.0.1

mail.*.de   MX preference = 1, mail exchanger = Exchange.*.de
Exchange.*.de       internet address = interne IP des Exchange

Hallo,

nachdem in meiner Teststellung alles gut geklappt hatte den MX Eintrag usw. zu setzen und es keine Fehler gab, testete ich das bei uns intern. Ich habe hier allerdings Fehler bei MXToolBox:

Wenn ich den MX Lookup ausführe kommt als Fehler DNS Record not found

Teste ich den E-Mail Server kommt SMTP Reverse DNS MismatchOK - *.*.*.* resolves to mail.*.de (also scheint ja der rDNS Eintrag zu funktionieren. Da er die feste IP zu einem von mir gesetzten Namen auflöst)

Mails scheinen bis jetzt versendet zu werden ohne jegliche Probleme. Trotzdem wurmt mich das grade.

Ich bitte um Hilfe.

VG Robin

Ah ok verstehe, danke für die Antwort!

Langsam kommt Licht ins dunkle :)

Hallo,

weiter arbeite ich an meiner Exchange Testumgebung. Ich möchte die Sicherheit verbessern mit einem HA Proxy den habe ich auf einer pfSense konfiguriert. Nun habe ich dazu eine Verständniss frage. Auf der pfSense habe ich den Port 443/80 freigegeben nur für den Exchange Server. Wenn ich den HA Proxy nutze könnte ich diese Ports doch schliessen, damit eben alles über den HA Proxy läuft. Ist das richtig?

Sollte ich einen Exchange immer in einer DMZ betrieben oder ist das übertrieben?

Sollte ich ein zusätzliches Relay einrichten? Das quasi die ersten anfragen bearbeitet?

Spam Filter ist klar aber was gibt es noch was notwendig wäre?

VG Robin