RobertRiebisch.de

Update 2013-10-31: Vor dem Einsenden habe ich noch einmal die eingelegten Batterien kontrolliert. Eine weise Entscheidung, denn sonst wäre es peinlich geworden. Ich habe nämlich feststellen können, dass ein Kontakt in der Fernbedienung ein wenig korrodiert war, obwohl die Fernbedienung nur in normalen Wohnräumen benutzt wird. Nach dem Putzen des Kontakts funktioniert die Fernbedienung nun wieder einwandfrei. Beim Digitalkameratest letztens muss die Batterie wohl irgendwie in eine Position gerutscht sein, in der sie Kontakt hatte. Anders kann ich mir das nicht erklären.

Update 2013-10-28: Avox schreibt mir: "Ihrer Schilderung entnehmen wir, dass Sie bereits analytisch korrekt alle für Sie behebbaren Fehlerquellen ausgeschlossen haben. Bitte senden Sie das Gerät mit Fernbedienung zu uns ein."

Seit Februar 2012 versieht in unserem Kinderzimmer o. g. Internetradio hauptsächlich als Abspieler der kindlichen Hörspielsammlung seinen Dienst. Anfangs war ich sehr vom kontrastreichen Farb-Display angetan, denn unsere beiden anderen Radios Freecom MusicPal und NOXON iRadio 300 verfügen nur über blasse monochrome Anzeigen. Inzwischen kann ich jedoch dem ganzen Bedienkonzept der Benutzeroberfläche des INDIO nichts mehr abgewinnen. Denn was nutzt mir das tolle Display, wenn ich mich trotz Fernbedienung vor das Gerät setzen muss, weil die Schrift in der Anzeige so klein ist. Hier wäre es wünschenswert, wenn Avox verschiedene Skins anbieten würde.

Tja, und nun kann ich das INDIO nach gerade 20 Monaten nicht mal mehr mit der Fernbedienung ein-/ausschalten oder die Lautstärke verändern. Es reagiert einfach nicht mehr auf die Befehle der Fernbedienung. Die Batterien habe ich natürlich schon gewechselt. Weiterhin habe ich mit dem digitalen Sucher meiner Digitalkamera geprüft, ob diese das Infrarot-Signal "sehen" kann. Sie kann. Ein Reset auf die Werkseinstellungen brachte auch nichts. Damit bleibt im Prinzip nur noch ein Defekt des IR-Empfängers als Fehlerursache übrig.

Mal sehen, was der Avox-Support dazu sagt.

Wie das immer so mit Ideen zu Blog-Beiträgen ist, bleibt aus Zeitmangel gern mal was liegen. Vor folgendem Problem stand ich daher bereits Anfang August: Auf einem Windows SBS 2011 funktionierten die Windows Server Update Services (WSUS) nicht mehr. Offenbar auch schon länger. Die Konfigurationskonsole konnte ich nicht öffnen.

In der Windows-Ereignisanzeige fand ich massig Einträge folgender Art (gekürzt):

Event code: 3008
Event message: Es ist ein Konfigurationsfehler aufgetreten.
Event time: 02.08.2013 18:07:33
Event time (UTC): 02.08.2013 16:07:33
Event ID: f00cb7b6aaa14c9491570b58dfb8d276
Event sequence: 1
Event occurrence: 1
Event detail code: 0

Application information:
    Application domain: /LM/W3SVC/908950345/ROOT/DssAuthWebService-40-130199332535170547
    Trust level: Full
    Application Virtual Path: /DssAuthWebService
    Application Path: C:\Program Files\Update Services\WebServices\DssAuthWebService\
    Machine name: W2K11SBS

Process information:
    Process ID: 16616
    Process name: w3wp.exe
    Account name: NT-AUTORITÄT\NETZWERKDIENST

Exception information:
    Exception type: HttpException
    Exception message: Die Datei oder Assembly "DssAuthWebService, Version=3.1.6001.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Falscher Parameter. (Ausnahme von HRESULT: 0x80070057 (E_INVALIDARG))

Nicht nur für "/DssAuthWebService", sondern ebenso für "/SimpleAuthWebService" und "/ClientWebService".

Weiteren Einträgen der Ereignisanzeige konnte ich dann entnehmen, dass der Server schon einmal abgestürzt sowie die System-Festplatte vollgelaufen war. Nach vielen Lösungsansätzen stieß ich auf den Beitrag Could not load file or assembly ... The parameter is incorrect ... HRESULT: 0x80070057 (E_INVALIDARG) des Benutzers "derekslager".

Das simple Leeren des Ordners "C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files" löste endlich das Problem.

Ja, ihr habt richtig gelesen, es gibt sie noch. Die Kunden, die ATIES in der Version 8.0 aus dem Jahr 2009 einsetzen.

Bei einem dieser Kunden stand ich vor der Aufgabe die Backup-Tasks dahingehend zu ändern, dass jeden Sonntag eine Vollsicherung abwechselnd mal in die erste und in der folgenden Woche in die zweite Archivdatei stattfindet.

