Jump to content

jets187

Newbie
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jets187

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Das stimmt. Bedeutet aber nicht, dass es nicht umkonfigueriert werden kann. Natürlich nach Best Practise
  2. Guten Morgen Norbert, leider ist es so. Wenn etwas mal läuft, dann lässt man es auch si laufen, auch wenn es ein Provisoriom ist
  3. Hallo Nobby, ist wirklich nicht Best Practise und gefrickel. Sauberer ist es natürlich mit Zertifikaten die an keiner stelke angemeckert werden. Auch unsere Mobile Devices jammern die Zertifikate an. Ok ist es für mich definitiv nicht aber bis ich alles sauber konfiguriert habe und SSN Zertifikate bezogen habe, ist das meine Lösung.
  4. Hallo zusammen. Ich habe das Problem gelöst. In Franks Artikel wird ja beschrieben, dass der SCP Eintrag der Target Domain, also in meinem Fall Forest B, in Forest A importiert werden muss. Habe das über den Exchange Server vom Forest B gemacht. $cred= Get-Credential Export-AutoDiscoverConfig -DomainController dc1.source.tld -TargetForestDomainController dc2.target.tld -TargetForestCredential $cred -MultipleExchangeDeployments $true -verbose Ich musste noch das Self Signed Zertifikat des Exchange von Forest B auf meinem RDSH Server in den Zertifikatsspeicher unter "Vertrauenswürdige Stammzertifizierungstellen" importieren. Jetzt klappt alles wie es soll. Danke nochmal an djmaker für den wertvollen Tipp.
  5. Hi Norbert, ich versuche gerade diese Lösung. https://www.msxfaq.de/exchange/autodiscover/autodiscover_sonderfaelle.htm Mit den Zertifikaten hast du recht. Ich muss natürlich autodidcover in beiden forests anpassen. Das sollte eigentlich zu machen sein.
  6. Hallo Norbert hallo Nobby, ok habe jetzt das Problem verstanden. Das heisst, dass es tatsächlich nur an den Self Signed Zertifikaten liegt und dadurch das Split DNS nicht zustande kommt. Ich glaube nicht, dass mein GF probleme damit hat, Zertifikate zu kaufen. Die kosten wirklich keine tausende mehr. 2 SAN Zertifikate für die entsprechenden Eschange Dienste und das war es (hoffe ich mal) Danke
  7. Sorry, habe mich mir Split DNS verlesen . Die Zertifikate auf meinem Exchange Server sind Self Signed. Im Forest B das gleiche.
  8. Hi djmaker, sieht danach aus. Ich werde der sache mal nachgehen. Hi NobbyausHB, beide Umgebunden haben ca. 30 Posftfächer und kein DAG. Was meinst du mit Split Brain. In meinem DNS gibt es ein Conditional Forwarding was auf die DNS Server von Forest B zeigt und umgekehrt. Auf beiden Seiten gibt es keine Interne und externe Autodiscover URL Get-AutodiscoverVirtualDirectory | fl internalurl,externalurl zeigt keine URLs an. Get-ClientAccessServer | fl *InternalUri* zeigt auf die FQDN des jeweiligen Exchange Servers. Danke
  9. Hallo zusammen, wir haben vor einiger Zeit ein Trust zwischen 2 Forests erstellt, da die Firmen der Forests fusioniert. Unser Forest nenne ich hier mal Forest A und die Gegenseite Forest B. Der Trust funktioniert wunderbar. Forest A stellt für die User von Forest B einen Terminal Server (RDSH Server 2016) zur Verfügung, damit Applikationen die auf Seiten von Forest A zur Verfügung stehen, die User von Forest B nutzen können. Die User von Forest B melden sich mit Ihren Forest B Accounts am Terminal Server von Forest A an. Dazu habe ich entsprechende GPO's eingerichtet. Wie schon gesagt funktioniert die Anmeldung am RDSH Server einwandfrei. Nun zu meinem eigentlichen Problem. Beide Forests besitzen eine Exchange Umgebung mit jeweils einem Exchange Server. Forest A hat einen Exchange 2010 im Einsatz und Forest B einen Exchange 2016. Die User von Forest B haben natürlich Postfächer, die weiter genutzt werden sollen. Über Exchange OWA können die User ohne Probleme am RDSH Server Ihre Postfächer nutzen. Was nicht klappt ist die Postfach Einrochtung der User von Forest B. Wenn ich Outlook starte, dann erkennt Outlook Automatisch die Mail Adresse des Users von Forest B (Anzeige auf der Startseite des Assistenten). Wenn ich auf weiter klicke, dann erscheint aber plötzlich das Zertifikat unserers Exchange Servers (für die Serverauthentifizierung) statt des Exchange Server Zertifikats von Forest B. Das ist für mich ein Indiz, dass Autodiscover von Outlook nicht an den Exchange von Forest B geht sondern von Forest A. Ist es überhaupt möglich, die Exchange Postfächer des Forest B auf dem RDSH Server / Outlook von Forest A einzurichten. Zur Info: Für den Trust haben ich im DNS des Forst A und B jeweils ein Conditionel Forwarding eingerichtet, was auf die jeweiligen DNS Server zeigt. Liegt es am DNS, oder gibt es auch sowas wie ein Exchange Forest Trust? Danke
  10. Hi Falkebo, vielen Dank für den Tipp. Den werde ich mal so durchführen. Ich schließe diesen Thread nun. Danke
  11. Hallo zussmmen, wir haben eine Bidirektionale (Gesamtstrukturweite Authentifizierung) Vertrauensstellung zwischen zwei Forests. Forest A ist unsere Seite und B die Remote Seite. Forest B stellt ein DFS Stamm mit Shares für z.B. Home Shares zur Verfügung. Nun sollen User von Forest B über einen RDSH 2016 Server am Forest A Arbeiten / Applikationen nutzen. Ich habe alle GPO's entsprechen in Forest A konfiguriert und die Anmeldung + GPO Verarbeitung funktionieren Tadellos (loopback + lockdown RDSH + Gesamtstrukturübergreifende Benutzerrichtlinien und servergespeicherte Profile zulassen). Was leider nicht klappt ist, dass die Home Shares aus Forest B per FQDN des DFS Stamms nicht gemountet werden (weder per GPO noch per net use über cmd). Per cmd bekomme ich die Fehlermeldung "Netzwerkname nicht gefunden". Gehe ich direkt an den Server in Foreat B der das Share hosted per FQDN ran, funktioniert es wunderbar. Es gibt auf beiden Seiten ein Conditionel DNS Forwarding für die entsprechenden Domänen. Was muss ich auf Seite A konfigurieren, damit ich per GPO die Homeshares der User von Forest B per \\domname.local\DFS\Share mounten kann. Danke
  12. Hi testperson net use H: \\domname.local\dfsstam\share. Also FQDN des DFS Stamm / AD Servers. Ich werde jetzt einen neuen Thread im entsprechenden Forum aufmachen. Danke Hi daabm, die GPO wird problemlos angewendet. WG DFS: Ich gehe per FQDN an DFS ran. net use H: \\domname.local\dfsstam\share. Also FQDN des DFS Stamm / AD Servers. Ich werde jetzt einen neuen Thread im entsprechenden Forum aufmachen. Danke auch dir für deine hilfe.
  13. Hi djmaker danke für den. Den habe ich auch umgesetzt und es hat auch geholfen. Auch der Tipp von testperson war sehr hilfreich, danke dafür. Ich habe eine verständnis Frage. Gibt es eine Möglichkeit die Freigaben eines DFS Stammes der Remote Domäne B an einem client det Domäne A durch einen Benutzer der Remote Domäne B zu mounten. In der Remote Domäne B existiert ein DFS Stamm und die Shares werden über den DFS Stamm Namen per GPO verteilt. Wenn ich aus der Domäne A versuche per net use an diesen Namen ran zu kommen bekomme ich die Meldung "Netzwerkname nicht gefunden" angezeigt. Danke euch
  14. Hi testsperson, danke für die schnelle Antwort. Es handelt sich um RDSV mit Server2016. Du hast natürlich recht mit den GPOs. Ich werde mir die Artikel anschauen. Wenn es nicht klappen sollte, melde ich mich nochmal. Danke Hi testperson, ich habe den Microsoft Artikel gelesen. Das würde bedeuten, dass ich alle Einstellungen für die User in DOM B anhand von GPOs erstellen muss, ist das richtig? GPOs für RDSH Konfigurationen haben aber keinen Einfluss auf Anmeldung an lokalen Computern in DOM B (hoffe ich zumindest) Die User sollen witerhin wie gewohnt in Dom B funktionieren. Danke
×
×
  • Create New...