schmitzp1978

Wie der Titel bereits sagt: Sobald ich eine neue DB erstellen möchte, erscheint die Fehlermeldung, dass angeblich kein Zugriff auf die AD möglich wäre. Die DB wird zwar dennoch im Exchange angelegt und ist nutzbar, aber in der AD ist sie per ADSIEDIT nicht zu finden. Wo fehlen denn hier Berechtigungen? Die ersten beiden Datenbanken konnten ohne Probleme erstellt werden, nun aus heiterem Himmel funktoniert der Zugriff zur AD nicht mehr. Wo liegt hier der Fehler? Vielen Dank!

Entschuldigt die späte Antwort, ich bin jetzt erst dazu gekommen, das Thema erneut anzugehen. Die Lösung war: Neustart des IIS. Danach verbinden sich die Clients, wenn auch sehr zögerlich. Leider hat das zu einem Problem geführt: Bei jedem Neustart der Exchange-Server, z.B. bei Windows-Updates, muss ich im IIS das Zertifikat neu an den Port binden (im Exchange Backend, Port 444). Er verliert es leider nach jedem Reboot.

Liebe Freunde des Exchange, ich benötige bitte euer Schwarmwissen. Folgendes Problem stellt sich dar: Im Einsatz ein Exchange 2016 CU11 auf Server 2016. Die AD hat die Gesamtstrukturfunktionsebene Server 2016. Der Exchange ist von außen erreichbar zwecks OWA und ActiveSync mit der URL https://outlook.contoso.de. Alle externen Pfade zeigen auf diese URL. Alle internen Pfade zeigen auf die URL https://exchange.contoso.local Da wir nun aber ein Letsencrypt-Zertifikat nutzen, bekommen alle Outlook 2016-Clients eine Zertifikatwarnung. Das liegt natürlich daran, dass .local - Adressen nicht in das Zertifikat mit aufgenommen werden können. Ich habe nun folgenden Lösungsansatz durchgeführt: Im internen DNS habe ich eine neue Forward-Zone mit dem Namen exchange.contoso.de erstellt und dort einen A-Eintrag auf die interne IP des Exchange gesetzt (der Name des Host-A-Eintrages ist identisch mit übergeordnetem Ordner). Danach habe ich die internen Pfade per GUI und Powershell im Exchange angepasst mit Set-ClientAccessServer -Identity "EX01" -AutodiscoverServiceInternalURI "https://exchange.contoso.de/Autodiscover/Autodiscover.xml" und Set-AutodiscoverVirtualDirectory -Identity "EX01\Autodiscover (Default Web Site)" -Interna lUrl "https://EX01.contoso.de/Autodiscover/Autodiscover.xml" -ExternalUrl "https://outlook.contoso.de/Autodisco ver/Autodiscover.xml" Die restlichen Pfade wie MAPI, OWA, EWS, ECP, ActiveSync usw. habe ich per GUI geändert. Ein nslookup und ping im internen Netz auf exchange.contoso.de funktioniert auf den Clients einwandfrei (DNS funktioniert also). Ein ipconfig /flushdns wurde von mir durchgeführt (auch auf den Servern). Trotzdem verbinden die Outlook-Clients sich nicht mit exchange.contoso.de. Eine Verbindung wird überhaupt nicht mehr aufgebaut. Wenn ich am Client eine E-Mail-AutoKonfiguration durchführe, zeigt er mir an, dass nach wie vor noch alle internen URLS auf exchange.contoso.local zeigen. Habt ihr noch eine Idee, warum meine Konfiguration nicht funktioniert? PS: Die Domäne heißt natürlich nicht contoso, ich habe hier einfach einen anderen Namen zu Veranschaulichung genommen. Vielen Dank und ein schönes WE euch!

Vielen Dank für die Bestätigung Meister Hat alles geklappt. Musste nur noch AD Sites und den DNS aufräumen, das hat er leider nicht autom. bereinigt.

Grüßt euch, folgender Aufbau: contoso.com = Parent Domain und besteht aus 3 Domänencontrollern (Server 2016) sub.contoso.com = Child Domain und besteht aus 1 Domänencontroller (Server 2008) Die Child Domain sub.contoso.com soll gelöscht werden. Beim Ausführen von dcpromo auf dem DC der Child Domain erscheint die Frage: "Domäne löschen, da der Server der letzte Domänencontroller in der Domäne ist". Nur zur Vergewisserung: Der Haken muss gesetzt werden, damit die sub.contoso.com sauber demoted wird? Die Parent Domain bleibt unberührt und wird nicht gelöscht? Vielen Dank

Sry für die späte Antwort. Ich sag nur: Jeder Boot tut gut (Clients)

Hab alles gefunden vielen Dank!

Es hat alles soweit funktioniert, aber: Nun kommt bei den Clients beim Versuch der Verbindung: Windows-Sicherheitshinweis: Der Verbindungsversuch wurde nicht abgeschlossen. Die vom Server bereitgestellten Anmeldeinformationen wurden nicht validiert. Beenden Sie die Verbindung, und wenden Sie sich mit den in den Details angegebenen Informationen an den Administrator. Eine Verbindung kann dennoch hergestellt werden. Sie sind dadurch jedoch den durch einen möglichen nicht autorisierten Server entstehenden Sicherheitsrisiken ausgesetzt. Der Server "XXX" ist für das Profil nicht als gültiger NPS-Server konfiguriert, mit dem Verbindungen hergestellt werden können. Wenn ich auf "Verbinden" klicke, kommt die Verbindung dennoch zustande.

Vielen Dank!

Hallo, ich habe nur mit Linuxbasierten Radius-Servern gearbeitet. Im neuen Unternehmen ist ein NPS im Einsatz, dieser soll auch nicht abgeschafft werden. Der NPS läuft auf dem DC inkl. CA. Das bisherige Zertifikat welches bei PEAP in den Netzwerkrichtlinien angegeben war, wurde von der internen CA ausgestellt. Seit heute ist aber ein Zertifikat mit dem Namen "WMSvc-Servername" in den Eigenschaften für EAP ausgewählt. Das alte kann im Dropdwon-Menü nicht mehr ausgewählt werden. Wie kann ich in den Eigenschaften für geschütztes EAP bei "Zertifikat ausgestellt" wieder die alte CA auswählen?