LukiHoer

Um die gesamte DNS Geschichte etwas zu vereinfachen habe ich jetzt alle virtuellen Verzeichnisse auf autodiscover. Per Script am 2019 umschreiben lassen. Alle DNS abfragen die an autodiscover.derdomain.gerät werden am Client mit der richtigen IP aufgelöst. Der SCP hat sich so wie er soll aktualisiert nach Ausführung des Scripts. Ich habe grade zu testzwecken den R-Proxy auf ein NAT und dann auf den 2019 umgestellt. Outlook will immer noch nicht aber mein Samsung konnte sich gerade problemlos Anmelden!!!! Nachtrag. Auch mit R-Proxy geht es... der ist es also nicht.

Meine Frage war vermutlich irreführend. Die Primäre Zone autodiscover. gibt es natürlich und zeigt auch auf den 2019 (also wenn ich gerade teste ;) ) mail. dementsprechend auch. Mit meine Frage war wirklich der SCP Eintrag gemeint. Weiß jemand ob es Logs gibt die solche Fehlerhaften Anmeldeversuche mitschreiben würden? Vielleicht gibt es dort einen Hinweis.

N'Abend, Keine Fehler im DNS auffindbar. Haben jetzt 3 Leute drüber geschaut. Jegliche DNS abfragen werden wie gewünscht aufgelöst. SCP: jetzt mal ne ganz selten dämliche Frage: muss die Sub Domain = autodiscover sein? Bei diesem kunden Wurde mit mail. gearbeitet. Soweit ich weiß macht das kein unterschied oder? Die XML wird auf jeden Fall aufgerufen und am 2016 kann ich diese auch nach Anmeldung sehen. Nur wie gesagt am 2019 kommt immer wieder das Popup. Das hatte ich bereits bei einem Kunden und hatte die Hoffnung das es auch bei diesem der Fall war. Leider kann ich das ausschließen :( Vielen Dank für die Ansätze und Ideen! Gibts noch weitere? Gruß Luki

Hallo an alle! ich habe vor langer Zeit schonmal von diesem Problem berichtet. Da jedoch damals mein Zeitfenster geschlossen war musste ich die Problemlösung verschieben. Ich habe einen Exchange 2016 auf einen 2019 migriert. Bei der Migration an sich sind keinerlei Probleme aufgetreten. Doof war nur: Nachdem ich das Postfach vom Exchange Admin und Administrator in die DB des 2019er Migriert hatte habe ich nur per OWA getestet ob alles passt. Da ich mich dort anmelden konnte, Test-Mails empfangen und versenden konnte habe ich mit allen andern Postfächern weitergemacht. Nach fertigstellen das Böse erwachen. Alle DNS auf den 2019er umgestellt und ALLE Outlook Clients fragen nach dem Passwort. Sowohl Clients innerhalb der Domäne also auch Clients die nicht in der Domäne sind und die Anmeldung manuell durchgeführt wurde. Sobald ich auf die DNS Einträge zurück auf den 2016 stelle alles i.o. Ich bin dabei wie immer nach der Anleitung von Frankys vorgegangen. Alle virtuellen Verzeichnisse des 2019er = des 2016er. Authentifizierung bei den Verzeichnissen abgeglichen. Zertifikat ist von einer öffentlichen Zertifizierungstelle und auf beiden Servern hinterlegt. Im Netzwerk gibt es nur einen DC. Naja ende vom Lied war das die Postfächer in der DB vom 2019 verblieben sind und der 2016 angesprochen wird. Solange der 2016 Supportet und gewartet wird ist das ja auch erstmal i.O. Jetzt hat der Kunde Betriebsferien und ich kann mich der Sache wieder annehmen ohne diesen zu stören. Weil wir ehrlich sind weiß der Kunde auch davon, wie gesagt solange der 2016er unterstützt wird ist das ja auch kein Problem, zu mindestens nicht für den Kunden. Nach wie vor ist ein Login per OWA über den 2019er Problemlos machbar. Jegliche Clients die ich per hosts dazu zwinge den 2019er anzusprechen haben das Passwort-Problem. Das gilt auch für ActivSync Geräte. Beide sind auf aktuellest CU und Patchstand. Nun hoffe ich auf das Schwarm-Wissen. Wo würdet ihr ansetzten? Welche Logs sollten geprüft werden? Vielen Dank schonmal vorab! Gruß, Luki p.s. Die Autodiscover.xml auf dem 2016 kann nach angaben der Benutzerdaten aufgerufen werden. Beim 2019er kommt immer nur das Benutzerdaten Pop-Up wieder. Das wäre ja schonmal ein Ansatz aber in welchen Logs muss ich da nach Fehlern suchen?

