wznutzer

Guten Tag, was ist "best practice" wenn lokale Anwendungen Emails versenden sollen? Gegeben ist Exchange mit Hybrid-Bereitstellung. Microsoft sieht 3 Möglichkeiten vor: https://docs.microsoft.com/de-de/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365 oder auch hier (etwas ergänzt) https://www.msxfaq.de/cloud/exchangeonline/multifunktionsgeraet_mit_exo.htm Am sympathischsten ist mir das mit dem Relay in Office 365. Alles funktioniert prima und die Limits von 30 Nachrichten pro Minute oder das Hantieren mit "send as" wie beim SMTP-Versand entfällt. Allerdings finde ich keine Möglichkeit verschlüsselte Verbindungen (TLS) zu erzwingen. Wenn der Client es macht dann geht es, ansosten nicht. Geht es irgendwie TLS zu erzwingen? Die Verbindung ist ja auf die feste IP beschränkt. Das bedeutet man muss im Netzwerk dafür sorgen, dass niemand Unsinn macht. Also z. B. die Verbindung über Port 25 nur von bestimmten Clients aus zulassen. Am besten würde mir die Kombination von O365 SMTP Relay gefallen das aber eine Authentifizierung erfordert. Gibt es das? Vielen Dank

Prima, Danke...

Wir reden, glaube ich, ziemlich gekonnt aneinander vorbei . Es wird nicht angezeigt, weil ich dem Exchange ja nicht gesagt habe, dass ich ExO verwende. Dann mache ich New-Remotemailbox. Ansonsten klicke ich oder halt auch New-Remotemailbox. So jedenfalls habe ich das verstanden.

Z. B. Neues Microsoft 365 Postfach, bei den Postfächer.

Ja (CodeTwo). Es funktioniert sehr gut, hat aber einige gravierende Nachteile. Die sogenannte Dealtamigration (wiederholte Migrationsläufe) kann nur neue Elemente übertragen, Änderungen nicht. Wenn z. B. im Quellpostfach ein bestehender Termin geändert wird, eine Email als gelesen markiert, eine Email gelöscht, wird das alles nicht übertragen. Aber für einmal rüber (wenn schon etwas da ist) und dann nie wieder taugt es. Ich habe mich entschieden Minimal Hybrid mit Modern Topology einzurichten und alle im Ziel löschbaren Postfächer zu übertragen. Das sind nach einer kleinen internen Umfrage 80%. Der Rest bekommt die Inhalte per 3rd Party einmalig übertragen. Das passt für mich gut und 80% können das Outlookprofil behalten. Falls jemand die gleichen Entscheidungen treffen muss: https://docs.microsoft.com/de-de/exchange/hybrid-configuration-wizard-options Zum Schluss noch eine Info die ich sonst nirgendwo erwähnt finde. Ohne Hybrid-Bereitstellung kann zwar der lokale Exchange bzw. die Powershell zur Verwaltung verwendet werden, es fehlen aber ein paar Punkte in der UI, bei einem Exchange 2016 jedenfalls.

Genau über diese Ungewissheit denke ich nach: "Was steht so alles im Postfach, was nicht offensichtlich ist". Einen ähnlichen Ansatz habe ich deswegen verfolgt. Nur hätte ich den Mailflow erst am Ende umgestellt. Lt. Tests benötige ich 5 Tage bis alle Mailboxen migriert sind (Drosselung bereits durch MS aufgehoben). Im Grunde aber schon so. Mit Variationen, wie über Nacht erst mal die letzten 60 Tage migrieren, Mailflow umstellen und dann im Betrieb den Rest nachholen. Soweit ich weiß matcht ADConnect über die ImmutableID, was ja eigentlich das Attribut ms-DS-ConsistencyGuid aus dem lokalen AD ist, automatisch, wenn ich ADConnect neu aktiviere. Warum ich dann aber noch Exchange Hybrid konfigurieren soll ist mir nicht klar. Danke und Grüße

