Um den Backupprozess zu vereinheitlichen wurde vor einiger Zeit bei den letzten verbliebenen physischen Rechnern/Servern auf Veem Endpoint Backup bzw. Veeam Agent for Linux bzw. for Windows umgestellt. Die Datenspeicherung erfolgt über ein zentrales Veeam Backup Repository. Das ganze Backup- und Recovery Szenario wurde in einer VM Umgebung durgespielt und dokumentiert und, man ahnt es schon, VM Umgebung…., gabs beim ersten Recoveryversuch an der echten phsyischen Maschine erhöhten Pulsschlag.
Im konkreten Fall wird eine Debian Maschine, installiert auf einer Dell Workstation T3600, mittels Veeam Agent for Linux täglich gesichert. Zum Zeitpunkt der Wiederherstellung lief das System noch. Es sollte nur ein paar Tage zurückgesetzt werden. Als erstes also das Linux Recovery Image bei Veeam heruntergeladen, per Rufus auf nen Stick gepresst, Workstation gebootet und schwupp die wupp, Kernel Panic!…. nach wenigen Sekunden.
Ein Blick in die Doku bei Veeam verrät, daß in dem Recovery Image u.U. Treiber für die eigene Hardware fehlen könnten und es eine Möglickeit für die Erstellung eines eigenen individuellen Recovery Mediums gibt. Glücklicherweise lief der betreffende Rechner noch. Man kopiert das Imagefile von Veeam (nenne ich jetzt mal ‚veeam-base-image.iso‘) auf den betreffenden Rechner und erzeugt mittels:
veeamconfig config patchiso --input /tmp/veeam-base-image.iso --/tmp/output custom-drivers-image.iso
ein neues Imagefile. Dieses dann wieder per Rufus auf den Stick pressen, Rechner neu starten und tadaaa…. o.O hängt der Bootvorgang schon wieder, diesmal in einer Schleife mit der unschönen Meldung
Not enough memory to load specified image
Hier half es auf dem Stick die Datei isolinux.cfg im Ordner isolinux mittels eines Texteditors (bspw. Notepad++ unter Windows) zu editieren.
Die letzte Zeile
append initrd=initrd.img
wird ergänzt um einen Eintrag für zugewiesenen Speicher. In meinem Fall sah das dann so aus
append initrd=initrd.img mem=2048M
Datei speichern, Stick anstecken, Dell T3600 Workstation damit booten uuuuunnnnddd….. tadaaa, Die Veeam Agent Oberfläche erscheint. Das sich diese nun nicht mehr bedienen ließ, konnte mit dem Anstecken einer PS2 Tastatur behoben werden. USB Tastatur wollte hier keine mehr reagieren.
Kurzer Check in den Netzwerkeinstellungen, Netzwerkkarte erkannt, IP per DHCP erhalten und somit konnte es losgehen im ersten Schritt die Anbindung an das Veeam Backup Repository zu konfigurieren. Die eigentliche Wiederherstellung lief dann so, wie man es von Veeam gewohnt ist. Schnell und zuverlässig. Nach einer Viertelstunde war das System auf den gewünschten Zeitpunkt zurückgesetzt.
Merke, die alte Weisheit mit Bart, daß ein Backup nur dann wirklich ein Backup ist wenn man die Wiederherstellung getestet hat, hat sich hier wieder einmal bewahrheitet. Glücklicherweise konnte das Recoverymedium noch an die spezifische Hardware angepasst werden. Das sollte man also künftig direkt bei der Einrichtung der Datensicherung mit erledigen. Und auf jeden Fall einen Testdurchlauf unter Echtbedingungen durchführen! Und dokumentiern! Eh klar… 😉
Sophos UTM – MS Office Update Fehler – reason=range
Seit einiger Zeit begleiten mich Probleme beim Update von Officeinstallationen. Diese scheitern an der Sophos UTM Firewall wenn der Webproxy im Transparent Mode läuft, reason=“range“.
Nach zahllosen fehlgeschlagenen Versuchen auf Basis div. Vorschläge aus den Sophos Community Foren habe ich schlussendlich folgende für mich funktionierende Lösung gefunden.
Im Bereich „Web Protection“ – „Filtering Options“ – „Exceptions“ eine neue Exception erstellen.
Skip these checks
Matching these URLs
Quelle: Sophos UTM: Range requests changes from 9.5 to 9.6
Quelle: Sophos Community Forum – UTM Web Filter blocks Office Updates
OCS Inventory NG – leere Computerliste nach Update
Nach dem Update des OCS Inventory Server (in meinem Fall auf 2.8, dann 2.91) bleibt beim Aufruf der Computerliste diese komplett leer.
Dies liegt an einem fehlerhaften Datenbankupdate. In der Tabelle Hardware fehlt meist die Spalte „archive“.
Funktionierender Lösungsvorschlag von Github Issuecomment 722304958
Kurz komplett zusammengefasst
Danach wird die Computerliste wieder vollständig gefüllt dargestellt.
HP EliteBook 840G3 – integrierte Cam + MS Teams funktioniert nicht
Die integrierte Kamera des HP EliteBook 840 G3 konnte für Teams Meetings nicht genutzt werden. Beim Start der Sitzung erschien kurz ein Bild, dieses fror dann ein und die Aktivitäts-LED der Cam ging aus. Mit Zoom oder anderen Programmen bestand dieses Verhalten nicht.
Scheinbar haben dieses Problem auch so manche Lenovo Notebooks. Für diese fand ich einen „Patch“ zum Download. Der Patch macht nichts weiter, als den Registry Schlüssel
zu löschen. Das kann man als vorsichtige Natur ja mal manuell mit umbenennen ausprobieren. Kein Reboot notwendig. Die integrierte Cam funktioniert anschließend auch mit MS Teams anstandslos.
Macbook Pro (early 2015) SSD Tausch
Ich besitze ein Macbook Pro von Anfang 2015 mit einer Festplattenkapazität von 256 GB. Das war eigentlich beim Gerätekauf schon nicht mehr ganz zeitgemäß aber ich bin eine Weile damit klargekommen. Inzwischen ging mir aber das Jonglieren mit dem knappen Speicherplatz so sehr auf die Nerven, daß ich mich zu einem SSD Upgrade entschied.
Das Macbook wird regelmäßig per Time Machine auf ein NAS gesichert. Weil ich es bis dahin nicht besser wusste, entschied ich mich für den Datentransfer auf die neue SSD allerdings für ein neues einmaliges Time Machine Backup auf eine lokal angeschlossene USB HDD (was nicht hätte sein müssen, später mehr dazu).
Als neue SSD sollte es das „Transcend JetDrive 850“ mit einer Kapazität von 960 GB werden. Zum Zeitpunkt Mai 2019 kostete das Laufwerk ca 360€ bei Amazon.
Also Daten gesichert, MacBook runterfahren, umdrehen und alle Schrauben am Boden lösen. Hier gut sortieren, sie sind nicht alle gleich groß!
Praktischerweise liegen dem JetDrive zwei Schraubendreher, T5 und P5. Mit dem P5 öffnet man das Macbook, mit dem T5 löst man die vorhandene SSD. Leider ist die Qualität der Werkzeuge so mangelhaft, daß sich damit nur die Demontage erledigen ließ.
Nach dem SSD Tausch den Deckel/Boden wieder aufsetzen und mit den sortierten Schrauben befestigen. Hier verabschiedete sich der mit dem JetDrive gelieferte P5 Schraubendreher. Das war für das Recovery erstmal egal aber um das Macbook schlussendlich wieder zu zu bekommen, orderte ich noch ein „Essential Electronics Toolkit“ von IFIXIT für ca. 20€ nach. Der hier mitgelieferte P5 Bit funktionierte dann wie erwartet.
Um nun das System von meiner Time Machine Sicherung wiederherzustellen, steckte ich die USB HDD an das Macbook, schaltete ein und wartete. Das System bootet in eine Wiederherstellungsumgebung in welcher man
1)eine Time Machine Sicherung wiederherstellen kann
2)MacOS neu installieren kann
3)auf die Online Hilfe zugreifen kann
4) die Festplatte mittels dem Festplattendienstprogramm „behandeln“ kann.
Um es kurz zu machen, ein direktes Recovery scheiterte mit einer wenig aussagekräftigen Meldung, daß ein Fehler bei der Formatierung aufgetreten sei. Es stellte sich raus, daß die SSD mit einer GUID-Partitionstabelle formatiert werden muss. Voreingestellt ist „Master Boot Record“. Also das Festplattendienstprogramm starten.
Anschließend den Festplattendienstmanager schließen und mittels Time Machine das Recovery anwerfen. Das dauerte für meine ca. 240 GB etwa 3 Stunden von der ext. USB HDD.
Im Anschluss steht dem System die komplette Kapazität der neuen SSD zur Verfügung. Es sind keine Partitionsanpassungen o.ä. nötig.
Bootet man nicht von einer angeschlossenen lokalen ext. HDD muss man beim Rechnerstart mittels CMD+R beim Einschalten den Recoverymodus initiieren. In dem Recoverymodus kann man das Macbook ins Wlan einbinden. Daher hätte ich somit auch eine Verbindung zu meinem Backup auf dem NAS herstellen können.
Ich beschreibe hier meine Erfahrung beim Wechsel der SSD am Macbook Pro. Für die Einstellung mit der GUID-Partitionstabelle habe ich eine Weile suchen müssen. Eventuell schone ich ja mit meinem Beitrag das ein oder andere Nervenkostüm.
EXCHANGE ERROR: 454 4.7.5 CERTIFICATE VALIDATION FAILURE ÜBER STRATO-SMARTHOST
Bei einem Exchange 2010 Server, der seine ausgehenden Mails direkt bei einem Strato Smarthost abkippt, gingen plötzlich keine E-Mail mehr raus. Die Analyse ergab, daß die Verbindung zum Smarthost mit Fehler 454 4.7.5 CERTIFICATE VALIDATION FAILURE scheiterte. Grund dafür ist, daß bei einem der letzten Windows Updates das Rootzertifikat von „T-Telesec GlobalRoot Class 2“ aus dem Zertifikatsspeicher für vertrauensvolle Stammzertifizierungsstellen entfernt wurde. Einen Grund hierfür konnte ich nicht ermitteln. Das betreffende Zertifikat kann man hier herunterladen:
https://www.telesec.de/de/public-key-infrastruktur/support/root-zertifikate/category/59-t-telesec-globalroot-class-2
Nach Import o.g. RootCA in den enstprechenden Zert.speicher auf dem Exchangeserver und Neustart des Exchange Transport Service klappt der ausgehende Mailverkehr wieder.
Danke an das Sophos Forum an dieser Stelle HIER.
Windows 10 Update wuauclt Nachfolger
Bei bisherigen Windowsversionen konnte das Erkennen von neuen Windows Updates per wuauclt /detectnow getriggert werden. Dies ist ab Windows 10 nicht mehr möglich. Hier hilft ein Zweizeiler in der Powershell:
Bei der Windows Update Fehlersuche war ein Blick in c:\windows\windowsupdate.log in der Vergangenheit hilfreich. Öffnet man diese Datei unter Windows 10 erscheint nur der lapidare Hinweis
Also hilft auch hier die Powershell weiter. Bei Eingabe von
wird die Datei WindowsUpdate.log auf dem Desktop des angemeldeten Benutzers erzeugt. Diese kann man wie gewohnt nach Hinweisen zum Updateprozess durchforsten.
Veeam Agent for Linux – Recovery mit Hürden
Um den Backupprozess zu vereinheitlichen wurde vor einiger Zeit bei den letzten verbliebenen physischen Rechnern/Servern auf Veem Endpoint Backup bzw. Veeam Agent for Linux bzw. for Windows umgestellt. Die Datenspeicherung erfolgt über ein zentrales Veeam Backup Repository. Das ganze Backup- und Recovery Szenario wurde in einer VM Umgebung durgespielt und dokumentiert und, man ahnt es schon, VM Umgebung…., gabs beim ersten Recoveryversuch an der echten phsyischen Maschine erhöhten Pulsschlag.
Im konkreten Fall wird eine Debian Maschine, installiert auf einer Dell Workstation T3600, mittels Veeam Agent for Linux täglich gesichert. Zum Zeitpunkt der Wiederherstellung lief das System noch. Es sollte nur ein paar Tage zurückgesetzt werden. Als erstes also das Linux Recovery Image bei Veeam heruntergeladen, per Rufus auf nen Stick gepresst, Workstation gebootet und schwupp die wupp, Kernel Panic!…. nach wenigen Sekunden.
Ein Blick in die Doku bei Veeam verrät, daß in dem Recovery Image u.U. Treiber für die eigene Hardware fehlen könnten und es eine Möglickeit für die Erstellung eines eigenen individuellen Recovery Mediums gibt. Glücklicherweise lief der betreffende Rechner noch. Man kopiert das Imagefile von Veeam (nenne ich jetzt mal ‚veeam-base-image.iso‘) auf den betreffenden Rechner und erzeugt mittels:
ein neues Imagefile. Dieses dann wieder per Rufus auf den Stick pressen, Rechner neu starten und tadaaa…. o.O hängt der Bootvorgang schon wieder, diesmal in einer Schleife mit der unschönen Meldung
Not enough memory to load specified image
Hier half es auf dem Stick die Datei isolinux.cfg im Ordner isolinux mittels eines Texteditors (bspw. Notepad++ unter Windows) zu editieren.
Die letzte Zeile
wird ergänzt um einen Eintrag für zugewiesenen Speicher. In meinem Fall sah das dann so aus
Datei speichern, Stick anstecken, Dell T3600 Workstation damit booten uuuuunnnnddd….. tadaaa, Die Veeam Agent Oberfläche erscheint. Das sich diese nun nicht mehr bedienen ließ, konnte mit dem Anstecken einer PS2 Tastatur behoben werden. USB Tastatur wollte hier keine mehr reagieren.
Kurzer Check in den Netzwerkeinstellungen, Netzwerkkarte erkannt, IP per DHCP erhalten und somit konnte es losgehen im ersten Schritt die Anbindung an das Veeam Backup Repository zu konfigurieren. Die eigentliche Wiederherstellung lief dann so, wie man es von Veeam gewohnt ist. Schnell und zuverlässig. Nach einer Viertelstunde war das System auf den gewünschten Zeitpunkt zurückgesetzt.
Merke, die alte Weisheit mit Bart, daß ein Backup nur dann wirklich ein Backup ist wenn man die Wiederherstellung getestet hat, hat sich hier wieder einmal bewahrheitet. Glücklicherweise konnte das Recoverymedium noch an die spezifische Hardware angepasst werden. Das sollte man also künftig direkt bei der Einrichtung der Datensicherung mit erledigen. Und auf jeden Fall einen Testdurchlauf unter Echtbedingungen durchführen! Und dokumentiern! Eh klar… 😉
falscher #wannacry Patchdownload für deutsches Windows XP
Folgt man dem technet blogartigel Customer Guidance for WannaCrypt attacks und lädt sich für ein deutsches Windows XP den vermeintlich passenden Patch herunter, bekommt man beim Installationsversuch auf einem Win XP SP3 folgenden unschönen Fehler: „Die installierte Windows-Version stimmt nicht mit dem Update überein, das installiert werden soll.“
Der Dateiname „WindowsXP-KB4012598-x86-Embedded-Custom-DEU.exe“ läßt einen ja schon erahnen, daß hier etwas nicht stimmt.
Über die Suche im Windows Update Catalog nach dem KB Artikel 4012598 findet sich aber ein gültiger funktionierender Download.
Hier der aktuell gültige Direktlink zum Patch für Windows XP SP3 DEU KB KB4012598
HPE DL380 Gen7 ILO ERR_SSL_BAD_RECORD_MAC_ALERT
Beim Aufruf des ILO Interface an einem HPE DL380 Gen 7 trat der Fehler „ERR_SSL_BAD_RECORD_MAC_ALERT“ auf.
Der Internet Explorer blieb eine konkrete Fehlermeldung gar ganz schuldig.
Ursache ist die alte ILO Version (hier ILO3 1.16) im Zusammenspiel mit der TLS Einstellung im Browser. Im IE läßt sich das mit dem temporären Abschalten von TLS 1.2 beheben.
Dann läßt sich ILO wenigstens mit dem IE aufrufen. Hinterher wieder TLS 1.2 aktivieren nicht vergessen.
Für Chrome konnte ich die Einstellung nicht finden.
Windows 10 – Windows Server 2016 – Update hinter Proxy
Wenn ein interner WSUS das Update für die aktuellste Windowsversion noch nicht mitregelt und zusätzlich der Internetzugang über einen Webproxy organisiert ist, dann sucht sich der Updatedienst von Windows 10 bzw. Server 2016 nen Wolf nach neuen Updates. Ein ähnliches Verhalten (teilweise sogar gepaart mit Update Dienst Abstürzen) zeigten auch schon ältere Windowsversionen.
Die Proxyeinstellungen für den Internet Explorer welche über die Systemsteuerung -> Internetoptionen gepflegt werden greifen nicht.
Welche Proxysettings Windows Update nutzt, läßt sich mittels netsh winhttp show proxy in einer Konsole abfragen.
Um diesen Wert zu ändern bedarf es einer Konsole mit Adminrechten.
Hier gibt es zwei Möglichkeiten. Man importiert die Einstellungen, welche bereits in der Systemsteuerung ->Internetoptionen hinterlegt sind,
netsh winhttp import proxy source=ie
oder man stellt es über folgendes Kommando selbst ein
netsh winhttp set proxy mein.proxyserver.local:8080
Hierbei ist selbstverstädlich ‚mein.proxyserver.local‘ sowie der Port ‚8080‘ gemäß der eigenen Umgebung anzugeben.
Wenn man Windows Update jetzt über das Einstellungen Menü aufruft, klappt der Abruf der Updates über den Proxyserver.