NorbertFe

vor 2 Minuten schrieb peterg:

Da ich noch nie was mit Teaming gemacht habe

So langsam haben wir das alle verstanden. ;)

Ja wahrscheinlich wäre es sinnvoll, wenn man für Server und Clients getrennte Updatekonfigurationen einrichtet. ;) Wie kommt man auf die Idee, alles mit einem GPO abzufackeln? ;)

Du musst Option 4 aktivieren. Bei deiner obigen Konfiguration wird nie eine Installation erfolgen. Über welches os reden wir?

Und wo is das Problem?

Ja logisch brauchst du eine, wie willst du sonst an den Host kommen. Deswegen kann man auch einfach den Haken setzen. Alternativ gehts sicher auch per VLAN auf dem Adapterteam, wenn deine Infrastruktur das zuläßt, Du hast doch oben selbst geschrieben, dass dein erster Befehl den Haken quasi per Powershell wieder gesetzt hat. 

vor 11 Minuten schrieb peterg:

Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen" habe ich NICHT aktiviert (siehe Anlage)

Dann brauchst du aber weitere Netzwerkverbindungen im Host, und Nils hatte dir genau was anderes geraten soweit ich mich erinnere.

Und klar, wenn du dann managment-OS wieder hinzufügst ist logischerweise der Haken drin.

Warum erzeugst du für JEDE VM nen eigenen VSwitch? Weise doch sinnvollerweise den oben erzeugten vSwitch-Team den VMs direkt zu. Oder spricht da irgendwas dagegen? Siehst du bei deiner Konfiguration überhaupt noch durch? Ich habe da Zweifel. :)

Bye

Norbert

Hallo erstmal,

Was ist denn die Anforderung für sowas?

bye

norbert

Einfach die klassische runterlasen und geht. Da muss man nichts mit Kompatibilität ändern. Ich vermute du hast da was falsches.

Auch die 8.x is gewöhnungsbedürftig. Ich habe noch die 7.4 und werde die so lange wie möglich behalten. ;)

Boah aber langsam... natürlich den beim Provider. Wieso rede ich hier eigentlich die ganze Zeit von der Reihenfolge usw.?

Ja, aber das hab ich gefühlt vor einem Jahr auch schon geschrieben. ;) Du kannst natürlich auch deinen Webserver korrekt konfigurieren. ;) Dann mußt du nix löschen. Und GPO ist in dem Fall einfach der falsche Weg, weil du das für Handys und Konsorten ja nicht verwenden kannst. Und Nein ich gewöhne meinen Nutzern nicht das Wegklicken von Zertifikatsproblemen an.

Ach menno. Was heißt denn "notwendig" in deinen Augen? Das sind genauso Einstellungen, die man einmal vornimmt, wie deine, nur dass sie im How To "sichtbar" sind und beim Tausch des PDC Emulators mitwandern. Das steht aber auch im Artikel ganz oben.

Was bedeutet das jetzt? Du hast dein Problem gelöst, oder wie soll ich den grünen Haken jetzt interpretieren?

Welche Skypeversion setzt du denn ein? Bei mir gibts den Link im Kontextmenü. Ich verwende aber auch noch die klassische Skype Version.

Wird dein DC erfolgreich (!) mit dem externen Timeserver gesynct und danach auch als vertrauenswürdige Zeitquelle im Netz angekündigt? Ist der DC physikalisch oder virtuell? Den Artikel hier kennst du?
https://www.gruppenrichtlinien.de/de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/

Bye

Norbert

Warum heißt dein Exchange eigentlich intern anders als extern? Warum gibts kein Split-DNS? Dann wäre das eventuell einfacher verständlich.

Wenn du dir die Reihenfolge des Autodiscoverprozesses vorn im Thread mal anschaust, dann dürfte doch verständlich werden, dass Outlook zuerst zu Nummer 1 (dem SCP) geht, allerdings funktioniert das NUR im internen LAN. Danach kommt Nr. 2 an die Reihe und das ist eben _immer_ https://domain.tld/autodiscover/autodiscover.xml (wobei domain.tld der Emaildomain des USERS entspricht). Erst danach kommt Nr. 3 https://autodiscover.domain.tld zum Tragen. Ist das jetzt verständlicher? Wenn dir also Nr. 2 einen Fehler liefert, dann geht Outlook nicht einfach weiter zu Nr. 3 sondern präsentiert dir den Fehler (dein fehlerhaftes Zertifikat).