Doku vom Microsoft erwarte ich auch von denen . Der Rest ist nett und auch sehr nützlich, aber die Bringschuld liegt bei Microsoft. ToDo ist z. B. weg. Das ist ohne EXO seit einiger Zeit, mit einem Geschäftskonto jedenfalls, nicht mehr nutzbar. Edit: Mir ist natürlich klar, dass das zuvor exportiert und wieder importiert werden kann.

Ich beschwere mich nicht, ich stelle fest. Vielleicht mache ich das , sobald ich eine Doku finde was alles in einem Postfach gespeichert ist und verloren geht, wenn ich mein Doppelpostfach lösche. Oder ich teste das halt selber.

Nichts. Da aber alle Dokumente, Blogs usw. davon ausgehen sind anderen Szenarien etwas mühsamer umzusetzen, weil nicht Standard.

Ich frage mich ob ich im ADSync die Exchange Hybridbereitstellung aktivieren muss wenn ich lokal nur verwalte. Die Attribute die zurückgeschrieben werden: https://docs.microsoft.com/de-de/azure/active-directory/hybrid/reference-connect-sync-attributes-synchronized?WT.mc_id=M365-MVP-6771 Das Attribut proxyAddresses würde z. B. zurückgeschrieben, aber ich kann das in EXO doch sowieso nicht ändern. Wenn ich mir die Attribute anschaue wird es egal sein ob ich das aktiviere oder nicht. In der Doku wird es bei der Verwaltung nicht erwähnt. Aber in der Microsoft-Welt scheint es nur Hybridbereitstellungen zu geben.

Das sollte nicht nötig sein. Ist nur dazu da, wenn man mal wieder zurückmigrieren will. Nach viel Lektüre sollte keine Hybridbereitstellung notwendig sein, wenn lokal nur verwaltet werden soll. Die Verwaltung setzt nur Attribute im AD die dann per AD-Sync übertragen werden. Auch New-Remotemailbox macht nichts online. Hybrid ist nur für den Mischbetrieb notwendig.

Vielen Dank für Deine Mühe am Wochenende. Seit April 2022 gibt es eine kostenlose Exchange 2019 Lizenz und ich kann "nur" die Management-Rolle von Ex2019 installieren. Das dann kein IIS installiert wird, geht das nur per Powershell, wäre OK, aber geht es tatsächlich ohne lokal etwas zu installieren? Es gibt zwar zwei Postfächer, aber das EXO Postfach wird nicht verwendet und könnte gelöscht werden. Evtl. so, nachdem die Lizenz entfernt wurde. Set-User xyz@abc.de -PermanentlyClearPreviousMailboxInfo Die Daten von Sharepoint (Teams, OneDrive) sollten so erhalten bleiben. Bei OneNote und ToDo bin ich mir nicht sicher. Weißt Du da was? Ist ToDo nicht der Aufgabenersatz bei EXO? Wenn ToDo oder OneNote weg wäre, gibt es keinen Weg zurück für mich, als das mit 3rd Party zu machen. Das Attribut MsExchMailboxGuid ist doch die Verbindung zwischen dem AD und Exchange. Das kann ich doch lokal nicht entfernen, oder? Deswegen nur beim Sync. Das Attribut sagt EXO, dass es ein lokales Postfach gibt, deswegen legt EXO keines an, nachdem eine Lizenz zugewiesen wurde. In EXO heißt es dann: Das lokale Postfach dieses Benutzers wurde noch nicht zu ‎Exchange Online‎ migriert. Das ‎Exchange Online‎-Postfach ist erst nach Abschluss der Migration verfügbar. Damit ich das richtig verstehe. 1) Mit 3rd Party migrieren Ab hier könnten dann alle User mit EXO arbeiten. Ich bin aber nicht in der Lage die Postfächer zu verwalten weil die nachfolgenden Schritte noch nicht gemacht sind. 2) Dann alle lokalen Mailboxen wie folgt deaktivieren: Disable-Mailbox-identity <xyz@abc.de> 3) Den HCW durchführen?? Mit welchen Einstellungen? 4) Remote-Mailbox für jeden User aktivieren?? Enable-Remote-Mailbox <xyz@abc.de> -RemoteRoutingAddress <xyz@abc.mail.onmicrosoft.com> 5) Jetzt ist aber doch die Mailbox noch immer im AD unbekannt, oder nicht? Im Attribut MsExchMailboxGuid steht doch noch immer die Guid vom alten Postfach. Ich könnte dann versuchen die Guid der nun deaktivierten lokalen Mailbox der Remotemailbox zuzuweisen, aber ist das den der richtige Weg und supportet. Edit: Denkfehler, hier müsste wahrscheinlich die Guid vom Online-Postfach eingetragen werden. Set-RemoteMailbox <xyz@abc.de> - ExchangeGuid <Guid vom Online-Postfach> Oder ich habe Dich nicht verstanden was Du mit "Cloudpostfächer matchen" meinst. Vielen Dank Nach der Migration mit 3rd Party habe ich theoretisch diesen Fall der hier beschrieben ist. https://www.msxfaq.de/cloud/identity/doppelpostfach_mit_exo.htm Aber muss ich wirklich Exchange Hybrid konfigurieren. Das würde man doch nach einer Migration ohne 3rd Party zurückbauen. Edit: Warum ich zur Verwaltung zwingend den HCW ausführen muss, ist mir nicht klar. Es gibt ja keinen Hybridbetrieb und somit auch nichts was zwischen EXO und lokal abgeglichen werden muss (Mail-Routing z. B. zwischen lokaler und Online-Mailbox). Alle User sind lokal oder nach der Migration online.

