Hope This Helps

Skript zum Abfragen der Mitglieder in einer dynamischen Verteilerlisten:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
$DDL = “Name-der-Verteilerliste”
Get-DynamicDistributionGroup $DDL | ForEach {Get-Recipient -RecipientPreviewFilter $_.RecipientFilter -OrganizationalUnit $_.RecipientContainer} | Select DisplayName,PrimarySMTPAddress | Format-Table 

Hinweis: Die erste Zeile braucht man nur, wenn das Powershell-Skript außerhalb der Exchange-Powershell laufen lässt. Diese lädt die Exchange-Verwaltungsmodule!

Problem:
Szenario: Windows Server 2008 R2 aktuell gepatcht - Exchange 2013 CU14 installiert

Beim Versuch auf die Powershell zuzugreifen, wird folgender Fehler mehrfach ausgegeben:

VERBOSE: Connecting to exchange2013. New-PSSession : [exchange2013] Connecting to remote server exchange2013 failed with the following error message : [ClientAccessServer=exchange2013,BackEndServer=exchange2013,RequestId=fd9724cd-19fb-4842-b30d-c9c4b976119f,TimeStamp =2016-03-24 18:55:58] [FailureCategory=Cafe-SendFailure] For more information, see the about_Remote_Troubleshooting He lp topic. At line:1 char:1 + New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Microsoft CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException + FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed

Lösung:
Nach etwas Recherche war mir klar, dass es mit dem SSL-Zertifikat von Exchange zu tun haben muss.

1. Lösungsansatz:
Bitte prüfen Sie im IIS-Manager ob sowohl bei der "Default Web Site" und der "Exchange Back End" unter "Bindungen" -> HTTPS das richtige (oder überhaupt ein gültiges) SSL-Zertifikat zugewiesen ist. Eventuell bei der Powershell-Website unter "Exchange Back End" auch mal bei den "SSL-Einstellungen" den Haken bei "SSL erforderlich" entfernen - somit wird das SSL-Zertifikat ignoriert und man kann prüfen, ob dann die Powershell-Verbindung funktioniert.

2. Lösungsansatz (Fehler bei mir):
Nachdem das Zertifikat in Ordnung war, musste ich nach einem anderem Fehler suchen.
Fündig würde ich im Ereignisprotokoll hier habe ich folgenden Eintrag gefunden:

Schannel - Event-ID: 36885
Bei der Nachfrage der Clientauthentifizierung sendet dieser Server eine Liste vertrauenswürdiger Zertifizierungsstellen an den Client. Der Client verwendet diese Liste, um ein Clientzertifikat auszuwählen, das für den Server vertrauenswürdig ist. Momentan vertraut dieser Server sehr vielen Zertifizierungsstellen, sodass die Liste zu lang ist. Die Liste wurde abgeschnitten. Der Administrator dieses Computer sollte die für Clientauthentifizierung vertrauenswürdigen Zertifizierungsstellen überprüfen und diejenigen entfernen, die nicht unbedingt als vertrauenswürdig eingestuft werden müssen.

Mit dieser Meldung habe ich mittels Zertifikats-MMC ein mal die "Vertrauenswürdigen Stammzertifikatsstellen überprüft" und hier 299(!!) Zertifikate gefunden, die Großteils mir überhaupt nicht bekannt waren. Eine weitere Suche im Netz hat folgenden Microsoft-Artikel hervorgebracht: Microsoft: SSL/TLS communication problems after you install KB931125
Hier wird beschrieben, dass so etwas auftreten kann, nach der Installation des Updates KB931125.
Die Lsöung im Artikel habe ich wie folgt durchgeführt:

1.) Öffnen Sie den Registry-Editor (regedit.exe)
2.) Navigieren Sie zu folgendem Pfad: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
3.) Exportieren Sie diesen Pfad sicherheitshalber und löschen Sie Ihn danach!

Danach hatte ich nur noch ca. 20 Zertifikate in den vertrauenswürdigen Stammzertifikatsstellen und meine Powershell und alle HTTPS-Seiten auf meinem Exchange 2013 liesen sich problemlos öffnen!

Quelle der Lösungsfindung:
blackseals.net: Liste der vertrauenswürdigen Stamm-Zertifizierungsstellen ist zu lang
Microsoft: SSL/TLS communication problems after you install KB931125

Problem:
Bei meiner Exchange-Installation wollte ich auf einem Server 2008R2 mittels Powershell alle nötigen Features hinzufügen. Dabei ist mir die Routine immer bei der Installation "NET-HTTP-Activation" auf den Fehler 0x800f081f gelaufen.


Lösung:
Nach einigem Probieren bin ich auf einen Eintrag im Internet gestoßen, wie man das .NetFX3 manuell installieren kann.
Hierzu bitte eine Installations-DVD in das Laufwerk legen (hier E:) und den folgenden Befehl als Administrator starten:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:E:\sources\sxs

Wobei Source: eventuell angepasst werden muss, je nachdem wo das Laufwerk gemountet ist.

Danach ließ sich die die NET-HTTP-Activation problemlos per Powershell installieren.

Problem : Das Windows Update läuft ewig und findet keine neuen Updates, hier gibts mehrere Gründe dafür. Bei mir war es nur das WMI das defekt ist.

Lösung : Einmal WMI reparieren

net stop winmgmt
REN "%windir%\System32\Wbem\Repository" "%windir%\System32\Wbem\Repository_BACKUP"
net start winmgmt
winmgmt /salvagerepository
winmgmt /resetrepository

Wenn man die installierten Rollen & Features eines Servers anzeigen möchte ist der schnellste Weg die Powershell.
Hierführ wird .NET Framework 4.5 und Powershell 4.0 benötigt.

Der Befehl dafür lautet :

Get-WindowsFeature | Where installed -eq true

Downloads :
.NET Framework 4.5
Powershell 4.0

Version der Powershell ermitteln :

$PSVersionTable