Archiv des Autors: weed

UltraEdit v17.30.x.x zeigt keine FTP-Ordner mehr an

Veröffentlicht am von — Keine Kommentare ↓

Ärgerlich: ein Update von UltraEdit (v 17.30.0.1014 um genau zu sein) sorgte auf meinem heiligen persönlichen Admin-Arbeitsplatz gestern für Irritationen. Der FTP-Browser (eines meiner Lieblingsfeatures in UE) zeigte keine Ordner auf einigen FTP/sFTP Servern mehr an – Dateien ja, Ordner nicht. Die üblichen PASV-Spielereien und Server-Type-Settings blieben ohne Erfolg, also musste ich suchen. Glücklicherweise gibt es ja dieses coole Ausgabefenster für die FTP-Kommunikation.

Ultraedit listete nicht mehr den ganzen Inhalt eines remote-Folders, sondern nur LIST *.*. Folgerichtig fehlten also nahezu alle Ordner in der Übersicht. Schuld ist der neue „Display-Filter“, der im FTP-Dialog oben rechts unter dem Schließen-Kopf wohnt. Was dort drin steht wird direkt beim LIST an den Server übergeben. Inhalt entfernen und alles ist wieder beim alten.

Ich kann mir zwar auch einige sehr sinnvolle Einsatzzwecke für diesen Filter vorstellen, aber dieser willkürliche Einsatz auf meine gesammelten Zugänge (immerhin so um die 50 Stück) ist doch etwas gewöhnungsbedürftig.

Danke für den Tipp an: http://www.ultraedit.com/forums/viewtopic.php?f=11&t=11631

Windows läd nur TEMP-Benutzerprofil

Veröffentlicht am von — Keine Kommentare ↓

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“

Veröffentlicht am von — Keine Kommentare ↓

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“

Veröffentlicht am von — Keine Kommentare ↓

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.

Die Empfängerrichtlinie ‘Default Policy’ mit Postfach-Manager-Einstellungen kann nicht über die aktuelle Version der Exchange-Verwaltungskonsole verwaltet werden

Veröffentlicht am von — 1 Kommentar ↓

Bei einer Migration von Exchange 2003 nach 2007/2010 kann es mal zu einem seltsamen Effekt kommen. Nach Abschluss der Postfachmigration wird ja in der Regel die „Default Policy“-Empfängerrichtlinie via

Set-EmailAddressPolicy „Default Policy“ -IncludedRecipients AllRecipients

umgestellt. Dies muss auch sein, da sich sonst die E-Mailadressrichtlinie (ab 2007 heisst das nicht mehr Empfängerrichtlinien, sondern Adressrichtlinie) nicht mit der EMC bearbeiten lässt. In der Regel klappt das auch. Manchmal gibt es aber den kreativ anmutenden Fehler:

Set-EmailAddressPolicy : Die Empfängerrichtlinie ‚Default Policy‘ mit Postfach-Manager-Einstellungen kann nicht über die aktuelle Version der Exchange-Verwaltungskonsole verwaltet werden

Liesst sich ein bisschen wirsch. Nach viel suchen kommt heraus: Der Postfach-Manager ist eine superselten genutzte Funktion von Exchange 2003. Inhalte aus Postfächern können damit automatisch bearbeitet werden, z.B. kann der fiese Admin alles was älter als 30 Tage ist damit löschen (oder ausdrucken oder so). Exchange 2007/2010 kennt das nicht mehr; Microsoft hat die Funktion an sich allerdings deutlich erweitert und der geneigte Admin kennt diese nun als „Richtlinien zum Verwalten von Nachrichtendatensätzen„. In meinem speziellen Fall stammen die Einstellungen von einer Exchange-nahen Faxlösung aus der frühen Steinzeit.

Lösung: Einfach alle alten Postfach-Managereinstellungen (beabsichtigt oder nicht) entfernen. Und das geht so:

  • Exchange Systemmanager (ja, das ding von 2003) öffnen
  • Rechte MT auf die „Default Policy“ und unter
  • „Eigenschaftenfenster ändern“ den Haken bei den Postfachmanagereinstellungen entfernen

Danach geht auch die Übernahme mir set-EmailAddressPolicy auch sofort.