Kategorie-Archiv: Microsoft 365

Kennwortänderung für alle Benutzer in Microsoft 365 erzwingen

Veröffentlicht am von — Keine Kommentare ↓
„Free digital security background“/ CC0 1.0

Das Erzwingen einer „selbstständigen“ Kennwortänderung kommt schon mal vor – vor allem, wenn ein Admin mit viel Wissen ein Unternehmen verlässt. Das ist in Microsoft 365 im GUI leider nicht möglich, aber natürlich an der PowerShell.

So zwingt man einen (oder mehrere) Benutzer, das eigene Kennwort bei der nächsten Anmeldung zu ändern – ohne das Kennwort zu kennen.

Lösung

Nach dem Obligatorischen Connect-MsolService:

Set-MsolUserPassword -UserPrincipalName [email protected] -ForceChangePasswordOnly $true -ForceChangePassword $true

Das lässt sich nun weiterverarbeiten.

Zum Beispiel, um alle Microsoft 365 Benutzer „auf einmal“ zu zwingen, ihr Kennwort zu ändern:

Get-MsolUser -All | Set-MsolUserPassword -ForceChangePasswordOnly $true -ForceChangePassword $true

So filtert man (zum Beispiel) eine Gruppe von Benutzern und erzwingt die Änderung:

Get-MsolUser -All | ? { $_.Country -eq "Hessen"} | Set-MsolUserPassword -ForceChangePasswordOnly $true -ForceChangePassword $true

Wichtig: Man muss sowohl den Parameter ForceChangePassword als auch ForceChangePasswordOnly setzen. Wenn man ForceChangePasswordOnly überspringt, wird nur ein neues Kennwort für den Benutzer (automatisch) generiert und man muss selbiges manuell verteilen (Stichwort „Initialkennwort“).

Windows Hello (PIN/Biometrie) für Benutzer vollständig zurücksetzen

Veröffentlicht am von — Keine Kommentare ↓

Manchmal geht Windows Hello kaputt. Windows Hello verwaltet die Computerlokale Komfort-Anmeldung mit „einfachen“ PINs, Fingerabdrücken, der Gesichtserkennung und so weiter. Grundsätzlich eine nette Erfindung, welche Anmeldung an Windows etwas komfortabler macht.

Es gibt Momente, in denen das kaputtgeht. Zum Beispiel wenn sich in der Domäne (AD/AAD) die PIN-Richtlinien ändern oder sich zwei Profile widersprechen.

Die Fehlermeldungen sind leider wenig zielführend. Wir haben die Meldung „Diese Option ist derzeit nicht verfügbar“ nach der PIN-Eingabe gesehen, die Fehlernummer 0x801c0451 beim Versuch die PIN zurückzusetzen und verschiedene Fehler nach einer Biometrischen Anmeldung.

Lösung

Die einfachste Möglichkeit ist, Windows Hello radikal zurückzusetzen und sauber neu zu konfigurieren. Das geht am einfachsten, indem man den Zertifikatsspeicher von Hello vollständig zu entfernt:

Certutil -DeleteHelloContainer

Das muss im Kontext des betroffenen Benutzers passieren. Bei einer defekten Windows-Anmeldung tut es auch ein angemeldeter Administrator, der die Shell „Als Benutzer“ ausführt. Nach dem Reboot kann man Hello dann neu einrichten, als hätte es das vorher nicht gegeben.

Excel/Word „Die Datei kann nicht geöffnet werden, da der Dateipfad größer als 259 Zeichen. Kürzen Sie den Pfad oder den Dateinamen“

Veröffentlicht am von — 2 Kommentare ↓

Es kommt vor, dass Benutzer beim Öffnen von Dateien aus tief verschachtelten Ordnern (oder sehr langen Pfadnamen) diese Fehlermeldung von Office-Apps wie Excel, Word oder PowerPoint erhalten:

Die Datei kann nicht geöffnet werden, da der Dateipfad größer als 259 Zeichen. Kürzen Sie den Pfad oder den Dateinamen

Abgesehen von dem grammatikalischen Fehler, dass im ersten Satz das abschließende Verb fehlt (vermutlich „ist“), stimmt diese Meldung.

Lösung

Es gibt keine Lösung, aber einen Workaround.

Microsoft Office-Apps, allen voran Excel, unterstützen keine Pfade mit mehr als 259 Zeichen. Das hat mit der heiligen Abwärtskompatibilität zu tun, denn es könnte ja sein das noch ein Unternehmen auf VB-Macros aus den 90ern baut. Und mit „ein“ sind hier „100% der Fortune 500“ gemeint 😉

  • Windows local and UNC files: 260 characters
  • OneDrive / SharePoint files synced to the local drive: 260 characters
  • Online OneDrive / Online SharePoint files (opened directly in the WebApp) 400 characters

Der Workaround ist einfach: Die Excel-Web-App nutzen und die Datei direkt auf dem Sharepoint (Online) bearbeiten,

Microsoft 365 Exchange online Mailbox neu mit einem lokalen Benutzer verbinden

Veröffentlicht am von — Keine Kommentare ↓

