AIP Client bzw. Microsoft Information Protection Client Fehler in Version 2.17.66.0

beim öffnen des Clients über das Kontextmenü der Maus oder wie auch immer, wird die die View des Clients verzerrt so das er unbrauchbar ist.

Quelle die das bestätigt [2024-03-07] : Microsoft Information Protection Client – Fehler bei der Januar Version – RaKöllner (rakoellner.de)

Schnelle Lösung: ein Rollback auf die alte Version

EnableMIPLabels

Azure Information Protection (AIP) für Microsoft 365-Gruppen und SharePoint-Websites lässt sich nicht aktivieren (EnableMIPLabels)

EnableMIPLabels
Darstellung des Problems

mit folgenden Powershell Schnipsel könnt Ihr die Option „EnableMIPLabels“ auf „Group.Unified“ aktivieren

Status abfragen
$grpUnifiedSetting = (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ)
$Setting = $grpUnifiedSetting
$grpUnifiedSetting.Values
wenn EnableMIPLabels = false
$Setting["EnableMIPLabels"] = "True"
#prüfen
$Setting.Values
#speicher
Set-AzureADDirectorySetting -Id $grpUnifiedSetting.Id -DirectorySetting $Setting

Quelle[2022-06-25] Zuweisen von Vertraulichkeitsbezeichnungen zu Microsoft 365-Gruppen in Azure Active Directory

schlägt die obere Anleitung fehlt, muss das richtige Template geladen werden, um der Wert zu setzen

$setting=(Get-AzureADDirectorySetting | where -Property DisplayName -Value “Group.Unified” -EQ)
if ($setting -eq $null)
{
$template = Get-AzureADDirectorySettingTemplate -Id 62375ab9-6b52-47ed-826b-58e47e0e304b
$setting = $template.CreateDirectorySetting()
$setting[“EnableMIPLabels”] = “True”
New-AzureADDirectorySetting -DirectorySetting $setting
}
else
{
$setting[“EnableMIPLabels”] = “True”
Set-AzureADDirectorySetting -Id $setting.Id -DirectorySetting $setting
}

Quelle[26.06.22] https://www.rakoellner.de/2019/12/sensitive-labeling-fuer-groups-und-sharepoint-sites-ist-nun-verfuegbar/

Directory Status in Teams unknown – Incorrect status in teams

in zahlreichen Foren zum Thema aus der Headline gibt es diverse Ansätze, um das Problem irgendwie einzugrenzen bzw. in Griff zu bekommen. Nun musste ich mich gezwungener Maßen auch damit beschäftigen und bin der Sache mal auf den Grund gegangen, weil ich nicht wirklich auf Informationen im Netz gestoßen bin, die das Phänomen wirklich analytisch beschreiben und einen Lösungsweg kommunizieren.

Hier nun meine Analyse und Lösung:

Grundsätzlich war mir schon klar, dass es irgendwie mit der Identität zu tun haben musste. Dementsprechend habe ich mit Powershell (MsolService) eine funktionierende Identität aus der Azure AD mit einer Identität, die nicht funtioniert, verglichen und schon einen AHA Effekt gehabt.

In mehreren Foren antwortete Microsoft auf die Fragen der User zum Thema sehr oft, sich mit dem „Koexistend Modus“ (Coexistence mode) im Teams Admin Center zu beschäftigen.

Hmm … was bedeutet das?

Wer sich mit dieser Option auseinander setzen soll, hat definitiv vor, von Skype Business auf Teams umzusteigen oder einen zwischenzeitlichen Parallelbetrieb beider Tools einzurichten.

Oder ihr habt irgendwann mal versucht, Skype for Business als Unternehmensanwendung mit euren AD-Usern zu verknüpfen.

So, das sollte als Vorgeschichte reichen … nun zur Analyse:

Was ihr hier seht, sind MSOluser Attribute von zwei Identitäen, mit einer starken Auffälligkeit bzgl. SIP Parameter

msRTCSIP Atrribute hängen mit der Skype Welt zusammen, wer mehr Informationen braucht, kann auf den folgenden Link klicken: Schemaattribute und Beschreibungen in Skype for Business Server

Hier meine Lösung

