21. Mai 2019

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.

9. April 2019

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.

10. Januar 2019

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:

$au = New-Object -ComObject "Microsoft.Update.AutoUpdate"
$au.DetectNow()

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

Windows Update logs are now generated using ETW (Event Tracing for Windows).
Please run the Get-WindowsUpdateLog PowerShell command to convert ETW traces into a readable WindowsUpdate.log.
For more information, please visit https://go.microsoft.com/fwlink/?LinkId=518345

Also hilft auch hier die Powershell weiter. Bei Eingabe von

Get-WindowsUpdateLog

wird die Datei WindowsUpdate.log auf dem Desktop des angemeldeten Benutzers erzeugt. Diese kann man wie gewohnt nach Hinweisen zum Updateprozess durchforsten.

4. Oktober 2017

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… 😉

15. Mai 2017

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

 

 

24. März 2017

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.

25. Januar 2017

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.

2. Januar 2017

Laut Datenblatt unterstützt das ProCurve Modell (2848) bis zu 256 VLANs gleichzeitig, bei der Konfiguration ist allerdings nach 8 VLANs Schluss. Standardmäßig ist das Limit 8 voreingestellt. Dieses läßt sich aber bis zum Maximalwert beliebig einstellen. Entweder im Config mode mittels

max-vlans 256

write memory 

reload

Switch startet bei ‚reload‘ neu.

Oder über das Menü

menu ->2. Switch Configuration... ->8. VLAN Menu... ->1. VLAN Support -> Maximum VLANs to support

27. Oktober 2016

Unser internes Intranet nutzt zur Nutzerauthentifizierung den Windowslogon. Um diesen bei Firefox durchzureichen muss man der URL Zeile

about:config

aufrufen und im Suchfeld (nach Bestätigung des Sicherheitshinweises) nach

trusted-uris

suchen.
Bei den ermittelten Suchergebnissen trägt man dann jeweils die freizuschaltende URL ein (per Doppelklick den Dialog öffnen). Mehrere Seiten werden per Komma getrennt aneinander gereiht.

 

27. Oktober 2016

Auf einem Ubuntu 14.04 Server startet MySQL nicht automatisch obwohl per

sudo update-rc.d mysql defaults

der Autostart aktiviert wurde. Grund ist die Datei

/etc/init/mysql.override

Diese Datei löschen, dann klappt der Autostart.