In einem relativ aktuellen Fall hatten wir das Problem, dass unter einer CentOS7-VM ein LVM-Volume volllief:

sudo lvm vgdisplay
 --- Volume group ---
 VG Name centos
 System ID
 Format lvm2
 Metadata Areas 3
 Metadata Sequence No 8
 VG Access read/write
 VG Status resizable
 MAX LV 0
 Cur LV 3
 Open LV 3
 Max PV 0
 Cur PV 3
 Act PV 3
 VG Size 1.27 TiB
 PE Size 4.00 MiB
 Total PE 332622
 Alloc PE / Size 332622 / 1.27 TiB
 Free PE / Size 0 / 0
 VG UUID xxxx

Nun wurde über Hyper-V eine weitere 500GB große Disk hinzugefügt. Diese muss nun zum logischen Volume hinzugefügt werden. Hierzu gehen wir erstmal in die LVM-Umgebung:

> Sudo LVM

Nach erneuter Eingabe des Passworts können wir loslegen. Über den Befehl lvmdiskscan können wir den Pfad der neuen Disk bestimmen:

lvm> lvmdiskscan
 /dev/centos/root [ 1.03 TiB]
 /dev/sda1 [ 200.00 MiB]
 /dev/centos/swap [ 2.00 GiB]
 /dev/sda2 [ 500.00 MiB]
 /dev/centos/home [ 247.25 GiB]
 /dev/sda3 [ 299.31 GiB] LVM physical volume
 /dev/sdb [ 500.00 GiB]
 /dev/sdc [ 500.00 GiB] LVM physical volume
 /dev/sdd1 [ 500.00 GiB] LVM physical volume
 4 disks
 2 partitions
 1 LVM physical volume whole disk
 2 LVM physical volumes

Mit dieser Disk werde ich das Beispiel durchmachen, Sie aber zur Verdeutlichung auch immer rot markieren. Als erstes wollen wir erreichen, dass die Disk über den LVM verwendet werden kann. Hierzu verwenden wir folgenden Befehl:

lvm> lvm pvcreate /dev/sdb
 Physical volume "/dev/sdb" successfully created

Führen wir nun erneut den Befehl lvmdiskscan aus, so sehen wir, dass die neue Disk hinzugefügt wurde:

lvm> lvmdiskscan
 /dev/centos/root [ 1.03 TiB]
 /dev/sda1 [ 200.00 MiB]
 /dev/centos/swap [ 2.00 GiB]
 /dev/sda2 [ 500.00 MiB]
 /dev/centos/home [ 247.25 GiB]
 /dev/sda3 [ 299.31 GiB] LVM physical volume
 /dev/sdb [ 500.00 GiB] LVM physical volume
 /dev/sdc [ 500.00 GiB] LVM physical volume
 /dev/sdd1 [ 500.00 GiB] LVM physical volume
 3 disks
 2 partitions
 2 LVM physical volume whole disks
 2 LVM physical volumes

Jetzt können wir die Disk nehmen, und sie unserer bestehenden LVM-Gruppe hinzufügen. Den Gruppennamen bekommt man über den Befehl vgdisplay heraus:

lvm> vgdisplay
 --- Volume group ---
 VG Name centos
 System ID
 Format lvm2
 Metadata Areas 3
 Metadata Sequence No 8
 VG Access read/write
 VG Status resizable
 MAX LV 0
 Cur LV 3
 Open LV 3
 Max PV 0
 Cur PV 3
 Act PV 3
 VG Size 1.27 TiB
 PE Size 4.00 MiB
 Total PE 332622
 Alloc PE / Size 332622 / 1.27 TiB
 Free PE / Size 0 / 0
 VG UUID x6THwj-1ybf-7UZD-GSb4-OJU0-ByTg-dyQL7h

Somit können wir folgenden Befehl abfeuern:

vgextend "centos" /dev/sdb
Volume group "centos" successfully extended

Sollten hier schon Fehlermeldungen wie diese hier kommen:

Couldn't create temporary text file name.
Backup of volume group centos metadata failed.

…so werden wir nachher noch was beachten müssen. Dies tritt vor allem dann auf, wenn das bestehende Volume wirklich komplett voll ist.