bereinigt die oben aufgeführten msRTCSIP Attribute (besten bereinigt gleich alle msRTCSIP Attribute), falls das Rudimente aus eine alten Skype for Business Implementierung sind.

Achtung: bitte vor dem löschen bzw. bereinigen immer fragen ob die Attribute nicht doch einen höheren Sinn haben.

Attribute einer User Identität im AD OnPrem

Dann einfach mit AADC die Identitäten synchronisieren und schon sollte der Status korrekt angezeigt werden.

Ich nehme keine Gewährleitung für meine Anleitung

… bleibt Gesund und macht schön eure Backup’s

Outlook akzeptiert keine Zugangsdaten nach 365 MFA

Nach dem Umstellen auf MFA in 365 möchte Outlook von Microsoft Office das die Identität (Zugangsdaten für das E-Mail Postfach) erneut bestätigt wird. Die Zugangsdaten werden aber nicht angenommen, wobei sie aber korrekt sind.

Damit es wieder funktioniert, müsst Ihr die gespeicherten Zugang aktualisieren. Entweder Ihr löscht die Daten über die Systemsteuerung

mehr Info von Microsoft: Verwalten von gespeicherten Benutzernamen und Kennwörtern auf einem nicht zu einer Domäne gehörenden Computer

Anmeldeinformationsverwaltung in Windows 10

oder Ihr löst da über die Powersell

Connect-EXOPSSession -UserPrincipalName admin@domain.dom
Get-OrganizationConfig | Format-Table Name,OAuth* -Auto
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Quelle [2020-02-12] https://dotmuc.org/office-365-mfa-outlook-anmeldung-schlaegt-fehl/

Warum 365 Deutschland eingestellt wird

Hier mal für alle ein paar Hintergründe warum die 365 Deutschland Cloud eingestellt wird

einfach zu geringe Nachfrage, weil

  1. weniger Leistung für mehr Geld erbracht wurde
  2. Unternehmen die hochsensible Daten verarbeiten, eher Ihre eigene Privat Cloud einrichten
  3. die Office 365 Services (Global) jetzt DSGVO konform sind

Punkt 1. und 2. Sind nachvollziehbar
Punkt 3. wird wie folgt durch Microsoft geregelt

Beim Abonnieren eines Onlinedienstes über ein Microsoft Volumenlizenzprogramm sind die Bestimmungen zur Nutzung des Dienstes in den Bestimmungen für Onlinedienste (Online Services Terms OST) und im Programmvertrag definiert. Die OST werden monatlich aktualisiert und sind das Nachfolge-Dokument der Microsoft Online Services Use Rights.

Folgender Absatz regelt die Anforderungen der DSGVO für Office 365 Services Global in den OST mit Stand 01.06.2018

Bestimmungen für Onlinedienste (Online Services Terms OST)
Folgender Absatz regelt die Anforderungen der DSGVO für Office 365 Services Global in den OST mit Stand 01.06.2018

Die aktuelle OST könnt Ihr euch hier beschaffen: https://www.microsoft.com/de-de/licensing/product-licensing/products.aspx

Fehler AADSTS90094 & das Ende von OWA für Geräte bei 365

jene die über IPhone & Co E-Mails bei Exchange Online abrufen und das nicht mit Outlook for iOS oder Outlook for Android machen, rufen entweder per IMAP oder OWA  für Geräte ( OWAforDevicesEnabled ) ab.

Seit dem 15.05.2018 hat Microsoft die Option OWA  für Geräte abgestellt (hier zu lesen), aber die Option im EAC ( Exchange Admin Center ) nicht rausgenommen, was leicht verwirren kann.

Standardmäßig sind bei einem Exchange Online Postfach die Option OWA für Geräte ( OWAforDevicesEnabled ) und Outlook Web App bzw. Outlook im Web ( OWAEnabled ) aktiviert und somit haben die meisten, die über OWA für Geräte abgerufen haben gar nicht bemerkt, dass Sie jetzt über Outlook Web App bzw. Outlook im Web ihre E-Mails abrufen.

Nun kann es aber sein, dass aus irgendeinen Grund Outlook im Web deaktiviert wurde und jemand versucht ohne die APP Outlook for iOS oder Outlook for Android E-Mails von einem mobilen Gerät von Exchange Online abzurufen, der erhalt folgende Fehlermeldung AADSTS90094

 

