Auf System (bei mir Servern) der großen Herstellern (HP, Fujitsu, Dell, Lenovo, etc) kann man die Seriennnummer des Systems ganz einfach aus dem BIOS auslesen. 

Braucht man ja öfters mal um z.B. Treiber für das spezifische System zu finden oder Calls bei Hardware-Problemen aufzumachen. 

Das geht zum einem in der Kommandozeile (cmd.exe als Administrator öffnen) mit

wmic bios get serialnumber

oder in der Powershell mit

get-wmiobject win32_bios|format-list SerialNumber

Seriennummerauslesen

Auf einem Windows Server, auf dem die Benutzer ihre Home-Laufwerke ablegen, wird im Explorer für die ganzen Home-Ordner nicht der eigentliche Ordnername sonder nur „Dokumente“ angezeigt.

ExplorerDokumente

Das liegt daran, dass in der Desktop.ini dieser Ordner dieses Verhalten definiert ist. Wenn man diese Datei löscht zeigt der Explorer wieder den eigentlichen Ordnernamen an.

Um die Datei im Explorer anzuzeigen muss man in den Ansicht-Optinen des Explorers Geschützte Systemdateien ausblenden deaktivieren und Ausgeblendete Dateien, Ordner und Laufwerke anzeigen aktivieren.

Bei einigen Zertifikaten die im Nginx verwendet werden, ist es notwendig die gesamte Zertifikatskette in dem Zertifikat mit anzugeben.

Das geht super einfach mit cat auf der Konsole:

cat domain.tld.crt sub-ca.cer > domain-bundle.crt

Erst also das eigentliche Zertifikat für die Domäne (domain.tld) – dann die Zwischenzertifizierungsstelle (sub-ca). Die Stammzertifizierungsstelle (Root-CA) wird meistens nicht benötigt.

Manchmal muss man aber doch auch das Root-CA mit in Kette mit aufnehmen (z.B. bei Zertifikate einer eigenen CA) – dann wäre es:

cat domain.tld.crt sub-ca.cer root-ca.cer > domain-bundle.crt

Erst also das eigentliche Zertifikat für die Domäne (domain.tld) – dann die Zwischenzertifizierungsstelle (sub-ca) und am Schluss die Stammzertifizierungsstelle (root-ca).

Wenn man die Zertifikate von Windows-Systemen bekommt, sollte man alle vorher mit

openssl x509 -inform der -in certificate.cer -out certificate.pem

umwandeln und dann eben mit

cat domain.tld.pem sub-ca.pem root-ca.pem > domain-bundle.crt

weiterverarbeiten.

In der Nginx-Config jetzt enfach das bundle.crt in der Zeile

ssl_certificate /etc/nginx/ssl/domain-bundle.crt;

angeben und nginx dann neustarten.

Ich muss öfters mal Zerifikate im PFX-Format umwandeln in .key und .crt-Datein für z.B. den WebServer NGINX umwandeln. Das geht mit OpenSSL ganz einfach:

Das eigentliche Zertifikat:

openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.crt

Den Privat Key bekommt man mit:

openssl pkcs12 -in cert.pfx -nocerts -out cert-encrypted.key

openssl rsa -in cert-encrypted.key -out cert.key

Der zweite Befehl beim Privat Key konvertieren ist dafür da, dass z.B. beim beim starten des WebServers nicht nach der PEM pass phrase gefragt wird (beim NGINX kommt beim starten sonst der Fehler: Starting nginx: Enter PEM pass phrase:)

Bei Installationen des ESXi auf einem USB-Stick oder einer SD-Karte wird die Warnung „Systemprotokolle auf dem host abc.xyz werden in einem nicht beständigen Speicher gespeichert„. VMware logt nämlich nicht auf USB-Speicher und Sd-Karten – den die sind nach VMWare-denke „volatil“. Nur Festplatten (respektive Datastores) sind beständig.

vmwarelogfehler

Das Problem löst man wie folgt in zwei einfachen Schritten:

1. Einen Speicherort für die Scratch-Files für jeden betroffenen ESX(i)-Host auf einem Datastore erstellen. Das geht direkt im vSphere Client und im laufenden Betrieb – die Änderung wird nur erst bei einem Neustart des Hosts aktiv.

Auf dem jeweiligen ESX(i)-Host unter Konfiguration/Speicher den passenden Datastore Durchsuchen und einen Ordner erstellen. VMWare schlägt einen Namen wie .locker-ESXHOSTNAME vor, denn Ordner die mit einem „.“ beginnen werden im Browser nicht angezeigt. Jeder Host braucht einen eigenen Scratch-Ordner.

2. Diesen neuen Ort dann in die ESX(i) Konfiguration der Hosts eintragen:

Unter