Nachdem nun die Gruppe vergrößert wurde, muss das Volume entsprechend vergrößert werden. Bei uns war es das root-Volume, dessen Pfad wir über den Befehl lvmdiskscan schon ausmachten:

lvm> lvmdiskscan
 /dev/centos/root [ 1.03 TiB]
 /dev/sda1 [ 200.00 MiB]
 /dev/centos/swap [ 2.00 GiB]
 /dev/sda2 [ 500.00 MiB]
 /dev/centos/home [ 247.25 GiB]
 /dev/sda3 [ 299.31 GiB] LVM physical volume
 /dev/sdb [ 500.00 GiB] LVM physical volume
 /dev/sdc [ 500.00 GiB] LVM physical volume
 /dev/sdd1 [ 500.00 GiB] LVM physical volume
 3 disks
 2 partitions
 2 LVM physical volume whole disks
 2 LVM physical volumes

Wir müssen uns nun also die zukünftige Größe des Volumes erschließen. Dies geschieht in zwei Schritten:

lvm> vgdisplay
 --- Volume group ---
 VG Name centos
 System ID
 Format lvm2
 Metadata Areas 4
 Metadata Sequence No 9
 VG Access read/write
 VG Status resizable
 MAX LV 0
 Cur LV 3
 Open LV 3
 Max PV 0
 Cur PV 4
 Act PV 4
 VG Size 1.76 TiB
 PE Size 4.00 MiB
 Total PE 460621
 Alloc PE / Size 332622 / 1.27 TiB
 Free PE / Size 127999 / 500.00 GiB
 VG UUID x6THwj-1ybf-7UZD-GSb4-OJU0-ByTg-dyQL7h

lvm> lvdisplay /dev/centos/root
 --- Logical volume ---
 LV Path /dev/centos/root
 LV Name root
 VG Name centos
 LV UUID 6wSo4q-yRO7-dZiZ-TwBf-QYeq-iTjf-O1Uk6Z
 LV Write Access read/write
 LV Creation host, time localhost.localdomain, 2016-03-14 13:42:03 +0100
 LV Status available
 # open 1
 LV Size 1.03 TiB
 Current LE 268814
 Segments 3
 Allocation inherit
 Read ahead sectors auto
 - currently set to 8192
 Block device 253:0

Addieren wir die aktuelle Größe des Volumes mit dem neu gewonnenen freien Speicherplatz (127999 + 268814), so bekommen wir als Endergebnis die neue Größe des Laufwerks (396813). Sofern es vorher keine Fehlermeldung bei Ausführung des Befehls vgextend „centos“ /dev/sdb gab, so können Sie nun mit folgendem Befehl das Volume erweitern:

lvm> lvresize -l 396813 /dev/centos/root
Size of logical volume centos/root changed from 1.03 TiB (268814 extents) to 1.51 TiB (396813 extents).
Logical volume root successfully resized.

Anderenfalls müssen wir noch das Autobackup deaktivieren, was aber durch eine kleine Abänderung des Befehls noch in der selben Line möglich ist:

lvm> lvresize -A n -l 396813 /dev/centos/root
 Size of logical volume centos/root changed from 1.03 TiB (268814 extents) to 1.51 TiB (396813 extents).
 WARNING: This metadata update is NOT backed up
 Logical volume root successfully resized.

Abschließend muss noch das Dateisystem erweitert werden. Dies erfolgt über den folgenden Befehl (außerhalb der LVM-Umgebung):

> sudo xfs_growfs /dev/centos/root

Das sollte es gewesen sein. Überprüfen kann man es mit dem Befehl df -h:

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/centos-root 1.6T 1.1T 500G 68% /
devtmpfs 5.8G 0 5.8G 0% /dev
tmpfs 5.8G 8.0K 5.8G 1% /dev/shm
tmpfs 5.8G 8.3M 5.8G 1% /run
tmpfs 5.8G 0 5.8G 0% /sys/fs/cgroup
/dev/sda2 494M 134M 361M 28% /boot
/dev/sda1 200M 9.5M 191M 5% /boot/efi
/dev/mapper/centos-home 248G 33M 248G 1% /home
tmpfs 1.2G 0 1.2G 0% /run/user/1001

