Auf einer RDS Farm durften wir soeben diesen Fehler suchen. Einige Benutzer erhielten beim Versuch Word-Dateien im Explorer via Doppelklick zu öffnen die Meldung:
Irreführend: „Überprüfen Sie die TEMP-Umgebungsvariable“
Die Arbeitsdatei konnte von Word nicht erstellt werden. Überprüfen Sie die TEMP-Umgebungsvariable.
Außerdem dauert es extrem lange, bis Word die Datei(en) öffnet. Das funktioniert, dauert nur wahnsinnig lange.
Lösung
Mit der %TEMP% Variable und dem Temp-Pfad hat diese Meldung in der Regel nicht viel zu tun. Der Fehler wird auch nicht von Word selbst verursacht, sondern von der Vorschau für Word-Dateien im Explorer. Selbige holt sich einen veralteten Verweis aus der Registry für einen Vorschauhandler, den es nicht mehr gibt.
Die folgenden Schlüssel sind in der Regel (bis auf Unterschlüssel) leer, enthalten also keine Werte. Wen dem so ist, einfach den ganzen Schlüssel mit Unterschlüsseln löschen, der Fehler ist dann sofort weg.
„Aus gegebenem Anlass“ schon wieder ein PowerShell Script. Mit leichtem Schmunzeln, denn die Zeit der Tippfehler ist in der IT noch nicht vorbei 😉
„Seral“ ohne „i“ (hier mit wenig hilfreichem Inhalt)
Ein Kunde möchte die Seriennummer seiner neuen Computer als Windows-Computernamen im AD verwendet wissen. Während einer „normalen“ Installation oder auch einer Cloud-Installation (ohne Autopilot) wird der Computername abgefragt, aber niemand kennt seine Seriennummer – und Menschen tendieren gerne mal zu äußerst seltsamen Namen. Daher führt der einfachste Weg zu Lösung über ein Script das die Namensvergabe automatisch nachträglich erledigt.
Das funktioniert nur richtig, wenn die Computer eine Seriennummer imn BIOS (EFI) hinterlegt haben. Ist das Feld leer, gibt Windows „To Be Filled by O.E.M.“ zurück und das Script setzt eine 10-Stellige Zufallszahl ein.
In diesem Fall soll(t)en alle Computer „CMP-<Serial>“ heissen und es gibt nur Clients von HP und Lenovo (mit gefülltem Serial-Feld). Selbige nutzen allerdings unterschiedlich lange Seriennummer, daher kürzen wir diese ein.
Lösung
Hier ist das kommentierte Script. Via Intune oder GPO ausgeführt bekommt so jeder PC nach dem nächsten Start seinen einmaligen Namen.
# Prefix festlegen
# - Achtung, der "Computername" hat maximal 15 Zeichen.
$prefix = "CMP-"
# Serial holen
# - Achtung, KEIN Tippfehler, die Property heisst "BiosSeralNumber"
$serial = Get-ComputerInfo | Select-Object BiosSeralNumber
$serial = $serial.BiosSeralNumber
# Kürzen (auf die ersten 10 Stellen)
$serial = $serial.substring(0, 10)
# leerzeichen entfernen
$serial = $serial.replace(' ','')
# Wenn leer, Warnung ausgeben und Random-Nummer verwenden
if ($serial -like "*ToBeFill*") {
$serial = Get-Random -Minimum 100000000 -Maximum 9999999999
Write-Warning "No Serial found, using Random Number '$serial' instead."
}
# Namen zusammenbauen (und anzeigen)
$computername = $prefix + $serial
Write-Host Henceforth you shall be known as: $computername
# Computer umbenennen
Rename-Computer -NewName $computername -Force -ErrorAction SilentlyContinue
Man registriert sein Windows-Gerät, auch den Home-PC, automatisch ins Microsot 365 AzureAD eines Unternehmens, indem man nach einer Office 365 Installation den Haken bei „Verwaltung meines Gerätes durch meine Organisation zulassen“ nicht entfernt. Alternativ kann man auch links unten auf den „unsichtbaren“ Button „Nein, nur bei dieser App anmelden“ klicken.
Wenn man sein Gerät registiert hat taucht es auch nach wenigen Cloudmomenten im AzureAD Device Manager auf:
Und bekommt von dort einige Richtlinien. Vor allem die Sicherheitsrichtlinien greifen dann auf dem Gerät – machmal ist das bei „Privat-PCs“ etwas überraschend.
Fehler CAA2000B (AADSTS500014)
Standardmäßig tritt beim zurücksetzen der Windows-Hello PIN auf dem PC nach dem Azure AD Registrierungsvorgang dieser Fehler auf:
Es ist ein Problem aufgetreten
wir konnten sie nicht anmelden. Falls dieser Fehler weiterhin besteht, wenden Sie sich an den Systemadministrator, und geben Sie den Fehlercode an: CAA2000B.
Das liegt daran, das der Administrator die „App“ die die Zugangs-PIN ändern will erst zu „seinem“ Azure AD hinzufügen und bestötigen muss.
Lösung
1. Die PIN-Reset Web-App „Service“ aufrufen und als Globaler Administrator anmelden. Am einfachten mit GENAU diesem Link:
Azure Active Directory > Anwendungen > Unternehmensanwendungen > Alle Anwendungen > „PIN“ suchen
Es sollten dort nun zwei Apps auftauchen:
Und schon (nach dem nächsten Neustart mit Internet) funktioniert das PIN-Ändern wieder wie vorher.
Wenn der Vorgang trotzdem noch fehlschlägt, hilft oft ein Blick in das Cloud App Security Dashboard für Anwendungen; möglicherweise hat hier anderer Admin das OAUTH dieser Apps vielleicht blockiert …
