Konfiguration von VPN Verbindungen unter Windows 10
Richtet man unter Windows 10 eine neue native VPN Verbindung ein – also mit Windows-Bordmitteln sozusagen – dann stellt man schnell fest, dass man nicht mehr an die TCP/IP Einstellungen der Verbindung herankommt.
Dieser “Bug” wird u.a. auf Youtube hier gezeigt: https://www.youtube.com/watch?v=I3fjNpkB-EE
Das ist insofern ärgerlich, weil neue VPN Verbindung immer das Standard-Gateway aktiviert haben. D.h. wählt sich der Benutzer ein, so gehen sofort alle Verbindungen nur noch über diese VPN Verbindung – in der Praxis wird das selten gewünscht.
Möchte man nun eine solche “Split-Tunnel” Konfiguration aber haben, so sind mir zur Zeit nur zwei Möglichkeiten bekannt.
a) Das Editieren der “rasphone.pbk”
oder besser
b) mit Powershell:
Set-VpnConnection -Name "NameVPNVerbindung" -SplitTunneling $True
Dies entfernt die Nutzung des Standard-Gateway der VPN-Verbindung.
Die VMRC-Konsole hat die Verbindung getrennt…
Neulich hatte ich bei einem VMWare ESXi 5.0 Server das Problem, dass ich auf keine VM-Konsole mehr zugreifen konnte. Bei jeder VM bekam ich den Fehler “Die VMRC-Konsole hat die Verbindung getrennt….”
Ich wusste aber, dass es mit dieser vSphere Client Installation schon funktioniert hat – und die Installation war auch schon älter.
Die gängigen Hilfmassnahmen die man im Netz findet (Neustart VMWare Dienste, Neuinstallation des Clients) haben nicht geholfen.
Durch Zufall bin ich auf die Lösung gestossen – es lag an der VERSION des vSphere Client. Der ESXi Server selber lotste mich immer zum Download http://vsphereclient.vmware.com/vsphereclient/6/2/3/3/7/3/VMware-viclient-all-5.0.0-623373.exe – aber diese Version “VMware vSphere Client 5.0 Update 1” ist längst veraltet.
Glücklicherweise bietet VMWare eine Übersichtsseite für den Download der jeweils aktuellen Version der Client an:
Und dort fand ich auch die notwendige Version 5.0.0-1300600. Installiert – und schon gings wieder.
qvPDF unter Windows 8/8.1 – Fehlermeldung pdftk.exe funktioniert nicht mehr
Auf mehreren Windows 8.1 Systemen hatte ich neulich folgendes Problem:
Beim Erzeugen eines PDFs mit Hilfe von qvPDF bekamen die Anwender folgende Fehlermeldung:
Wenn man die Fehlermeldung wegegklickt, kam qvPDF ganz normal hoch und man konnte das PDF abspeichern. Die Fehlermeldung war jedoch nervig.
Im Ereignisprotokoll fand ich dann folgenden Eintrag:
Name der fehlerhaften Anwendung: pdftk.exe, Version: 0.0.0.0, Zeitstempel: 0x4cc9eed0 Name des fehlerhaften Moduls: libiconv2.dll, Version: 6.3.9600.17668, Zeitstempel: 0x54c846bb Ausnahmecode: 0xc0000135 Fehleroffset: 0x0009e052 ID des fehlerhaften Prozesses: 0x2f94 Startzeit der fehlerhaften Anwendung: 0x01d072b373403526 Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\qvPDF\pdftk.exe Pfad des fehlerhaften Moduls: libiconv2.dll Berichtskennung: b0f64aae-dea6-11e4-8375-0024d79e0a9c Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Das interessante daran ist, dass sich auf dem PC das angeblich fehlerhafte Modul libiconv2.dll gar nicht befand!
Diese Datei ist Bestandteil der Library libiconv (http://www.gnu.org/software/libiconv/).
Also habe ich die Library für Windows von http://gnuwin32.sourceforge.net/packages/libiconv.htm heruntergeladen und die Datei libiconv2.dll in das Verzeichnis C:\Program Files (x86)\qvPDF der betroffenen Computer kopiert.
Siehe da – die Fehlermeldung kommt nicht mehr.
Windows Server 2003 R2 – Schwarze Anmeldung
schwarzer Adler auf schwarzem Grund…
Gestern hatte ich bei einem Windows 2003 R2 Server ein interessantes Problem. Bei der Anmeldung am Server, sowohl lokal als auch per RDP, bekam man folgendes Bild:
Wenn man die Login-Daten blind eingetippt hat, kam man ganz normal auf den Desktop. Auch nach einem Neustart des Servers bestand dieses Problem weiterhin.
Eine kurze Google-Recherche brachte mich zu folgendem KB Eintrag
http://support.microsoft.com/kb/906510/de und damit zur Lösung des Problems:
In der Registry des Servers warenunter
[HKEY_USERS\.DEFAULT\Control Panel\Colors] alle Farben auf 0,0,0 gesetzt:
MS schreibt, man solle den Registry-Bereich von einem anderen Server exportieren und auf dem betroffenen Server wieder importieren. Das habe ich auch getan und konnte das Problem damit beheben.
Für alle die keinen Zugriff auf die schnelle auf einen anderen Server haben hier der entsprechende Code:
Windows Registry Editor Version 5.00 [HKEY_USERS\.DEFAULT\Control Panel\Colors] "ActiveBorder"="212 208 200" "ActiveTitle"="10 36 106" "AppWorkSpace"="128 128 128" "Background"="102 111 116" "ButtonAlternateFace"="181 181 181" "ButtonDkShadow"="64 64 64" "ButtonFace"="212 208 200" "ButtonHilight"="255 255 255" "ButtonLight"="212 208 200" "ButtonShadow"="128 128 128" "ButtonText"="0 0 0" "GradientActiveTitle"="166 202 240" "GradientInactiveTitle"="192 192 192" "GrayText"="128 128 128" "Hilight"="10 36 106" "HilightText"="255 255 255" "HotTrackingColor"="0 0 128" "InactiveBorder"="212 208 200" "InactiveTitle"="128 128 128" "InactiveTitleText"="212 208 200" "InfoText"="0 0 0" "InfoWindow"="255 255 225" "Menu"="212 208 200" "MenuText"="0 0 0" "Scrollbar"="212 208 200" "TitleText"="255 255 255" "Window"="255 255 255" "WindowFrame"="0 0 0" "WindowText"="0 0 0"
Als zip: Control_Panel_Colors_fix
Seriennummer einer HP MSA P2000 auslesen
Problem: Man möchte ein HP MSA 2000 SAN bei HP registrieren und benötigt hierzu die Seriennummer des Geräts.
Dummerweise ist das SAN aber schon eingebaut und/oder man kann den Aufkleber nicht lesen (weil man z.B. nicht vor Ort ist.) Auch blöd: die Seriennummer des Geräts wird nicht in der GUI angezeigt.
Lösung: Man kann die Seriennummer per CLI auslesen. Hierzu loggt man sich per Telnet (z.B. Putty) auf die IP eines der Controller mit dem “manage” Account ein und gibt das Kommando
show enclosure-status
ein. Man erhält eine lange Liste mit den verschiedensten Seriennnummern:
Oben links steht auf der ersten Seite die Seriennummer des Geräts. Sie fängt mit 2S6 an:
Quelle: HP P2000 G3 MSA System CLI Reference Guide
Neueste Kommentare