=BT=Viper

Ist eigentlich auch so der letzte Strohhalm den ich noch hab. Aber eigentlich macht es keinen Sinn und da er beim Kopieren abkachelt ist das recht unwahrscheinlich. Mein Kollege versucht grad das in seiner Entwicklungsumgebung nachzustellen.

Ja das ist klar, da hab ich ja das gepostete Log her. Gibt es denn nicht mehr zu sehen? Oder kann man nen Debug aktivieren das man mehr sieht?

Es ist echt komisch... er fängt an zu kopieren, hängt lang bei 16%, macht dann weiter bis 85%, springt auf null, dann dauert es ne Weile und dann kommt der Fehler. Ne Norbert, ist alles ganz neu und sauber. Im selben IP Bereich gibt es einen alten SBS2011, jedoch andere Domäne und die DNS kennen sich nicht. Also keine Vertrauensstellung oder so.

Gibt es eine Möglichkeit im Log noch mehr zu sehen was schief geht? Der Fehler 1603 ist ja recht allgemein.

Ich hatte es zuvor so gemacht das alles durchgepatcht war und Defender auch aus. Hat alles nix gebracht. Das mit dem alten ISO war so ein Versuch falls doch irgend ein Update Ärger macht.

Klaro, hab jetzt auch nochmal alles total sauber mit einem alten 2019 Server ISO aufgesetzt und laufe in den selben Fehler. Bei der Exchange Installation halte ich mich an die Anleitung von Franky: https://www.frankysweb.de/howto-installation-von-exchange-2019-auf-server-2019/ Ein Gedanke kommt mir gerade... Der Exchange will ja min 128GB RAM. Die hat er grad nicht, Sollte aber an der Stelle ja nicht das Problem sein.

