Von MBR zu GPT ohne Datenverlust

Beim erstellen einer VM plant man eigentlich immer den zu verwendbaren Speicherplatz so optimal das man nicht unbedingt alle 2 Wochen erneut an die VM hand anlegen muss um den Speicherbedarf
anzupassen. So zumindest die Theorie. In der Praxis kommt dann ein Exchange Server und eine immer kleiner werdende physikalische Festplatte die einem das Leben etwas erschweren. Das Problem der immer kleiner werdenden physikalischen Festplatte wurde durch ein neues Storage behoben. Allerdings musste nun auch der VM entsprechend mehr Speicherplatz zugewiesen werden. In VMware einer virtuellen Festplatte meher Speicher zu geben ist eine Leichtigkeit. Das ist in diesem Fall eher die Windows Seite. Alles was über 2 TB Datengröße kommt braucht nämlich eine GPT Partitionstabelle. Microsoft bietet zwar mit Diskpart eine Lösung an um aus Festplatten mit MBR welche mit GPT Partitionstabellen zu machen aber das geht nur wenn keine Partition vorhanden sind bzw. er löscht die bestehenden.

Achtung meine Vorgehensweise nicht direkt mit Festplatten umsetzbar auf denen euer Betriebssystem läuft.

Nach etwas suche bin ich auf ein Linux Tool gestossen das es auch für Windows gibt. gptgen
Als erstes müsst ihr die mit diskpart herausfinden ob es sich um disk0, disk1 oder ähnlich handelt. Wichtig ist eigentlich nur die Zahl. Mit list disk bekommt ihr hier eine schöne übersicht.

gptgen.exe \\.\\physicaldrive1
Write primary.img to LBA address 0.
Write secondary.img to LBA address 4395431903.

GPTGEN macht seine Anpassungen nicht direkt auf die Festplatte. Er erstellt von seinen änderugen entsprechende Datei. Einmal vom Primären MBR und eine Datei vom Backup MBR. Wichtig ist dies für deswegen da GTPGEN ausgibt an welche Stelle sich der Backup MBR befindet auf der Festplatte. Damit können wir im Fall das GPTGEN misst baut den Original MBR wiederherstellen.

Dazu müssen wir aber erst mal ein Backup von dem bestehenden MBR machen. Idealerweise mit dd

dd if=\\.\\physicaldrive1 of=primary-backup.img bs=512 count=34
dd if=\\.\\physicaldrive1 of=secondary-backup.img bs=512 count=33 skip=4395431903

Nun können wir GPTGEN auch wirklich schreiben lassen. Dazu führt ihr folgenden Befehl aus.

gptgen.exe -w \\.\\physicaldrive1

In der Datengrägerverwaltung sollte die Festplatte nach einem Aktualisieren ( F5 ) nun entsprechend als dynamischer Datenträger mit GPT Partitionstabelle zu finden sein.

Sollte tatsächlich etwas schief gegenangen sein könnt ihr mit folgenden Befehl den MBR wiederherstellen.

dd if=primary-backup.img of=\\.\\physicaldrive1 bs=512 count=34
dd if=secondary-backup.img of=\\.\\physicaldrive1 bs=512 count=33 seek=4395431903

VMware ESXi 5.x-6.x Hostname/FQDN ändern via CLI

Manchmal steht man vor Aufgaben die eigentlich sehr einfach sind wenn man einen Webbrowser hat. Wenn man aber so wie ich in diesem Fall keinen wirklich anwendbaren Browser sondern nur ein iPad hat genügt auch ein Terminal.

Mit diesen zwei Befehlen lässt sich via ESXCLI der Hostname sowie den Full Qualified Domain Name anpassen.


esxcli system hostname set --host=hostname

esxcli System hostname set --fqdn=fqdn

Wichtig ist das der Host nicht mit einem vCenter verbunden ist. Würde man den Hostnamen ändern und der Host wäre noch mit eine vCenter verbunden würde dieser eben den Host nicht mehr finden. Vorausgesetzt man hat Best Practice den Host auch nicht via IP sondern via hostname.fqdn verbunden 😉

Das entfernen des Hosts aus dem Cluster sollte über den vSphere Client passen. Egal ob nun Web oder C# Client. Der Host muss dazu im den Wartungszustand versetzt werden(Rechtsklick aus dem Host und Wartungsmodus) und alle VMs verschoben oder Ausgeschaltet sein. Danach könnt ihr den Host mit einem Rechtsklick und entfernen aus dem Cluster lösen.