ich glaube der Rest erklärt sich von selbst … bleibt Gesund und macht schön eure Backups

Onedrive Business und Privat behindern sich (Unable to resolve upload host: 11001)

Eher selten kommt es dazu das Onedrive for Businuess wegen Onedrive Privat nicht richtig funktioniert.

Folgende Fehlermeldungen erscheinen im Log

08/15/2016 18:59:28.081 SetupEngine: IsPerMachineWorkNeeded? No

08/15/2016 18:59:28.081 SetupEngine: RegisterForARP was skipped on threshold or greater…

08/15/2016 18:59:28.081 SetupEngine: Done!

08/15/2016 18:59:28.081 SetupEngine: Overall result = 0x00000000

08/15/2016 18:59:28.081 SetupController: SetupControllerImpl::OnEndWork

08/15/2016 18:59:28.128 RunAsStandardUser: CreateProcess: file=[C:\Users\Zahni404\AppData\Local\Microsoft\OneDrive\OneDrive.exe] args=[ /background /versionReinstalledUseForTraceOnly]

08/15/2016 18:59:28.137 SetupController: Waiting for client event in order to continue

08/15/2016 18:59:38.137 SetupController: Something went wrong waiting for the client to signal us. Error code: 0x102

08/15/2016 18:59:38.137 SetupView: Closing SetupView

08/15/2016 18:59:38.143 SetupView: Destroying SetupView

08/15/2016 18:59:38.619 SetupView: Uninitializing SetupView

08/15/2016 18:59:38.619 SetupController: Uninitializing SetupController

08/15/2016 18:59:38.640 LogsUploader: Unable to resolve upload host: 11001

den Lösungsweg habe ich auf folgender Webseite GEFUNDEN

Error installing OneDrive for Business Next Generation Sync Client

und hier die Lösungsansätze:

Computer Configuration – Polices – Administrative Templates – Windows Components – OneDrive
“Prevent usage of onedrive for file storage” = Disabled

This was set to Enabled and was causing our errors.

To quickly prove this we tweaked the corresponding registry key located here: HKLM\Software\Policies\Microsoft\Windows\OneDrive – DisableFileSyncNGSC and set it to the value 0 (zero)

We also came across some registry settings that we used to customise the user experience of the new client.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive

Create a DWORD key with value name “DefaultToBusiness” with value data 1
Create a DWORD key with value name “EnableAddAccounts” with value data 1
Create a DWORD key with value name “DisablePersonalSync” with value data 1

 

Share Mailbox im Exchange Online (EO) einmal kurz erklärt

Einer der wirklich Interessanten Optionen im Office 365 ist die Shared Mailbox. Die Share Mailbox im Exchange Online ist ein spezielles Postfach, welche keine Lizenz benötigt und eine alternative für den öffentlichen Ordner im Exchange Server darstellt.

Hier nun kurz erklärt.

Eine Shared Mailbox hat alles was eine normale Mailbox in Office 365 besitzt. Dazu gehören die Postfach-, Kalender und -Aufgaben Funktionen sowie ein Adressbuch Container. Man kann der speziellen Mailbox auch mehrere E-Mail Adressen zuweisen und somit z.B. ein Sammelpostfach für ein Team oder Gruppe einrichten (Team Verkauf, Team Einkauf, Team Support usw.).

Durch die Delegationsfunktion kann ein Full Access (Vollzugriff) und/oder eine Send As (Senden als) Option für ausgewählte User oder Usergruppen freigeschaltet werden und somit wird diese spezielle Mailbox ein Gruppeninstrument.

Dieses Instrument ermöglicht es z.B. das eine Gruppe von Benutzern auf den Posteingang der Shared Mailbox zugreifen sowie auch mit den zugewiesenen E-Mail Adressen Nachrichten erstellen und versenden zu können. Ich glaube die Vorteil und Möglichkeiten eines gemeinsamen Kalenders, Adressbuch oder Aufgabenliste für eine bestimmte Gruppe von Benutzern liegen klar auf der Hand.

