Factory reset und reboot auf einem Honeywell Dolphin 99EX/99GX

Die Anleitung dieser Windows Mobile (oder Windows embedded) Handhaldgeräte verzeichnet zwar einen Abschnitt für den Warmstart, nicht aber für einen kalten Systemreset. Ärgerlicherweise steht in der anleitung nur dieser Hinweis:

dolphin-99ex_reset

Wie kommt man auf eine solche arbeitsintensive Idee? Wie auch immer, ugg.li to the rescue! Das Terminal wird hart auf den Auslieferzustand zurückgesetzt wenn man diese Schritte bevolgt:

  1. Warmstart auslösen: „ALT/CTRL“ und  „ESC“ gleichzeitig für 5 Sekunden drücken
  2. Wenn das Display wieder angeht und das Logo anzeigt schnell „1277“ auf dem Keypad (oder „7811“ auf der Calculator-Tastatur) eintippen.
  3. Dann erscheint einen Moment später das Reset-Menü. Hier kann mit der Nummer 1 ein totalreset gestartet werden.

Überflüssig zu erwähnen, das ein Factory Reset ALLES löscht.

ActiveFax mit Lancom LANCAPI Autostart

Die Software ActiveFax ist – aus Adminsicht –  sehr sympatisch. Extrem stabil, ausgereift, sehr flexibel und hochperformormant. Eine klare Empfehlung für Admins (jedenfalls von den Admins von von ugg.li). Ähnliches gilt auch für die Lancom Lancapi. Ausgereift, stabil, sicher, flexibel … ales was man sich als Admin so wünscht. Hoffentlich behält Lancom diese Software noch ein bisschen im Portfolio 🙂

Eine Herausforderung ist der automatische Start von ActiveFax mit der Lancapi. Beim Serverreboot ActFax ist „leider“ zu schnell. Beim Reboot benötigt der RCAPI Client einen kurzen Moment (kurz ist in diesem Fall dehnbar) um seine(n) Router zu finden und mit den CAPI-Diensten zu verbinden. Startet ActFax vorher, beschwert es sich lautstark das kein ISDN-Gerät gefunden werden konnte.

Lösung: Den Administrator automatisch anmelden, die Dienste via Autostart in der richtigen Reihenfolge starten und die Konsole wieder sperren. Und das auch nur auf der Konsole um die Admins auf den weiteren RDP-Sessions nicht zu verärgern. Geht alles, kein Problem.

if "%SESSIONNAME%" == "Console" goto actfax
rem goto ende

:actfax
net stop ActiveFaxServiceNT
start "Intentionally left not blank." /d "C:Progra~1LANCOMLANCAPI" rcapi.exe
ping localhost -n 4 > NUL
net start ActiveFaxServiceNT
rundll32.exe user32.dll,LockWorkStation

:ende
@exit

Vermutlich wird Lancom dieses Verhalten nicht ändern (für Desktop-Anwendungen ist das ja auch in Ordnung) und ActiveFax wird auch keine Rücksicht auf die Lancom Lancapi nehmen. Daher dieser quick-and-dirty Fix für das Phänomen.

Veeam: FLR oder InstantRecovery Jobs werden nie beendet

Einmal gestartete Restore-Jobs sind recht hartnäckig: hat einer der Backup-Proxys einmal einen Job, führt dieser diesen vermeintlich auch fast unstoppbar aus. Für immer.

Das geschieht gerne dann, wenn man Maschinen in einer solchen Vorgang neu startet und das UI nicht mehr synchron mit der SQL-Datenbank ist. Das ist zum Beispiel reproduzierbar, indem man Proxy und Repositories ihren Job machen lässt und den Backup-Server mittendrin neu startet.

So behebt man diesen „Läuft noch“ Zustand:

  • SQL Management Studio starten
  • Verbinden mit der passenden Instanz (z.B. SERERNAMEVEEAMSQL2008R2)
    • Windows Authentifizierung nutzen
  • Neue Query in der Veeam-Datenbank „VeeamBackup“ ausführen:

[sql]
UPDATE [ReportRestoreSessionsAndTaskSessionsView]
SET „state“ = -1
WHERE „initiator_name“ not like ’null‘
[/sql]

Schon passen der UI-Status und die Tätigkeit des Systems wieder richtig zueinander. Quelle: Veeam-KB