Archiv des Autors: weed

Outlook E-Mail Standardschriftart mit GPO festlegen

Veröffentlicht am von — Keine Kommentare ↓

Praktisch seit dem Erscheinen des ersten Outlook-Clients in „Office 2000“ wünschen sich Unternehmen die Möglichkeit, eine Standartschriftart in E-Mail für Benutzer in der Domöne vorzugeben. Natürlich ist es generell nicht möglich Fonts zu verwenden die der Empfänger nicht besitzt – und man hat ja keine Ahnung welche der Empfänger hat. Aber nunja „bei uns wird das dann ja richtig angezeigt“ scheint das faktenignorierende Killerargument zu sein. Und der Kunde ist ja schliesslich König.

Unter OWA gibt es sowiso bisher keine Möglichkeit, die Standartschriftart vorzugeben. Jeder Postfachnutzer muss das selber machen.

Aufgrund der technischen Unlösbarkeit dieser Herausforderung, gibt es keine Standart-Gruppenrichtlinie (GPO) dafür; jedenfalls nicht bis Windows Server 2016 und Office 2016 (Office365).

Outlook Standartschriftart mit GPO vorgebenSo legt man die Standart-Schriftart für Outlook (Office 365) mittels GPO fest

  1. Einen Outlook-Client wunschgemäß mit der Standartschriftart konfigurieren.
    Je nach Outlook-Version findet sich die Einstellung etwas versteckt. In Outlook 2013/2016 liegt das beispielsweise unter Datei > Optionen > E-Mail > Briefpapier und Schriftarten.
  2. Einstellungen aus der Registry in eine GPO (idealerweise GPO-Preferences) übernehmen 
    HKEY_CURRENT_USER\Software\Microsoft\Office\<Version>\Common\Mailsettings

    Die Einstellung ist ein Wert von Typ „REG_BINARY“ und sieht etwas seltsam aus, das ist aber korrekt so. Es reicht auch eine „Benutzer-Richtlinie“ um den Wert zu vergeben,

Am einfachsten geht das, wenn auf dem client mit Outlook auch die Remoteserver-Verwaltungstools für Windows 10 (RSAT) installiert sind. Dann öffnet man die Gruppenrichtlinienverwaltung einfach auf dem Client, erstellt/bearbeitet das passende Richtlinienobjekt (GPO), fügt unter Benutzerkonfiguration > Einstellungen > Windows-Einstellungen > Registrierung ein neues Element hinzu und wählt die passenden Schlüssel aus.

Zum Beispiel für Outlook 2016 lautet der Registry-Pfad:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\MailSettings

Die relevanten Schlüssel für die Auswahl der Outlook-Schriftart sind:

  • ComposeFontComplex – Neue E-Mail
  • ComposeFontSimple – Neue E-Mail
  • CReplyFontComplex – Antworten und Weiterleiten
  • CReplyFontSimple – Antworten und Weiterleiten
  • TextFontComplex – Lokale Anzeige bei Plain-Text E-Mails
  • TextFontSimple – Lokale Anzeige bei Plain-Text E-Mails

Windows 8/10 Suche findet keine Inhalte mehr in PDF-Dateien

Veröffentlicht am von — Keine Kommentare ↓

Problem

Unter Windows 8/8.1 und Windows 10 findet die Suche „auf einmal“ keine Text-Treffer mehr in PDF-Dateien. Normalerweise funktioniert die Volltextindizierung auch für PDF-Dateien ausgezeichnet, auber „auf einmal“ klappt das nicht mehr.

Lösung

Der Adobe „the Krebsgeschwür“ Reader ist in den allermeisten Fällen schuld. In vielen Cases zerstört dieser bei der Installation oder beim Update den Windows PDF-Reader iFilter.

In der Windows-Registry unter de Schlüssel HKEY_CLASSES_ROOT\.pdf\PersistentHandler den „Standart“ Wert ersetzen:

{F6594A6D-D57F-4EFD-B2C3-DCD9779E382E} (FALSCH)

{1AA9BF05-9A97-48c1-BA28-D9DCE795E93C} (RICHTIG)

Danach den Dienst Windows-Suche stoppen und wieder starten. Falls der Ordner PersistentHandler unter .pdf nicht existiert, muss man ihn vorher neu anlegen.