Guten Tag, es wurde leider etwas länger. Gegeben ist Exchange 2016 und ein bestehender Office Tenant. Alle User sind bereits im Tenant vorhanden und die Apps (Teams, OneDrive, OneNote usw.) werden aktiv genutzt. Die User werden per ADConnect mit SSO synchronisiert. Nun soll der lokale Exchange weg und nur noch Exchange-Online genutzt werden. Es soll keine Hybrid-Umgebung eingerichtet werden. Die User haben derzeit zwei voneinander unabhängige Postfächer. Nun gibt es aber ein paar sich widersprechende Dinge: Ist AD-Connect aktiv braucht es einen lokalen Exchange . Cut-Over Migration ist nicht möglich, weil diese keine bestehenden User mag. User zu löschen ist nicht möglich, wegen der bereits bestehenden Daten (Teams, Sharepoint usw.) Aufgrund einer Empfehlung eines Dienstleisters habe ich mir die Migration mit einem Drittanbieter-Tool angesehen. Funktioniert perfekt. Aber doch gibt es ein paar Ungereimtheiten. Wenige User die erst durch AD-Connect angelegt wurden, haben trotz Lizenz keine Mailbox und warten auf die Microsoft eigene Migration. Das lässt sich durch setzen des Attributs MsExchMailboxGuid auf NULL im Regelwerk von AD-Connect beheben. Dann bekommt nach Zuweisung einer Lizenz der User ein Postfach und die Daten können migriert werden. Aber so hat der lokale Exchange ja keine Kenntnis der Mailbox in Exchange-Online und kann somit auch nicht zur Verwaltung verwendet werden . Nun ergeben sich zwei Fragen: 1) Wie schaffe ich es, dass ich einen lokalen Exchange habe den ich zur Verwaltung von Exchange-Online verwenden kann? Der alte Exchange müsste ja zuvor deinstalliert werden oder dieser muss zur Verwaltung umfunktioniert werden. 2) Ich setze das alles zurück und verwende die Microsoft-Migration. Aber kann die Hybrid-Migration in bestehende Postfächer migrieren? In der Doku finde ich da nichts. Und welche Migrationsart wäre da wohl am geeignetsten? Minimal Hybrid mit Modern Hybrid Technology. Mit Modern Hybrid Technologie wären keine eingehenden Verbindungen nötig. Evtl. könnt Ihr mich etwas in die richtige Richtung schieben. Danke