Zwei separate Tasks anzulegen und diese auf "alle 2 Wochen" zu stellen, war keine Kunst. Jedoch gibt es über die Programmoberfläche keine Möglichkeit den ersten Ausführungstermin zu bestimmen. Somit würden beide Sicherungen immer am selben (Sonn)Tag starten.

Ich hätte natürlich auch einfach den ersten Sonntag abwarten und dann den zweiten Backup-Task erstellen können, aber wir machen hier doch richtige IT. ;-)

Die Lösung kommt in Form des Kommandozeilenprogramms Acronis Scheduler daher, das ihr euch im Artikel Acronis Backup Software Scheduled Tasks Do Not Run herunterladen könnt.

Die darin enthaltene Datei "schedmgr.exe" kopiert ihr in den ATIES-Programmordner (z. B. "C:\Program Files (x86)\Acronis\TrueImageEchoServer") und öffnet dann dort ein "DOS-Fenster". Hier gibt ihr dann den Befehl "schedmgr get report | clip" ein. Anschließend könnt ihr den Bericht aus der Zwischenablage in Notepad einfügen und ihn in Ruhe studieren.

Ziemlich weit unten findet ihr jeden Task detailliert aufgelistet. Wichtig ist dabei die Zeile "Next try". Bei mir stand dort z. B. "03.11.2013" für die Tasks 1-2 und 1-3. Um den Backup-Task für die 1. Woche bereits ab dem 27. Oktober ausführen zu lassen, habe ich die Datei "schedmgr.exe" direkt gestartet und danach diese drei Befehle eingegeben:

task 1-2
set Begin=27.10.2013
exit

Den Erfolg der Aktion könnt ihr wieder mit "schedmgr get report | clip" und Notepad kontrollieren.

Wenn euch beim Aufrufen des Tabs "Live-Status" in der Trend Micro WFBS-Konsole die Fehlermeldung "Message returned, but with error status" angezeigt wird, ist sehr wahrscheinlich die interne Datenbank von WFBS beschädigt.

Im Artikel Recreating the HTTPDB database in Worry-Free Business Security (WFBS) erklärt Trend Micro, wie ihr die Datenbank neu erstellen lassen könnt.

Danach sind die Computergruppen in der Konsole erst einmal leer. Aber brecht bitte nicht gleich in Panik aus! Die Clients erscheinen wieder, sobald sie neu gestartet wurden.

"HTML ist gut. Markdown ist besser."

Diese Aussage hatte ich am 8. Oktober getroffen. Mehr als vier Wochen später bin ich noch genau der selben Meinung. Ich habe inzwischen zwar nur die Zeit gefunden, fünf neue Beiträge in Markdown-Syntax zu verfassen, aber das funktioniert nun endlich recht komfortabel.

Ich komme nun zu den Details der Realisierung: Das miniblog ist in PHP geschrieben. Die Anlaufstelle für Markdown in PHP ist Michel Fortins Seite PHP Markdown. Michel bietet dort zwei verschiedene Varianten an. Die Library benötigt PHP mindestens in der Version 5.3. Auf meinem gemieteten Webspace läuft jedoch nur die Version 5.2.17. Deswegen habe ich mir die Variante Classic angeschaut, die lediglich PHP ab der Version 4.0.5 voraussetzt. Michel will jedoch leider den Support dafür im Februar 2014 einstellen.

Aus dem Download PHP Markdown Extra 1.2.7 habe ich die Datei "markdown.php" in den Ordner "/includes/" kopiert. Im zweiten Schritt habe ich die Datei "/includes/miniblog.php" geändert: Unter die Zeile include(PATH . 'includes/functions.php'); gehört nun include(PATH . 'includes/markdown.php');. Weiterhin wird stripslashes($posts['post_content']), durch Markdown(stripslashes($posts['post_content'])), ersetzt.

Zuletzt muss die Datei "/feed.php" ähnlich angepasst werden: Unter include('includes/functions.php'); kommt noch include('includes/markdown.php'); und aus stripslashes($post_content) wird Markdown(stripslashes($post_content)).

Obwohl sonst Perfektionist, habe ich es mangels Zeit diesmal dabei bewenden lassen. Wer mag, könnte noch einen Ein-/Ausschalter für Markdown als Konfigurationsoption einbauen und den Hinweis "To format just use raw HTML.. <strong>, <span>, etc" editieren.

Trend Micro hat am 02. Oktober die deutsche Variante des Service Pack 1 (Build 2026) zum Download bereitgestellt. In der Readme-Datei steht zwar der 01. August, aber die neuesten enthaltenen Dateien datieren auf den 11. September. Wenn ich mir die aufgeführten Änderungen anschaue, solltet ihr das Service Pack auf jeden Fall installieren.

• WFBS_80_WIN_DE_SP1_StandAlone_B2026.exe
• Readme_WFBS_80_DE_SP1_WIN.txt

Kein Brüller, aber immer wieder erstaunlich, welche Stilblüten es bis in die finale Version einer Software (hier: Windows Server 2008 R2) schaffen: