Man kann es kaum glauben, aber da Kommandozeilentools ja bekanntlich nicht lügen, muss es ja so gewesen sein. Dieser Server läuft offenbar schon seit 29 (!) Jahren ohne Reboot durch. Da kann sich die Unix-Welt nochmal was abschauen 🙂
Archiv des Autors: weed
Nach einem Upgrade von vSphere 4.1 auf 5 kann der datastore nicht erweitert werden
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“ …
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
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.
Exchange 2010 will Datenbank nicht verschieben „MapiExceptionNetworkError“
Exchange 2010 (SP1) möchte seine Datenbanken schon mal nicht freiwillig verschieben, wenn man die interne URL der OWA/OAB Dienste auf http umgestellt hat (um Zertifikatsfehler|kosten|Umstand zu vermeiden). Die Fehlermeldungen dazu sind auch recht kreativ, vor allem in EMC und EMS unterscheidlich.
Der Status von Datenbank "Mailbox Database 0110421406" konnte nicht abgerufen werden. + CategoryInfo : InvalidOperation: (Mailbox Database 0110421406:DatabaseIdParameter) [Move-DatabasePath], InvalidOperationException + FullyQualifiedErrorId : 79FDD20B,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveDatabasePath
In diesem Fall reicht es aus, den SSL-erzwingen Haken von der ECP-zugehörgien IIS-Site zu entfernen:
IIS-Manager -> Site -> SSL-Einstellungen -> SSL Erzwingen Haken entfernen -> Übernehmen.
Dann eine Rauchen gehen oder anders etwa 5 Minuten Zeit vertrödeln. EMC neu starten und schon geht wieder alles. Das das NATÜRLICH nicht die goldene Lösung ist dürfte dem Lokalen Administrator klar sein, aber wer will schon für seine internen Sitehostheader extra Zertifikate beantragen oder eine extra-PKI bauen?