Ich lerne gerne: Starting test: SystemLog * The System Event log test Fehler. Ereignis-ID: 0x0000272C Ich vermute ich kann das ignorieren. Der Fehler wird immer im Ereignislog protokolliert wenn ich dcdiag ausführe. EventID 10028. Es ist so oft im Log wie ich dcdiag ausführe. Auffällig ist, dass nicht alle Fehler des Eventlog ausgegeben werden, sondern nur die in einem bestimmten Zeitfenster (60 Minuten) vor dem Aufruf von dcdiag. Wenn ich eine Stunde lang dcdiag nicht ausführe steht da: Found no errors in "System" Event log in the last 60 minutes. Somit generiert dcdiag selber einen Fehler der dann bei einem nachfolgenden Aufruf protokolliert wird .

ja Nach: ** Sichere ausgehende Kanäle wurden nicht getestet, da "/testdomain:" nicht eingegeben wurde. Ich verwende dcdiag /c /v /e /q

Hallo zusammen, wenn ich dcdiag ausführe erscheint folgende Meldung: DCOM konnte mit keinem der konfigurierten Protokolle mit dem Computer "IP-Adresse der Firewall" kommunizieren; angefordert von PID 474 (C:\Windows\System32\dcdiag.exe). Erklären kann ich mir das nicht. Wisst Ihr etwas darüber? Danke und Grüße

Guten Abend, weil es hier angesprochen wurde, ja ich versuche schon ein Schutzkonzept (Tier 0 usw.) umzusetzen. Den Restore habe ich mir nicht aus der Sicht, dass ein Update den AADC kaputt macht vorgestellt. Ich denke, dann habt ihr das schon erlebt. Mein Restore-Konzept wäre gewesen, neuer DC, replizieren lassen, alter raus aus der Domäne und AADC lt. meiner Doku neu installieren. Aber das will ich natürlich nicht jeden Monat machen, weil es ein Update von AADC gibt. Wenn es da ein erhöhtes Risiko gibt, habe ich darauf keine Lust und ich lasse das. Meine Motivation war einfach, wegen so einem kleinen Programm nicht eine weitere VM haben zu müssen auf die ich aufpassen muss. Ab Herbst hätte ich auf einem Host eine Datacenter-Lizenz. Da würde die separate VM noch nicht einmal etwas kosten. Vielen Dank für euren Input.

Guten Abend, lt. Doku ist es problemlos möglich AADConnect auf einem Domänencontroller zu installieren, aber ist das eine gute Idee? Lt. Microsoft muss der Server ohnehin so "beschützt" werden wie alle Member in Tier 0. Es muss ein SQL-Server installiert werden, da ist jetzt eher so mittelgut auf einem DC, aber ist es so schlimm? Bei Problemen mit AADConnect müsste ich vielleicht mal den Server starten, dann ist auch der DC weg, aber ich habe ja sowieso mehrere. Der DC ist nicht mehr identisch zu den anderen, wäre aber auch egal. Ein DC ist ja schnell installiert und hinzugefügt. In einer sehr großen Umgebung ist das vielleicht etwas anderes, aber bei < 200 User will mir kein trifftiger Grund einfallen das nicht zu tun. Evtl. irre ich mich, aber deswegen frage ich. Danke und Grüße

Inzwischen ca. 130 User. Jede Menge Einstellungen, Gerätschaften und vergebene Rechte und leider erst seit ca. 5 Jahren vollständig dokumentiert. Davor . Ja, Upgrade. Habe ich bei faq-o-matic glatt übersehen. Danke. Aber ich habe verstanden. Es gibt keinen technischen Grund das unbedingt machen zu müssen. Vielen Dank