Konfiguration
– Software
– Erweiterte Einstellungen
– ScratchConfig
– ScratchConfig.ConfiguredScratchLocation
auf den neuen Pfad setzen, z.B. /vmfs/volumes/DATASTORENAME/.locker-ESXHOSTNAME

Der Defaultwert ist /tmp/scratch, was in einer Standartinstallation auf der Ramdisk liegt. Danach muss wie gesagt noch neu gestartet werden – danach ist die Meldung verschwunden!

Quelle: ugg.li

Wann man – wie ich – auf einem Rechner VMware Workstation bzw. Player und den integrierten Hypervisor Hyper-V unter Windows verwenden will muss man ein wenig tricksen.
Denn wenn einr der beiden installiert / aktiviert ist, kann man den anderen Hypervisor nicht verwenden.
Um dieses Problem zu lösen muss man den Hyper-V beim booten aktivieren um Hyper-V zu verwenden – bzw. deaktivieren um VMware zu verwenden.

Das funktioniert am einfachsten wenn man eine Powershell als Administrator öffnet und mit

bcdedit /set hypervisorlaunchtype off

Hyper-V beim nächsten booten zu deaktivieren (um mit VMware zu arbeiten), bzw.

bcdedit /set hypervisorlaunchtype auto

um Hyper-V beim nächsten starten zu aktivieren um eben mit Hyper-V zu arbeiten.

Ich wollte eine Checkpoint Appliance auf der GAiA installiert war (in meinem Fall R77.20) auf die aktuelle Version upgraden.
Problem: Ein klick in der WebUI bzw. im Gaia Portal auf Status und Action unter Software Updates führte zu einem dauerkreiselenden Portal und die WebUI war nicht mehr benutzbar. Auf der Kommandozeile war auch kein Arbeiten mit dem DAClient möglich – weder über den expert-mode noch über die cli.sh – alles war super langsam.

Ein top brachte folgendes zu Tage:

CheckpointGAiAconfdFehler

Der confd lief konstant zwischen 90 und 100 % CPU-Usage.

Das hat die Ursache das eine Datenbank in der in GAiA mitgelogt wird zu groß ist. Man kann das mit

ls -lh /config/db/initial_db

überprüfen – es sollte unter 100 MB liegen – ab 100 MB habe ich bei diversen Maschinen das Problem erlebt.

Um das Problem zu beheben muss man folgendes im Expert-Modus machen:


tellpm process:confd

mkdir /config/db/BKP

mv /config/db/initial_db /config/db/BKP/

conv2db /config/db/initial /config/db/initial_db

sqlite3 /config/db/initial_db "update revisions set time='1980-01-01 02:00:00';"

tellpm process:confd t

Wenn man jetzt mit top den Status überprüft, dürfte der confd-Prozess nicht mehr die Maschine zu machen.

Ich habe dann im Anschluss dann noch gleich den CPUSE manuell auf den neuesten Stand gebracht:

Im Checkpoint-Support-Center kann man den aktuellen Agent herunterladen

Auf die Appliance hochladen und im Expert-Modus mit

tar -zxvf DeploymentAgent_BuildNummer.tgz

entpacken und mit

rpm -Uhv --force CPda-00-00.i386.rpm

installieren. Danach noch schnell den Dienst mit

$DADIR/bin/dastart

starten.

Jetzt hat bei mir das Upgrade im GAiA Portal (WebUI) ohne Probleme funktioniert 🙂

Eine Positive Sache: Der Bug ist bekannt und auch schon gepatcht (z.B. Mit dem Jumbo-Hotfix für R77.20) – allerdings ist das Problem das diese Patches die Datenbank nicht verkleinern und man so auch auf vermeintlich gepatchten Machinen in das Problem laufen kann….

Quelle: Checkpoint

Nach dem Update auf Windows 10 fiel mir auf, dass man das Hintergrundbild des Anmeldebildschirm (Logon Screen) nicht ändern kann.

Mir – und auch einige die ich kenne – gefällt das Hintergrundbild (Windows 10 Hero) nicht wirklich. Da ich es standardmäßig nicht in den Einstellungen ändern kann und auch keine komischen Tools aus dem Netz verwenden will – deativiere ich es einfach mit einem einfachen Registry-Key 🙂

Man öffnet einfach den Registry Editor

regedit.exe

und geht zum Schlüssel

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System

und erstellt dort ein 32-bit REQ_DWORD Eintrag

DisableLogonBackgroundImage mit dem Wert 1

Windows10-LogonScreenDisable

Danach muss man den Windows-10-Rechner neustarten.

Danach ist das Bild weg und es wird nur noch ein einfarbiger Hintergrund angezeigt – es schaut jetzt aus wie unter Windows 8 bzw. 8.1 🙂