Grosse, unscharfe Schriften nach Windows 8.1 Update
Nach dem Update auf Windows 8.1 stachen mir immer wieder grosse, unscharfe Schriften ins Auge. Ein Update des Grafiktreibers brachte auch keine Besserung. Gleiches nach der Aktualisierung der betroffenen Applikationen und dem Installieren aller Windows Updates. Also machte ich mich auf die Suche nach möglichen Einstellungen, welche während des Updates geändert wurden.
Gehen Sie wie folgt vor, um die Schriften wieder in Originalgrösse und scharf darstellen zu lassen:
- Klicken Sie mit der rechten Maustaste auf den Desktop und wählen Sie Screen resolution aus
- Im neu geöffneten Fenster Make text and other items larger or smaller anklicken
- Setzen Sie das Häckchen im Feld Let me choose one scaling level for all my displays
- Klicken Sie Apply
- Starten Sie den PC neu
Alle Einstellungen und Programme nach Windows 8.1 Update gelöscht
Beim Update eines englischen Windows 8 auf Windows 8.1 kann es dazu kommen, dass die Option Keep Windows settings, personal files and applications fehlt.
Da der Benutzer zu diesem Zeitpunkt nicht darüber in Kenntnis gesetzt wird, dass diese Option ebenfalls zur Verfügung stehen würde, kann es sein, dass nach dem Update alle Einstellungen und Programme verloren gegangen sind.
Dieses Problem tritt auf Computern verschiedenster Herstellern mit englischsprachigem Betriebssystem auf. Der Grund dafür ist, dass viele der Hersteller das Betriebssystem mit dem Sprachcode en-GB (English, Great Britain) zur Verfügung stellen. Wird auf diesen Computern versucht Windows 8.1 mit dem Sprachcode en-US (English, United States of America) zu installieren, dann ist dies zwar möglich, jedoch nur mit dem Verlust aller Einstellungen und Applikationen.
Der Sprachcode des Betriebssystems lässt sich einfach herausfinden:
- Mit der Windows-Taste das Modern UI (Startmenü) öffnen
- cmd eintippen
- Mit der rechten Maustaste auf Command Prompt klicken und Run as administrator wählen
- Im Command Prompt Fenster den Befehl dism /online /get-intl ausführen
Mittlerweile wurde das Problem erkannt; auf MSDN und TechNet steht eine spezielle Windows 8.1 Version für en-GB zum Download bereit.
Powershell liefert inkonsistente Ergebnisse (Configuration Cache)
Ein, auf den ersten Blick, merkwürdiges Phänomen bei der SharePoint 2010 Farm eines Kunden. Das Setup der Farm besteht aus zwei Web Front-end Servern, einem Application- und einem Crawl Server sowie drei FAST Servern.
In den Crawl Logs für eine bestimmte Content Source traten plötzlich mehrere hunderttausend Errors derselben Art auf. Ich versuchte als erstes, die in den Logs erwähnten URLs direkt vom Crawl Server aus im Browser zu erreichen. Keine der URLs war erreichbar, weder mit dem Farm Admin Account noch mit dem Content Access Account. Die erste Beunruhigung machte sich breit: Sind die Seiten nicht mehr erreichbar – aber warum gibt es noch keinen allgemeinen Aufschrei?
The SharePoint item being crawled returned an error when requesting data from the web service.
Was ist da los?
Daraufhin habe ich versucht den Status einer der nicht erreichbaren Site Collections vom Crawl Server aus in Powershell zu überprüfen.
Laut Powershell Resultate gibt es die entsprechenden Site Collections gar nicht (mehr). Jetzt begann es merkwürdig zu werden. Ein Blick in die Central Administration (läuft auf dem Application Server) zeigte nämlich ein völlig anderes Bild; gemäss Central Administration gab es die, von Powershell als nicht auffindbar gemeldeten, Site Collections sehr wohl. Doch eines hatten alle nicht auffindbaren Site Collections gemeinsam; sie waren in der gleichen Content Datenbank. Die Statusüberprüfung der Content DB via Central Administration zeigte diese als gestartet, und mit 13 Site Collections gefüllt, an. Soweit so gut, aber in den Resultaten von get-spspcontentdatabase (vom Crawl Server aus) fehlte genau diese Content DB.
Wie konnte das sein?
Die Central Administration zeigt im Grunde die grafisch aufbereiteten Ergebnisse, von Powershell Befehlen ausgeführt - auf dem Server, auf dem sie läuft - und ausgeführt mit dem Account, unter welchem sie betrieben wird.
Erste Vermutung: Gibt es vielleicht ein Berechtigungsproblem mit dem Farm Admin User und allenfalls dem Content Access Account auf dem SQL Server? Unwahrscheinlich, erstens gab es dort keine Änderungen. Warum sollte es nur eine Datenbank betreffen und müsste die Fehlermeldung dann nicht eher in die Richtung „Access denied“ gehen?
Kurze Gegenprobe: Gleicher Befehl auf dem Crawl Server unter dem Kontext des Farm Admin Accounts -> gleiches Ergebnis.
The content database could not be found.
Wenn aber die Central Administration diese Datenbank kennt, bleibt nur noch eine Möglichkeit offen: get-spspcontentdatabase vom Application Server, sowohl mit dem Farm Admin Account oder meinem Admin Account, wird die Datenbank als Resultat liefern. So war es auch. Gleiches galt auch für die beiden Web Front-end Server, was auch der Grund war, warum es keinen direkten Einfluss auf den End-User zu diesem Zeitpunkt hatte. Die Seiten waren durchgehend erreichbar.
Fazit
Es muss ein Server-spezifisches Problem sein.
Was für ein Problem hat der Crawler und wie kann es sein, dass es sich das nur in einer Datenbank äussert? Möglich wäre gewesen, dass die eine Content Datenbank mit einem anderen Connection String als alle anderen DBs zum SQL verbindet und es zum Beispiel bei den SQL Aliases einen lokal zerschossen hat, aber ein kurze Überprüfung hat diese Theorie ad acta gelegt.
- Berechtigungen: OK
- Verbindung SQL: OK
- Auffällige Event in den Logs: Keine
- Der obligatorische Serverneustart: Keine Veränderung
- Internet Recherche: Keine schnellen Hinweise
Also musste es etwas sein, was für den Server so korrekt zu sein scheint, aber nicht mit der tatsächlichen Situation übereinstimmt: Ein Caching Problem.
Lösung
Jeder SharePoint Server speichert die Informationen der Configuration DB Objekte lokal im Configuration Cache, um die Anzahl Abfragen an die Config DB zu verringern. Dieser Cache kann aufgrund diverser Probleme (z.B. SQL Timeouts während einer Änderung in der Config DB) inkonsistent werden und bedarf eines manuellen Eingriffes, damit der Server sich den Cache neu aufbaut.
Kurzbeschreibung Vorgehensweise
- OWS TimerJob Service stoppen
- Backup der cache.ini unter Drive:\ProgramData\Microsoft\SharePoint\Config\GUID
- Löschen aller XML Dateien unter Drive:\ProgramData\Microsoft\SharePoint\Config\GUID
- Cache.ini mit dem Notepad öffnen und die dortige Zahl löschen und mit der Zahl 1 ersetzen.
- OWS TimerJob Service wieder starten, der TimerJob Config Refresh wird nun die gelöschten XML Files neu und als korrekten Abbild der Config DB erstellen.
Ergebnis
Nachdem der Objekt Cache auf dem Crawler neu aufgebaut wurde, war das Ergebnis der Powershell Cmdlets mit den anderen Servern wieder konsistent und auch die Crawl-Komponente konnte die Site Collections der vermissten Content DB wieder erfolgreich crawlen.
Weitere Informationen
Clear the SharePoint Configuration Cache
http://blogs.msdn.com/b/josrod/archive/2007/12/12/clear-the-sharepoint-configuration-cache-for-timer-job-and-psconfig-errors.aspx
What Is a Configuration Cache and Why Do I Care About It?
http://blogs.technet.com/b/chad/archive/2009/11/25/tip-8_3a00_-what-is-a-configuration-cache-and-why-do-i-care-about-it_3f00_.aspx