Gerber

Ja One Drive 4 Business wird definit genutzt. Ja SharePoint nutze halt OneDrive als Speicher für die SharePoint Sites, Teams, Datenablage etc... Es sind aber definitiv in der Website nur 400 GB in OneDrive vorhanden und SharePoint Admin zeigt an, dass 2.5 TB vorhanden sind. Die müssen erst mal irgendwo liegen Ich werde mal ein Ticket eröffnen. Grüße Phil

Danke dir. Was mich gerade sehr stark wunder ist, dass die einzelnen Seiten gar nicht den Webspeicher beanspruchen, was angezeigt wird. Ich weiß gar nicht wo der belegte Speicher herkommen soll.

Danke dir. Kennst du evtl auch ein solches Tool?

Morgen zusammen, ich habe gerade ein kleines Problem mit einem SharePoint Online Kono. Es wird der aktuell verfügbare Speicher komplett in Sharepoint genutzt (2.56TB). Gibt es eine Möglichkeit um den verwendeten Speicher etwas genauer aufzulisten? Eventuell so eine Art Sharepoint Explorer? Ich kann es zwar nach Sites sortieren, allerdings sehe ich nur, dass eine Site 2.4 TB nutzt. Leider sehe ich nicht wo oder was den Speicher füllt. Danke euch. Grüße Phil

Ok, krass. Ja klingt nicht so gut. Ich Persönlich würde auch immer einen lokalen Exchange mit ECP betreiben. ??. Alles klar ich habe verstanden. Du federierst also immer (egal welche Größe) und kennwortsync ist ka**e... Danke euch für die Hilfe und die Infos?. Grüße Phil

. Ja da hast du natürlich vollkommen Recht. Ich weiß, dass die Tools von anderen Anbietern welche die Kennwörter in die Cloud spiegeln nicht wirklich super sind. Und das AD Sync Tool hier schon seinen Dienst gut macht. Vllt mal weg von den Microsoft Supporteten Maßnahmen . Ziel von mir war ja auch den Best Practice von euch zu erfragen, wie ihr mit genau solchen Situationen umgeht? - Generell immer AAD Installation + ein lokalen Exchange Server um die Verwaltung durchzuführen? - AD Sync + Powershell oder ADSI oder extra Dritt Tools Falls der Kunde sowas nicht will: - AD Sync abschalten und beide Welten Parallel pflegen? Danke euch. Grüße Phil

Okay okay, Es war auch einfach nur eine Feststellung, sry . Microsoft darf auch gerne eine Kennwortsynchronisation oder Authentifizierung im Netz des Kunden hinbekommen, kein Problem . Grüße Phil

Ja natürlich nicht Deswegen meinte ich ja, dass wir gerade etwas aneinander vorbei reden... Aber es passt halt wieder nicht zusammen. Wenn Microsoft sagt, sobald ein AD SyncTool eingesetzt wird, muss die lokale ECP vorgehalten werden, damit Änderungen durchgeführt werden können und es von MS Supportet ist. Ich kann hier nur immer wieder auf die kleineren Unternehmen verweißen. Welches Unternehmen mit 10 - 20 Mitarbeitern will einen lokalen Exchange ECP betreiben, wenn sowieso die Postfächer in der CLoud liege und einmal im halben Jahr eine Änderung durchgeführt wird? Diese wollen einfach nur ihren Kennwort Hash Synchronisieren. Naja, dass wollen aus der Erfahrung doch sehr sehr viele oder willst du auf jeder Plattform dein Kennwort händisch ändern? Dies ist ja für die meisten schon ausreichend, wenn das Kennwort vom lokalen AD mit dem Kennwort aus Microsoft 365 übereinstimmt, weswegen ja auch das Tool sehr häufig zum Einsatz kommt. Grüße Phil

