LukiHoer

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

Hallo NilsK, Sowohl die Benutzer aus Test1 also auch die aus Test2 sollen auf der Test2 arbeiten. Test2 Benutzer aber nicht auf Test1. Und es sind unterschiedliche Domains. Test2 ist ein Tochterunternehmen welches selbst geführt ist aber Test1 gehört. DAS kann sich aber auch schnell ändern, sodass die Test1 Benutzer nach verkauf kein Zugriff mehr auf Test2 haben dürfen. Nach meiner Recherche ist/war die Tree/Methode da die "sauberste". Ist dem nicht so? Problem Kurz und knapp: Der Exchange in Test2.de lässt sich nicht installieren.

Hallo Zusammen, vorab: TESTNETZWERK als Vorbereitung auf ein Produktivnetzwerk. Ich habe zum ersten Mal den Auftrag eine Tree-Domain zu installieren für ein Franchise Unternehmen. Vorrausetzungen: Vorhandene Domäne SERVER2016 : test1.de, DC: dc.test1.de 192.168.100.2 (,wahrscheinlich unwichtig es gibt einen Exchange *.100.3 für Domain test1.de) Site-to-Site VPN zur Tree-Domain... Portfirewall Any to Any accept... also keine Blockenden innerhalb der Netze über VPN. Routing logischerweise eingerichtet, Kein Proxy vorhanden. Ziel des Ganzen SERVER2022: Domäne: test2.de, DC: dc-test2.test2.de 192.168.101.2 , Exchange mit 101.3 für Domain test2.de (später im Produktivnetz dann auch noch DB, Terminal, ect) Wie ich vorgegangen bin: 1. 2ten DC(-test2) im 101er installiert 2. Verbindung von DC zu DC-Test2 und andersherum per pings getestet 3. Dem DC-Test2 den DNS Server DC (100.2) gegeben 4. AD per Servermanger installiert 5. DC-Test2 hochgestuft... add to existing forest.. tree Domain Test1.de und test2.de eingeben. Anmelden mit Test1\Administrator............. 6. 1. Blick nach dem Neustart alles i.o. Domain erstellt. AD-Tools sind alle da. AD-Vertrauensstellung sieht gut aus. 7. Spaßeshalber dem Administrator aus Test1 RDP-Rechte auf DC-Test2 gegeben. Anmeldung i.o. 8. Wieder als Test2\Administrator rein und, weil ichs mal bei Frankys gelernte hab, Exchange-Admin angelegt. 9. Hier mein erstes Problem. Der Exchange-Admin muss natürlich die benötigten Rechte haben. Also Domänen-Admins -> i.o, Organisations-Admin-> Fehler: Name nicht gefunden?! Schema-Admins das selbe. weder im Suchpfad Test2 noch Test1?! Exchange-Admin von Test1 geprüft. Gruppen sind da.... 10. Das Setup vom Exchange hat dann auch nicht funktioniert weder mit den beiden Exchange-Admins noch mit den beiden Administratoren. (war mir vorher schon klar aber die Hoffnung stirbt zuletzt) 10.1 Problem beim Überprüfen des Status von Active Directory: Es wurden keine Exchange-Objekte auf Organisationsebene erstellt. Diese Objekte können nicht während der Installation erstellt werden, weil sich der lokale Computer nicht in derselben Domäne und nicht im selben Standort wie der Schemamaster befindet 10.2 Active Directory ist nicht vorhanden, oder es kann keine Verbindung damit hergestellt werden. -> der Server selber ist aber in der Domäne Test2.de 11. Nochmal die Kommunikation zwischen den beiden DC's auf Netzwerkebene geprüft... ping, tracert etc. alles i.o. Routing funktioniert. 12. Ereignissanzeige auf dem DC-Test2: 1. Fehler: Der DFS-Replikationsdienst konnte keine Verbindung mit dem Domänencontroller "" zum Zugriff auf die Konfigurationsinformationen herstellen. ...... (wieso "" muss da nicht DC.test1.de stehen?) 2. Fehler: Der DNS-Dienst wurde mit weniger Rechten gestartet, da KDC zurzeit nicht verfügbar ist. 3. Fehler: Der DNS-Server konnte keine integrierte Verzeichnispartition "DomainDnsZones.test2.de"erstellen. Fehler: 9906. 4. Fehler: Der DNS-Server hat einen kritischen Active Directory-Fehler ermittelt. Stellen Sie sicher, dass Active Directory ordnungsgemäß funktioniert. Die erweiterten Fehlerdebuginformationen (die eventuell leer sind) lauten "00002199: SvcErr: DSID-03201641, problem 5002 (UNAVAILABLE), data 8585". Die Ereignisdaten enthalten den Fehlercode 13. ABER Im DNS Manger für Test2.de sieht alles i.o. aus. Namen werden aufgelöst. 14 Verzeichnispartition ist da... zumindest ist das die Meldung wenn ich eine neue erstellen will. 15. Im AD Verwaltungscenter bei beiden DC's jeweil die andere Domain hinzugefügt und Testbenutzer erstellt. Replezierung funktioniert in beide Richtungen. 16. Auf Grund des Fehlers 10.1 -> netdom query fsmo Schema-Master und Domänenname-Master = DC.test1.de -> Ist das schon der Fehler? Wenn ja was ist wenn ich diese auf den DC-test2 verschieben? läuft danach noch alles im Test1 Netzwerk? Würde das auch wenn es nur ein Testnetzwerk ist nur ungerne machen ohne sicher zu sein. Weil der Exchange im Test1.de als "Vorlage" für einiges dient. müsste also alles dokumentieren damit meine Kollegen sich an dieser Doku orientieren und nicht mehr an dem Exchange. Eigentlich soll ja das Ziel der Tree-Domain sein das AUCH unterschiedliche Exchangeversionen miteinander bzw. unabhänig laufen können weil diese ja garnicht miteinander kommunizieren sollen. Zumal ich ja sowieso keinen älteren Exchange installieren möchte sondern nur einen 2019er. Es fehlt mir ein wenig der Ansatz was das Ursprungsproblem ist. Ist schlichtweg beim Heraufstufen was schief gelaufen? Gibt es nur Grundkonfigurationen die für eine Tree-Domain benötigt werden? Für jeden Ansatz bin ich dankbar weil der Kunde natürlich die Installation schon gerne vorgestern gehabt hätte. Und bitte nicht die Aussage: "Einen Dienstleister anrufen" treffen. Ich bin der Dienstleister. Und wenn immer nur die DL die es schon wissen Projekte umsetzten wird es irgendwann keine mehr geben die es könnten. Gruß LukiHoer