Wie du das unterbinden kannst, hab ich dir im Posting weiter oben bereits geschrieben. Wenn du wissen willst, ob es wirklich daran liegt, dann kannst du am Client die nicht benötigten Autodiscoverschritte per GPO deaktivieren. Das würde ich dir aber nur empfehlen, wenn du das für ALLE Clients hinbekommst (eher selten der Fall) und zweitens, wenn du den Server nicht im Griff hast (ich hab ja noch Hoffnung). Alternativ kauf dir einfach jemanden ein der dir hilft.

So ich hoffe, das war jetzt verständlich.

Bye

Norbert

Wer ist denn 192.168.0.15? Und für wen greift diese Policy? Client oder DC?

Hau doch mal ab mit deinem owa.domain.tld  ( :)) (auch intern brauchst du das nicht, es sei denn dein internen AD Domain Name ist gleich deinem externen DNS Namen.

Hand aufs Herz, verstehst du eigentlich, worum es mir hier in der Diskussion eigentlich geht?

Intern und extern die selbe Antwort mit dem selben Zertifikat? Also landest du immer beim Provider. Damit wären wir wieder bei den drei Möglichkeiten, die man in dem Fall hat:

1. Dein Webserver beim Provider antwortet korrekt mit 404 auf Dinge die er nicht kennt. Wie und ob das geht, kann ich dir nicht sagen.

2. Dein Webserver reagiert überhaupt nicht auf ssl, was heutzutage aber ggf. auch keine besonders kluge Idee ist, aber evtl. schnell fürs Troubleshooting funktionieren würde (vorausgesetzt du hast kein hsts auf der Seite konfiguriert)

3. Du löschst den Domain Eintrag, dann kann _niemand_ mehr https://domain.tld aufrufen und das bedeutet, dass der _gemeine_ User eben https://www.domain.tld eintippen muss. (die billigste Lösung die immer geht, aber nicht immer auf Gegenliebe stößt bei erwähnten Nutzern)

Bye

Norbert

Du sollst auch nicht owa.domain.tld aufrufen, sondern https://domain.tld/autodiscover/autodiscover.xml

Menno. Bisschen Mitdenken wäre schon hilfreich. :)

Abgesehen davon, ist das so schwer zu verstehen, dass Outlook immer die selbe Reihenfolge abarbeitet und logischerweise dein SRV Record nie für das Problem verantwortlich war? ;)

vor 28 Minuten schrieb Vinc211:

Habe die Änderungen gemacht und den SRV Eintrag beim Provider gelöscht und nur autodiscover.domain.tld hinzugefügt bekomme das Problem aber weiterhin.

Welchen Eintrag hast du denn gelöscht? Den Domain Einträg oder den SRV Eintrag? Was passiert eigentlich, wenn du https://domain.tld/autodiscover/autodiscover.xml in einem Browser aufrufst?

Wer will dich hindern (mal davon abgesehen, dass du die ja sinnvollerweise schreibgeschützt mounten kannst)? Geht aber nur offline.

Welcher Name steht denn im Zertifikat, welches die Nutzer präsentiert bekommen?

Gerade eben schrieb Vinc211:

Reverse Proxy ist nicht vorhanden.

Ich meinte auch Forward Proxies. Welche Exchangeversion nutzt du?

Dann liegts meist auch nicht am Server/DNS sondern am Client oder Proxy. Welche Versionen (patchstand) von Outlook setzt du ein? Tritt das Problem intern oder extern auf?

vor 5 Minuten schrieb Gu4rdi4n:

Also Chrome wird beispielsweise fast täglich gepatcht

Bei mir nicht. Ich bin aber auch nicht auf dem canary oder nightly Channel (oder wie auch immer die heißen) und auf dem normalen stable channel kommen im Normalfall maximal 2x im Monat Aktualisierung. Ähnliches gilt für Adobe mit Flashplayer und diverse Reader Versionen.

Ja natürlich ist es Arbeit, aber dafür eben meine Zeit und mein Geld und nicht das des Anbieters. Wie oben schon erwähnt, gibt es immer mehrere Varianten und den Kosten/Nutzen Faktor muß sich jeder selbst ausrechnen.

Bye

Norbert