Schneller Fix für die Kommandozeile:

C:\> REG ADD HKEY_CLASSES_ROOT\.pdf\PersistentHandler /d "{1AA9BF05-9A97-48c1-BA28-D9DCE795E93C}" /t REG_SZ /f
C:\> net stop WSEARCH && net start WSEARCH

Leider kann Windows die nun fehlenden PDFs nicht nachträglich erkennen. Allerdings wird jedes PDF das vom Dateisystem modifiziert wird, wird automatisch neu indiziert …

WSUS HTTP Fehler 503 „The service is unavailable“ und „Serverknoten zurücksetzen“

Veröffentlicht am von — 8 Kommentare ↓

Problem

Die Windows-Update Infrastruktur über den WSUS funktioniert nicht zuverlässig. Nach einem Serverneustart funktioniert noch alles, aber irgendwann steht der Dienst. Die Testweise aufgerufene URL:

http://THISISNOTTHEBESTWSUSINTHE.WORLD:8530/SimpleAuthWebService/SimpleAuth.asmx

Meldet einen „503: Service Unavailable“ zurück. Der IIS scheint nichts mehr vom WSUS auszuliefern.

Dazu gibt es im Eventlog den Hinweis:

Event ID: 6703
 WSUS Synchronization failed.
 Message: The request failed with HTTP status 503: Service Unavailable.
 Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer.

Oder auch:

HTTP Error 503 The service is unavailable

Nähere Forschungen ergeben, das der IIS-Applikationspool für die WSUS-Dienste („WsusPool“) sich im Status „Beendet“ befindet.

Lösung

Wenn der „WsusPool“ mit dieser Meldung steht, ist das Arbeitsspeicherlimit vermutlich schuld. Bei vielen Clients (in diesem Fall etwa 500) oder vielen Administratoren die die WSUS-Konsole verwenden, wird der Speicher schon mal knapp. Default sind 2Gb, wir empfehlen mindestens 4Gb.

Die Einstellungen am Pool heißen „Limit für den privaten Speicher“ („Private Memory Limit“). Diesen auf ~4000000 (etwa 4gb) setzen und den Pool wieder starten. Bei größeren Umgebungen darf es auch gerne etwas mehr sein.

IIS-Manager > Anwendungspools > WsusPool > Erweiterte Einstellungen > „Limit für den privaten Speicher“ auf 4000000

Wenn man schonmal da ist, lohnt auch ein kurzer Blick auf die anderen relevanten Einstellungen:

  • „Private Memory Limit (KB)“ empfehlen wir auf „0“
  • „Limit Interval (minutes)“ von 5 auf 15 erhöhen
  • „Service Unavailable Response“ umstellen, HttpLevel auf TcpLevel
  • „Queue Length“ von 1000 auf (locker) 2500 erhöhen

„Failed registration of app type 2 (Signals) from plugin unity.“ VMWare Tools

Veröffentlicht am von — Keine Kommentare ↓

Problem

Nach Installation/Update der VMware Tools tritt auf einmal im Windows-Eventlog eine weitere Warnung auf:

Ereignistyp:    Warnung
 Ereignisquelle:    VMware Tools
 Ereigniskategorie:    Keine
 Ereigniskennung:    1000
 Beschreibung: [warning] [vmusr:vmtoolsd] Failed registration of app type 2 (Signals) from plugin unity.

Das ist besonders bei Terminalservern (RDS) nervig, weil der Fehler bei jeder Anmeldung protokolliert wird. Im Prinzip funktioniert aber alles.

Lösung

Zuerst: Updaten der VMware Tools auf die aktuellste Version. Der Fehler sollte danach nicht mehr auftreten.

Wenn doch, wird ein zusätzlicher Eintrag in der Konfiguration der VMware Tools „tools.conf“ den Fehler zuverlässig beheben. Die Datei findet sich im Pfad „%ProgramData%\VMware\VMware Tools\tools.conf“.

[unity]
Pbrpc.enable=false

Damit wird der „Protocol Buffer Remote Procedure Call“ (PBRPC) zu deaktiviert und es gibt keine Ladefehler des Unity-Plugins beim anmelden mehr. Mehr Informationen: VMware KB2038263