Windows läd nur TEMP-Benutzerprofil

Aus unterschiedlichen Gründen mag Windows manchmal seine Servergespeicherten Benutzerprofile nicht mehr laden. Wirre Eventlog-Fehlermeldungen sind die Folge, von Rechten und Verzeichnissen ist die Rede. Wenn das übliche debuggen entlang dieser Meldungen nicht mehr fruchtet, hilft oft das Profil einfach zurückzusetzen:

  • PC neu starten (Wichtig um alle Zweige zu entladen!)
  • Als lokaler Administrator anmelden und das betroffene Profil komplett löschen (oder von der Maschine schieben)
  • Registry öffnen:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
    
  • Löschen des Unterschlüssels mit dem Namen <SID>.bak

Die <SID> ist die Sicherheits-ID (SID) des Benutzerkontos, bei dem das Problem auftritt. Der Unterschlüssel SID.bak sollte einen Registrierungseintrag ProfileImagePath enthalten, der auf den ursprünglichen Profilordner verweist, bei dem das Problem auftritt.

Wenn das Profil noch intakt und alle Rechte korrekt sind (schlimmstenfalls nochmal drüber erben und den Besitzer nicht vergessen), den key state auf „0“ setzen, das .bak entfernen (nachdem man die ID mit dem temp-profil gelöscht hat) und rebooten. NICHT ab- und anmelden, sondern rebooten (denn dann wird die profilelist erst neu geladen).

„Die Anzahl der vSphere HA-Taktsignal-Datenspeicher für diesen Host beträgt 1. Dies ist weniger als die erforderliche Menge: 2“

Vmware vSphere 5 führt den Heartbeat über den Datastore ein; genau wie im Management-Network muss auch dieser folgerichtig nun redundant ausgelegt oder angebunden sein. In kleinen Umgebungen gibt es häufiger aber nur ein SAN oder nur ein einzelnes Plattenshelf und die Warnung ist ein wenig nervig. Natürlich gibt es auch keinen (klickbaren) Schalter dafür, sondern in bester vmware-manier einen erweiterten Konfigurations-Eintrag.

Die Warnung wird entfernt durch:

  • Eigenschaften des Clusters
  • Vmware HA -> Erweiterte Optionen
  • Hinzufügen eines neuen Eintrages:

    das.ignoreinsufficienthbdatastore mit dem Wert true

 

Die vSphere Dokumentation hält diesen Eintrag natürlich auch bereit. Alle erweiterten Optionen sind Hier zu finden und alle Optionen für alle Knoten (FPM und VPXD) hier.

vSphere ESXi 5 Warnung „Die Systemprotokollierung ist auf dem Host nicht konfiguriert“

Vor allem bei von vSphere 4 oder 4.1 migrierten Hosts vergisst der ESXi5 Installer gerne mal den Syslog-Host auf den ESXi-Hosts zu konfigurieren. Dann erscheint auf jedem Hoats nach dem starten im vSphere Clients diese Warnung „Die Systemprotokollierung ist auf dem Host <hostname> nicht konfiguriert“:

 

Lösung: Den Syslog-Host (den vCenter Server) einfach nachtragen:

  • Host -> Tab: Konfiguration -> Erweiterte Einstellungen
  • In der Baumstruktur „Syslog“ aufwählen
  • In dem Feld „Syslog.global.loghost“ die Adresse des vCenter-Servers nachtragen:

    udp://<fqdn-hostname-vcenter>:514

    z.B.: udp://vcenter5.cooldomain.local:514

In der Konsole auf dem Hosts (local oder SSH) geht das natürlich auch:

esxcli system syslog config set –loghost=
udp://<fqdn-hostname-vcenter>:514

Der passende KB-Artikel dazu liegt hier.

Nach der Kennwortänderung kann ich mich nicht mehr anmelden …

So eine kleine Kennwortänderung kann zu massiven Reibereien in einem eingefahrenen Unternehmens-Abeitsablauf führen – viele Administratoren kennen die oft recht emotionalen Beschwerden der Benutzer vermutlich. Das Informationssicherheit aber ohne Kennwörter und ohne eine regelmäßige Änderung dieser Zugänge nicht zu gewährleisten ist, sollte ebenfalls klar sein (und ist sogar meistens auch die Benutzer vermittelbar). Praxis-Tipp: VORHER informieren spart hinterher gefühlte 99% der Beschwerden 🙂

