Autoren-Archiv: weed

Kalender einer Ressource zeigt keinen Betreff an, sondern den Namen des Organisators

Veröffentlicht am von — Keine Kommentare ↓

Ein Ressourcenpostfach (z.B. Shared Mailbox) ist in Exchange Online mit „AutoAccept“ (automatische Zusagen, AutomateProcessing) konfiguriert, damit der Kalender Besprechungsanfragen bestätigt.

Die Besprechungsanfragen werden auch korrekt automatisch angenommen. Der Besprechungsbetreff wird im Postfach des Organisators auch angezeigt.

Aber alle anderen Benutzer (mit Berechtigungen auf dem Postfach) sehen statt des Besprechungsbetreffs nur den Namen des Organisators.

Lösung

Dies ist das Standardverhalten von Exchange Online (und Exchange seit 2010) und seither irritierend. Das passiert immer dann, wenn AddOrganizerToSubject und/oder DeleteSubject auf True festgelegt sind.

Aktuelle Einstellung anzeigen:

Get-CalendarProcessing -Identity <RESSOURCE> | fl *subject*

Einstellungen ändern:

Set-CalendarProcessing -Identity <RESSOURCE> -DeleteSubject $false -AddOrganizerToSubject $false

DeleteSubject: Soll der Betreff entfernt werden? (true=ja)

AddOrganizerToSubject: Soll der Name des Organisierenden den Betreff ersetzen? (true=ja)

Windows 11 Explorer Kontextmenü von Windows 10 wiederherstellen

Veröffentlicht am von — Keine Kommentare ↓

Windows 11 bietet per Rechtsklick ein „neues“ Kontextmenü im Explorer an, das um alle wichtigen Funktionen beschnitten wurde. Wer das, wie wir Admins, ebefalls nicht mag, kann auch weiterhin das „alte“ Menü von Windows 10 nutzen.

Windows 10 und 11 mit Ihren Explorer-Kontextmenüs

Lösung

Im Explorer (und Desktop) kann man die Tastenkombination Shift+F10 nutzen, um das alte Kontextmenü sofort zu öffnen.

Ab Windows 11 Version 22572 reicht sogar das einfache drücken von Shift aus, um das gute alte Kontextmenü aufzurufen.

Wer nur das alte Kontextmenü nutzen möchte, kann mit einer schnellen Änderung in der Registry das Default-VErhanlten ändern.

Für den aktuellen Benutzer

reg add "HKEY_CURRENT_USER\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve

WSUS liefer keine Updates aus, Event 1309 tritt auf, Windows Update zeigt Fehler 0x8024401f

Veröffentlicht am von — Keine Kommentare ↓

Problem

Ein WSUS-Server mag keine Updates mehr ausliefern. Wir haben das bei „alten“ WSUS-Setups gesehen, aber auch bei nagelneu und ganz frisch installierten Server-Rollen.

Auf den (Windows 10) Clients gibt es nur die wenig hilfreichen Windows-Update Fehlermeldung 0x8024401f gegen die auch kein „Troubleshooting“ hilft:

Windows Update Fehler 0x8024401f

Auf dem WSUS-Server hingegen sagt das Ereignisprotokoll unter „Anwendung“ mit dem Fehler 1309 zumindest etwas mehr aus, wenn auch sehr kryptisch:

Event code: 3005 
Event message: Es ist eine unbehandelte Ausnahme aufgetreten. 
Event sequence: 4 
Event occurrence: 1 
Event detail code: 0 
 
Application information: 
    Application domain: /LM/W3SVC/2062417591/ROOT/ClientWebService-1-132949411067470524 
    Trust level: Full 
    Application Virtual Path: /ClientWebService 
    Application Path: C:\Program Files\Update Services\WebServices\ClientWebService\ 
    Machine name: SRV-DC01 
 
Process information: 
    Process ID: 10664 
    Process name: w3wp.exe 
    Account name: NT-AUTORITÄT\Netzwerkdienst 
 
Exception information: 
    Exception type: InvalidCastException 
    Exception message: Das Objekt des Typs "System.Web.Compilation.BuildResultCustomString" kann nicht in Typ "System.Web.Compilation.BuildResultCompiledType" umgewandelt werden.
   bei System.Web.UI.WebServiceParser.GetCompiledType(String inputFile, HttpContext context)


[...]

Lösung

