meinerjunge

Im Zertifikat sind als alt. Namen, autodiscover.interne.domain und autodiscover.externe.domain enthalten. Nein, per GPO haben wir das Autodiscover-Verhalten nicht angepasst. Proxy usw. was HTTPS aufbricht ist im internen Netzwerk nicht vorhanden. Die URLs in den virtuellen Verzeichnissen hatte ich ebenfalls angepasst und wieder zurück gesetzt. Als Bsp. OWA Alt: Intern URL= owa.interne.domain/owa Extern URL= owa.externe.domain/owa Neu: Intern URL= owa.externe.domain/owa Extern URL= owa.externe.domain/owa Aktuell wieder nach "alt" zurück geändert. MfG Meiner

In der Verwaltungsshell des Exchange mittels: Set-ClientAccessServer -Identity "Exchange" -AutoDiscoverServiceInternalUri https://servername.interne.domain/Autodiscover/Autodiscover.xml

Ausgestellt ist das Zertifikat auf den Exchange, als Alternative Name steht die interne und externe URL. (servername.interne.domain; mail.externe.domain) Self signed: weil es immer funktioniert hat...

Der Split-DNS wurde schon vor längerem eingerichtet. Der IIS wurde neu gestartet. Das Zertifikat ist "self signed", daher wurde die Hybrid-Konfig abgebrochen. Jetzt machen nur die Clients Probleme.

Vorher: HTTPS://servername.interne.domain/Autodiscover/Autodiscover.xml Geändert zu: HTTPS://mail.externe.domain/Autodiscover/Autodiscover.xml Aktuelle eingetragen URL: HTTPS://servername.interne.domain/Autodiscover/Autodiscover.xml Im Zertifikat steht, die interne und externe Domain drin. Ja, nur dieser eine Exchange (keine DAG), kein Loadbalancer, kein Reverse-Proxy im Einsatz, nur ein vorgeschalteter Spam-Filter. Im oben genannten Fall geht es um die Verbindung der Outlook-Clients von intern. MfG Meiner

Die URL wurde am Exchange geändert, zur Vorbereitung des Hybrid-Betriebs. Split-DNS ist eingerichtet und die URLs werden auch sauber aufgelöst. MfG Meiner

Hallo Schwarmwissen, nach dem Ändern der Autodiscover-URL auf unserem Exchange öffnet sich bei ca. der Hälfte der User (ca. 1000) das Outlook nicht mit der Fehlermeldung "der Informationsspeicher steht nicht zur Verfügung". Nach dem die Autodiscover-URL wieder auf den Ursprungswert zurück geändert wurde, öffnet sich bei einer Vielzahl der User das Outlook mit der selben Fehlermeldung ebenfalls nicht. Workaround ist: - Ein neues Outlook Profil anlegen - Outlook mit altem Profil starten Lösche ich das neue Outlook Profil, startet das Outlook wieder nicht mit der Fehlermeldung "der Informationsspeicher steht nicht zur Verfügung". Was bewirkt das Anlagen eines neuen Profils, so dass das Outlook auch mit dem alten Profil startet? Ich möchte die ominöse Konfig auf alle betroffenen User ausbringen. Vielen Dank! MfG Meiner EDIT: Server: Exchange 2019 CU15 Client: Office 2021 LTSC

Kannst du mir bitte den PS Befehl sagen um Cluster-Shares zu importieren? Vielen Dank!

Es sind ca. 150 Shares :(

Hallo, ich habe die Shares aus der Registry aus dem alten Cluster exportiert und im neuen Cluster importiert. (Die ID der Rolle habe ich angepasst). Die Shares werden auch im neuen Cluster angezeigt, nur kann er offensichtlich die Benutzer und Gruppen nicht auflösen/zuordnen, im FailoverManager wird nichts unter Permission angezeigt und auch auf die Shares komme ich nicht drauf. Ich habe die Reg auf allen Nodes unter "[HKEY_LOCAL_MACHINE\Cluster\Resources\--Rollen-ID--\Shares] importiert. Habt Ihr noch eine Lösung? MfG meiner

Hallo Forum, ist es möglich, nur die Freigaben eines "Fileserver Failovercluster" auf einen 2ten Failovercluster in eine neue Rolle zu migrieren? Es geht mir nicht um die Daten (wurden inkl. Bertechtigungen schon kopiert), diese sind bereits auf der neuen Cluster-Rolle, es geht mir nur im die Shares inkl. Berechtigungen. Vielen Dank! MfG Meiner

Hallo Jan, - der Ordner GroupPolicy wird nicht excluded. - Die VDIs werden nach dem Abmelden gelöscht, somit existieren keine gecatchten Profile beim Neuanmelden. - Wir haben die aktuelle Version im Einsatz "FSLogix 2210 hotfix 4 (2.9.8884.27471)". MfG meiner

Update: Die gestoppte bzw. verhinderte Abarbeitung der Gruppenrichtlinien lässt sich in meiner Umgebung auf die Benutzung von FSlogix Profilen nachvollziehen. Ohne FSLogix werden die GPOs sauber gezogen. Quelle: User group policies not applying when using FSLogix Profile Containers – JAMES-RANKIN.COM Die Abarbeitung der GPOs bei Anmeldung habe ich durch setzen folgender Reg-Keys wieder ans laufen bekommen. HKLM\SOFTWARE\FSLogix\Profiles “GroupPolicyState”=dword:00000000 HKLM\Software\Policies\FSLogix\ODFC “RefreshUserPolicy”=dword:00000001 Quelle: GPO User Policy not applying when using FSLogix - Windows - Spiceworks Community Jedoch scheint FSLogix die Abarbeitung neuer GPOs nach Anmeldung zu stoppen, so dass aktualisierte GPOs erst nach Neuanmeldung gezogen werden. Hat hier jemand das selbe Phänomen? oder noch nen Tip? Google und das Eventlog sind leider sehr schweigsam zu meinem FSLogix Verhalten. MfG Meiner

Der Timestamp passt, ich habe 15:19:xx Uhr das "gpupdate /target: user" ausgeführt und etwas laufen lassen, Ergebnis steht oben. Vollständiges Log folgt per PN. MfG Meiner

Die Frage ist ja, wonach soll ich Filtern und meine Domain und DCs hatte ich eigentlich editiert.