Ich glaube wir haben aneinander vorbei geredet :D. Das Thema was du ansprichst ist mir schon klar und wird auch in dem Artikel und von dir verlinkten Text eindeutig. Tool oder ADSI Edit um die Exchange Atribute zu verwalten. Meine Frage war aber eine andere: - Wenn es z.B. bereits Postfächer in O365 gibt und das AD Sync Tool nachträglich zur Kennwortsynchronisation eingerichtet wird, ob es automatisch die Konten verknüpft. Ich habe es gerade getestet. Es wird dann automatisch das bereits vorhanden Konto in O365 auf "von lokal Synchronisiert" umgestellt. Ja ist es sicher nicht. Aber wenn ich andere Produkte sehe, welche ohne Probleme die AD Kennwörter in Ihre CLoud Syncen können um damit zu arbeiten und Microsoft bekommt es nicht hin? Ja vllt auch das. Ich persönlich bin ja ebenfalls ein Fan davon und finde auch den Ansatz sehr sehr gut. Aber wenn ich einen lokalen Exchange nur für die Verwaltung der Attribute vorhalten muss, auch wenn es noch nie einen Exchange in diesem Unternehmen gab und nur weil ich die Kennwörter Synchron halten will, dann finde ich es etwas in dem jetzigen Moment b***d gelöst. Grüße Phil

Naja die Antwort von dir beantwortet nicht wirklich meine Frage mit dem verknüpfen bereits vorhandener Postfächer in O365, oder? Hier geht es ja nur um die Verwaltung mit dem Tool und den verschobenen Postfächern. OK, da hat MIcrosoft wieder mal nicht weiter gedacht ... Naja ist doch schön sowas zu hören . Grüße Phil

Moin, Joa habe ich eigentlich gelesen. Dort wird eben das Tool zur Verwaltung der Attribute eingesetzt. Mir ist einfach noch nicht 100 Prozent Klar: - wenn es bereits O365 Postfächer gibt, kann nachträglich das AD Sync Tool angebunden und die Postfächer verknüpft werden? - Wenn dies nicht funktioniert muss ja das AD Sync Tool zwingend vor der Migration konfiguriert werden und somit würde ja nur die PST Methode in Frage kommen, bei der keine Hybridbereitstellung im AD Sync Tool angegeben werden muss. Angenommen ich richte das AD SyncTool ein ohne Hybridbereitstellung, nur Kennwort Synchronisation -> dann sind die Benutzer ja im Portal angelegt und können über das Office 365 Portal verwaltet werden, auch die Email Attribute Richtig? Hier ein Edit: https://docs.microsoft.com/de-de/exchange/decommission-on-premises-exchange#why-you-may-not-want-to-decommission-exchange-servers-from-on-premises Habe gerade selbst gesehen, dass beim generellen Einsatz von Verzeichnis Sync auch ohne Hybrid gewisse Attribute nur lokal gepflegt werden können... Korrigiert mich bitte. Aber wie machen das z.B. kleinere Unternehmen, welche generell in die Cloud gehen und einfach nur eine Kennwortsynchronisation haben wollen ? Sobald der Sync eingerichtet ist benötigen diese einen lokalen Exchange? Angenommen es kommt ein Kunde von Strato IMAP und will in die CLoud, aber will die lokalen AD Kennwörter synchron halten. Geht dies dann überhaupt`? Grüße Phil

Eine Vllt blöde Frage noch. Wenn ich nun z. B. ÜBER codetwo in die Cloud migriere. Ist es dann nach der Deinstallation vom Exchange möglich das AD Sync Tool zu nutzen und ohne Hybrid Bereitstellung zu betreiben? Grüße Phil

Hi Norbert, Danke dirfür die Antwort. Ja Adsi Edit wäre ne Option um die Exchange Attribute zu pflegen... Meinst du dritt Tools für die Migration oder für die Verwaltung der Attribute nach der Deinstallation des Exchange Servers? Und wie machst du es in diesen Situationen? Exchange hybrid auflösen, exchange Deinstallation und dann mit Adsiedit weiterhin die Attribute pflegen? Greets Phil

Hi zusammen, ich denke die Frage ist bereits schon sehr häufig aufgetreten. Mir geht es nochmals um da leidige Thema: Was passiert, bzw. wie ist der beste Weg für eine Migration nach Office365 oder jetzt Microsoft 365 um den lokalen Exchange komplett aus der ORganisation zu entfernen? Das AD Synctool soll weiterhin für die Kennwörter genutzt werden und die Verwaltung der Postfächer soll nur noch über die CLoud erfolgen. ----- Sobald eine Hybrid Bereitstellung konfiguriert wurde, muss ein Exchange mit ECP zwingend erhalten bleiben, das es Microsoft sonst nicht supportet, richtig? Wenn die CutOver Migration genutzt wird, kann dann danach das AD SyncTool ohne Probleme weiterhin benutzt und die Postfächer in 365 verwaltet werden? Wie geht ihr mit diesen Situationen um? Bisher habe ich immer noch einen Exchange mit der kostenlosen Hybrid Lizenz 2016 installiert gelassen, damit dieser Weg supportet ist. ----- Ich hoffe Microsoft bringt bald ein Tool raus, damit auch bei einer Hybridbereitstellung die Exchange Attribute lokal verwaltet werden können. ----- Danke euch im Voraus. Grüße Phil