Da dieses Feature keine Lizenz benötigt und eine ausgezeichnet darstellt Gruppen- oder Team- Instrument bereitstellt, sollte es in keiner Planung beim Einsatz von Office 365 fehlen.

Hinweis: In meinem Fall beschreibe ich die Möglichkeiten aus einer MidSize Lizenz, welche mir eine Shared Mailbox mit 50Gb und die Archivierung Funktion bereitstellt.

Hier noch eine interessanter Gedanken Anstoß: Eine Office 365 Lizenz kann auf 5 Geräte installiert und über einen Account gleichzeitig gemeinsam genutzt werden. Da Ihr unbegrenzt Shared Mailboxen anlegen könnt, ergibt sich daraus eine ganz interessante Situation, welche BESTIMMT Kosten einspart oder den Mehrwert erhöht 🙂

Create shared mailboxes in Office 365 for Small Business

Ablauf von EO Benutzerkennwörter deaktivieren

Als globaler Administrator für Microsoft Office 365 für Unternehmen können Sie mit dem Windows Azure Active Directory Module for Windows PowerShell Benutzerkennwörter einrichten, die nie ablaufen. Sie können auch Windows PowerShell-Cmdlets verwenden, um die Konfiguration „never-expires“ zu entfernen oder anzuzeigen, für welche Benutzerkennwörter festgelegt ist, dass sie nie ablaufen.

Benötig wird dazu die „Azure Active Directory Module for Windows PowerShell“ die ihr nachfolgend in zwei Versionen downloaden könnt.

Windows Azure Active Directory Module for Windows PowerShell (32-bit version)

Windows Azure Active Directory Module for Windows PowerShell (64-bit version)

Nach der Installation starte Ihr die Powershell und solltet euch wie folgt mit dem Office 365 Administrator Account über die PS-Console anmelden.

$msolcred = get-credential

Eingabemaske mit Office365 Account (Administrator Rechte) füllen

connect-msolservice -credential $msolcred

mit folgendem Command könnt Ihr die Einstellungen überprüft

Get-MSOLUser | Select UserPrincipalName, PasswordNeverExpires

mit folgendem Command setzt ihr für alle User die Option auf Wahr

Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $true

mit folgendem Command setzt ihr für alle User die Option auf Falsch

Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $false

Nützliche Quellen: Manage Azure AD using Windows PowerShell, Konfigurieren von Benutzerkennwörtern, sodass diese nie ablaufen

Exchange Online mit Powershell administrieren

mache Dinge lassen sich mit der Powershell schneller und einfache handhaben, auch den Exchange Online

Vorabinformation zur Powershell

falls du keine Powershell auf deinem Rechner hast, kannst du die folgende Anleitung benutzen, ansonsten über springe diesen Teil

  1. Deinstalliere falls vorhanden deine alte Powershell Umgebung
  2. Installiere das Windows Management Framework

Detail kannst du auch hier lesen:  Install and ConfigureWindowsPowerShell

Verbindung zum Exchange Online über Powershell

  1. Powershell als Administrator starten (rechte Maustaste benutzen :))
  2. folgender Befehl, fühlt die Variable $LiveCred mit einem Office365 Admin:
$LiveCred = Get-Credential
  1. es öffnet sich ein Fenster wo du deine Account Daten für Office365 bestätigst (sollte ein Account mit Admin Rechten sein)
  2. danach folgende Kommandos in der PS ausführen:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session
  1. jetzt seid Ihr erfolgreich verbunden

detaillierte Informationen zum Thema findet Ihr hier:  Connect WindowsPowerShell to the Service

Jetzt ein Bespiel, um den Parameter OWAEnable zu prüfen sowie anzupassen

  1. mit folgenden cmlet prüft Ihr den Parameter  OWAEnabled für eine E-Mail Adresse. Falls OWAEnabled eingeschaltet ist, bekommt Ihr ein „true“ als Rückgabewert
Get-CASMailbox -Identity user@sample.com | FL *owa*
  1. um den OWAEnabled Parameter für eine E-Mail Adresse anzupassen, benutzt Ihr das cmlet wie folgt
Set-CASMailbox -Identity user@sample.com -OWAEnabled:$true

Mehr Informationen zum Thema findet Ihr unter folgendem Link:  Exchange-Verwaltungsshell