Outlook Suche in Freigegeben Ordnern liefert keine Ergebnisse (Suche funktioniert nicht in „fremden“ Ordnern)

Die Outlook-Suche verhält sich ja häufiger etwas ungewöhnlich, das man aber sei einer Weile praktisch nicht mehr freigegebene Ordnern (Nicht freigegebene Postfächer) von anderen Nutzern suchen kann, ist merh als ärgerlich. Grade in Zeiten von Exchange Online ist das sehr ärgerlich.

Schuld ist Outlook in Verbindunge mit dem Windows Indexdienst. Freigegebene Ordner werden standartmäßig wie freigegebene Postfächer heruntergeladen; diese landen somit im Index. Leider beauftragt Outllook bei der Sucher nur noch „Eigenes Postfach“ und liefer somit bei freigegebenen Ordnern nur leere Ergebnismengen zurück.

Woraround

Man kann Exchange dazu zwingen, die Serverseitige Suche zu verwenden. Der Zugriff auf Microsoft 365 Exchange Online-Postfächer ist dann zwar etwas langsamer, dafür liefert die Outlook-Suche plötzliche wieder korrekte Ergebnisse. Bonus: Neu vergebene Berechtigungen greifen nun ebenfalls sofort.

Das geht unter den E-Mail Konten > E-Mail > Postfach auswähen und oben „Ändern“ > Weitere Einstellungen > Erweitert > Freigegebene Ordner herunterladen AUS schalten.

Kein Zugriff auf Admin-Shares (c$, d$) auf Windows (10, Server 2016/2019) für lokale Administratoren

„Zugriff verweigert“ bekommen (lokale) Administratoren für den Zugriff auf \\server\c$ Admin-Freigaben. Die Freigabe ist aktiv, in der Freigabenverwaltung sichtbar, das Kennwort stimmt, aber Windows verweigert den Zugriff.

Schuld ist, mal wieder, die Benutzerkontensteuerung, genauer die Remote User Account Control (Teil der UAC) in Windows. Abhängig davon mit welcher Art von Konto man sich anmeldet, also Domänenkonto oder Lokal, schlägt die Filterung des UAC-Zugriffstokens zu. Diese wirkt sich in der Standardeinstellung nicht auf Domänenkonten in der Gruppe der lokalen Administratoren aus, sondern nur auf lokale Konten.

Lösung

Um die Filterung des Tokens zu deaktivieren:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

 "LocalAccountTokenFilterPolicy"=dword:00000001

Bluescreen Fehler APC_INDEX_MISMATCH nach Windows Update KB5000808 beim Drucken

Das kummulative Update vom 9. März 2021 (KB5000808) verursacht BSOD-Abstürze von Windows über die w2in32kfull.sys. Das passiert beim Drucken auf vielen verschiedenen Druckern von Kyocera, HP, Nashuatec und anderen. Unabhängig vom „echten“ Gerätetreiber oder einer Universal-Lösung.

Workaround und Lösung

Es gibt zwei halbwegs praktikable Möglichkeiten den Fehler zu umgehen, bis die Hersteller aktualisierte Treiber bereitstellen.

  1. Nutzung des XPS Treibers (im Usermode). Einige Hersteller stellen einen Treiber bereit, der den Druckauftrag via XPS verarbeitet. Das funktioniert (bei uns bisher) fehlerfrei. HPE hat sowas aber beispielsweise nicht für alle Modelle.
  2. Nutzung des Microsoft PCL6 printer drivers. Die Drucker verstehen alle PCL6, die Druckaufträge funktionieren also fehlerfrei. Leider verliert man den Zugriff auf die Drucker-Spezifischen Funktionen (PIN-Freigabe, Tackern …), aber einfache Drucke funktionieren erstmal wieder.

Update: Die Deinstallation von KB5000808 hilft natürlich auch

Update: Die Hersteller arbeiten mit Hochdruck an aktualisierten Treibern (… „working hard on this problem …“).

Thx Dariusz

Benutzerprofil-Datenträger Maximal Größe nachträglich anpassen

In einer RDS-Sammlung kann man die maximal Größe einer User Profile Disk bei der Erstellung vorgeben. Nachträgliche Änderungen sind jedoch nicht mehr möglich. Die Option „Maximale Größe“ ist ausgegraut. Man müsste die ganze Sammlung dafür eigentlich neu erstellen …

Die Option maximal Größe ist ausgegraut

Lösung

Man muss direkt das VHDX-Template das die Sammlung bei der Erstellung anlegt bearbeiten. Das Template heisst UVHD-template.vhdx und liegt in dem in der Sammlung festgelegten Share.

