If you mail-enable a public folder, it happens sometimes, that the folder still isn’t able to receive any mails. If just external mails aren’t received, you may review this thread. If internal mails are also affected the following instructions should do the trick.

If you track those mails on your exchange server, you may receive the following line:

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

This line says, that the sender was recognized by the exchange infrastructure. And this user has no right to “create items”, because that’s the thing that is basically happening if you send a mail to a public folder. To fix this, we allow all users to “create items” who do not own an explicit right set:

Add-PublicFolderClientPermission -identity "\Folder\Subfolder” –User Default -AccessRights CreateItems

Of course you are able to allow just single users by replacing “Default” with the regarding user. “Default” stands for all those users who were not set up previously.

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.

We recently had the request to determine the size of a public folder. Not a problem at all, this should do the trick:

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

… not really. All we get is the summarized size of the items included in this specific folder. Subfolders and items in subfolders will be ignored. But there is another way which will include subfolder sizes. Here you go:

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

Optically improved version:

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

Please be aware that this oneliner may takes some time to complete your request.

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.

 

If you are removing/disabling Users from Active Directory, which had some permissions left on your SharePoint-Site, SharePoint will keep those Userprofiles in it’s Content-Database. This is a proposed behaviour, since this method ensures that SharePoint is still able to fill fields like “Modified by” or “Created by” with names from old users. However this also results in some negative points as the PeoplePicker will still show all old users because he’s using the same database as source.

To permanently delete those orphaned users, we have to follow the following steps:

First, we need to access the system group which contains all those records by using the following URL:

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

Here you can mark all orphaned Users and delete them by clicking on Actions -> Remove Users from Site Collection.

That’s it!

Merkmal


Outlook stürzt unerwartet ab und zeigt folgende Meldung:

AppName: Outlook.exe
AppVer: 14.0.4760.1000
ModName: Kernelbase.dll
ModVer: 6.1.7600.16385
Offset: 0003194b

Ursache


Diese Problem tritt bei dem Verfall der Outlook Dateien (.pst oder .ost) auf.

Lösung


Um dieses Problem zu lösen, nutzen Sie das “Tool zum Reparieren von Microsoft Office” um die Outlook Dateien zu reparieren.

1. Schließen Sie Outlook

2. Gehen Sie zu folgendem  Ordner:  C:\Programme\Microsoft Office\Office[Version]

3. Doppelklick Scanpst.exe

Unbenannt0

4. Klicken Sie im Dialogfenster “Tool zum Reparieren von Microsoft Office”  Durchsuchen.

Unbenannt

5. Wählen Sie Ihr Outlook Dateien (.pst oder .ost) aus, dann klicken sie Öffnen.

6. Klicken Sie im Dialogfenster “Tool zum Reparieren von Microsoft Office”  Start.

  • Bei Windows 7, Windows 10 und Windows Vista ist der Default Ort für die Outlook Dateien in Outlook 2010:

(.pst file)

C:\Users\username\Documents\Outlook-Dateien

Unbenannt1

(.ost file)

C:\Users\username\AppData\Local\Microsoft\Outlook

Unbenannt

Notiz: Um diesen Pfad für die .ost Datei zu sehen, müssen Sie die versteckten Dateien und Ordner sichtbar machen mit dn folgenden Schritten

1. Öffnen Sie die Ordneroptionen, indem Sie auf die Schaltfläche StartSchaltfläche  klicken, auf Systemsteuerung klicken, auf Darstellung und Anpassung klicken und dann auf Ordneroptionen klicken.

2. Klicken Sie auf die Registerkarte Ansicht.

3. Klicken Sie unter Erweiterte Einstellungen auf Ausgeblendete Dateien, Ordner und Laufwerke anzeigen, und klicken Sie anschließend auf OK.

7. Nachdem Ihre Datei gescannt wurde, überprüfen sie bitte die angezeigte Information des Dialogfensters “Tool zum Reparieren von Microsoft Office” .

Wichtig:  Setzen Sie den Hacken bei Sicherungskopie von geprüfter Datei vor Reparatur, damit das “Tool zum Reparieren von Microsoft Office” eine Backup Datei erstellt bevor es den Prozess der Reparatur startet.

Unbenannt2

8. Klicken Sie Reparieren.

9. Nachdem der Reparaturprozess abgeschlossen ist, klicken Sie OK.

Unbenannt3

Wenn der Reparaturprozess fertiggestellt ist, werden Sie folgende drei Dateien finden:

 File  Description
 filename.bak Das ist die ursprüngliche nicht reparierte Backup-Datei. Wenn sie auf diese Datei in Outlook zurückgreifen wollen, benennen Sie die .bak Datei um zu einer .pst Datei.
 filename.log  Dieses log file dokumentiert den Reparatur Prozess aufgeführt durch “Tool zum Reparieren von Microsoft Office”.
 filename.pst oder filename.ost  Dies ist die reparierte Outlook Datenbank Datei.

Unbenannt4