Jump to content

jets187

Members
  • Gesamte Inhalte

    33
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von jets187

  1. vor 34 Minuten schrieb testperson:

    Hi,

     

    zu 1: Eine Möglichkeit wäre bspw.: FSLogix FRX Command-Line Reference - FSLogix | Microsoft Docs

    zu 2: Alles was du umleitest, liegt nicht im Profil und interessiert FS Logix somit nicht. Die Frage wäre, was du alles umleitest und ob das (weiterhin) Sinn macht.

     

    Gruß

    Jan

    Hi Jan,

     

    FRX ist genau das, was ich brauche.

     

    Ich bin der Meinung, dass die Umleitung von Dedktop, Documents und Downloads sinn macht. Das werde ich auch stehen lassen.

     

    Vieken Dank für deine Unterstützung.

  2. vor 51 Minuten schrieb testperson:

    Hi,

     

    x, y und z "funktionieren nicht", da du keine Roaming Profiles nutzt/nutzen möchtest. Warum nutzt du nicht "einfach" FS Logix als Profillösung?

     

    Gruß

    Jan

    Hi Jan,

     

    FSLogix habe ich im blick. Generell habe ich keine Probleme RUP zu nutzen. Egal in welcher Form.

     

    Könntest du mir folgende Fragen beantworten?

     

    1. Was passiert mit den lokal angelgten profilen der TS nutzer auf den TS Servern, wenn ich jetzt FSLogix auf diesen TS einsetzen würde? Kann man diese Profile in FSLogix Container kopieren und bereitstellen? Oder werden diese Profile gelöscht?

    2. Ich nutze Folder Redirection. Wie kann ich das FSLogix beibringen? Konnte hierfür keine Infos finden.

     

    Danke

  3. Liebe Community,

     

    nach einigen Tests konnte ich folgendes feststellen.

     

    Leider konnte ich per Assoc.xml die Zuordnung der Default Apps für die User nicht definieren. Die GPO greift sauber. Aich die XML wurde gefunden. Leider wird für die RDP User der Standard micht überschrieben

     

    Ich kann dieses Problem nur lösen, wenn jeder User seine Standard Apps einmalig selber definiert. Das muss natürlich pro Server gemacht werden, da ich aktuell keine Roaming Profile nutze. 

     

    Wer hat für mich noch weitere Tipps zu dem Thema Standard Apps per XML.

     

    Jetzt habe ich aber auch gute Nachrichten.

     

    Ich konnte das Problem mit der Ständigen Passwort Abfrage von Outlook ermitteln. Outlook war bei jedem User im Online Modus eingestellt. Es gibt keine Lokale ost Datei. Dadurch hat der User sich bei jedem starten von Outlook erneut an O365 angemeldet. Ist ja Logisch. Nur kann ich dieses Problem jetzt erstmal nicht dauerhaft lösen da ich keine Roaming Profiles nutze. 

     

    Darüber Hinaus konnte ich durch das manuelle setzen des Standard Browsers, dass Problem mit der Sicherheitseinstellung lösen. Wenn kein Standard Browser gesetzt ist, dann ist der IE der Standard. Der lässt es aber Default nicht zu, dass Hyperlinks aus Outlook heraus geöffnet werden.

     

    Soll ich diesen Thread schließen und einen eigenen Thread bzgl. Standard Apps aufmachen? Was sagt Ihr dazu.

     

    Danke

     

     

  4. Guten Morgen Community,

     

    wir betreiben bei uns eine RDP Farm zu der ich eine Fragen im Kopf hab, die Ihr mir eventuell beantworten könnt.

     

    Folgendes ist gegeben

     

    1. Betriebssystem Server 2016

    2. 5 virtuelle Server

    3. 1 Connectionbroker (ein 2. CB für das HA ist geplant)

    4. 3 Sesseionhosts

    5. 1 Lizenzserver

    6. Der Connection Broker ist auch gleichzeitig als Webacces Server konfiguriert

    7. DNS Einträge sind gesetzt

    8. Wir arbeiten ausschließlich mit Sessions. Kein Webaccess und keine VDI

     

    Die Server sind allesamt in einer eigenen OU. Dieser OU sind diverse GPOs zugewiesen. Unter anderem werden viele Einschränkungen mit GPOs gesetzt. Z.B. Laufwerke ausblenden, ausführen von Programmen wie cmd, powershell etc. unterbunden.

    Wir arbeiten nicht mit Roaming Profilen und UPD

    Ordnerumleitung ist eingerichtet und die umgeleiteten Ordner werden per DFS auf einen weitere File Server repliziert.

     

    Auf den Session Hosts sind diverse Programme installiert. Unter anderem der Firefox, Office 2019 Standard (Volumenlizenz) etc.

     

    Allesamt funktioniert die Farm sehr gut. Ich habe nur kleinere Probleme mit den installierten Anwendungen.

     

    1. Die TS Benutzer können den Firefox nicht als Standard Browser setzen. Jedesmal wenn der Firefox gestartet wird, kommt eine Aufforderung von Firefox für die Standardeinstellung. Kann dieses Verhalten durch den Einsatz einer FileAssoc.xml die ich per GPO an die Sessionhost verteile gelöst werden.

    2. Bisher hat sich keine Benutzer darüber beschwert, dass Ihm LEsezeichen und gespeicherte Passwörter im Firefox fehlen. Dadruch das wir keine Roaming Profile einsetzen, sollte das doch früher oder später der Fall sein oder? Es wird ja das AppData\Local verezichnis nicht über alle SessionHosts gesynct.

    3. Wenn die Benutzer Outlook starten dann werden die User aufgefordert, Ihre Passwörter für die O365 Accounts einzugeben. Wir nutzen Exchange Online. Wir haben keinen aktiven Sync zwischen Azure AD und OnPrem AD. Die USer wurden einmal zu O365 gesynct und die Postfächer erstellt. Bitte siehe auch Screenshot. Hängt dieses verhalten eventuell damit zusammen, dass wir Office 2019 falsch lizensiert haben? Muss ich auch den Session Hosts in der Registry zusätzlich einen Wert für SharedComputerLicensing setzen (eventuell per GPO)?

    4. Wenn die User versuchen einen Link aus einer Mail heraus zu öffnen, wird folgender Fehler angezeigt "Die Richtlinien Ihrer Organisation verhindern, dass diese Aktion abgeschlossen werden kann. Wenden Sie sich an Ihr Helpdesk". Hängt dieses verhalten eventuell damit zusammen, dass die USer keinen Standard Browser definieren können und der IE diese Aktion nicht zulässt.

     

    Ich danke euch jetzt schonmal für eure hilfreichen Tipps.

     

    Bildschirmfoto 2021-05-28 um 09.26.17.png

    Bildschirmfoto 2021-05-28 um 09.36.17.png

  5. 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.

  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. vor 42 Minuten schrieb djmaker:

    Ich glaube Frank hat deine Situation hier beschrieben:

     

    https://www.msxfaq.de/exchange/autodiscover/autodiscover_sonderfaelle.htm

    Hi djmaker,


    sieht danach aus. Ich werde der sache mal nachgehen.

     

    vor 10 Minuten schrieb Nobbyaushb:

    Dann ist das kein von extern ausgestelltes Zertifikat - oder Split-DNS passt nicht.

     

    Müssten man aus beiden Umgebungen einmal sehen

     

    Wie groß sind die jeweils?

     

    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

  8. 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

    Bildschirmfoto 2020-06-10 um 12.34.44.jpg

  9. 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

     

  10. vor 1 Stunde schrieb testperson:

    Ja, das sollte machbar sein. "Netzwerkname nicht gefunden" deutet erstmal auf Probleme mit der Namensauflösung hin. Wie versuchst du denn zuzugreifen?

    Die neue bzw. weitere Frage packst du am besten in einen eigenen Thread mit passendem Titel, dann schauen sich das sicherlich auch User mit DFS Know-How an.

    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

    vor 51 Minuten schrieb daabm:

    Mehr braucht's eigentlich nicht - wendet der RDS die GPO auch an?

    Und wegen DFS: Gehst Du auf den FQDN oder nur Netbios als "Server"-Name?

    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.

  11. vor 12 Stunden schrieb djmaker:

    Das Stichwort lautet "loop back". Ich hoffe das gilt noch für Server 2016. In folgendem Artikel ist das hervorragend beschrieben:

     

    https://www.gruppenrichtlinien.de/artikel/loopbackverarbeitungsmodus-loopback-processing-mode/

     

    "Die Herausforderung:
    Ich muss die Richtlinie irgendwie auf das Computerkonto anwenden? Aber der Computer ignoriert den Anteil der Benutzerkonfiguration einer Richtlinie, da er ja schliesslich ein Computerobjekt ist und kein Benutzer. Ebenfalls, ist dem anmeldenden Benutzer die Benutzerkonfiguration einer Richtlinien auf dem Computerobjekt egal, da der Benutzer die Computerkonfiguration garnicht liest, und damit am Ende die Richtlinie, nicht übernehmen kann. Es kommt noch hinzu, daß der Benutzer meistens nicht in der OU des Computers steht, damit nicht im Verwaltungsbereich der Richtlinie ist und er somit die GPO generell nicht anwenden kann."

    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

  12. 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

    vor 13 Minuten schrieb testperson:

    Hi,

     

    wenn es sich hier um RDSH mit Windows Server 2016 oder 2019 handelt wird das Problem sein, dass den RDSHs die Einstellungen im AD-Objekt des Benutzers erstmal egal sind: https://support.microsoft.com/en-us/help/3200967/changes-to-remote-connection-manager-in-windows-server

     

    Generell würde ich nur das Nötigste im AD-Objekt konfigurieren und so viel wie möglich per GPO erledigen. Bei RDSH Profilen würde ich aber auch direkt in Richtung FSLogix schauen.

     

    Gruß

    Jan

    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

  13. Hallo zusammen,

     

    wir haben eine Bidirektionale Vertrauensstellung zwischen Domäne A und Domäne B. Der Trust funktioniert hervorragend. Damit Ihr mein Problem besser versteht, nenne ich meine Domäne A und die Remote Domäne B.

     

    Ich habe bisher nicht viel getestet, da ich schon beim ersten Test bzw. meinem eigentlichen Ziel nicht weiter komme.

     

    In unserer Domäne, also Domäne A wird für die Domäne B ein RDS Server bereit gestellt, damit bestimmte User Applikationen die in Domäne A bereitgestellt werden, nutzen können. 

     

    Der RDS Server ist vollständig konfiguriert und Logins von Benutzern aus der Domäne A samt dem mapping von Laufwerken (auch Home Laufwerk), Umleitung von Ordnern wie "Desktop, Download usw." funktioniert per GPO wunderbar. Ich habe keine Servergespeicherten Profile für die User in Dom A konfiguriert. In Dom B sind auch keine Servergespeicherten Profile konfiguriert.

     

    Ich habe noch eine weitere GPO für den RDS in Dom A mit folgender Einstellung konfiguriert -> Gesamtstrukturübergreifende Benutzerrichtlinien und Servergespeicherte Profile zulassen

     

    Ich habe in Domäne B einen Test user "test" erstellt und diesen User in eine Globale Sicherheits- Gruppe in Dom B rein geschoben. Diese Gruppe ist Mitglied in einer Lokalen Gruppe in Dom A und diese Lokale Gruppe hat das Recht, sich am RDS Server anzumelden.

     

    Der "test" User aus der Dom B hat ein Home Verzeichnis unter dem Reiter "Remotedesktop-Dienste Profil" in den Eigenschaften des Users eingestellt (Laufwerksbuchstabe P). Auch hat er ein Home Laufwerk unter dem Reiter "Profil" mit dem Laufwerksbuchstaben H konfiguriert. Beide Homelaufwerke zeigen auf verschiedene Ordner auf dem gleichen Server. Der "test" User hat Vollen Zugriff auf beide Ordner.

     

    -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

    Oben habe ich mal grob meine Konfiguration beschrieben.

     

    Mein Problem liegt darin, dass das Home Verzeichnis (weder H noch P) beim Login am RDS Server in Dom A nicht gemappt werden. Mappe ich die Laufwerke über cmd, komme ich ohne weiteres dran.

     

    Ich weis, ich habe hier einen Denkfehler oder ich habe etwas vergessen zu konfigurieren. Ich vermute mal, dass ich in der Remote Domäne B eine GPO konfigurieren muss, damit die Laufwerke übernommen werden, oder so ähnlich.

     

    Habt Ihr vielleicht einen Tipp für mich, wie ich hier vorgehen kann?

     

    Danke

     

     

  14. vor 11 Stunden schrieb daabm:

    Waren da Berechtigungen auf Registry "RPC" mit drin? Dann kann ich das Verhalten bestätigen, das haben "hochqualifizierte Admins" früher gerne gemacht. Inzwischen sind aber neue Standardgruppen dazu gekommen (konkret "Alle Anwendungspakete"), und wenn die fehlen, tritt der von Dir beschriebene Fehler auf. Woher ich das weiß? Hab selber so eine GPO geerbt...

    Hi daabm,

     

    da waren tatsächlich Berechtigungen auf Registry "RPC" mit enthalten. 

     

    Ich hatte die GPO gestern deaktiviert. Es hat sich bisher keiner meiner Kollegen beschwert. Ich vermute tatsächlich, dass das für unsere früheren Win 2000 Clients gebaut wurde.

     

    Aus diesem Grund würde ich sagen, hat sich das Thema zum Glück erledigt :applaus::thumb1::victory:

  15. vor 4 Minuten schrieb MurdocX:

    Manchmal muss man einfach "Eier" beweisen und alte Hüte entfernen;-)

     

    vor 6 Minuten schrieb testperson:

    Das ist dann wohl die Lösung für Leute "mit Eiern". ;)

     

    Ggfs. solltest du im GPO erstmal gucken, was da überhaupt konfiguriert ist. Eine etwas weichere Lösung könnte sein, per WMI Filter oder per Berechtigungen die Win10 Clients erstmal auszuschließen.

    Jungs genau so ist es. Nein scherz bei Seite. Klar sind zwar "Eier" zu haben gut, aber ich habe mir die gpo mal angesehen und da sind diverse Einstellungen die die Registry betreffen. Ich habe auf meinem Win 7 Rechner geschaut und viele der Einstellungen garnicht gefunden. Wars***einlich alles Einstellungen von Win 2000 oder so.

     

    Ich warte jetzt aber trotzdem ab. meine Kollegen haben Verständnis bei kleineren Aussetzern ;-). Wenn ihr die GPO Einstellungen sehen wollt, kann ich es gerne einmal posten

×
×
  • Neu erstellen...