Wird ein öffentlicher Ordner bzw. ein darin untergeordneter Ordner für das Empfangen von Mails aktiviert, kann es sein, dass er auf Grund von vorher gesetzten Berechtigungen dennoch keine Mails empfängt. Sollte dies externe Mails betreffen, können Sie die Lösung hier nachlesen. Geht es jedoch um interne Mails, sind Sie hier richtig.

Führt man eine Sendungsverfolgung auf dem Exchange aus, wird uns folgender Fehler angezeigt:

RecipientStatus: {[{LRT=};{LED=550 5.7.1 RESOLVER.RST.NotAuthorized; not authorized [Stage: CreateMessage]};{FQDN=};{IP=}]}

Hier wird also ein Benutzer erkannt, von dem die Mail ausgeht. Dieser hat keine Berechtigung, Mails im Zielordner zu „erstellen“. Nichts anderes passiert im Prinzip, wenn man eine Mail an einen Public Folder schickt. Beheben kann man das folgendermaßen:

Add-PublicFolderClientPermission -identity "\Ordner\Unterordner” –User Default -AccessRights CreateItems

Man kann es natürlich an dieser Stelle auch auf einzelne Benutzer runterbrechen. „Default“ beschreibt alle nicht extra genannten Benutzer.

Einleitung:

Im Rahmen einer Fehlersuche entfernten wir ein CSV aus dem Cluster, da dieses von einer der Clusternodes nicht mehr „in Besitz“ genommen werden konnte. Später an diesem Tag wollten wir das CSV wieder dem Cluster hinzufügen, da das Problem an anderer Stelle festgemacht werden konnte. Da wir das CSV nicht nur als solches, sondern auch als verfügbaren Speicher enfernt hatten, wollten wir über den Knopf „+ Add Disk“ die präsentierte Disk wieder hinzufügen. Statt uns die Disk anzubieten, überraschte uns Microsoft mit der Fehlermeldung:

Für Clusterdatenträger wurden keine geeigneten Datenträger gefunden.

In der Datenträgerverwaltung wurde die Disk in einem der Cluster als RAW-Datenträger erkannt, auf den anderen Nodes war gar keine Formatierung zu erkennen. Egal welche Node wir zu diesem Zeitpunkt als Master verwendeten, die Fehlermeldung blieb die selbe.

Wir versuchten sogar, die Disk auf einer Node online zu schalten und ihr einen Laufwerksbuchstaben zu verpassen. Auch dieser Zugriff war nicht möglich, hier bekamen wir nur folgenden Fehler:

Die angeforderte Ressource wird bereits verwendet.

Ursache:

Scheinbar hat sich bei dem übergeordneten Problem, welches wir hatten und weswegen auch dieser Schritt erst notwendig wurde, der Cluster bei der Ownership-Vergabe verhaspelt. Fakt ist, dass dieses scheinbar nicht lesbare Laufwerk zum Zeitpunkt des Enfernens aus den CSVs noch einer Node zugeordnet war und diese Zuordnung auch nicht verloren hat. Diese Zuordnung verhindert ein erneutes Auffinden der Disk über den Knopf „+ Add Disk“.

Behebung:

Ein einfacher PowerShell-Befehl hat uns im Endeffekt geholfen. Über die Datenträgerverwaltung konnten wir die Disknummer ausmachen (Disk 6). Mit diesem Wissen konnte folgender Befehl über die PowerShell-Konsole abgesetzt werden:

Clear-ClusterDiskReservation -Disk 6

Das ganze musste kurz bestätigt werden und direkt im Anschluss war die Disk wieder zu finden.

Geben Sie in Ihren Webbrowser https://(IP-Adresse Ihres Geräts) ein, um auf das Webinterface zu kommen, z.B. https://192.128.10.64.

Die IP-Adresse des Telefons findet man am Telefon unter: (Menü Taste) > 6 Information > 2 Systeminfo

Die Eingabe der SIP-URI am Telefon kann man umgehen, indem man 3 Mal hintereinander, ungefähr 3 Sekunden lang die X –Taste drückt. So kommen Sie auf die Startseite und können nach Ihrer IP-Adresse schauen.

Sobald Sie Ihre IP-Adresse im Webbrowser eingegeben haben, klicken Sie Links im Menü auf UC Zugangsdaten.