Ich habe gerade mal zum Test noch auf meiner Test Umgebung alles nachgestellt. Auf dem Exchange Server 2019 ein Konto angelegt und über Outlook 365 eine E-Mail an das Konto verschickt. Danach habe ich das Konto gelöscht, Outlook neu gestartet und versucht an die Adresse zu senden: Office 365 Outlook (2019) ist so schlau um zu erkennen, dass diese Adresse nicht mehr gültig ist. Wenn ich nun mit deinem Powershell Befehl auf dem Exchange Server danach suche bekomme ich eine Fehlermeldung ausgegeben: MIt folgendem Befehl wird alles sauber aufgelistet: Get-TransportService | Get-MessageTrackinglog -EventID FAIL -Start (Get-Date).AddDays(-7) -ResultSize Unlimited | Where {$_.Recipients -match "^IMCEAEX*"} ### Ebenfalls möglich: Suche ich über die Message gui von Frankys Web finde ich nun die Einträge mit dem {IMCEA* ... ''''' Somit finde ich nun die ganzen Empfänger welche angeschrieben werden. Und wie wäre nun dein Weg? Entscheiden ob der Empfänger noch existiert und ein X500 Eintrag beim Empfänger hinzufügen? Falls der Empfänger nicht mehr existiert, diese gezielt über den Auto Cache herauslöschen? Güße Phil

@mikro Danke dir für den verlinkten Artikel. Jetzt muss ich nochmal dumm fragen. Meinst du ins Message Log auf dem Exchange Server? Und wie würdest du dann genau vorgehen? Sry, stehe gerade auf dem Schlauch. Grüße Phil

@mikro Den Artikel von dem guten Mann kann ich leider nicht mehr finden, schade. @testperson Auch hier wird es mier nicht einfach gemacht. Es merkt sich natürlich wieder niemand die Fehlermeldung. Allerdings in den Mails welche ich mit den Fehlermeldungen bekommen haben, werden eigentlich vom Namen her externe mail Adressen angesprochen. Die Fehlermeldung löst der Exchange aber auf die Administrativ Group und mit einem @domain.de der Firma auf. Somit muss es diesen Kontakt ja schon mal irgendwo gegeben haben, oder liege ich da falsch? Grüße Phil

@massaraksch Outlook wurde neu gestartet, jap. @mikro Ok, perfekt. Ich werde mir das tool die Tage mal amschauen. Eventuell werde ich auch bei den betroffenen clients einfach alle Einträge welche nach IMCEAEX auflösen und das Adressbuch neu ziehen. Ich weiß nämlich nicht um wieviel adressen es sich handelt. Grüße Phil

Hi mikro, Danke für die rasche Antwort. Ich habe vergessen zu erwähnen, dass es sich um Outlook 2013 und 2016 handelt. Funktioniert die Software dort auch? Die Frage ist auch, werden die defekten Einträge erkannt? Der Benutzer bekommt die Meldung ja erst nach dem senden an die nicht vorhandene Adresse. Grüße Phil

Hi zusammen, ich habe bei ein paar Benutzern die Problematik, dass diese einen '550 5.1.1 Fehler beim senden an bestimmte Empfänger bekommen. Die Problematik ist, dass die Adressen noch im AutoCache des Benutzers hängen und dieser Benutzer so nicht mehr aufgelöst werden kann. Leider kommt für die Benutzer kein löschen des gesamten Caches in Frage (nach dem löschen ist es OK). Manuelles löschen der einzelnen Einträge hilft nicht, komischerweise wird die Vervollständigung trotzdem nach ein paar Sekunden warten ausgeführt. Wie kommt es zu solch einem Fehler? Wurden diese Adressen jemals als Kontakte im Exchange angelegt? Hat jemand eine Idee, wie man es eventuell noch anders lösen könnte? Danke im Voraus. Grüße Phil