Ich finde es einfacher für reine Lizenzkonten die Passwörter unterschiedlich zum Domänenkonto zu halten. Damit kann der Admin auch Datenschutz umgehen wenn es zur Neuinstallation kommt ;) Also: 1. Neues Profil = beim anlegen Fehlerbild identisch. 2. Webproxy ja aber für interne Kommunikation deaktiviert. Habe aber auch Testweise den GW der DC's, Exchange's, und meine Testclients in ein "anderen" Router im Netz gesetzt. (Keine sorge den Router bzw die 2te IP des Routers/Proxys habe ich natürlich direkt wieder physisch entfernt ;) ) 3. Split DNS ja. Auch wenn ich/wir oft damit arbeiten vermute ich da meinen oder den Fehler weil: Habe die Einträge zurück auf den "alten" Exchange gesetzt und siehe da die Outlooks starten auch intern wieder Problemlos. Dazu folgende Infos: Die Postfächer liegen schon auf dem neuen.... Test per OWA nach der Mig war ja auch io. Beide Exchange haben den neuen DC als als DNS-Server. Den alten DC habe ich mittlerweile sogar schon runtergestuft und entfernt. Ich habe die Einträge im DNS jetzt schon mehrfach hin und her getauscht um Tippfehler meinerseits auszuschließen. OOOODER Gibt es vielleicht noch ein unterschied in der Authentifizierung von einem 2016 zu 2019 den ich nur nie bemerkt habe? Den Kunden haben wir im Sommer übernommen weil schon der Vorgänger massive ausfälle und Datenverlust am Exchange bzw. Mailtechnisch verursacht hat. Nur wie schon erwähnt haben wir alle damaligen Problemchen beseitigt und seit dem läuft alles einwandfrei. Nicht das der irgendwas abweichend der "Norm" vorgenommen hat was bisher nicht zum tragen gekommen ist weil kein 2019er da war. Wir haben im Januar nochmals ein Wartungsfenster daher werde ich es erstmal so belassen um keinen Druck zu bekommen. Es ist zwar nicht schön aber auch nicht pauschal unsauber. Endgültig würde ich das natürlich schon gerne Umstellen. Für weitere Ideen wäre ich dankbar. Danke für deine Hilfe und Ansätze Gruß Luki

Nein definitiv lokales Anmeldefenster... Die unterscheiden sich ja optisch, außerdem plopt das Fenster zu schnell auf für online. Aber ich hab auch schon das Onlinepasswort probiert. Und noch ein Nachtrag: Von Außerhalb kann ich Outlook konfigurieren bzw. die Handys und Laptops außerhalb der Domain funktionieren. Ich suche jetzt schon seit 2 Stunden meine falschen internen DNS Einträge. Aber jegliche Pings werden sauber aufgelöst.