Zuerst wird nach der SIP-URI gefragt. Dort tragen Sie die E-Mail Adresse ein, die Sie auch in Lync nutzen, z.B. MMustermann@Beispiel.de.

Danach müssen Sie Domain\User eingeben, z.B. Beispiel\MMustermann.

Zum Schluss geben Sie Ihr Lync Passwort ein. Danach ist ihr Telefon mit Lync verbunden und funktionsfähig.

Ihre Lync- Kontakte werden auf das Telefon synchronisiert.

Anschließend gehen Sie auf Identität 1. Ihnen erscheint oben die Meldung: „Es gibt Änderungen, die noch nicht permanent gespeichert wurden“ welche sie mit Speichern bestätigen.

Danach klicken Sie unten auf Übernehmen und dann auf Re-Registrieren.

Bei uns gab es die Anforderung, die Größe eines Öffentlichen Ordners zu bestimmen. Kein Problem eigentlich, gibt es doch folgenden Befehl:

[PS] C:\Windows\system32>Get-PublicFolder "\[Ordnername]" | Get-PublicFolderStatistics | Select TotalItemSize

Doch weit gefehlt, dieser Befehl gibt nur die Größe der direkt darin befindlichen Dateien zurück. Größen von Unterordner bzw. der darin befindlichen Dateien werden nicht berücksichtigt. Abhilfe schafft hier folgender Befehl:

[PS] C:\Windows\system32>Get-PublicFolder "\[Ordnername]" -Recurse | Get-PublicFolderStatistics | Measure TotalItemSize -sum

Oder etwas freundlicher fürs Auge:

[PS] C:\Windows\system32>Get-PublicFolder "\[Ordnername]" -Recurse | Get-PublicFolderStatistics | Measure TotalItemSize -sum | Select @{N='Anzahl der Items'; E={$_.Count}}, @{N='Speicher in Byte'; E={$_.Sum}} | fl

Bitte beachten Sie, dass es eine Weile dauern kann, bis der Befehl durchgeführt wurde.

Im Internet gibt es viele Anleitungen, die beschreiben, wie man einen WSUS-Server mit einem SSL-Zertifikat versieht. Jedoch ist dort immer nur die Rede von selbst erstellten Zertifikaten und damit einhergehend auch grundsätzlich von einem internen Namen. Geht man nun strikt nach der Anleitung, verwendet aber stattdessen ein öffentliches Zertifikat, so scheitert es spätestens beim Verbinden der Serverkonsole (MMC) auf die neue Zugriffs-URL.

In diesem Tutorial gehe ich davon aus, dass das Zertifikat bereits im Zertifikatsspeicher des WSUS liegt. Im Anschluss sind folgende Schritte zu tätigen:

Setzen des Zertifikats

  • Wir öffnen den IIS Manager
  • Erweitern die Baumstruktur links auf folgenden Pfad:
    [Servername] -> Sites -> WSUS Administration
  • Während WSUS Administration markiert ist, kann rechts unter Actions auf Bindings… geklickt werden.
  • Nun kann auf das https-Binding doppelgeklickt werden.
  • Unten in der Rubrik SSL certificate kann im DropDown-Menü nun das Zertifikat ausgewählt werden, das zuvor eingespielt wurde.
  • Anschließend können die offenen Fenster mit OK und Close geschlossen werden.

