Jump to content

Gerber

Members
  • Gesamte Inhalte

    238
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Gerber

  1. Guten Morgen, hat wohl niemand eine Idee hierzu oder kann mir sagen was ich falsch mache? Frohe Ostern euch. Grüße Phil
  2. Hello zusammen, ich wollte mich jetzt nochmals kurz zu Wort melden mit einer Kleinigkeit Ich habe nun diverse Szenarien der Wiederherstellung nochmals getestet und durchgespielt. Eine Frage hätte ich zur Offline Wiederherstellung: 1.) ich habe die Offline Wiederherstellung wie folgt getestet: - Exchange Datenbank Verbindung aufgehoben -> Datenbank Offline wegkopiert - Exchange DB eingebunden und diverse Änderungen gemacht. - Exchange DB Verbindung aufgehoben - ECK Datei im PFad C:\DB der Original DB gelöscht - EDB Datei aus dem Backup in das Original Verzeichnis "c:\DB "der DB kopiert und ersetzt. Somit hat die DB ja den Stand des Offline Backups - Datenbank eingebunden - Alles super und passt 2.) Offline Wiederherstellung mit ständigem Fehler bei der Einbindung der DB - Die Schritte wie oben gleich bis zur Wiederherstellung - Exchange DB Verbindung aufgehoben - Komplettes Verzeichnis (original) C:\DB nach D:\Backup wegkopiert und aus dem Original Pfad C:\DB gelöscht - Offline Backup komplett mit den Logs zum Stand des Offline Backups und mit allen Dateien in den Original DB Pfad C:\DB kopiert - Zuvor wegkopiertes (original DB) per Copy und Paste aus D:\Backup in den Pfad C:\DB kopiert und nur die fehlenden Dateien kopiert - DB eingebunden - Fehler Diesen Schritt habe ich schon mehrfach gesehen und habe ich bei mir schon mehrfach versucht. Es kommt immer zu einem Fehler und die DB kann nicht eingebunden werden. Die Backup DB hatte Clean Shutdown. Testserver ist ein Exchange 2019. Kann sich daraus irgend jemand ein Reim machen? Danke euch im Voraus. Grüße Phil
  3. @NorbertFe Hast du Recht . Dann werde ich mir mal das ganz in Hyper V kurz aufbauen. @magheinz Heheh, und den Elfmeter hast du mal sauber versenkt ... Yes. Die Situation gilt es tatsächlich im Voraus zu vermeiden. Die Stündliche Sicherung ist natürlich viel Wert und sehr schön. Grüße
  4. Ohjeee, was ist denn jetzt los. :) Das war ne einfache Frage um etwas Erfahrungsaustausch zu betreiben. Entschuldigung hierfür ... Vllt ist mir dies auch zwecks der momentanen Corona Situation in den Sinn gekommen, um mal etwas Abwechslung zu finden. Von sowas lebt meiner Meinung ebenfalls ein Forum (Erfahrungsaustausch, oder nicht?) ?. Grüße Phil
  5. @magheinz ... Ich habe ehrlich gesagt nur auf den Kommentar mit der USV und dem zweiten Server gewartet ... Ich hätte auch schreiben können. Nehmen wir an: 2 Server 2x USV und alles ist abgeschmiert . Grüße Phil
  6. Klaro gibt es genügend Unterlagen im Netz, welche ich auch schon Gefühlt alle durchgeschaut habe. Ich wollte einfach mal die Erfahrung anderer erfragen, wie Ihr an die Sache geht . Danke dir. Grüße Phil
  7. Danke dir für die Antwort. Bedeutet in diesem Fall (Falls sowas auftreten sollte) hat man keine Chance und müsste somit mit Dritt Tools versuchen an die Mails zu kommen? Kannst du mir auch zu den ersten zwei Punkten behilflich sein? - Vorgehensweise beim Restore/Repair - Defekte Datenbank mit altem Backup und aktuellen Trans Logs? Grüße Phil
  8. Hallo zusammen, gleich vorne Weg, es gibt Momentan kein Problem mit einem Exchange Server. Es geht mir lediglich um euer Vorgehen, bzw. die Möglichkeiten eines Recoverys, bzw. Reparatur der Datenbank. Angenommen wir haben einen Exchange Server mit einer Datenbank. Die Datenbank wird täglich um 22 Uhr mit Veeam gesichert und die Transaktions-Logs werden somit vom Exchange gelöscht. Aus einem nicht bekannten Grund crasht die Datenbank. Eventuell Stromausfall und keine USV Vorhanden, oder die Datenbank lässt sich einfach nicht mehr einbinden. Wie ist jetzt euer Vorgehen, bzw. welche Methoden geht ihr nacheinander durch und was versucht ihr alles, bevor Ihr die Datenbank komplett aus einem Backup wiederherstellt? 1.) Aktuelle Logs + Datenbank wegsichern / kopieren. 2.) Softrecovery mit Eseutil 3.) Hardrecovery mit Eseutil 4.) Wiederherstellung der Datenbank "Dial Tone" 5.) Recovery Group um zu versuchen die alte Datenbank wieder Online zu bekommen oder Dritt Tools ####### Zusätzliche Frage: Angenommen man sichert wie oben beschrieben jeden Tag um 22 Uhr. Die Datenbank fliegt am nächsten Tag um 18 Uhr auf die Nase. Somit hat man einen alte Datensicherung von circa 22:00 uhr und hat eine Defekte Datenbank. Zusätzlich zur defekten Datenbank hat man allerdings die noch nicht entfernen Transaktionsprotokolle. Somit kann man den wenn alles gut läuft mit der Sicherung vom Vortag und den aktuellen Logs den aktuellen Stand wiederherstellen. Wie ist hier genau das Vorgehen, um so einen Stand wiederherzustellen? 1.) Verzeichnis sichern / kopieren 2.) Verzeichnis aus Backup in das ursprüngliche Verzeichnis kopieren 3.) die Logs, welche im Backup fehlen, allerdings bis zum crash geschrieben wurden hinzu kopieren 4.) und dann versuchen per Softrecovery die Protokolle einzuspielen? Ist diese Vorgehen so richtig, oder habe ich einen Fehler. ##### Angenommen es sind einige Transaktionslogs defekt, weswegen diese nicht korrekt in die Datenbank eingespielt werden können. Kann man diese Logs mit einem Befehl ausfindig machen und löschen? Wenn mann danach wieder versucht die Logs in die Datenbank einzuspielen, wird dies erledigt oder meckert der Exchange da Zwischenschritte bei den Logs fehlen? Danke euch im Voraus. Grüße Phil
  9. @NorbertFe ich denk auch, dass ich auf den Exchange 2019 hochgehen werden. Es handelt sich um eine kleinere Umgebung, bei der ich es nicht sehr als kritisch ansehe. Dies hoffe ich natürlich auch. Grüße Phil
  10. Guten Morgen zusammen, genau. Ich wollte nur zuerst die Funktionen mit der Hosts Datei antesten, bevor ich die DNS Einstellungen komplett für alle Clients umstelle. Ebenfalls ist momentan auf dem alten Terminalserver noch Outlook 2010 im Einsatz. Die Version: 14.0.7237.5000 und ist somit mit dem Exchange 2016 kompatibel. Bedeutet ich werde nächste Woche die DNS Einstellung auf den neuen Zeigen lassen. Ehm habe ich mir ehrlich gesagt nicht wirklich Gedanken gemacht. Ich dachte wenn ich schon am migrieren bin ziehe ich den Server gleich auf Exchange 2019 hoch. Es ist kein Proxy bei diesem Benutzer im Spiel. Wie es das Gesetzt manchmal so will funktioniert heute auch unter dem Admin Profil das Autodiscover perfekt. Ich habe über Nacht nichts verändert und nichts neu gestartet. Manchmal darf man sich tatsächlich nicht alle Dinge hinterfragen . Oo, werde ich mir doch mal noch genauer ansehen. Ein Problem ist allerdings noch, dass ich nur Windows Server 2019 Lizenzen besitzen und somit eine dieser Lizenzen Downgraden müsste. Grüße Phil
  11. Hi zusammen, Ich bin gerade in einer Migration von Exchange 2010 zu 2016 und danach auf 2019. Stand ist, dass der Exchange 2016 Koexistenz läuft und Versand möglich ist. Nun habe ich zum Test 4 Postfächer migriert und auf einem neuen Terminalserver die Host Datei von autodiscover. Domain. De und Outlook. Domain. De auf den neuen Exchange angepasst. Soweit so gut. Auf dem Terminalserver mit den migrierten Postfächern eingeloggt und Outlook Profil erstellt - > alles läuft sauber. Mit einem Benutzer auf dem neuen Terminalserver eingeloggt, welcher noch ein Postfach auf dem exch2010 hat - > alles läuft super. Jetzt habe ich aber ein Postfach (admin) auf dem Terminalserver eingeloggt und bei diesem schlägt die Autodiscover Konfiguration fehl. Wenn ich unter einem anderen Benutzer die Autokonfiguration über Outlook mit den Admin Daten teste, geht er sauber auf die autodiscover. Domain. De, schlägt aber fehl. ### Es ist splitdns mit gültigen öffentlichen Zertifikaten konfiguriert. Profil wurde mehrfach neu angelegt. ### Ich kann mir nicht erklären warum auf dem gleichen Terminalserver ein Benutzer beim Autodiscover fehl schlägt ??. Hat hier jemand eine Idee zu, bzw tipps, wie ich dem Fehler auf die Schliche kommen kann(Logs und Co)... Danke euch im Voraus. Grüße Phil
  12. Hey zusammen, danke euch für die Antworten. @Dukel Danke dir @JoachimH Und wo kannst du aus dem Artikel rauslesen, dass die Datenbank nicht eingebunden wird? @NorbertFe Werde ich gleich nochmals checken. Aber habe nichts auffälliges gesehen. Für mich war einfach die Frage, ob die PUblic Folder Database eingebunden wird oder nicht. JoachimH schriebt, dass diese nicht eingebunden wird. Aber wie du schreibst, wie soll diese sonst verwendet werden Grüße Phil #### Edit: Also ich habe die Datenbank nun eingebunden und der Vorgang war erfolgreich. Eventlog ist sauber. Ich habe wohl etwas zu kompliziert gedacht :D. Danke euch für die Hilfe. Grüße Phil
  13. Hi zusammen, ich habe kurz eine Frage zur Koexistenz der Public Folder zwischen einem Exchange 2016 und 2010. Damit die Verbindung von den Exchange Konten, welche auf dem Exch 2016 liegen auf die Public Folder auf dem Exchange 2010 zugreifen können wird ein Postfach als Proxy genutzt. Ich habe auf dem alten Exchange Server 2010 eine neue Datenbank + Proxy Postfach angelegt. Dieses habe ich dann aus dem Adressbuch ausgeblendet. Nun ist mir aufgefallen, dass die PFProxyDatabase direkt nach dem erstellen als "nicht eingebunden" angezeigt wird. Danke im Voraus. Grüße Phil
  14. Ja diese Punkte haben mir zur Vervollständigung gefehlt. Danke dir für die Hilfe. Ich denke du kennst es selbst, wenn man mal vor der Wand steht und nicht weiterkommt (in den Gedanken). Outlook Annywhere hat mir gefehlt. Grüße Phil
  15. Hi Norbert, danke die für die blitzschnelle Antwort. Ich habe mir diverse Migrationsanleitungen angesehen und habe auch schon einige durchgeführt. Allerdings habe ich immer Migrationen durchgeführt, in denen ich meist alle Postfächer in einem Rutsch, oder übers Wochenende migriert habe und somit keine Verbindung zum Exchange mehr notwendig war. Ich werde mir trotzdem nochmals einige Migrationsanleitungen ansehen, vllt komme ich ja dahinter: In z.B. einer Anleitung von Franky ist allerdings zu sehen, dass er die Proxy Verbindung über das CAS Array "outlook-int.domain.de" zum alten Exch2010 aufbaut. Aus diesem Grund war ich mir nicht sicher, ob ich für die Koexistenz und die Nutzung von Autodiscover dann das CAS Array benötige. Aber in dem Fall nicht. Hast du die Geduld mir kurz zu erklären, wie der Exchange 2016 dann die Proxy Verbindung zum 2010 aufbaut, für die Benutzer welche noch auf dem Exchange 2010 liegen? Edit: Ich habe nochmals einige Forumsbeiträge usw durchforscht. Der Exchange 2016 reicht also alle Anfragen als Proxy an den Exchange 2010 weiter. Der Exch2010 kann kein Proxy für 2013 oder 2016 spielen. Aus diesem Grund muss auch dieser als Punkt für Autodiscover usw konfiguriert sein. ## Trotzdem würde mich stark der Hintergrund Interessieren, wie oder über welchen Weg die Proxy Verbindung zustande kommt. Vllt hat jemand ja noch speziellen Lesestoff für mich. Danke Grüße Phil
  16. Hi zusammen, ich habe eine kurze Frage in Bezug auf das CAS Array in Bezug auf die Koexistenz zwischen Exchange 2010 und Exchange 2016. Es soll ein 2010 Exchange auf den 2016er migriert werden. Damit weiterhin die Benutzer deren Postfächer auf dem Exchange 2010 liegen per Autodiscover ihren Server finden wird die Anfrage von autodiscover.domain.de (exchange 2016) über den Proxy auf das CAS Array vom 2010 weitergeleitet um die Anfrage der Benutzer zu bearbeiten. Hierzu hätte ich ein zwei Fragen: Natürlich werden zunächst alle Einstellungen getestet und angepasst (URLs für die einzelnen Dienste, Authentifizierung der beiden Server angepasst, usw ...) bevor z.B. die URL "autodiscover.domain.de" und dessen Eintrag auf den neuen Server umgestellt wird. 1.) Momentan ist auf dem Exchange 2010 kein CAS Array konfiguriert. Muss zwingend ein CAS Array konfiguriert werden, damit der Exchange 2016 die Anfragen welche nicht an Ihn gerichtet sind an den Exchange 2010 weiterleiten kann, oder ist dies auch anders möglich? 2.) Wenn ja, muss der FQDN vom CAS Array nur auflösbar für den Exchange 2016 sein, oder muss ein gültiges Zertifikat dafür vorhanden sein? 3.) Das CAS Array wird dann vom Exch 2016 automatisch gefunden, richtig? Danke euch im Voraus. Grüße Phil
  17. @NilsK Alles klar. Wichtig ist, wenn ich es richtig verstanden habe, dass der DC automatisch startet ? Der zweite DC werde ich jedes mal ansprechen bis er vorhanden ist . @testpersonen Heheh ok. Ja ich denke dies mit der Live Migration wird dann der beste Weg sein, oder nicht? Raid 5 hast du natürlich Recht. Allerdings habe ich dies leider so vorgefunden (lange Geschichte :D). ---- P.S. Hierzu noch eine Frage zum Raid. Es sind momentan 4x 4 TB Festplatten verbaut. Davon 3x 4TB im Raid 5 + Hotspare. Alleine dies hätte ich schon anders gemacht. Ich wäre hierbei auf kleinere Platten gegangen, aber nun sind die Festplatten mal da . Wie würdet ihr nun das Raid aufbauen? Ich habe überlegt eine weitere 4 TB Festplatte zu kaufen und entweder 2x ein Raid 1 + globale Hotspare aufzubauen oder alle Platten in ein Raid 10 mit einer Hotspare zu packen. Danke im Voraus. LG
  18. @Dukel Naja, die Infos sind eventuell für manche wichtig und ich habe es doch einigermaßen schön aufgebaut, oder ? . In einem Forum sollte man doch genügend Infos preisgeben, nicht? Shared Nothing: Yes, habe ich oben beschrieben. Da beide nicht in der Domäne sind ist dies doch nicht möglich, oder? @testperson OK. Beide Hosts in die DOmäne aufnehmen, danach eine LiveMigration auf den neuen Host durchführen. Raid neu aufbauen und danach die Live Migration zurück?
  19. Guten Morgen zusammen, ich habe eine Frage bezüglich einem Windows Server 2019 mit Hyper V und 4 Virtuellen Maschinen (DC,FILE, Zeiterfassung, Terminal). Als Backup Software wird Altaro Backup eingesetzt. Der Hyper V Host ist nicht Mitglied der Domäne, da der DC als virtueller Server auf dem Hyper V Host läuft und somit beim starten nicht erreichbar ist. Ich weiß es sollte ein zweiter DC vorhanden sein, allerdings wollte dies der Kunde trotz aller Versuche nicht und ist sich der Risiken beim Ausfall des DCs bewusst. Eventuell bekomme ich in naher Zukunft trotzdem noch ein physikalischen DC vor Ort installiert :D. ---- Hintergrund: Es wurde auf einem HP Server ein Raid 5 Verbund aufgebaut. Leider ist die Initialisierung der Parität fehlgeschlagen, so dass ich das logische Raid löschen und komplett neu aufsetzten muss. Auf diesem Raid 5 Verbund sind allerdings mehrere Volumen angelegt (Host + VMs usw ..) Somit muss ich nun den kompletten Host neu installieren und die VMS für den Übergang auf einen anderen Host verschieben. Nun die Frage an euch: Wie würdet ihr am besten vorgehen um die VMs mit so wenig Ausfall als möglich zu verschieben? Ich habe mir überlegt einen zweiten Hyper V Host Server für den Übergang vor Ort zu platzieren und mit folgender Vorgehensweise die Vms zu übertragen: 1.) Alle VMS herunterfahren 2.) Die kompletten VMs auf den neuen Hyper V Host kopieren (hard disks, Cconfig, Snapshot Ordner usw ...) 3.) Auf dem neuen Hyper V Host per Import Job importieren 4.) Netzwerkkarten anpassen 5.) DC starten 6.) restliche Maschinen starten 7.) Nach erfolgreichem Start das logische Raid erneut aufbauen 8.) Hyper V Host neu installieren 9.) Auf die gleiche Art wieder alles auf den Original Host zurück kopieren 10.) Maschinen starten ---- Was haltet ihr von dieser Vorgehensweise? Würdet ihr anders vorgehen? Meint ihr es gibt Probleme mit dem DC bei diesem Weg? Leider kann ich keine Live Migration machen, da die Hosts eben nicht Mitglied in der Domäne sind oder ist eine Live Migration auch außerhalb einer Domäne möglich? Vielen Dank im Voraus. Grüße Phil
  20. Hierzu hat wohl keiner eine Idee ???
  21. Morgen zusammen, danke euch nochmals für die Hilfe. Die Scripte habe ich bisher auch nie in den Scriptspeicher $exscripts kopiert. -- Dann werde ich wohl mal ein Ticket eröffnen und sehen was Microsoft zu diesem Thema sagt. Sobald ich die Lösung oder weiter Infos habe, melde ich mich zurück.
  22. Hi zusammen, ich will mich ein wenig mit dem Azure AD Connect Tool auseinander setzten und habe mit verschiedensten Konfigurationen versucht, einen korrekt gefilterten Sync zu konfigurieren. Allerdings ohne Erfolg. Folgendes würde ich gerne Umsetzen: - Ich habe bei der Konfiguration von Azure AD Connect eine OU "Mitarbeiter" angegeben. Nun würde ich gerne von allen Mitarbeitern in der OU, welche das Attribut "extensionAttrbite15" mit dem Wert "Azure" besitzen in Azure syncen. Also die Benutzer die bereits in Azure vorhanden sind, sollen nur mit dem Kennwort des lokalen ADs gesynct werden (sso) und alle anderen, welche noch nicht im Azure AD vorhanden sind sollen neu erstellt werden. --- Wenn ich nach der Anleitung von Docs.Microsoft vorgehe, bekomme ich ständig nur die Negative Filterung ans laufen: https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-sync-configure-filtering Bedeutet, Synchronisiere alle Benutzer nur diese nicht, die im Attribut "Azure" stehen haben. Ich will genau dies umgekehrt ans laufen bekommen. Hintergrund ist, dass wir Skype nutzen und dies nur mit 14 Benutzer und nicht alle 50 des Unternehmens. Nun müsste ich natürlich jedem Benutzer der nicht geesynct werden soll dieses Attribut verpassen. ###### Hat jemand von euch Erfahrung zum Produkt und kennt sich mit den Regel Einstellungen aus? Ich stehe irgendwie komplett auf dem Schlauch.... ### Anhand von Gruppen wäre der Sync auch sehr schön, allerdings wird dies von Microsoft nur zur Übernahme empfohlen und nicht zur Dauerlösung. Danke euch im Voraus. Grüße Phil
  23. Morgen, anbei der Screenshot von den Eigenschaften der PS Datei...
  24. Moin, heute früh ein Neustart durchgeführt. Ohne Erfolg, die Fehlermeldung bleibt die gleiche.
  25. @MurdocX Ich werde in den nächsten Tagen nochmals ein Neustart durchführen, wenn dies der Betrieb zulässt. Ich bin mir nicht mehr sicher, ob ich den Neustart nach den Einstellungen vorgenommen habe. Ich werde Rückmeldung geben. Zwecks dem Encoding: Die Datei habe ich bereits auf anderen Exchange Servern ausgeführt, deswegen sollte die PS Datei passen.
×
×
  • Neu erstellen...