Jump to content

fly87

Junior Member
  • Content Count

    143
  • Joined

  • Last visited

Community Reputation

10 Neutral

About fly87

  • Rank
    Junior Member
  1. Hallo Zusammen, ich bin immer dran als echte Archivierungslösung MailStrore-Server einzuführen. Ich habe es mir nur noch nicht wirklich anschauen können. Falls da jemand Erfahrung hat oder eine Lösung empfehlen kann, bin ich da offen für. Bisher läuft das so, dass ich ausgeschiedene gar nicht lösche sondern nur deaktiviere und ausblende. Bei unserer überschaubaren Unternehmensgröße stellte das noch kein Problem dar. Das macht die Sache aber nicht besser. Irgendwann wird es auch hier kritisch. Deshalb würde ich mir gerne bevor das passiert eine Lösung überlegen. Postfächer ins PST exportieren hatte ich auch schon mal im Sinn jedoch mache ich mir Gedanken, wie beständig ein solches File ist. Ist das File beschädigt sind die Mails verloren. Und unter Umständen bemerkt man das gar nicht oder erst dann, wenn man wieder Zugriff benötigt. in meiner Überlegung mit der zweiten Exchange Datenbank hätte ich die AD Benutzer Objekte einfach behalten als deaktivierte Objekte mit dem Zusatz, wann deaktiviert wurde. Auf den Bändern hätte man die Möglichkeit zu hinterlegen, welche Postfächer bzw. welcher Stand einer Datenbank gesichert wurde. So kann man im Ernstfall schnell das richtige Band identifizieren und müsste zusätzlich nur das AD Objekt wieder aktivieren. Nach 10 Jahren leert oder entsorgt man die Bänder und löscht die zugehörigen AD Objekte. Ist natürlich alles kein Enterprise in dem Sinne sondern mehr der Versuch möglichst Kostenneutral aber trotzdem Effizient ein gutes Modell hinzustellen. Wie toll das Modell wirklich ist, höre mir dann gerne hier an. ;) Ich habe nicht den Anspruch zu behaupten, dass meine Lösung das Non-Plus Ultra ist. Sie kann genau so gut für die Tonne sein aufgrund von Umständen die ich nicht bedacht habe. LG Fly
  2. Hallo Zusammen, ich habe hier ein Thema welches mich schon länger beschäftigt. Mein Backuptool Arcserve kann leider nur die ganze DB sichern und nicht einzelne Postfächer. Ich stelle mir jetzt die Frage, wie ich am besten vorgehe um ausgeschiedene Mitarbeiter ins Archiv zu packen, da E-Mails ja viele Jahre aufbewahrt werden müssen. Möglich wäre ja: Sicherung der ganzen DB auf ein Band und dieses kommt ins Archiv. Das ist natürlich insofern b***d, als das ich dann auch immer Benutzerpostfächer im Backup habe, die da gar nicht hin müssen. Ein anderes Backuptool steht momentan auch nicht zur Debatte. Das wäre vom Gefühl her schlecht durchdacht. Jetzt hatte ich überlegt, eine zweite DB in Exchange einzurichten und die ausgeschiedenen dorthin zu verschieben. Dann eine Sicherung durchzuführen und dann die Postfächer zu löschen. Von meinem Gedanken her müsste das dann so sein, dass ich aufgrund der Zuwachssicherung die bereits auf dem Band gespeicherten Postfächer nicht verliere, selbst wenn sie bereits auf Exchange gelöscht wurden. Würdet ihr dem Gedanken so zustimmen? Ist die Lösung gut oder gibt es sogar noch bessere Möglichkeiten? Ich bin hier Einzelkämpfer und habe leider niemanden mit dem ich Ideen oder Gedanken austauschen könnte. Deshalb hoffe ich, hier ist keiner böse wenn ich dieses Forum manchmal für meine geistigen Umnachtungen "missbrauche". Man kann alleine einfach nicht alles wissen. Deshalb bin ich Dankbar um eine solche Möglichkeit des Austausches. LG Fly
  3. Hallo, vielen Dank für die Links. Diese sind bekannt. Falscher Weg für wen? Für dich vermutlich. Ich persönlich bin kein Freund von Pauschalaussagen, die wenig hilfreich sind. ;-) Wenn Du dazu geschrieben hättest das es sich um ein bekanntes Problem handelt, was ich derzeit noch nicht weiß dann wäre das ja ok. Aber so kennst Du weder meine Umgebung noch weitere Entscheidungen die zum ausrollen dieser Version geführt haben. Auch wenn dir das aus deiner Sicht nicht unbedingt einleuchten mag. Das muss aber auch nicht. :) Und da Text das schlecht transportieren kann. Diese Aussage von mir ist in keiner Weise "böse" gemeint. Warum macht man sowas? Nur ein paar wenige Gründe angeführt: Diese Version wurde weitgehend getestet, Kompatobilitäts Issues aufgrund 3rd Party Software etc müssen ausgeschlossen sein, CUs kommen häufiger als Updates von 3rd Party Herstellern... Der Betrieb muss sichergestellt sein. Sicherlich hätte man auf ein CU 2 oder 3 setzen können als die Testphase begonnen wurde, hat man aber nicht. Für mich wäre daher interessant, ist dieses Phänomen ein bekanntes der RTM Version? Oder hat jemand weitergehende Infos? Wir werden das CU7 in einer Lab Umgebung mal testen und schauen ob dort das Phänomen ähnlich ist. Grüße und allen erst mal vielen Dank Fly87
  4. Hallo ja, ganz sicher. Die entsprechenden CU's kommen in einem nächsten Schritt.
  5. Ihr Lieben, ich habe hier ein seltsames Problem und weiß nicht weiter. Vielleicht könnt ihr helfen. Exch2016 Version 15.1 ‎(Build 225.42) als alleiniger Exch. Keine älteren Versionen vorhanden. Migration von 2013 auf 2016. System läuft soweit stabil und ohne größere Probleme. Konfig der Virtual Directories wie folgt: Interne und Externe URL identisch, über Split DNS entsprechend aufgebaut nach Zonen. Das heißt autodiscover etc. ist jeweils ne eigene Zone. Klappt soweit auch. Entsprechende Abfragen lösen von intern jeweils die interne IP auf, von extern die public IP. Das selbe gilt für AutoDiscover. Die interne URL für Autodiscover zeigt ebenfalls auf die entsprechende URL und nicht auf den Servernamen. Der SCP für autodiscover passt ebenfalls. Manuelle Outlook Konfig und entsprechnder Test bringt ebenfalls das richtige Ergebnis. Server bereits neu gestartet. Keine Änderung. Problem: Neue Clients bzw. frische Outlook 2013 Clients fügen ein Mailprofil hinzu. Die automatische Erkennung jeodch leitet sofort auf den Servername und nicht auf die interne/externe URL. Das ist ansich zumindest für mich nichts neues. Das hat der Exchange 2013 auch gemacht. Klickt man dann auf weiter gibts ein Zertifikat Error, weil Exch2016 versucht auf den Servernamen zu refrenzieren. Das war jedoch beim 2013er nicht der Fall. Bei manueller Konfiguration des Clients ist das jedoch nicht der Fall und erfolgreich. Klicke ich jedoch während der Einrichtung auf Namen prüfen ändert sich die URL ebenfalls zum Servernamen, auch bei manueller Einrichtung. Es gibt allerdings keinen Zertifikatsfehler. Also nehme ich an es handelt sich dabei nur um eine Anzeige. Frage an euch: Was vergesse ich oder mache ich falsch? Alle Dienste und Verzeichnisse inkl. der SCP's zeigen auf die interne/externe URL und trotzdem gibts bei der Auto Erkennung dieses Problem. Outlook meldet dann entsprechend bei jedem Start das dass entsprechende Zertifikat nicht passend ist. Manuell klappt es jedoch. Danke und lieben Gruß Fly87
  6. Hallo Zusammen, ich habe eigentlich gedacht ich hätte es schon so gut wie möglich erklärt. So kann man sich irren. :shock: Also zur Situation: Es gibt ein verbautes und verbasteltest AD DS auf der 2008 R2 Funktionsebene. Das Schema und der Forest selbst hatte teilweise verstellte Objekte die eine Installation von Exchnage z.B. unmöglich machten. Die Anpassung des Schemas durch die Setuproutine brach mit unbeklanntem Fehler ab. Daraufhin haben wir, weil die Möglichkeit der Neuinstallation vermieden werden musste, eine Säuberung des gesamten AD DS vorgenommen. Dazu gehörten auch Elemente aus dem Schema. Uralte Exchange Einträge zum Beispiel. Dies war auch erfolgreich. Entsprechend umsichtig wurde gerade in dem Zusammenhang gehandelt. Danach haben wir uns den Berechtigungen gewidmet. Auf dem höchsten Objekt des Domänenstamms waren im Reiter Sicherheit alte Sicherheitsgruppen eingetragen, die als unbekannte Konten aufgeführt werden, weil es die entsprechenden alten Sicherheitsgruppen bereits im Vorfeld schon nicht mehr gab. Diese haben wir entfernt. Für alle Objekte, die in irgendeinerweise die Domäne Administrativ beeinflussen können z.B. das Objekt des Domänenadministrators. Account Name: Administrator oder die Sicherheitsgruppen Schema-Admins, Domänen-Admins usw. wurden diese alten Sicherheitsgruppen nicht entfernt, weil die Vererbung deaktivert wurde. Das zog sich durch alle Sicherheitsgruppen und Objekte, die Administrativ die Domäne beeinflussen können. Auch das wurde bereinigt und über beide DC's repliziert. Die Folge war: Benutzer können sich wieder anmelden, die Replikation funktioniert wieder usw. Danach haben wir begonnen einen Exchange 2016 sauber in das Schema und den Forest zu integrieren. Eine Demo Umgebung durfte und konnte zu unserem Leidwesen nicht erstellt werden. Also wurde das gesamte AD DS per Backup gesichert. Dieser Vorgang war erfolgreich. Auch die Installation und die Inbetriebnahme des Exchange hat ohne erkennbare Probleme funktioniert. Man könnte meinen alles gut gegangen. System läuft. Wäre da nicht folgender Umstand: Die Gruppen Domänen-Admins, Schema-Admins, das Objekt Administrator usw. haben plötzlich wieder die unbekannten Objekte in ihrer ACL. Beim ersten mal hält man das für einen sontigen Fehler. Es wurde wieder angepasst. Beide DC's haben den selben Stand ohne diese unbekannten in ihrer ACL. Einige Stunden später sind diese Objekte wieder da. Und ich weiß ehrlich gesagt nicht warum. Ich weiß nicht woher die repliziert werden. Untersucht man diese unbekannten Konto ACL Einträge genauer, stellt man fest das diese z.B. die Berechtigung "Exchange Personal Information" lesen haben. Oder andere Exchange Elemente. Ich hänge mal ein Bild zur Visualisierung an. Ich frage mich: Woher stammen diese offenbar alten unbekannten Konten. Woher werden die repliziert oder wiederhergestellt? Es gibt nur nachweislich zwei DC's die aber korrekt replizieren. Das heißt enfernt man diese Gruppen sind sie auf beiden DC's auch weg. Nach Stunden sind sie plötzlich wieder da. Ich hoffe mich jetzt verständlicher ausgedrückt zu haben. LG, Fly87
  7. Hallo Nils, das wir die Replikation abgeschaltet haben nach der Säuberung hatte u.a. den Grund das wir herausfinden wollten wie sich das AD DS nach dem vorbereiten auf Exchange verhält. Vorher gab es u.a jede Menge Fehler die von dcdaig und weiteren Analyse Tools ausgeworfen wurden. In einer Umgebung, die nicht so verbaut ist käme uns das auch nicht in den Sinn. Alle Objekte die Administrative Funktionen ausführen haben eine Reihe unbekannter Konten im Sicherheitsreiter des jeweiligen Objekts. Das kann der Account Administrator sein, das kann der Account IT_Admin sein völlig egal. Sobald diese Accounts die Gruppen Organisations-Admins, Domänen-Admins etc. zugewiesen haben tauchen diese Konten nach einiger Zeit dort wieder auf. Selbst wenn sie entfernt wurden und der Account auf Standardwerte zurückgesetzt wurde. Bei genauerer Analyse stellt man fest das dies alles alte Exchange Objekte sind wie z.B. die Server oder Subsystem Gruppe... Mit Stamm vorbereitet meinte ich die Anpassung des Schemas, die Vorbereitung des AD DS für Exchange. Sprich sämtliche Vorab Vorbereitungen des AD DS für Exchange. Ich leider auch nicht. Solange es keine Exchange Vorbereitung gibt im AD DS tauchen diese unbekannten Konten nach entfernen nicht wieder auf. Wird aber die Vorbereitung durchgeführt sind kurze Zeit später auf den genannten Konten die unbekannten Konten wieder da. Ein Vergleich in einer sauber aufgesetzten Testinstallation konnte dieses Verhalten nicht hervorrufen. Grüße Fly87
  8. Leider leider ist das eine Produktive Umgebung dort vor Ort. Es gibt natürlich Backups nach der Säuberung. Interessant ist aber eines: Solange kein Exchange den Weg in die Umgung findet bleiben die entsprechenden unbekannten Konten auch dem System fern.
  9. Hallo Zusammen, der Betreff ist etwas b***d gewählt aber mir fiel nichts passenderes ein. Eigentlich ist dieser Beitrag eine Mischung aus AD DS und Exchange. Ich schildere es einfach mal: Umgebung mit zwei DC's je auf 2K8R2, Funktionsebene 298R2. Installation eines Exchange Servers 2016 durch Benutzer ohne Kentnisse durchgeführt. Das klappte nicht, also das System gelöscht und neu aufgesetzt. Dann wurden geteilte Berechtigungen aktiviert und man erreichte wieder nicht was man wollte. Schlussletztlich sitzen wir jetzt an dem System. Leider ziemlich verbaut und vernarbt. Vieles konnten wir in Ordnung bringen. Wir haben uns entschlossen, weil es aus das angedachte Exchnage System nicht mehr gibt aber ein Exchange 2016 integriert werden soll, die AD DS Datenbank zu reinigen. Inkl. des Schemas. Zur Säuberung gehörte u.a. die Löschung alter Security Principals die mal auf Exchange verwiesen hatten. Einzelne Gruppen und Benutzer wie z.B. die Domänen-Admins wurden durch geteilte Berechtigungen verändert und die Übernahme übergordneter und vererbter Berechtigungen ausgeschaltet. Dies wurde wieder in den Standard zurückversetzt. Das war auch alles soweit erfolgreich. Auf beiden DC's stimmt das Schema, die Datenbank, alles identisch. Replikation wurde entsprechend manuell angestoßen Wir konnten anschließend den Stamm und das Schema sauber mittels der entsprechenden Befehle auf die Integration eines Exchange vorbereiten. Dieser Vorgang war ebenfalls erfolgreich. Wir hatten im Vorfeld die Replikation abgeschaltet. Nachdem nun Stamm und Schema auf MsExch vorbereitet waren haben wir die Replikation wieder eingeschaltet und einmal manuell angestoßen. DcDiag etc. alles sauber ohne Fehler. Jetzt der Hammer: Die unbekannten Konten auf den Gruppen Domänen-Admins, Built In Administratoren etc. sind wieder da. Wir wissen aber nicht woher die repliziert werden. Es gibt nachweislich nur zwei DC's. Beide hatten vor der Schemaanpassung den selben Stand ohne diese unbekannten Konten. Nach Prüfung stellt man fest es handelt sich um alte Exchange Objekte. Habt ihr eine Idee was das sein kann? Freue mich auf eine Rückmeldung. Viele Grüße Fly87
  10. Ja es gibt nur einen. Das Netzwerk ist auch vom Live Netz getrennt... Aber ich vermute das Hund ggf. darin begraben liegt, dass ein Exchange 2003 aus diesem System nicht richtig entfernt wurde. Das habe ich gerade im Moment erfahren... Das System wurde 2008 mal installiert und dann vermutlich nicht richtig entfernt. Nun schleppt man das nun schon durch die Jahre hinweg mit. Kann es sein, dass es hier Probleme gibt? Edit: Wobei ich gerade mit dem ADSI Editor festgestellt habe, es befindet sich kein alter Exchange Eintrag im AD DS. Weder unter den Servern noch findet man irgendwo einen Hinweis... Also wurde es wohl doch korrekt entfernt damals.
  11. Hallo Forum, wir haben zum ersten mal und weil wir überlegen auf Exchange zu wechseln einen Exchange 2016 installiert. Das ganze in einer Test Achtive Directoriy Struktur. OWA funktioniert tadellos. Lediglich Outlook bereitet uns Probleme. Wir richten das Konto ein. Das funktioniert wunderbar. Wir geben den Servernamen ein und den Benutzeraccount und Outlook zieht alles notwendige vom Exchange Server. Nach einiger Zeit so ca. 3 - 5 Minuten gibt es die Meldung: Der Exchange Administrator eine Änderung durchgeführt, dies erfodert einen Neustart. Outlook Version ist 2013. Schließt man Outlook und öffnet es anschließend gibt es die Meldung: Outlook kann nicht gestartet werden. Das Outlook Fenster kann nicht geöffnet werden. Diese Ordnergruppe kann nicht geöffnet werden. Fehler bei der Anmeldung an Exchange. Kontrolliert man dann das Profil hat sich der Servername von ursprünglich: "MeinServer.intern.meineDomain.de" auf "https://MeinServer.intern.meineDomain.de/mapi/emsmdb/?MailboxId=9a937ba4-0e30-4d03-b923-d6b745fea103@externaldomain.de"geändert. Hat jemand vielleicht eine Idee was hier passiert? Und was wir ggf. tun können? Viele Grüße, Fly87
  12. Hallo Zusammen, merkwürdiges Problem... Ich kann NTFS Berechtigungen nur als lokaler Admin setzen. Setze ich diese mit einem anderen Benutzer z.B. einem Domänen Admin bekomme ich eine Meldung das der Zugriff verweigert wurde. Hat da jemand eine Idee, was hier los sein könnte? Viele Grüße, Fly
  13. Hallo Zusammen, ich fuchse mich zur Zeit immer noch in die SSIS Services rein. Ich versuche folgendes zu erreichen. Ich hab eine Excel Quelle, welche in eine OleDB geladen wurde. Komplett. Datatype nText weil selbst die Integer Zellen weiter unten String Elemente enthalten. Das hat soweit auch geklappt. Technisch sieht das so aus: Feld 1 (Zahl Datatype nText) Feld 2 (Zahl Datatype nText) Feld 3 (Zahl Datatype nText) Feld 4 (Zahl Datatype nText) In SSIS habe ich nun einen Dataflow und eine OleDB Quelle, welche genau auf diese Tabelle zeigt. Dann führe ich eine Datenkonvertierung aus um die nText auf Integer zu verändern. Klappt wunderbar. Allerdings würde ich gerne folgendes tun. Die Quelle sieht also so aus: Feld 1 Feld 2 Feld 3 Feld 4 Das Zeil sieht so aus: Feld1 Feld 2 Feld 3 Feld 4 Es sind also eigene Spalten. Wie schaffe ich es denn, die Zeilen auf Spalten aufzuteilen? Also diese 4 Zeilen zu nehmen und sie in die Spalten einzutragen. Bisher sind sie ja in einer Spalte. Danke. Lg, Fly P.s. Das ist alles nur Test...
  14. Hallo Zusammen, ich habe bei der Installation von VS 2013 ursprünglich deutsch ausgewählt. War keine so prickelnde Idee. Ich bin mit den deutschen Begriffen der Toolbox nicht klar gekommen. Manches ist zwar einleuchtend, manches aber auch komplett missverständlich. Nun hab ich schlau wie ich dachte zu sein das Language Pack Englisch heruntergeladen. Dieses eingespielt und zack ist der Oberfläche auf Englisch. Aber die SSIS Toolbox ist teilweise Dengelisch. Manches auf Englisch, aber sehr vieles auf deutsch. Das war natürlich nicht im Sinne des Erfinders. Bevor ich aber alles neu installiere auf Englisch wollte ich erstmal fragen: Ist das normal? Das OS selbst ist ein deutsches. Die Installation dauert ja so ewig lang. Vielen Dank im Voraus :)
  15. In dem Fall sind Entwickler und Admin die selbe Person... ;-) @all Vielen Dank bis hierhin. Das hilft mir schonmal weiter.
×
×
  • Create New...