Ab WSUS3 mit allen Updates und „einigen“ Clients, schlägt bei gleichzeitigen Anfragen eine Typkovertierung fehl. Das ist ein Bug im WSUS-Installer, der die Anwendung fälschlicherweise mit der klassischen (meint: Typenstrenger ISAPI) Pipeline konfiguriert.

Korrekt ist die „Managed ASP.NET“ Pipeline für diesen Applikationspool:

WSUS "Error Code 3005" beheben
  1. Den IIS-Manager auf dem WSUS-Server öffnen
  2. Link unter SERVERNAME\Anwendungspools\WsusPool öffnen
  3. Den „Verwalteter Pipelinemodus“ von „Klassisch“ auf „Integriert“ umstellen
  4. „Anwendungspool sofort starten“ anhaken

Man muss den Server (oder den IIS) danach nicht neu starten, die Änderungen setzt sich sofort durch und die Updates fließen wieder fehlerfrei. Oder zumindest ohne diesen Fehler.

WordPress „Das Verzeichnis uploads kann nicht angelegt werden. Ist das übergeordnete Verzeichnis durch den Server beschreibbar?“ trotz korrekter Rechte

Veröffentlicht am von — 1 Kommentar ↓

Nach diesem Effekt habe im im Auftrag der Admins hier soeben viel zu lange gesucht.

Screenshot: Das Verzeichnis uploads kann nicht angelegt werden. Ist das übergeordnete Verzeichnis durch den Server beschreibbar?

Wenn WordPress beim Upload von Daten in die Mediathek die Fehlermeldung anzeigt

Das Verzeichnis uploads kann nicht angelegt werden. Ist das übergeordnete Verzeichnis durch den Server beschreibbar?

liegt es oft an den Berechtigungen des Ordners /wp-content/uploads (Soll: 0755). Aber das ist es nicht immer.

Lösung

Nach dem Umzug eines WordPress Setups auf einen anderen Server war es vielmehr der upload_path aus der Datenbank, der noch auf ein altes Verzeichnis zeigte, das es so nicht mehr gibt. In der Tabelle wp_options gibt es dieses entscheidende Feld. Also ich kannte es bisher nicht 🙂

Also schnell am mysql cli gefixt:

UPDATE `wp_options` SET `option_value` = '/var/www/<PATH>' WHERE `wp_options`.`option_id` = 58 AND `wp_options`.`option_name` = 'upload_path';

und schon geht es wieder. Schade das WordPress die Fehlermeldung nicht etwas aussagekräftiger macht, zum Beispiel wohin es denn schreiben möchte.

Ich hätte viel eher diesen Beitrag von Lothar lesen sollen …

Outlook „Offline Adressbuch kann nicht heruntergeladen werden“ Fehler 0x8004010F

Veröffentlicht am von — Keine Kommentare ↓

Outlook versucht im Cache Modus immer das Offline Adressbuch (OAB) zu synchronisieren. Der Prozess bricht aber gerne mal mit dem wenig hilfreichen Fehler 0x8004010F ab.

Das Problem tritt gerne nach Migrationen auf, wenn ein Exchange Server auf ein anderes System (oder neue VErsion) migriert wurde. Dabei wird nämlich ein neues OfflineAddressBook (OAB) generiert, welches auch die Verteilung der Adresslisten übernimmt.

Die Adressliste auf den Clients ist dann meist auch nicht mehr richtig (veraltete Inhalte), allerdigns ist im OWA alles korrekt und aktuell.

Lösung

Zuerst: An der EMS prüfen ob das Adressbuch als „Default“ markiert ist:

Get-OfflineAddressBook | select Name, IsDefault

Hier sollte ein IsDefault: True zurückkommen.

Dann kann man mit prüfen, ob das OAB auch korrekt via Autodiscover verbreitet wird:

Get-OfflineAddressBook | select Name, VirtualDirectories, *web*

Und hier passiert gerne der Fehler. Exchange kennt zwei verschiedene Varianten, um dem Client den Zugriff auf das OAB zu wemöglichen:

  1. Man gibt an welche (IIS-) Virtual Directories vom Client abgefragt werden können um das OAB herunterzuladen
  2. Man erlaubt allen Virtual Directories den Download anzubieten

Microsoft (und wir) raten natürlich zur Variante Nummer 2:

Set-OfflineAddressBook "Standard-Offlineadressbuch" -GlobalWebDistributionEnabled $true

Der Name „Standart-Offlineadressbuch“ ist hier exemplarisch, alle existierenden Offline-Adressbücher listet man mit Get-OfflineAddressBook auf.