Morgen zusammen, nach einigen Tests mehr habe ich noch folgendes herausgefunden: Wenn ich ein Benutzer von OnPremise in die Cloud migriere und danach versuche on Premise in OWA den Kalender dieses Postfachs zu öffnen, dann funktioniert es problemlos. Alle Benutzer, welche nicht zuvor ein Postfach On Premise hatten, kann ich nur über Outlook öffnen. Ich habe gleichzeitig mal noch ein Ticket bei Microsoft eröffnet. Die Antwort war, dass es in OWA mit einer TEstlizenz nicht möglich ist, die Cloud Kalender zu öffnen. Naja auf weiter Nachfragen sind die vom Support nicht mehr eingegangen. Warum kann man dann die migrierten Postfächer öffnen . Klingt für mich etwas komisch. ABer ich denke ich werde den Thread an dieser Stelle mal als gelöst markieren. Grüße Phil

Hallo zusammen, ein kurzes Edit von meiner Seite: ich habe es nun soweit mit der Hybrid Bereitstellung hinbekommen. Über folgende Probleme bin ich gestoßen + Lösung: 1.) Ich konnte von On Premise keine Mails nach O365 senden. Meine IP sei wohl auf einer Blacklist gestanden was falsch war. Über das Portal von Microsoft hat es sogar bestätigt, dass meine IP Adresse nicht gebannt ist und trotzdem hat es nicht funktioniert. Nach eintragen meiner Public IP bei den erlaubten Adressen unter dem Punkt "Schutz" sind die Mails sauber über den Connector in O365 angenommen worden. 2.) Mails von O365 nach On Premise sind nicht angekommen. Die Connector Prüfung hat bereits fehlgeschlagen, dass keine Verbindung zum Remoteserver aufgebaut werden kann. Ich habe unzählige Tests mit dem Remote Analyze Tool durchgeführt, welche alle erfolgreich waren. Was sehr seltsam war: Ich habe im Outbound Connector in O365 die Public IP vom Anschluss anstelle dem DNS Namen eingesetzt. Auch hier konnte keine Verbindung hergestellt werden. Heute, ein Tag später genau das gleiche. Zum Test habe ich nochmals die IP Adresse eingesetzt und versucht den COnnector mit verschiedensten TLS Konfigurationen ans laufen zu bekommen. Siehe da, der Connector baut die Verbindung korrekt auf und kann eine Test E-mail an den lokalen Exchange versenden. Nochmals den Namen eingesetzt und nun bekomme ich auch die Fehlermeldung, dass der Name komplett falsch von den Microsoft Nameservern aufgelöst wird. Der MX Record ist bereits 3 Tage gesetzt und über MXtoolbox und weitere Dienste auch sauber auflösbar. Warum auch immer Microsoft noch die alte IP auflöst und warum es ein Tag zuvor nicht mit der Public IP geklappt hat **keine Ahnung** E-Mail von O365 nach On Premise funktioniert also.... 3.) Nicht alle Kalender können angezeigt / abgerufen werden. Hier habe ich Probleme bei den Postfächern, welche vor der Hybridbereitstellung bereits in der Cloud waren und nicht neu erstellt oder migriert wurden. Auf alle anderen Postfächer welche ich nach dem Wizard neu erstellt oder in die CLoud verschoben habe, dessen Kalender kann ich korrekt aufrufen. Erstelle ich allerdings direkt ein O365 Postfach über die Lokale On Premise Konsole, dann kann ich den Kalender nicht öffnen. Nochmal eine neue Erkenntnis hierzu: Wenn ich über den PlanungsAssistent ein Termin erstelle und ein Benutzer aus der Cloud hinzufüge, dann wird der Kalender vom Cloud Postfach korrekt abgerufen und angezeigt ob Frei oder Gebucht ist. Wird allerdings versucht den Kalender über OWA zu öffnen, dann kommt die Fehlermeldung, dass dieser nicht geöffnet werden kann. Ich habe nun zum Test mal noch ein Outlook Profil angelegt und dort versucht die Kalender zu öffnen. Funktioniert über Outlook problemlos. Nur über OWA gibt es die Probleme. 4.) Migration von den Postfächern nach O365 funktioniert nun ebenfalls. ------ Zum Test werde ich nun nochmal mit den Kalendern experimentieren. Ob dies nun ohne Probleme funktioniert. Ebenfalls werde ich nochmals von der Modernen Hybrid Installation auf die Klassische wechseln, welche eingehende Verbindungen benötigt. #### Eventuell kann mir ja jemand zum Punkt 3 noch etwas sagen und hatte ähnliche Probleme. Danke euch. Grüße Phil