Es kommt in Hybrid-Szenarien schon mal vor, dass ein Admin einen synchronisierten AD-Benutzer nachträglich innerhalb von Microsoft 365 mit einem Postfach versieht. Das ist nicht „supported“, das Postfach taucht nicht im Exchange ECP auf und es drohen fiese Konflikte, wenn Attribute synchronisiert werden. Außerdem kann es auf einmal doppelte Mailadressen geben, weil beide Exchange-Server auf unterschiedliche Adresslisten zugreifen.

Da sollen/müssen die Benutzer wieder auftauchen.

Lösung

Eine „offizielle“ Lösung gibt es nicht so richtig. Exchange Online verwaltet Postfächer etwas anders als der „on Premises“ Exchange, man kann daher Postfächer eigentlich nicht auf die Schnelle ab- und wieder anhängen. Vor allem nicht mit verbundenen Benutzern (Outlook oder Applegeräte).

Es gibt aber einen (bisher) ganz brauchbar funktionierenden Trick.

  • Wenn eine Mailbox in EXO angelegt wurde
  • UND diese On-Premises im ECP [noch] nicht existiert (Postfachtyp „Office 365“)
  • DANN kann man die Mailbox „noch einmal“ On-Premises als Remote-Mailbox enablen. ACHTUNG: Dabei werden die im Exchange Online erstellten Attribute (SMTP-Adressen, Kontaktinformationen, Berechtigungen …) bei der nächsten Synchronisation überschrieben.

Schritt für Schritt geht das so

  1. Exchange GUID der Mailbox aus Exchange Online holen:
    Get-Mailbox <NAME> | fl ExchangeGuid
  2. Primäre E-Mail-Adresse der Mailbox auslesen (wenn nötig):
    Get-Recipient <NAME>| fl PrimarySmtpAddres
  3. Alle weiteren E-Mail-Adressen der Mailbox auslesen (wenn nötig):
    Get-Recipient <NAME> -ResultSize Unlimited | fl @{Name="EmailAddresses";Expression={($_.EmailAddresses | Where-Object {$_ -clike "smtp*"} | ForEach-Object {$_ -replace "smtp:",""}) -join ", "}}
  4. Mailbox On-Premises „neu“ in Exchange Online enabeln
    Connect-ExchangeOnline
    Enable-RemoteMailbox <NAME> -RemoteRoutingAddress @domain.mail.onmicrosoft.com
    Set-RemoteMailbox <NAME> -ExchangeGuid <GUID AUS SCHRITT1>
  5. Im ECP (On-Premises) die E-Mail Adressen aus Schritt 2 und 3 der Mailbox wieder hinzufügen und einen „Entra ID Connect“ Sync („initial“) starten.

Wenn das erledigt ist, kann es eine Weile dauern, bis das Online-Adressbuch das Postfach wieder korrekt anzeigt. In meinem letzten Fall hier etwas weniger als 24 Stunden.

Microsoft Office 365 Apps auf RDS (RD-Sessionhosts) oder VDI Fehler „Da hat etwas nicht geklappt, [1001]“

Veröffentlicht am von — Keine Kommentare ↓

Auf RDS oder in VDI-Umgebungen, auch mit FSLogix, sehen wir schon mal diesen Fehler, wenn ein Benutzer sein Office (meit Outlook) öffnen möchte:

Fehler: Es ist ein Fehler aufgetreten. [1001]

oder auch

Fehler: Da hat etwas nicht geklappt. [1001]

Der Effekt ist nicht wirklich persistent und scheint nicht immer aufzutreten. Manchmal geht es auch „Vormittags“ und „Nachmittags“ aber nicht mehr.

Lösung

Es gibt ein paar Pfade, die eigentlich nicht roamingfähig sind, aber in Szenarien mit FSLogix-Profilcontainern trotzdem unfreiwillig umgezogen werden. Die Ordner (und Registry-Schlüssel) werden somit zwischen RDS oder VDI Hosts „geroamt“ge-roamed“. Das macht die Schlüssel und Host-Zertifikate aber ungültig.

Am einfachsten ist es, die betreffenden Pfade und Registry-Schlüssel einfach zu löschen. Nach einem ab- und wieder anmelden tritt der Fehler dann nicht mehr auf, bis es wieder zu einem Hostwechsel kommt. Dann kann das Script aber einfach wieder ausgeführt werden.

@echo off
REM /*
REM	Office (Outlook) Fehler "1001" beheben
REM	https://support.microsoft.com/en-us/office/6f63238d-d83c-437c-a929-de72fe819793
REM	10.04.2024 Admins auf ugg.li
REM */

if exist "%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy" rd /s /q "%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy"
if exist "%localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy" rd /s /q "%localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy"

for /d %%i in ("%localappdata%\Packages\*") do (
	if exist %%i\AC\TokenBroker echo rd /s /q %%i\AC\TokenBroker
)

reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL" /f
reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD" /f
reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin" /f

Die „richtige“ Lösung wäre eine Anpassung von FSLogix, oder einfach ein Fix von Microsoft das roamed-certificates einfach einbezieht …