Den Wartungsmodus könnte ihr auch über die ESXCLI aktivieren und beenden.

Zum aktivieren

esxcli system maintenanceMode set --enable true

Zum deaktivieren

esxcli system maintenanceMode set --enable false

Wichtig ist das alle VMs vorher beedet sind sonst schlägt das versetzen in den Wartungsmodus über CLi fehl.

VMware Horizon View 6.2.4 Uprade und TLSv1.0

Eigentlich gibt es eine goldene Regel in der IT. Freitag ist Read Only Friday und weil man kein Bock hat auf Panik am Wochenende hält man die Finger still. Leider musste ich unsere angestaubte VMware Horizon View Farm aber mal eben schnell aktualisieren weil das verwenden von Windows 10 Enterprise als Gastsystem nicht möglich war. Ich wollte nicht direkt mit der Brechstange auf Version 7 gehen und da es sich nur um ein Bugfix Release handelte und der eh schon überfällig war dachte ich mir dabei auch sehr wenig.

Mein Gastbetriebssystem lief nach einer kurzen Updatephase einwandfrei. Leider haben wir bei manchen Hubs eine ältere Version vom VMware View Client im Einsatz und hier kam es auch zur ersten Meldung das eine Verbindung nicht möglich war. Kein Problem, dachte ich! In der Softwareverteilung war schon ein neues MSI Paket von mir für unseren Standort bereitgestellt. Einfach GPO’s anpassen und spätestens Montag oder nach einem Neustart ist alle wieder gut.

Dann kam aber leider der Anruf den ich Freitag Mittag 14:30 nicht mal meinen Feinden wünsche :-). In einem Aussenlager war ein HP Thinclient im Einsatz und der verweigerte wegen einem SSL/TLS Fehler den Zugriff auf dem View Securityserver.

Jetzt kommt ein gut gemeinter Ratschlag von mir an euch! Lest vor einem Upgrade immer die Release Notes. Wenn ich das gemacht hätte wäre mir schon vorher die Problematik bewusst geworden. Ein Remoteupdate war aus mehreren Gründen so nicht möglich. Ich musste also den View Server dazu bewegen, wenn auch mit eine bösen herhobemen Security Zeigefinger, das er das TLSv1 Protokoll sowie diverse Cipher wieder annimmt.

Erster Schritt war das anlegen der Datei locked.properties im Ordner c:\Program Files\VMware\VMware View\Server\sslgateway\conf

Die Datei bekommt folgenden Inhalt:


# Liste der möglichen Protokolle

secureProtocols.1=TLSv1.2
secureProtocols.2=TLSv1.1
secureProtocols.3=TLSv1
secureProtocols.4=SSLv3
secureProtocols.5=SSLv2Hello

# Wähle das bevorzugte Protkoll aus. Das sollte auch in der Liste ganz oben stehen.

preferredSecureProtocol=TLSv1.2

# aktiviere folgende Chiper

enabledCipherSuite.1=TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
enabledCipherSuite.2=TLS_DHE_DSS_WITH_AES_128_CBC_SHA
enabledCipherSuite.3=TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
enabledCipherSuite.4=TLS_DHE_DSS_WITH_AES_256_CBC_SHA
enabledCipherSuite.5=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
enabledCipherSuite.6=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.7=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
enabledCipherSuite.8=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
enabledCipherSuite.9=TLS_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.10=TLS_RSA_WITH_AES_256_CBC_SHA
enabledCipherSuite.11=SSL_RSA_WITH_RC4_128_MD5
enabledCipherSuite.12=SSL_RSA_WITH_RC4_128_SHA
enabledCipherSuite.13=TLS_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.14=TLS_DHE_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.15=TLS_DHE_DSS_WITH_AES_128_CBC_SHA
enabledCipherSuite.16=SSL_RSA_WITH_3DES_EDE_CBC_SHA
enabledCipherSuite.17=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
enabledCipherSuite.18=SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Anschliessend nehmen wir noch einen Registry Eintrag vor:

HKLM\Software\Teradici\SecurityGateway
Name: SSLProtocol
Type: REG_SZ
Value: tls1.2:tls1.1:tls1.0

Wenn das erledigt ist starten wir den Dienst des Verbindungssicherungsserver neu. Die ThinClients sollten sich jetzt wieder verbinden können. Dies sollte aber nur eine temporäre Lösung sein bis ihr einen passenden Austausch ThinClient mit entsprechenden Update vor Ort installiert habt.

