Das „MyAnalytics“ Tool ist ja nett gemeint, aber aufgrund seiner „Opt Out“ Konfiguration in den meisten Fällen sehr nervig und was den Datenschutz betrifft ser „anfällig“. Wir können auch nicht nachvollziehen, wiso Microsoft so ein Tool für alle Nutzer Standartmäßig einschaltet.
Abschalten von MyAnalytics für den ganzen Tenant
Als Globaler Admin einloggen. Mit der „Delegierten Administration“ ist die Konfiguration nicht möglich.
Links unter (Alle anzeigen) Einstellungen > Einstellungen der Organisation > MyAnalytics öffnen
Manchmal muss der Admin genau ein einziges Objekt, oder nur wenige ganz bestimmte Objekte von der Synchronisation vom lokalen AD in das Microsoft 365 Azure AD ausschließen.
Das geht überraschend einfach, mann kann exclude-Regeln einfach im „Synchronization Rule Editor“ hinzufügen.
Schritt für Schritt Anleitung um ein Objekt nicht mehr zu synchroniseren
Zeitplan für die Synchronisation abschalten, damit keine automatischen Aufgaben die Änderungen durcheinander bringen:
Set-ADSyncScheduler -SyncCycleEnabled $False
Der Status des ADSyncSchedulers lässt sich jeder überprüfen mittels:
2. „Synchronization Rules Editor“ starten (als Administrator)
3. In der „View and manage …“ Liste die „Direction“ auf „Inbound“ stellen und eine freie Nummer unterhalb der bestehenden „Precedence“ Regeln finden (und merken). In der Regel ist das irgendetwas <100.
4. Oben rechts „Add New rule“
5. Den „Create inbound synchronization rule“ Assistenten nun ausfüllen:
Name: Ein beschreibender Name, z.B. „In from AD – Bernd auslassen“
Connected System: Der lokale AD Forest
Connected System Object Type: user
Metaverse Object Type: Person
Link Type: join
Precedence: Die gemerkte Nummer von oben (z.B. „90“)
„Tag“, „Enable Password Sync“ oder „Disabled“ nicht verändern
Next > …
6. „Add group“ > dann > „Add clause“
7. Als „Attribut“ ein zu filterned Attribut wählen, zum Beispiel den „name“ oder ein anderes Attribut. Bei größeren Mengen an Objekten nutzen wir hier gerne die „Extended Attributes“, die normalerweise solange ungenutzt und leer sind. Der Operator ist im Beispiel „equal“, der „Value“ der zu matchende Inhalt.
8. „Next >“, an den nun angezeigten „Add join Rules“ nichts ändern > „Next >“
9. Bei den „Add join rules“ eine Transformation hinzufügen:
Wenn man einen SQL Benutzer nicht vom SQL-Server entfernen kann, weil dieser Fehler auftritt („Error: 15150“), hat der Benutzer vermutlich noch ein Datenbankschema im Besitz.
Lösung
Der Besitz der Datenbank (des Schemas) muss einfach wieder „mit Gewalt“ übergeben werden. Wir machen das in aller Regel für den SA und vergeben dann als dieser neue Berechtigungen.
Da es in Microsoft Office 365 leider keine „Generierungsrichtlinie“ gibt, oder zumindest keine auf die man schreibenden Zugriff hat, muss man für neue Alias-Domains jeden Benutzer einzeln anfassen. Jedem Postfach müssen die neuen E-Mailadressen einzeln hinzugefügt werden. Bei vielen Postfächern (oder Domains) ein sehr ermüdender Job.
Das ist auch erst einmal so, denn Microsoft scheint der Meinung, das eine E-Mail Domain für immer genug sei. Oder zumindest Änderungen daran selten.
Natürlich kommen Namens- oder Domainänderungen in der Realität aber ständig vor, auch für (neue) Alias-Domains. Der findige Admin macht das natürlich nicht mehr manuell im ECP, sondern an der PowerShell.
Neuen Domain E-Mail Alias mit der PowerShell hinzufügen
Ich nutze ein kleines „AddEMailAliasDomain“ Script. Die Domain example.com ist die „alte“ und richtige Absende-Adresse, beispiel.de ist die neue hinzuzufügende. Es wird nach der „alten“ Domain gefiltert, damit keine anderslautenden Postfächer verändert werden.
Wenn ein Benutzer in einer Hybrid-Umgebung erstellt wird und ihm dann eine Exchange Online-Lizenz zugeordnet wird, wird für diesen Benutzer ein Cloud-Postfach erstellt.
Der OnPremises Exchange Server erfährt davon aber nichts, daher ist der Benutzer im lokalen ECP nicht aufzufinden und das Mailrouting („Nachrichtenfluss“) von intern nach extern schlägt fehl.
Wenn man Office 365 zum ersten Mal im Hybridmodus verwendet, erstellt man oft neue Benutzer, indem man einfach ein AD-Konto erstellt und dieses via ADConnect synchronisiert. Danach wird der neue User lizenziert und bekommt ein Postfach. Das erzeugt genau das oben genannte Problem – die OnPremises Exchange Adressliste weiss nichts von dem neuen Objekt und routet keine E-Mails in die Cloud.
Beim Verschieben einer solchen Mailbox zurück nach On Premises tritt dieser Fehler auf:
Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ''. --> Cannot find a recipient that has mailbox GUID '<GUID>'
Die „richtige“ Methode zum Bereitstellen neuer Benutzer in Office 365 besteht darin, neue Remotepostfächer zu erstellen.
Lösung
Man kann einen OnPremises-Benutzer auch nachträglich mit seiner „echten“ Exchange-Online Mailbox verbinden.
Man schaltet einfach die Remote-Mailx im Exchgange ein und trägt die Online-GUID des Postfaches ein.
1. In der OnPremises Exchange PowerShell (EMS) die Remote-Mailbox einschalten:
3. In der OnPremises Exchange PowerShell (EMS) genau diese GUID wieder eintragen:
Set-RemoteMailbox <USER> –ExchangeGUID <GUID>
Das funktioniert natürlich in beide Richtungen, also auch für Benutzer-Objekte die in der Exchange Online EMC nicht mehr angezeigt werden. Interessanterweise beschreibt Microsoft in diesem Artikel nur den Weg in die Cloud 😇
