ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
Um unter Windows die Auswahlmöglichkeiten aus dem „Senden an“ Menü der rechten Maustaste zu bearbeiten, sind nur wenige Handgriffe notwendig:
Mit Start > Ausführen > „shell:sendto“ kommt man da noch schneller hin (thx heiko)
Die HP Integrated Lights-Out Webseiten (iLO 3 und iLO 2) zeigen im Internet Explorer ab Version 10 nur noch „Die Seite kann nicht angezeigt werden.“
Die selbe URL im Firefox zeigt den Fehler „Fehler: Gesicherte Verbindung fehlgeschlagen“ mit der Erkläsrung „Ein Fehler ist während einer Verbindung mit 192.168.0.foo aufgetreten. Das Aussteller-Zertifikat ist ungültig. (Fehlercode: sec_error_ca_cert_invalid)“
Um möglichst schnell und unkompliziert auf die Remote-Console und Remote-Media zuzugreifen, gibt es ein Standalone-Tool für Windows, das eine direkte Verbindung unabhängig von den SSL-Fehlern zulässt.
Die vollständige Lösung ist natürlich, auf die jeweils aktuelle ILO-Firmware zu aktualisieren; ab der Version 1.8x ist das fehlerhafte (leere) ausstellende Zertifikat nicht mehr vorhanden. Admin-Kurztipp: Google Chrome lässt dem Admin noch die Wahl, die Seite „trotzdem“ anzuzeigen.
Achtung, ältere iLO 3 Versionen vor v1.20 müssen erst auf v1.20 aktualisiert werden, sonst startet die ILO-Engine überhaupt nicht mehr ohne Kaltstart. Die Update auf v1.20 gibt es hier:
Alle HP ILO Firmware Downloads finden sich auf hp.com/go/ilo (Danke monopoly-spieler)
Auf einem Server können keine neuen Volumenschattenkopie-Jobs angelegt werden („Das Volumen ist bereits vorhanden“), es können keine weiteren Schattenkopien für ein DPM-geschütztes Voume angelegt werden („Die Schattenkopie mit der ID xxxxxxxxxxxxx ist bereits vorhanden“) und/oder bestehende DPM-Jobs starten nach einem Volumenwechsel nicht mehr, weil die bestehenden Jobs auf das „alte“ Volumen zeigen („Es wurde bereits eine Schattenkopie mit der ID xxxxxxxxxxx gefunden“).
Zuerst sind die bestehnden verwaisten Schattenkopien zu entfernen, dann das Ziel-Volumen (Shadowcopy-Storage). Es gibt mehrere Möglichkeiten die Einträge der Schattenkopie-Liste eines Systems aufzuräumen.
1) Sofern die orginal-Volumenzuordnung noch existiert, ist es möglich aud der Liste der Schattenkopien die ID der betroffenen Kopie zu extrahieren:
vssadmin list shadows
Aus der ausgegebenen Liste nun einfach die Schattenkopie-ID kopieren und löschen:
vssadmin Delete Shadows /shadow={Schattenkopie-ID}
Zum Beispiel: vssadmin Delete Shadows /shadow={affeaffe-dead-beef-b444-dfafafafafdf}
2) Wenn Vssadmin dabei aber seltsame Fehler ausspuckt, hat die Zuordnung nicht (mehr) richtig funktioniert. Hier hilft es in der Regel, die betroffene Kopie direkt zu entfernen; dazu gibt es ein WMI-Interface für den VSS-WMI-Provider.
C:\>wmic wmic:root\cli>shadowcopy list
Zeigt die vorhandene Liste an. Einzelne einträge kann man löschen. pro Eintrag erfolgt eine einzelne Abfrage:
C:\>wmic
wmic:root\cli>shadowcopy delete
"\\SERERNAME\ROOT\CIMV2:Win32_ShadowCopy.ID="{Schattenkopie-ID}" löschen (J/N/?)?
ACHTUNG! Obwohl Das Tool nach J/N fragt, wird ein „Y“ zum bestätigen benötigt *seufz*.
Wenn ein ganzes Volumen verwaist ist, zum Beisspiel wenn ein Admin darauf geschützte oder vom DPM als Ziel verwendete Partitionen entfernt, ist uns keine andere Möglichkeit bekannt, als dem Volumen eine neue Seriennummer zu geben. Das geht indem man das betroffene physikalische Array einfach löscht und neu erstellt, oder die Seriennummer einer neu erstellten NTFS-Partition mit „Volume-ID“ aus der Sysinternals-Trickkiste verändert:
C:\>volumeid T: f0000-ba00
ACHTUNG: Danach die Maschine neu starten und NICHT VERSUCHEN eine Schattenkpie anzulegen. Nach dem Neustart sollte das Volumen aus der VSS-Zielliste verschwunden sein. Das ist zu prüfen mit:
C:\>vssadmin list shadowstorage
Eine SAN Lun (NetAPP, EMC, Nimble, Nutanix …) die (insgeheim oder nicht) Thin Provisioning auf dem Array (oder Volumen, Aggregat, Shelf, whateveritscalled) macht, läuft seit vSphere 5.x langsam voll. Es ist immer weniger Speicher auf dem Aggregat frei. Die Gastmaschienen bleiben gleich groß, aber jeder Storage-vMotion-Vorgang und jedes erstellen/löschen von Daten auf dem Datastore hinterlässt weniger freien phasikalischen Speicher auf dem Aggregat. Der Datastore wird im vSphere Client aber mit unverändert viel Speicher und unverändert viel freiem Speicher angezeigt. Nur die physikalisch Belegung wird größer und größer.
Wenn eine thin provisioned Lun mit Daten beschrieben wird, werden diese Daten „hart“ geschrieben. Werden diese Daten dann wieder gelöscht, werden die Daten aber nicht wirklich gelöscht („mit Nullen überschrieben“), sondern die betroffenen Blöcke werden nur als „frei“ markiert. Ähnlich arbeiten praktisch alle heutigen Dateisysteme, weil ein Löschvorgang andernfall ein Schreibvorgang vollständiger größe und wäre und somit (potentiell) lange dauern würde.
Wenn nun häufig Daten geschrieben und gelöscht werden, werden nach und nach mehr Blöcke mit „als gelöscht“ markierten Daten hinterlassen. Ein SAN kann von aussen nicht unterscheiden, welche Daten echt sind und welche als löschbar markiert – dazu wäre technisch tiefe Einsicht in das Dateisystem notwendig. Tatsächlich freie Bereiche („Nullen“) erkennen SANs aber in der Regel als solche. Dieser Vorgang wird oft als punchzero, zero free space, reclaim wasted space, unmap disk space oder ähnliches bezeichnet.
Windows 2003 und höher
Unter Windows kann das Tool sDelete von Sysinternals den freien Bereich eines Datenträgers mit Nullen füllen.
c:\>sdelete -p 1 -z c:
ESX(i) Instalationen bringen ein entsprechendes Tool ebenfalls mit. Je nach vSphere Release unterscheidet gibt es allerdings etwas andere Namespaces dafür.
vSphere 5.1
vmkfstools -y 95 -d /vmfs/volumes/DATASTORENAME
vSphere 5.5
storage vmfs unmap -l DATASTORENAME
Linux
dd if=/dev/zero of=/DISK/foo.bar bs=4096 && rm -f /DISK/foo.bar
Zum Beispiel lässt sich dieser Vorgang auch via ESXCLI auslösen, zum Beispiel monatlich:
c:\>esxcli -s SERVER -u root -p PASSWD storage vmfs unmap -l DATASTORENAME
Es ist seit Exchange 2010 SP1 möglich, mit der PowerShell PST-Dateien direkt in Exchange-Mailboxen zu importieren. Dazu verwendet man man am bestem das CMDlet New-MailboxImportRequest. Die PST-Dateien müssen auf einem UNC-Pfad zur Verfügung stehen.
New-ManagementRoleAssignment –Role "Mailbox Import Export" –User MEINUSER
Der aufrufende Nutzer muss Mitglied der RBAC-Rolle „Mailbox Import Export“ sein. NAch diesem PowerShell-Kommando ab- und wieder anmelden und eine neue Powershell-Sitzung starten. Erst dann steht das New-MailboxImportRequest CMDlet zur Verfügung.
New-MailboxImportRequest -Mailbox USERAALIAS -FilePath \\esp-ho-ex2010a\pst\USERAALIAS.pst -BadItemLimit 20
Das BadItemLimit ist eine Vorsichtmaßnahme aus der Praxis, damit der Import nicht an einer kaputten Spam-Mail aus dem Jahr 1994 scheitert. Für Härtefälle die PST-Datei mehrfach mit Scanpst behandeln oder mittels „-AcceptLargeDataLoss“ alle Defekte ausschliessen.
New-MailboxImportRequest -FilePath \\SERVER\c$\PST\foobar.pst -Mailbox foobar -TargetRootFolder "NAME DES ORDNERS" -BadItemLimit 20
Ab und an macht das Sinn, vor allem wenn Benutzer ihr Postfach dringend mal aufräumen sollten …
Einfach ein -IsArchive an den New-MailboxImportRequest anhängen. Das persönliche Exchange Archiv muss schon existieren und entsprechend lizenziert sein.
Mehrere PST-Dateien in Mailboxen Importieren
Sofern der Benutzer-Alias und der Name der PST-Datei übereinanderstimmen, ist es kein Problem alle Import-Auträge auf eoinmal zu erstellen (Exchange arbeitet diese Nacheinander ab):
Get-ChildItem \\SERVER\c$\PST\*.pst | %{ New-MailboxImportRequest -BadItemLimit 20 -Mailbox $_.BaseName -FilePath $_.FullName }
Get-MailboxImportRequest -Identity USERALIAS | Get-MailboxImportRequestStatistics -IncludeReport
Get-MailboxImportRequest -Status Completed
Get-MailboxImportRequest -Status Queued
Get-MailboxImportRequest -Status InProgress
Get-MailboxImportRequest -Status Failed
Exchange 2013 hat eien Bug, der die Gruppe für den Suchdienst nicht korrekt anlegt. Mit dem Setup aus CU7 oder höher ist das behoben. Das kann man aber manuell nacholen:
Get-MailboxImportRequest | Remove-MailboxImportRequest
Get-MailboxImportRequest | where {$_.status -eq "Completed"} | Remove-MailboxImportRequest