Guten Tag, mich würde eure Meinung interessieren. Gegeben ist eine Domain firma.local die komplett auf Server 2022 migriert werden soll. Nun frage ich mich, ob es mir irgendeinen Vorteil bringt eine neue Domäne firma.de zu machen und mit ADMT zu migrieren. Die Anmeldung mit @firma.de kann ich ja auch mit einem Suffix machen. Gibt es einen gravierenden Nachteil bei firma.local? Mir fällt keiner ein und bemerkt habe ich auch noch nichts. Grüße und Danke.

Das habe ich verstanden und will da auch gar nicht dagegen argumentieren. Die Idee war ja, durch das Trennen per Multiboot, beide Bereiche zufriedenstellend abzudecken. Und da scheinen die Meinungen auseinander zu gehen mit der Tendenz: Nicht so schlecht , aber wenn möglich lass es lieber.

Ja, z. B. ob das überhaupt stimmen kann. Weil die Anzahl der Computer im Internet auf 4,9 Mrd. geschätzt wird und somit 1/5 betroffen gewesen wäre. Ich kann ja nicht in Panik ausbrechen, sondern muss entscheiden ob das was mit Smartphones gang und gäbe ist, auch auf Windows-Rechner übertragbar ist. Wenn nicht, dann ist das auch in Ordnung, aber ich muss das schon stichhaltig mit einem realen Szenario begründen. Genau um solche Meinungen zu hören suche ich ja den Austausch. Was ich selber denke weiß ich ja schon .

Hoppla: https://www.it-daily.net/it-sicherheit/cybercrime/uefi-malware-bleibt-bedrohung-fuer-privatanwender-und-unternehmen Über eine Milliarde Windows-Rechner weltweit waren von Lojax betroffen.

Wir hantieren da ja mit Wahrscheinlichkeiten. Ich bin mir der Gefahr bewusst, aber wie groß ist die Gefahr, dass das passiert? Das versuche ich herauszufinden, ob das akzeptabel ist. Klar ist natürlich, dass ich am Ende kein Konstrukt will das aufwändiger, teurer und unsicherer ist, als wenn ich jedem Kollegen einfach ein separates Notebook in die Hand drücke. Da würde ich einfach den Rat des CSP einholen, wenn das relevant wird. Wobei das schon schräg wäre, wäre das nicht erlaubt. Eine Lizenz aus dem Abo, welche komplett lt. Bedingungen genutzt wird und eine Lizenz die mit dem Gerät zusammen erworben wurde. Das entspricht ja genau dem Grundsatz, dass jede Installation eine Lizenz benötigt.

OK, falsch im Gedächtnis abgespeichert. Müsste trotzdem OK sein, weil der geschäftliche Zweck dem entspricht und für die private Nutzung der Key aus dem Bios (W10 Pro) verwendet werden könnte. Zielkonflikt. Dem Mitarbeiter den Vorteil zu bieten sich kein eigenes Gerät anschaffen zu müssen und trotzdem alle geschäftlichen Anforderungen zu erfüllen. Aber wenn es keine zufriedenstellende Lösung gibt, ist auch das ein Weg. Die Idee ist eine Vereinbarung zu treffen, dass private Daten in der Verantwortung des Nutzers liegen und die Nutzung das Einverständnis darstellt im Fall der Fälle ein frisches Windows zur Verfügung gestellt zu bekommen und den Rest selber erledigen zu müssen. Variante 2 ist derzeit mein Favorit. Nur bei der Ausbreitung von Malware vom privaten OS auf das geschäftliche bin ich mir nicht 100%ig sicher. Aber wenn es sich nicht gerade um eine raffinierte Malware für das UEFI handelt, doch eher unwahrscheinlich. Für Variante 3 habe ich noch keine genaue Vorstellung ==> zu wenig Wissen über Microsoft Intune. Ich lese nur, dass sich damit auch auf W10 Geräten ein privater Bereich abbilden lässt. Ich hatte auf Erfahrungen gehofft . Mit privat ist wirklich "ohne Einschränkung" gemeint, also: "Klick auf alles was du meinst, es ist privat und trifft die Firma nicht." Auch wenn es auf der Firmeninstallation möglich wäre, soll es per Vereinbarung unterbunden werden.