Von üben kann hier nicht gesprochen werden. Der Kunde konnte sehr gut auf eine temporäre extern Synchronisation verzichten. Seine Outlook Kontakte hatten sich intern schon mit dem iPhone synchronisiert! ;) Das wundert mich leider nicht. Genau das ist das schlimme. Wir haben über "Nacht" alle Server gepatcht.. einen zu spät. Und das war ein Handwerker mit 3 Mitarbeitern/Postfächern, Pech bzw. nicht schnell genug. Nicht fahrlässig oder mutwillig. Einfach nur Pech. Aber verhindern können wir Systemintegratoren das in solchen Fällen auch nicht.

Ich hoffe das es SPÄTESTENS nach den Hackerwellen keinen mehr gibt der den HTTPS Port an den Exchange weitergibt! Die SP macht ihren Job bei uns schon seit Jahren (Wortmann Partner....) Nie große Probleme gehabt. Bei den Filtern sind wir mittlerweile bei vielen hingegangen und lassen betroffene Inhalte löschen und Markiert zustellen. Den Rest erledig dann das lokale Antivirenprogramm von anderen Herstellern... sind davon Fan das verschiedene von Engines laufen. Hatten schon das Problem mit der Festplatte ;) Auch wenn ich nach wie vor die Handhabung und vor allem die Begrifflichkeiten nicht top finde bei SP. Kabelmodem mit DHCP.... ne ist klar. Aber zurück zum Thema! Wieder Einmal schnell und unkompliziert Hilfe erhalten. Vielen Dank euch beiden! Vielleicht sollten wir mal davon weg gehen alle Kunden alle 5 Jahre auf den "neusten" Stand zu bringen. ;) Dann fällt sowas schneller auf und man hat keinen Druck sich diese Infos innerhalb kürzester Zeit zu organisieren. Gruß!

Zu Punkt 1 - Jaaa eine Info zu wenig ;) CU13 installiert, hatte die Hoffnung das auch das SU schon drinne ist um sicher zu gehen habe ich das Script ausgeführt. Zu Punkt 2- Das ist die Antwort die erhofft hatte! :) :) Zu Punkt 3 - Ja auch diese Info habe ich nicht geschrieben. Seit dem wir Exchange ohne VPN von Unterwegs verfügbar machen tunen wir das über ein Revers-Proxy. (Securepoint, falls das deine Frage war) Achja... aber kann man dann nicht zu mindestens davon ausgehen das alle SU's bis zum neuen CU mit drin sind. Es wurden mir definitiv die Lücken aus ganz 2022 angezeigt vor SU Juni 2023.

Um dem Systemintegrator nicht in den Wahnsinn zu treiben. ;) Jup, sorry hätte ich direkt schreiben sollen. Auch frisch heruntergeladen: V23.07.13.1135

N'Abend! Ich habe heute seit langen einen Exchange Server neu aufgesetzt. Der Neukunde freut sich sehr über die Funktionen ;) Installation kann ich mittlerweile im schlaf. NUR nach dem ich alles fertig gestellt habe und als letzten Step den EX aus dem Internet erreichbar machen wollte, habe ich nochmal den HealthChecker laufen lassen... als ob MS das Juni Update schon in die ISO packen würde.... pfff.... Aber ich lasse mich ja gerne positiv überraschen! Überrascht war ich auf jeden Fall nachdem das Script mit jede Sicherheitslücke seit Januar 2022 aufgelistet hat!! Mit Tränen in den Augen habe ich dann mit dem Juni 2023 Update angefangen... Tag war lang, wieso ich von hinten angefangen hab weiß ich selber nicht. Seit dem zeigt aber das Script keine einzige Sicherheitslücken mehr an?! Soweit ich mich erinnere waren zumindest die Oktober und November Updates deutlich größer als das Juni 2023. Ich kann mir also nicht vorstellen das diese mit dort mit drin sind. Es stand doch bestimmt schon jemand von euch vor der selben Frage. Lügt mich das Script nach dem Juni 2023 Update an und ich muss die anderen auch noch installieren? Oder sind wirklich alle Sicherheitspatches im Update enthalten? Noch zur Info: Server 2022 Std., EX2019 Std. neu von MS heruntergeladen. ps. er ist natürlich noch nicht aus dem WWW erreichbar... Wünsche vorab schonmal einen schönen (Feier)Abend! Gruß Luki

Das haben wir bisher schon so gemacht. Es geht dabei nur um eine Arbeitserleichterung für uns hinsichtig der Benutzer. Die immer wieder eingerichtet werden müssen. Blaupausen für die eigenständigen Domänen und Serveranlegen gibt es schon. Und ich weiß jetzt das mein Ansatz sowieso vollkommen falsch war weil eine nachträgliche Trennung nicht möglich gewesen wäre. Der Kunde weiß von unserer Idee nichts... wir hätte es Ihm erst präsentiert wenn es eine sichere und saubere Lösung mit Ersparnissen hin sichtig der Einrichtung gewesen wäre. Ich habe nicht gesagt das alle Böse sind... damit hätte ich mich ja mit einbezogen. Wobei ja oft nicht der Dienst leistende sondern der Nutznießer der Böse wäre/ist. Vielen Dank euch allen!