Die VHDX „Festplatte“ vergrößert man am einfachsten mit DISKPART.

C:> Diskpart

DISKPART> select vdisk file="F:\vhdx\UVHD-template.vhdx"
(Datei auswählen)

DISKPART> expand vdisk maximum=20000
(Vergrößern, 20000 = 20 Gbyte)

DISKPART> attach vdisk
(vDisk mounten)

DISKPART> list volume
(Volumes auflisten)

DISKPART> select volume <VOLUME-ID>
(Auswählen des Volumes, die ID der VHDX-Partition wählen)

DISKPART> extend

DISKPART> detach vdisk

DISKPART> exit

Im Live-Betrieb sieht das dann so aus:

Leider wird die Anzeige im Windows Server-Manager dazu nie aktualisiert, der Wert bleibt im GUI auf dem erstmalig eingetragenen Wert stehen. Die Box also müsste eigentlich „Maximale Größe bei erstellung“ heißen. Da der Server-Manager aufgrund seiner Fehler und generellen Schwerfälligkeit grundsätzlich aber nicht unbedingt das Lieblingswerkzeug von Administratoren ist, kann man diese rein kosmetische Angabe dort ganz gut ignorieren.

„Der ausgewählte Anschluss kann nicht entfernt werden. Dieser Vorgang wird nicht unterstützt.“ beim löschen von WSD Ports

Wenn man versucht WSD-Ports unter Windows 10 (Server 2016/2019) zu löschen, erhält man die Fehlermeldung „Der ausgewählte Anschluss kann nicht entfernt werden. Dieser Vorgang wird nicht unterstützt.“

Solange en Drucker mit dem Port verbunden ist klappt da auch mit „normalen“ Ports nicht, aber WSD-Anschlüsse lassen sich auch ungenutzt nicht entfernen.

Lösung

Erstelle einen Temporären Drucker auf genau diesem Port (Treiber egal) und lösche dann den ganzen neuen TEMP-Drucker. Der WSD-Port wird damit zusammen fehlerfrei entfernt.

Windows Server 2008R2 Windows Update Fehler 0x80092004

Windows Server 2008 R2 ist zwar schon in die Jahre gekommen, läuft aber hier und da noch und soll auch Updates bekommen. Die aktuellen Updates (zum Beispiel „2020-01 Sicherheitsupdate für .NET Framework 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8 für Windows 7 und Server 2008 R2 für x64 (KB4534976)“ schlagen aber mit dem Fehler 0x80092004 fehl.

Grund ist die Signatur der aktuellen Patches. Der Fehlercode 0x80092004 steht für CRYPT_E_NOT_FOUND. Das Windows Update konnte einen kryptografischen Wert nicht verifizieren und lehnt das Update daher ab. Die besagten Pakete sind alle nur noch mit einem SHA2 Hash signiert – Windows 2008 R2 versteht aber kein SHA2.

Lösung

Manuell Installation des „Servicing stack update for Windows 7 SP1 and Windows Server 2008 R2 SP1: March 12, 2019“ (KB4490628) von:

http://www.catalog.update.microsoft.com/search.aspx?q=4490628

Sobald das Update SHA2ermöglichst, läuft die Installation der weiteren sofort fehlerfrei Updates durch.

TEMP-Verzeichnisse aller Benutzer (und Windows) auf einmal aufräumen

Problem

Terminalserver, oder mit der modernen Bezeichnung „RemoteDesktop Sessionhosts“, neigen trotz aller Pflege dazu nach und nach „Voll zu müllen“.

Vor allem die verschiedenen TEMP-Verzeichnisse sammeln im Laufe der Zeit (meist) unnötige Daten an. Zu den „üblichen Verdächtigen“ wie %WINDIR%\Temp und %Windows%\Prefetch gesellen sich vor allem die Benutzer-Verzeichnisse Appdata\Local\Temp\.

Lösung

Mit der PowerShell kann dieses Problem in zwei Zeilen (und einem regelmäßigen Start mit enstsprechenden Rechten) gelöst werden:

$tempfolders = @("C:\Windows\Temp\*", "C:\Windows\Prefetch\*", "C:\Users\*\Appdata\Local\Temp\*" )

Remove-Item $tempfolders -force -recurse

Die erste Zeile enthält in einem Array die entsprehenden Ordner (PS versteht auch Platzhalter wie ‚*‘), die zweite Zeile den Befehl der dafür ausgeführt wird.