Archiv des Autors: weed

Citrix oder Terminal Server „Fehler bei der Anmeldung mit dem Benutzerprofildienst. Das Benutzerprofil kann nicht geladen werden“

Veröffentlicht am von — Keine Kommentare ↓

Wenn man sich bei einem Computer mit Windows Vista oder Windows anmelden will, wird die folgende Fehlermeldung angezeigt:

"Fehler bei der Anmeldung mit dem Benutzerprofildienst. Das Benutzerprofil kann nicht geladen werden."

Dieser Fehler kann auftreten, wenn die Gruppenrichtlinieneinstellung „Benutzer mit temporären Profilen nicht anmelden“ konfiguriert ist – das ist in der Regel bei lokalen Terminalservern und so gut wie allen Citrix-Xenapp Server (vor allem Fundamentals) der Fall.

Lösung: Benutzerprofil neu machen und Kennwort des Benutzers zurücksetzen.

  • In der Registry das alte Profil entfernen: 
    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList
  • Hier den ganzen Schlüssel, den den Pfad zu dem betreffenden Profil enthält entfernen (das ist der Eintrag „ProfileImagePath“)

  • Das alte Profil (Users%username%) umbenennen und daraus später Daten retten.

Nach einem Upgrade von vSphere 4.1 auf 5 kann der datastore nicht erweitert werden

Veröffentlicht am von — Keine Kommentare ↓

 

Führt man ein entsprechendes Update durch, und erweitert anschließend das Array des datastores um weitere HDDs, kann die Größe des datastores im vSphere Client nicht erhöht werden, obwohl die neue Größe korrekt angezeigt wird.

Hier hilft die gute alte SSH Konsole 🙂

SSH einschalten:

  • „F2“ an der lokalen Konsole: „Troubleshooting Options“

oder

  • vSphere Client: Host auswählen, „Konfiguration“, „Software“ – „Sicherheitsprofil“, „Dienste“ – „Eigenschaften“, „SSH“ => „Optionen

Nun verbindet man sich mit dem favorisierten SSH Client (z.B. PuTTY).

Nach dem root login helfen die folgenden Befehle (Pfade, etc. bitte anpassen):

  • vmkfstools -P "/vmfs/volumes/datastore"

    => Partiton span ermitteln (für partedUtil)

  • partedUtil get "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0"
  • Partition ermitteln (251=VMFS), ersten Sektor der Partition notieren
  • partedUtil getUsableSectors "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0"

    => Letzten Sektor notieren

  • partedUtil resize "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0" <partition> <startsektor> <endsektor>
    • z.B: partedUtil resize "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0" 2 10229760 213196319
  • vmkfstools --growfs "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0:<partition>" "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0:<partition>"

    => GROWEN 😉

Exchange 2010 Verwaltungskonsole startet nicht: „Ausnahme beim Aufrufen von „GetSteppablePipeline“ …

Veröffentlicht am von — 1 Kommentar ↓

Gestern ging es noch, heute startet die EMC (Exchange-Verwaltungskonsole) von Exchange 2010 nicht mehr:

„Ausnahme beim Aufrufen von „GetSteppablePipeline“ mit 1 Argument(en): „Die Datei C:Program FilesmicrosoftExchange ServerV14Remote ScriptsConsoleInitialize.ps1″ kann nicht geladen werden, die die Ausführung von scripts auf diesem System deaktiviert ist.“

Der Fehler tritt gerne auf, wenn man Sharepoint-Komponennten von einem Server deinstalliert, häufig beim SBS2011. Die Ursache ist, das das Sharepoint-Setup bei der Deinstallation die Ausführungsrichtlinie (ExecutionPolicy) auf „restricted“ setzt und damit praktisch jede Scriptausführung verhindert.

Den Status der der Policy zeigt:

get-executionpolicy

und den korrekten Zustand stellt das setzen der Policy wieder her:

set-ExecutionPolicy RemoteSigned

schon klappt die Konsole meistens wieder.

Manchmal bekommt man auch eine andere Fehlermeldung die so lautet:

Set-ExecutionPolicy : Access to the registry key ‚HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell‘ is denied.

At line:1 char:20

+ Set-ExecutionPolicy <<<< RemoteSigned

In diesem Fall half mir:

  • Reg://HKLMSOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell
  • Die Zeichenfolge „ExecutionPolicy“ mit dem Wert „RemoteSigned“ erstellen

und dann zur Sicherheit mit get-executionpolicy den Zustand noch einmal prüfen.

mod_fcgid: read data timeout in 120 seconds, referer: /nav-menus.php

Veröffentlicht am von — Keine Kommentare ↓

In WordPress lassen sich Menüs nicht mehr bearbeiten? Du hast eine große Seite am Start mit vielen Pages und kann keine neuen Seiten mehr ins Menü aufnehmen? Das mag an deiner FastCGI-Limitierung liegen. WordPress (3.0 bis 3.x) nutz zur Menüverwaltung ein Ressourcenfressendes System das bei jedem Speichern ein gigantisches POST lostritt. Google hilft die passenden Diskussionen im WP-Bugtracker und den Foren zu finden. Wir wären aber schliesslich keine Admins, wenn wir keinen schnellen schmutzigen Fix zur Hand hätten:

fcgid.conf (Debian: /etc/apache2/mods-available/fcgid.conf)

IPCCommTimeout 240

Das Limit ist in Sekunden angegeben. Ob das generelle Erhöhen dieses Limits auf deinem Server allerdings eine gute Idee ist, liegt in deiner Verantwortung.