Quelle:

https://thatonecomputerguy.wordpress.com/2016/04/22/ssl-settings-to-allow-connection-from-old-view-clients-on-view-horizon-6-2/

https://pubs.vmware.com/Release_Notes/en/horizon-6-view/624/horizon-view-release-notes.html

Cisco 1841 – Back 2 Back Configuration SHDSL

Als freund gut abgehangener DSL Technik habe ich es mir für mein Lab nicht nehmen lassen 2 SHDSL Karten zuzulegen um damit zwei Router zu verbinden.

Nach etwas suchen im Internet habe ich auch entsprechend eine nette Seite gefunden die das ganze auch schon einmal versucht hat. Ich habe die Config mal aufs wesentlich gekürzt. Einmal die Vermittlungsstelle und einmal das Kundengerät:

Router1#sh run

controller DSL 0/0/0
mode atm
line-term co <= Central Office
line-mode 4-wire enhanced
dsl-mode shdsl symmetric annex B
ignore-error-duration  15
!
interface ATM0/0/0
no ip address
load-interval 30
no atm ilmi-keepalive
!
interface ATM0/0/0.1 point-to-point
ip address 10.0.0.1 255.255.255.0
no snmp trap link-status
pvc 2/100
no oam-pvc manage
encapsulation aal5mux ip
!
Router2#sh run

controller DSL 0/0/0
mode atm
line-term cpe <= Customer Premises Equipment
line-mode 4-wire enhanced
dsl-mode shdsl symmetric annex B
ignore-error-duration  15
!

interface ATM0/0/0
no ip address
load-interval 30
no atm ilmi-keepalive
!
interface ATM0/0/0.1 point-to-point
ip address 10.0.0.2 255.255.255.0
no snmp trap link-status
pvc 2/100
no oam-pvc manage
encapsulation aal5mux ip
!

Quelle: http://www.computecnetworks.com/?q=node/52

Cisco – Wissen und Zertifikate

Ich bin mittlerweile etwas mehr als 2 Jahre bei meinem Arbeitgeber und leite dort entsprechend die IT Abteilung. Doch ein Job als Rechnungsabzeichner und Meeting-schubser war noch nie so mein Ding! Oft sind ITler in der gleichen Position nur noch welche die sich um die Entwicklung der Abteilung kümmern aber selbst nur noch wenig dazu beitragen im „Alltagsgeschäft“. Bei mir ist das nicht so. Deswegen lege ich auch noch gerne selbst Hand mit an wenn es darum geht neue ESX Hosts zu installieren und die VMs zu migrieren. Genauso auch wenn es darum geht eines unserer Juniper Switches zu konfigurieren.

Das schlimme in dem Job den ich inne hab ist allerdings das du oft Baustellen einmal hast, das Problem beseitigst und bis es dann wieder auftritt mehrere Monate vergehen. Das Wissen kann sich also nie richtig festigen. Für mich war klar das ich diesen Misstand leider nicht so weiter hinnehmen kann auch mit Blick auf meine weitere berufliche Karriere. Eigentlich wollte ich mich als erstes an VMware VCP6 versuchen aber da es hier aktuell noch kein richtiges Prüfungsmaterial gibt dachte ich an Juniper. Schlussendlich haben mich aber die mangelnde Hardware im privaten Umfeld in die Arme von Cisco getrieben. Ich war zwar schon vor einigen Jahren damit beschäftigt für die Prüfungen zu lernen aber diesmal ist der Ansporn definitiv ein anderer.

Zuhause stehen nun ein LAB von 3 x Cisco 1841, 1 x Cisco 1802, 1 x Cisco 2960-8P mit dem ich zumindest alle prüfungsrelevanten Spielchen machen kann. Wäre da nicht Cisco mit ihrer genialen Idee genau in dem Zeitraum den ich mir rausgesucht habe um die Prüfung abzulegen eben diese komplett zu ändern. Nicht das die Frage nach ICND 1 + 2(100-101,200-101) oder CCNA(200-120) schon eine schwere Frage wäre! Nein jetzt muss man sich auch noch entscheiden ob man neue oder alte Prüfungen ablegt…

Die ersten Testprüfungen die ich abgelegt habe zeigten eindeutig noch Defizite im Bereich ACLs und OSPF und so lange die nicht aus der Welt sind werde ich mich persönlich noch zu keiner Entscheidung hinreissen.