Erzwingen von SSL-Verbindungen

  • Erneut im IIS Manager angekommen erweitern die Baumstruktur links auf folgenden Pfad:
    [Servername] -> Sites -> WSUS Administration (
  • Darunter sind folgende Applications für uns nun von Belang:
    ApiRemoting30
    ClientWebService
    DSSAuthWebService
    ServerSyncWebService
    SimpleAuthWebService
  • Nacheinander markieren wir nun jede dieser Applikationen, um anschließend auf SSL Settings zu gehen und folgende Einstellungen vorzunehmen:
    [X] Require SSL
    Client certificates: (o) Ignore
  • Damit wäre dieser Schritt erledigt. Sollte zum Zeitpunkt der Tätigkeiten der WSUS Manager geöffnet gewesen sein, wird dieser nun meckern.

WSUS für SSL konfigurieren

  • Nun öffnen wir ein Konsolenfenster als Administrator
  • Dort angekommen navigieren wir zu folgendem Pfad: „C:\Program Files\Update Services\Tools“
  • Nun führen wir folgenden Befehl aus: WSUSUtil.exe ConfigureSSL [Zukünftige URL]
    Bsp: WSUSUtil.exe ConfigureSSL wsus.domain.tld

Der Serverkonsole den lokalen Zugriff ermöglichen

Nun kommen wir zum Knackpunkt. Die Serverkonsole kann sich standardmäßig nur auf den internen Namen verbinden. Nach den vorhergehenden Änderungen wäre nun aber eigentlich die URL zum erneuten Verbinden der WSUS Managementkonsole einzugeben. Die Lösung hierfür konnte im TechNet von Microsoft (unten verlinkt) gefunden werden:

  • Wir öffnen den Registry-Editor und navigieren zu folgendem Pfad: „HKLM\System\CurrentControlSet\Controls\Lsa\MSV1_0“
  • Nun rechtsklicken wir auf den Key MSV1_0 und klicken dann auf New -> Multi-String Value. Als Name geben wir BackConnectionHostNames ein.
  • Nach der Anlegung öffnen wir nochmals den Wert, um als Value data die zukünftige URL einzutragen.
  • Anschließend kann das Fenster per Klick auf OK bestätigt und der Registry Editor wieder geschlossen werden.

Die Serverkonsole erneut verbinden

Abschließend können wir auf der Serverkonsole die aktuelle Verbindung auf den „alten“ FQDN schließen und anschließend auf die neue URL verbinden.

Quellen:
Problemlösung mit der externen URL: https://social.technet.microsoft.com/Forums/windowsserver/en-US/84033ed9-f7aa-4676-a68a-01607eb1f160/wsus-not-working-properly-with-ssl?forum=winserverwsus

Benötigt wird:

  • Das Zertifikat im PFX-Format
  • Das Passwort für das Zertifikat
  • Die CA-Chain in Textform
  • OpenSSL (http://www.heise.de/download/product/win32-openssl-47316/download)

Als erstes „zerlegen“ wir das PFX-File in die benötigten Einzelteile. Am einfachsten geht das, in dem man das Zertifikat mit den OpenSSL-Binaries in einen Ordner legt, z.B. C:\OpenSSL-Win64\bin. Danach öffnen wir eine Konsole und navigieren mit Ihr zu diesem Pfad. Alternativ kann man auch in dem Zielordner per Shift-Rechtsklick die „Eingabeaufforderung hier öffnen“.

In dem Ordner angekommen, setzen wir als erstes folgenden Befehl ab ([Cert] durch Dateinamen ersetzen):

openssl pkcs12 -in [Cert].pfx -clcerts -nokeys -out [Cert].cer

Damit haben wir das reine Zertifikat. Mit dem nächsten Befehl…:

openssl pkcs12 -in [Cert].pfx -nocerts -nodes  -out [Cert].key

haben wir dann auch noch das passende Keyfile. Beide Dateien öffnen wir nun am besten mit WordPad oder Notepad++ (Editor kann die Zeilenumbrüche nicht interpretieren). Im Header beider Files stehen ein paar Infos zum Zertifikat (Bag Attributes), die uns aber nicht interessieren. Wir kopieren nun aus dem .cer-File folgenden Inhalt…:

-----BEGIN CERTIFICATE-----
[Zeichenfolge]
-----END CERTIFICATE-----

und fügen diesen in ISPConfig unter Webseiten -> Webseite -> [Seitenname] -> Reiter „SSL“ -> Textbox „SSL-Zertifikat“ ein.

Anschließend nehmen wir das .key-File, öffnen es ebenfalls mit einem Texteditor und kopieren folgenden Block:

-----BEGIN PRIVATE KEY-----
[Zeichenfolge]
-----END PRIVATE KEY-----

in die Textbox „SSL-Key“ rein.

Nun muss nur noch die CA-Chain ebenfalls inklusive der Begin- und End-Markierungen in des Textfeld „SSL-Bundle“ eingefügt werden. Hier kann es auch passieren, dass der Text aus mehreren Begins und Ends besteht:

-----BEGIN CERTIFICATE-----
[Zeichenfolge]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Zeichenfolge]
-----END CERTIFICATE-----

Abschließend muss noch das Feld „SSL-Aktion“ auf Zertifikat speichern gesetzt werden. Die restlichen Felder müssen nicht ausgefüllt werden, diese wären nur für die Beantragung eines Zertifikats wichtig. Nach dem Klick auf Speichern sollte das Zertifikat nach kurzer Zeit sichtbar werden.

Man darf allerdings nicht den Haken „SSL“ bei den allgemeinen Domain-Einstellungen vergessen. Ohne diesen reagiert die Seite nicht auf SSL-Anfragen.

Anders als es der Begriff ‚Cluster‘ vielleicht vermuten lässt, müssen einige Vorbereitungen getroffen werden, um einen Exchange-Server in einer „Database Availability Group“ – kurz DAG – sauber neuzustarten. Macht man das nicht, so kann es gut gehen, im schlimmsten Falle fliegt einem allerdings der Datenbank-Index um die Ohren und die Suche funktioniert nicht mehr. Das wäre der schlimmste mir bekannte Fehler.

Um das zu vermeiden, machen wir folgendes:

Mittels dieses PowerShell-Befehls:

Get-MailboxDatabaseCopyStatus *

lassen wir uns alle Postfach-Datenbanken auf jedem eingehängten Server in der DAG ausgeben. Nun schauen wir nach Datenbanken, welche auf dem neuzustartenden Server den Status „Mounted“ beziehungsweise „Eingehängt“ haben. Sind solche Datenbanken vorhanden, muss folgender Befehl ausgeführt werden:

Move-ActiveMailboxDatabase -Server [Neuzustartender Server]

Hiermit erreichen wir, das die Datenbanken nicht mehr auf diesem Server eingehängt sind, sondern ein beliebiger anderer Server in der DAG diesen Job übernimmt.

Nun kann der Neustart durchgeführt werden. Sobald dieser durch ist, kann man mit dem ersten Befehl prüfen, ob alle Datenbanken den „Healthy“-Status haben bzw. nach kurzer Zeit wieder annehmen. Wichtig ist, dass alle Datenbanken einen solchen Status haben, bevor eine Verschiebung stattfindet. Ist dies der Fall, könnte auch mit dem nächsten Neustart fortgefahren werden.

Es wird davon abgeraten, innerhalb eines Clusters mehr als einen Server gleichzeitig neuzustarten.

 

Sofern Sie folgenden Fehler bei der Ausführung eines Reports bekommen:

Berichtfehler

Berichte können nicht ausgeführt werden, da der Konnektor für Microsoft
SQL Server Reporting Services, eine erforderliche Komponente für die
Berichterstellung, auf dem Server mit Microsoft SQL Server Reporting
Services nicht installiert ist.

… sollten Sie mal einen Blick auf diesen Artikel von Bhavesh Shastri werfen.

Wenn man diverse User aus dem Active Directory entfernt beziehungsweise deaktiviert, diese aber noch über Berechtigungen auf der SharePoint-Seite verfügen, so behält der SharePoint diese User in seiner Content-Datenbank. Dies macht er auch nicht ohne Grund: Durch dieses Verhalten ist es möglich, dass der SharePoint auch nach dem Löschen von Usern noch in der Lage ist, Felder wie „Zuletzt bearbeitet von“ und „Erstellt von“ korrekt zu befüllen. Doch es führt auch zu diversen Nachteilen: Der Peoplepicker beispielsweise wird nach wie vor die gelöschten User aufführen, da dieser dieselbe Datenbank als Quelle verwendet.

Um nun die User endgültig vom SharePoint zu entfernen, geht man wie folgt vor:

Als erstes müssen Sie über eine spezielle URL auf diese Systemgruppe zugreifen, welche den Inhalt der UserInfo-Table wiederspiegelt. Diese lautet wie folgt:

https://[SharePoint-URL]/_layouts/people.aspx?MembershipGroupId=0

Dort angekommen können Sie die verwaisten Profile markieren und anschließend über Aktionen -> Benutzer aus Websitesammlung löschen die User endgültig entfernen.

Damit sind wir schon fertig.