Ich persöhnlich bin großer Fan der „Komplexitätsrichtlinie“ in Windows Server 2008 (und R2 natürlich). Diese schriebt vor:

Kennwort muss Komplexitätsvoraussetzungen entsprechen

Wenn diese Richtlinie aktiviert ist, müssen Kennwörter die folgenden Mindestvoraussetzungen erfüllen:

Das Kennwort darf nicht den Kontonamen des Benutzers oder mehr als zwei Zeichen enthalten, die nacheinander im vollständigen Namen des Benutzers vorkommen.
Das Kennwort muss mindestenssechs Zeichen lang sein.
Das Kennwort muss Zeichen aus drei der folgenden Kategorien enthalten:
Großbuchstaben (A bis Z)
Kleinbuchstaben (a bis z)
Zahlen zur Basis 10 (0 bis 9)
Nicht alphabetische Zeichen (zum Beispiel !, $, #, %)
Die Komplexitätsvoraussetzungen werden erzwungen, wenn Kennwörter geändert oder erstellt werden.

Diese Komplexität macht Sinn und ist logisch. Hilfreich ist für Benutzer auch oft der Tipp, das das Wort „Kennwort“ schon eigendlich unangebracht ist. Meiner Meinung nach sollte das durchaus „Kennsatz“ heissen. Einem Computer ist für einen Einbruchsversuch die vermeintliche Komplexität eines D54FG93-Kennwort nämlich völlig egal; für diesen zählt als Sicherheitsfaktor nahezu ausschlesslich die Entropie (sprich: Länge). Kennwörter wie „2Hände2Füße“ oder „8Zeichensinddoof!!“ sind tolle Möglichkeiten lange Kennwörter einfach zu merken und bei der Änderung vielleicht sogar etwas Spass zu haben. Ganz nebenbei tippen sich üblich Sätze „2Kopiedavonbitte…“ wesentlich natürlicher und schneller als „t]_Kwia0$“.

Die „üblichen“ Verdächtigen nach einer Kennwortänderung und folgenden Anmeldefehlern:

  • CAPS-Lock: Ihr Kennwort wurde vielleicht Groß/Klein invertiert?
  • NUM-Lock: Auf Notebooks ein besonderer Spass. je nachdem wo der Hersteller seinen Pseude-Nummernblock auf die QWERTZ-Tasten (doppelt-) belegt hat, ist die Kennwortsuche ein spannendes vergnügen. Ein guter Indikator für eine solche Konstellation: „Auf meinem PC kann ich mich anmelden, auf den Notebook nicht“. Oder „Auf meinem Notebook klappt alles, aber das Android|iPhone|WinMobile nicht…“.

 

Unsichtbare Snapshots

Es gibt immer mal wieder Snapshots von virtuellen Maschinen, die nicht (mehr) im Snapshot-Manager angezeigt werden. Seit ESX 3.5 bekommt man solche zum Beispiel, indem man einen Snapshot löscht und in der selben Sekunde den betreffenden Host in den Wartungsmodus wirft, oder im falschen Moment den vCenter Server neu startet.

Kein Panik, solande am Datastore und an der VM selber nichts geändert wurde hilft dieser dreizeile, auszuführen bei ausgeschalteter (!) VM:


mv FOOBAR.vmsd FOOBAR.vmsd.old
vmware-cmd FOOBAR.vmx createsnapshot recovery "recovery" 0 0
vmware-cmd FOOBAR.vmx removesnapshots

Das dauert jetzt je nach Größe und jetzt Anzahl der Snapshots und vmdk’s ein paar Ewigkeiten, führt aber in den meisten Fällen zum Erfolg. Achtung: Snapshots werden generell erst zusammengeführt (Paet-by-Part), dann übernommen. Es sollte also genügend Platz frei sein.

Man kann dem treiben auch recht komfortabel live zuschauen, indem man an einer zusätzlichen Konsole die Zeitstempeländerungen beobachtet:

watch "ls –oghut –-full-time *.vmdk"

*thanks to David Barrett