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.

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

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

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.

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.

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

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.

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.

Man benötigt den Installationsdatenträger von Windows Server 2012 R2. Von diesem läßt sich das .NET Framework 3.5 nachinstallieren wenn die Installation per Gui (Hinzufügen von Rollen und Features) fehlschlägt.

dism /online /enable-feature /featurename:NetFX3 /all /Source:d:\sources\sxs /LimitAccess

Das Zeitfenster für das kostenlose Upgrade von Windows 7/8 auf Windows 10 endet bekannterweise am 29.7.2016.

Da ich im Unternehmen nicht mal schnell hop hop die Rechner auf Windows 10 upgraden möchte/kann, mir aber die Option für ein späteres (kostenloses) Upgrade wahren möchte, kam mir die Idee die Windows 10 Aktivierung der Rechner schon im Vorfeld durchzuführen. Hintergrund ist die Vorgehensweise zur Aktivierung von Windows 10 aus einem installierten aktiviertem Windows 7/8 ohne dabei das Setup zu bemühen.

Wie auf zahlreichen Seiten beschrieben (Bsp. heise.de) läßt sich mit dem Programm gatherosstate.exe aus dem Installationsdatenträger von Windows 10 eine sog GenuineTicket.xml erzeugen. Mit dieser Datei läßt sich eine frische Windows 10 Installation auf diesem Rechner aktivieren (Nach der Installation einfügen in C:\ProgramData\Microsoft\Windows\ClipSVC\GenuineTicket, Neustart, Onlinezwang!).

Die Idee ist nun also, einfach gatherosstate.exe auf jedem Rechner im Netz auszuführen der für ein evtl. Windows 10 Upgrade in Frage kommt. Um das ganze zu automatisieren, habe ich ein kurzes AutoIt Script geschrieben welches ich in kompilierter Fassung (als Win10UpdPrep.exe Datei) zusammen mit gatherosstate.exe per OCS Client Management auf alle betreffenden Rechner im Netz verteile. Das Script ruft gatherosstate.exe auf, wartet bis es fertig ist, prüft ob die XML Datei vorhanden ist, benennt diese um (Computernamen voranstellen) und mailt diese Datei dann an ein IT Postfach. Somit sammle ich die XML Files von allen Rechnern ein. Eine lokale Kopie lasse ich auch noch auf dem jeweiligen Rechner liegen.

Das AutoIt Script stelle ich HIER zur Verfügung.

Bleibt jetzt noch die Frage, ob die Aktivierung auf diesem Wege auch noch nach dem 29.7.2016 funktioniert.

Ich werds berichten.

[UPDATE 04.08.2016]

Wie beinah zu erwarten war, funktioniert die Aktivierung in dieser Form jetzt nicht mehr.