Bei der Aktualisierung eines Exchange 2010 Service Pack 3-Servers lief die Installaton des Update Rollups an, blieb dann aber im Schritt “Stopping Services” hängen: weder wurde die Anzahl an Systemprozessen geringer noch konnte in der Dienste-Verwaltung ein Fortschritt beobachtet werden - alle Dienste liefen ungestört weiter. Auch der Versuch, vor der Installation des Update Rollups die Dienste manuell zu stoppen wurde vom Installationsprogramm zuverlässig ignoriert.

Nachdem die eigenen guten Ideen aufgebraucht waren, führte die Google-Suche nach vielen sinnlosen Forentreffern schließlich zum Artikel “Installing Exchange Server 2007/2010 Update Rollups”, der zwar mit “Have you ever tried to install an Exchange Server Update Rollup which ended with an error message?” auf den ersten Blick ebenfalls nicht zum Problem passend aussah, aber mit dem Stichwort “PowerShell execution polices” genau den zielführenden Hinweis lieferte:

Das Installationsprogramm des Update Rollups scheint im Hintergrund einige PowerShell-Skripte zu starten (u.a. zum Stoppen der Dienste), überprüft aber vorher weder, ob die Ausführungsvoraussetzungen gegeben sind noch wird offentlichlich eine Auswertung der erfolgreichen bzw. erfolglosen Skriptausführung vorgenommen - mit dem Resultat, daß die GUI des Installers mitsamt Progressbar artig bis in alle Ewigkeit auf ein Skript wartet, das seine Aufgaben gar nicht beginnen konnte.

Nachdem die Berechtigungen mittels

zunächst überprüft und dann vom ursprünglichen “Nur signierte Skripts” auf “Lokale und remote signierte Skripts zulassen” geändert wurde, lief die Installation des Update Rollups innerhalb weniger Minuten durch.

Wenn eine Firma Meister darin ist, sinnvolle Funktionen zu streichen, sinnbefreite Funktionen einzuführen und mit Konfigurationsmöglichkeiten zu geizen, dann ist das Google.

So war ich auch wenig begeistert, als mir in einem neuen Tab unter der Überschrift “Artikel für Sie” als erstes die News “Kevin Großkreutz im Krankenhaus” und “Nachholspiel gegen Dortmund” angeboten wurden. Tröstlich, daß selbst akribische jahrelange Beobachtung und Datenspeicherung offensichtlich nicht dazu führt, ein halbwegs sinnvolles Nutzerprofil erstellen zu können.

Natürlich ist auf den ersten und zweiten Blick keine Möglichkeit vorgesehen, dem unnützen Daten- und Akkuverbrauch ein Ende zu bereiten.

bis einschließlich Chome 57:

Erst ein Blick in die erweiterten Einstellungen, die über die URL “chrome://flags” erreichbar sind, bietet die Möglichkeit, “Show content snippets on the New Tab page” auf “Deaktiviert” zu stellen.

ab Chrome 58:

Mit Chome 58 hat Google den Parameter geändert, dieser lautet nun “Show server-side suggestions on the New Tab page”, der Weg zu den Einstellungen führt weiterhin über die URL “chrome://flags”.

ab Chrome 68:

In Chome 68 heisst der Parameter immer noch “Show server-side suggestions on the New Tab page”, die Optionen wurden aber umbeannt und die gesuchte Einstellung ist nun “Disabled”. Der Weg zu den Einstellungen führt weiterhin über die URL “chrome://flags”.

ab Chrome 78:

Wie NoNPerfect in den Kommentaren gepostet hat, reicht “Show server-side suggestions on the New Tab page“ auf “Disabled” alleine nicht mehr aus. Zusätzlich muß noch “Interest Feed Content Suggestions” ebenfalls auf “Disabled” gesetzt werden.

ab Chrome 80:

Wie den Kommentaren zu entnehmen ist, scheinen die oben aufgezeigten Lösungen unter Chrome 80+ nicht mehr zu funktionieren. Da ich Google Chrome inzwischen sowohl vom Mobilgerät als auch vom Desktop verbannt habe, kann ich selbst keine Lösung mehr liefern - falls jemand fündig wird, bitte in den Kommentaren posten.

Wenn Windows nach dem Systemstart plötzlich mit einem “Fehler 1069: Der Dienst konnte wegen einer fehlerhaften Anmeldung nicht gestartet werden.” vermeldet, daß ein Start des “SQL Server (SQLEXPRESS)” nicht möglich ist, so blickt man im ersten Moment ratlos auf den Bildschirm, denn in der Regel wurden dem Dienst keine expliziten Anmeldedaten zugewiesen.

Die Lösung des Problems ist einfach, wenn auch auf den ersten Blick nicht unbedingt intuituv:

• Übersicht der Dienste öffnen

• Den SQL Server Dienst mit der rechten Maustaste anklicken und “Eigenschaften” wählen

• Zur Registerkarte “Anmelden” wechseln

• Die Punkte in den Kennwort-Feldern löschen

• Mit “OK” bestätigen

Dies sollte zur Meldung führen, daß Windows die benötigten Berechtigungen erneut zugewiesen hat und der Dienst sollte sich wieder starten lassen.

Sofern das Problem nach einiger Zeit erneut auftritt, sollte ein Blick in die Gruppenrichtlinien erfolgen, ob hier eine benötigte Einstellung fälschlicherweise überschrieben wird.

Sollte es auf einem Android-Gerät zu Fehlern kommen, kann - wie bei vielen anderen Systemen auch - ein Blick in die Logdateien helfen. Dies kann entweder direkt auf dem Gerät - oder deutlich komfortabler und besser auswertbar auf einem mittels USB verbundenen PC geschehen.

Zum Auslesen bzw. Mitschreiben der Logdateien muss zuerst das USB-Debugging aktiviert werden: hierzu die Einstellungen öffnen und den i.d.R. letzten Punkt “Über das Tablet” öffnen. Hier ebenfalls wieder bis zum Ende scrollen und insgesamt sieben mal auf die Zeile “Build-Nummer” tippen. Sofern man ein halbwegs standardkonforme Android-Version installiert hat, sollte nun der Hinweis erscheinen, daß man ab sofort Entwickler ist. In den Einstellungen wird nun der zusätzliche Punkt “Entwickleroptionen” angeboten. Diese Einstellungen öffnen, aktivieren und unter dem Punkt “Debugging” den Punkt “USB-Debugging” aktivieren.

Nun das Gerät mit dem Rechner verbinden und das Logging mittels

starten. Bei der ersten Verbindung erscheint eine Autorisierungsabfrage, die bestätigt werden muss. Ab sofort werden alle Meldungen in die oben genannte Datei geschrieben. Bei Bedarf kann die Ausgabe noch angepasst werden, nähere Informationen hierzu befinden sich in der Android Developer Dokumentation.

Soll ein Microsoft SQL Server (an der Stelle egal, ob Express- oder Vollversion) mit Icinga2 überwacht werden, so stellt der Name des Dienstes eine kleine Hürde dar:

Wird der Name mit “MSSQL$SQLEXPRESS” in der entsprechenden Argumentliste angegeben, so beschwert sich Icinga2 beim Überprüfen der Konfiguration mit

Ein im ersten Reflex eingefügtes Backslash-Zeichen vor dem Dollar-Zeichen löst das Problem nicht, führt aber zu einer neuen Fehlermeldung:

Des Rätsels Lösung bietet - wie so oft RTFM - oder hier RTFAQ, denn dort steht:

How do I properly escape $ in strings
Dollar signs are “strange” in Nagios and has to be escaped using double $$s. Thus in Nagios config you need to put $$.