Der DC mit DNS

Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : Server-DMC Prim„res DNS-Suffix . . . . . . . : nt-bla.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : nt-bla.local Ethernet-Adapter Ethernet: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft Hyper-V Network Adapter Physische Adresse . . . . . . . . : 00-15-5D-65-05-08 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::7478:f17:3246:57b0%3(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.101.3(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.101.1 DHCPv6-IAID . . . . . . . . . . . : 50337117 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-26-55-5E-B6-00-15-5D-65-05-08 DNS-Server . . . . . . . . . . . : 192.168.101.3 NetBIOS ber TCP/IP . . . . . . . : Aktiviert

Bin jetzt grad dabei alles nochmal neu zu installieren mit nem älteren 2019 ISO. Aber der DC zeigt seine Verbindung noch immer als Öffentliches Netzwerk an. Damit fängt es schon an. Deaktiviere/Aktiviere ich den Adapter, Ist es OK. IPv6 ist komplett auf automatisch.

Da die Server nicht per IPv6 erreichbar sein müssen. Aber wurde ja auch neu installiert mit IPv6 und hat auch nix gebracht. Aber zu IPv6 noch die Frage, stellt ihr DNS auf automatisch oder lasst ihr es wie es ist?

Ja Sunny, schalte IPv6 immer als erstes ab. War ja auch nur eine der vorgeschlagenen Lösungen zu dem Problem. System hat Vollzugriff auf Quelle, Ziel und Temp Ordner. Und nochmal runtergeladen hab ich es natürlich auch schon. Die Lösung oben hab ich auch schon gesehen, ist aber nicht relevant da ja noch keine Exchange Dienste installiert sind.

Ich hoffe es hat noch jemand ne Idee, denn so langsam hab ich glaub alles durch was ich im Netz finden konnte. Umgebung: DC Server 2019 (Da Neuinstallation wurde dieser schon neu Aufgesetzt) Exch. auf Server 2019 (auch schon nochmal neu aufgesetzt) Das Exchange Setup bricht immer beim Kopieren der Dateien ab mit der Meldung: Was bisher versucht wurde: 1. IPv6 aktivieren 2. Defender aus 3. ISO entpackt und liegt lokal 4. Das Ding mit den 8.4 Dateinamen deaktiviert 5. Setup mit Rechtsklick als Admin ausführen Diesen Fehler bekomme ich im Anwendungsprotokoll bevor die Dateien kopiert werden: Und ich muss noch eine Anmerkung zum DC machen, der hat die Problematik das er nach dem Reboot das LAN als öffentliches Netzwerk anzeigt und dies bisher nur über Deaktivieren/aktivieren der Schnittstelle behoben werden kann. Alle andern Lösungen haben hier nicht gefruchtet. Es handelt sich um virtuelle Maschinen im Hyper-V die mit den aktuellen ISOs installiert wurden. Einzig das Setup mal mit CU4 zu versuchen konnte ich nicht machen, da ich im MS VLSC scheinbar nur das CU5 bekomme. Wie schon erwähnt habe ich schon alles neu aufgesetzt und bekomme immer die selben Fehler, sei es am DC oder EXCH. Und es ist nicht das erste Mal das ich sowas aufsetzte, ausser mit komplett 2019. Ich hoffe es hat jemand ne Idee.

Ich hab ja schon einige Kunden übernommen und hatte keine Probleme weil alles nach Schema F gemacht wurde. Aber sowas wie hier hab ich noch nie gesehen! Da hat einer mit 0 Wissen seinen Spieltrieb ausgelebt und echt rumgepfuscht. Die Entscheidung ist mir auch nicht leicht gefallen, aber wird im dem Fall wohl echt der beste Weg sein, wenn auch nicht leicht. Aber dann pack ich auch nicht bei jeder Aktion in die Sch.... Mittlerweile haben wir uns auch entschieden einen anderen Domänennamen zu nehmen. Nicht das wir uns doch noch dadurch wieder Eier legen.

Hi, wir haben vor einiger Zeit einen Kunden übernommen. Bisher haben wir uns durch das total unübersichtliche Konstrukt im AD und den GPOs durchgewurschtelt aber wo wir den Deckel vom Topf heben, ergeben sich neue Baustellen. So sollte z.B. der Exchange migriert werden, jedoch knallte es hier schon beim Setup wegen Fehlern im Exchange und AD. Weil das ein endloser Rattenschwanz zu sein scheint, haben wir beschlossen das Netz neu aufzusetzen. So viele Clients sind es nicht und daher überschaubar. Jetzt würden wir gerne den selben Domänennamen nutzen, was natürlich so erstmal nicht möglich ist. Da alles virtualisiert ist könnte ich natürlich die Domäne erstmal in einem privaten Netz installieren und danach auf den anderen LAN Adapter switchen. DNS technisch würden die Domänen nichts voneinander wissen und es müsste auch kein Datenaustausch stattfinden. Lediglich während der Umstellung wären beide DC verfügbar bis die Client umgezogen sind. Was meint ihr dazu?

Ja natürlich SNMP

So, endlich mal wieder Zeit für F&E im Büro :) Die verschiedenen Anwendungen hab ich mir schon angeschaut. Über PRTG stolpert man da ja automatisch. Die anderen Vorschläge muss ich mir noch anschauen. Bei meinen Recherchen hierzu bin ich aber darauf gestoßen, dass meine Switche natürlich auch entsprechende Infos per SMTP liefern muss, also die Traps wie Broadcast Storm Control einstellen. Das wirkt auf den ersten Blick wie eine Wissenschaft für sich.

Mein Chef ist auf die Idee gekommen, MFA für die Anmeldung an Windows Servern zu nutzen, vorzugsweise mit dem Google Authenticator. Prinzipiell wäre das hier die Lösung, wobei ich vielleicht nicht gerade eine Firma aus Moldawien bevorzugen würde: https://www.rohos.net/2014/02/google-authenticator-otp-zur-windows-anmeldung-verwenden/ Da wäre also die erste Frage ob ihr eine derartige Lösung kennt, bevorzugt von einem deutschen Hersteller, oder zumindest Europa? Die andere Frage die ich mir stelle ist: Was ist mit Diensten die z.B. vom Domänen-Admin gestartet werden. Sind die dann auch davon betroffen? OK, hängt natürlich davon ab wie das MFA AddOn arbeitet. Wenn es sich nur in die Anmeldemaske lokal und remote einklinkt , sollte das ja kein Problem sein. Wie sind da eure Erfahrungen?

Ich möchte mehrere Switche per SNMP überwachen und per Mail benachrichtigt werden falls z.B. viele Broadcasts auftauchen oder fehlerhafte Pakete usw. Jetzt gibt es da ja etliche Programme dafür von kostenfrei bis stattlicher Preis. Welche könntet ihr da empfehlen?

Achso… Das wäre dann meine lokale IP

Äh okay, und warum nicht?

POPCon=Käse … OK, stimme ich zu. Aber dennoch müsste ich das doch in dieser Konstellation umsetzen können, oder?

Da bei einem Kunden immer wieder gefakte Mails mit der eigenen Domäne ankommen, überlegen wir SPF einzusetzen. Für mich ist das Thema neu und ich bin gerade dabei mich da rein zu lesen. Aber vielleicht könnt ihr mir mal eure Erfahrungen dazu mitteilen und Tips geben. Der Exchange holt die Mail mittels POPCon vom Mailserver im Web ab, auf dem der SPF Record schon gesetzt wurde. Nach meinem jetzigen Verständnis muss ich dem Exchange sagen, dass er alle Mails von meinedomäne.de ohne oder mit falschem SPF markieren soll. Beschrieben ist das Ganze ja hier: https://docs.microsoft.com/de-de/Exchange/manage-sender-id-exchange-2013-help Oder gibt's noch bessere Beschreibungen?

Ja ich vermute auch das Problem ist das die Konfig auf der Platte ist. Dann bau ich halt doch noch so nen Davicontroller ein, mit denen geht's.

Gehört zwar nicht ganz hier her... Ich habe eine Avago MegaRaid Controller SAS 9361 in einem Server 2012 R2. Ich würde gerne einen Slot nutzen um auf eine Platte zu sichern und diese wöchentlich zu wechseln. Dazu habe ich ein Raid 0 erstellt. Doof ist jetzt das er beim Wechsel der Platte diese als "Unconfigured Bad" anzeigt. Gibt es eine Möglichkeit den Port so zu konfigurieren das er die Platte automatisch als "Good" markiert und die Foreign Configuration lädt? Mit Dawicontroll geht das problemlos.

Klar, es gibt mittlerweile sehr schöne Migrationswege die ich sonst auch nutze. Mein Hauptproblemkind ist eigentlich der Fileserver auf dem noch das alte Tobit David läuft. Wird zwar kaum noch genutzt, aber ihr kennt das ja, schalte ich den ab kommt bestimmt ein paar Wochen später ein Vertriebler der irgend ne alte Mail sucht. Ich bezweifle mal das ich von Tobit noch ein Setup für die alte Lizenz bekomme. Aber die Frage war ja auch nicht nach Migrationswegen, sondern nach Erfahrungen mit Upgrades.