Das ist ne Aussage mit der ich arbeiten kann! Vielen Dank! Dann konfrontiere ich meine Chef mal damit. Hätte nicht gedacht das die M´möglichen Microsoftlösungen Komplizierter/Zeitaufwändiger ist als das manuelle anlegen von Benutzern ist. Wie gesagt Vielen Dank! ps. Ist denn der DC-Test2 jetzt der letzte Domaincontroller in der Domain Test2.de oder verabschiedet sich Test1 dann auch? ;)

Testunternehmen 2 läuft unter dem Namen der Hotelkette nicht unter dem Namen von Testunternehmen 1... daher die Unterschiedlichen Domänen. Die Mitarbeiter von Testunternehmen 1 arbeiten aber bei Testunternehmen 2. Das wiederhotl sich bei jedem Hotel was Testunternehmen 1 kauft. Und ich/wir wollen uns das Anlegen der Benutzer (in dem Fall 70) bei jedem neuen ersparen. Also um noch etwas konkreter zu werden. Die Server gehören TU2 aber gearbeitet (auf dem Terminal) wird von TU1.... zu mindestens bis zum Verkauf.

Das wäre eine schöne Welt in der sich die Dl untereinander so helfen wie du mir vorschlägst. Leider haben wir schon den Fall gehabt das vorneherum die Projekt wie geplant mit Hilfe durchgeführt wurde und hintenherum die Kunde gesagt bekommen hat das es eine bessere Lösung gibt um 2 Mal zu kassieren. Aber dafür gibt es ja diese Foren in denen sich die Dl oder internen sich gegenseitig helfen ohne einen wirtschaftlichen Hintergrund. Damit es etwas durchsichtiger wird. Test1 Unternehmen kauf ein Gebäude und macht ein Hotel daraus welches durch einer der großen Hotelketten vermarktet wird. Also Testunternehmen baut das Hotel auf, sucht sich ein Partner (Hilton oder so), kümmert sich um Angestellt, Arbeite aber auch selber als Angestellt im Hotel, betriebt das Hotel einige Zeit und verkauft es dann nach einiger Zeit mit Gewinn. Ähnelt also einer umgedrehten Franchise Kette... Ein bessere Beispiel finde ich nicht xD Ich Probe ja nicht am leben Objekt habe ja ein Testsystem. Danke für den Link ich schaue mal weiter ob ich ein Einrichtungsbespiel finde und teste es dann mal! Ich würde es gerne lernen ohne das mir meine Kollegen den Hals umdrehen! ;) für Tipps bin ich dankbar! Natürlich bin ich auch für dein Wissen dankbar @NorbertFe!!

Das stimmt. Der Chef würde dabei auch auf den Verdienst verzichten. Es gibt aber 2 Gründe das nicht zu tun. 1. Was man sich selbst beibringt vergisst man nie, außerdem lernt man dann Sache wie ich beispielweise heute, weil der DL das mit den Tree-Domains durchgezogen hätte. 2. Kommt dann immer die Frage beim Kunden auf: Wieso sollte ich dann nicht zu dem 2ten Dienstleister wechseln wenn er besser auf meine jetzige Situation passt.... Die Überlegen das der 1 Dl. alles andere vielleicht besser kann bzw. schon kennt kommt leider heute nicht mehr auf. Heute zählt gefühlt nur: Wer kann mir jetzt sofort am günstigsten helfen. Weil die Gefahr besteht das sich das Unternehmen Test1 von dem Unternehmen Test2 trennt bzw. es verkauft fällt leider Ansatz 1 aus weil ein nachträgliches trennen viel Arbeit mit sich bringt für den Test1 uns nicht bezahlen wird und fraglich ist ob der Käufer das bezahlen möchte. Hast du ein seriösen Link oder ein Tipp für mich im Bezug auf Trust Einrichtung. Wie schon erwähnt: Wenn man sich selbst etwas beibringt vergisst man es nie wieder! ;) Und vielleicht nochmal: Kann ich Test2 zurückstufen ohne Test1 zu schreddern um meine Kollegen Test1 nur kurz weg zu nehmen. Schonmal vielen Dank vorab für euer Wissen und Tipps!! @NilsK und @testperson Gruß LukiHoer

Okok... Tree böse. Welchen Lösungsweg würdest du empfehlen? 70 Benutzer aus Test1 auf Test2 anlegen scheint mir etwas umständlich. Es muss doch einen weg geben das Test 1 auch auf Test2 mit den vorhandenen Benutzer arbeiten kann. Und dann noch eine Frager dazu: Wenn ich den vorhandenen Test2 wieder zurückstufe ist der dc-test2 der letzte innerhalb der Domäne oder darf die Domäne nicht gelöscht werden wenn ich die Test1 behalten will? Sicherung wiederherstellen ist zwar möglich aber dann nehme ich meinen Kollegen erstmal das Test1 weg.... Die werden sich nicht freuen! ;)