Hi, Danke dir für die Antwort ... Adressrichtlinien? Sind konfiguriert. Echte Domain ist im O365 validiert und konfiguriert. Der MX und Autodiscover zeigen allerdings auf den lokalen Exchange Server, welcher die Anfragen dann proxy in die Cloud spielen soll. Ok, ist ein wichtiger Punkt bei dem du natürlich Recht hast. Allerdings wundert es mich stark, dass es gestern ebenfalls den gleichen Fehler gebracht hat und auch schon einige Zeit verstrichen ist. Ebenfalls funktionieren Teilweise Funktionen und eben teilweise nicht. Edit: Ich habe auch bereits mit dem Test Tool von Microsoft "remote analyzer" einige Tests durchgeführt und es war alles erfolgreich. - active Sync, outlook Verbindung, smtp eingehend, frei Gebucht usw... Grüße Phil

Hi J, ich habe es zum Test versucht über die Mount Funktion einzubinden. Wie gesagt, wenn ich nur die DB verwende funktioniert alles und die TransaktionsLogs werden wieder korrekt eingespielt. Wenn ich wie beschrieben die DB + die Logs kopiere, dann kommt der Fehler beim einbinden. Grüße Phil

Hi zusammen, vorweg erstmal frohe Ostern an alle. Ich habe die Zeit über Ostern etwas genutzt um eine Testumgebung aufzubauen. In der Testumgebung habe ich 2 x Windows Server 2019 und 1x Windows Exchange Server 2019 installiert. Der Exchange Server ist mit einem gültigen Zertifikat von Lets Encrypt konfiguriert. Nun wollte ich mir die Hybrid Geschichten seitens Microsoft mal genauer anschauen und einige Tests durchführen. Folgendes Testszenario ist zuhause aufgebaut: - Fritzbox Exposed Host auf eine Fortigate Firewall. Diese leitet den Port 25 und 443 auf den Exchange Server weiter. - Im DNS sind die Autodsicover und MX Einträge auf den Hausanschluss gesetzt und kommen beim Exchange Server an - Mailflow eingehend/ausgehend -> OK - Autodiscover -> OK - OWA Zugriff -> OK. - Urls sind korrekt gesetzt. Nun wollte ich wie oben geschrieben eine Hybrid Umgebung zu meinem Test Tenant aufbauen (o354 Premium oder jetzt Microsoft365 Plan). Soweit so gut hat alles nach ein paar Anläufen funktioniert und ich habe die Klassische, sowie die moderne Hybridkonfiguration getestet. Beide habe ich mit Voller Konfiguration konfiguriert, damit auch Frei / Gebucht abgerufen werden kann. - Es wurde soweit alles vom Hybrid angelegt (Aktzeptiere Domänen, Connectoren, Organsiation (Frei Gebucht)) - Ich habe über die Interne O365 Exchange KOnsole Office 365 Postfächer angelegt, welche auch als sowas gekennzeichnet sind. - Nach erneutem anstoßen des AD Syncs wurde auch der Benutzer in die O365 Cloud synchronisiert und ich habe diesem eine Lizenz zugewiesen. - Adressbuch Aufruf funktioniert von O365 (Web App) auf die lokalen Benutzer und anders herum. - Mail Flow von On Premise nach Microsoft 365 Postfach funktioniert Edit: Falls den Post vorhin schon jemand gelesen hatte: Die Frei Gebucht Synchronisation funktioniert. Ich habe den Wizard nochmals durchlaufen und einen neuen Modernen Hybrid Agent installiert. Allerdings nur wenn ein Cloud Benutzer den Kalender von ON Premise abruft. Hier die Probleme: - Will ich auf eine Mail von O365 auf ein Postfach On Premise antworten wird diese nicht zugestellt. Wenn ich den Sendeconnector in O365 von O365 nach OnPremise teste kommt ebenfalls fehlgeschlagen mit der Meldung: 401 4.5.4 Invalid Arguments - possible version Missmatch Schaue ich in die Nachrichtenverfolgung bekomme ich folgende Meldung: cannot connect to remote Server 4504.4.317 - Frei Gebucht in der Cloud abrufen funktioniert nicht. Also lokaler ON Premise Benutzer kann den Kalender eines Postfachs in der CLoud nicht anzeigen. ### Habt ihr hierzu Ideen, wo oder wie man hier am besten mit der Fehlersuche loslegt? Danke euch im Voraus Grüße Phil