wznutzer

Guten Abend, Szenario 2 oder 3 RDSH Es sollen keine UPD oder FSLogix verwendet werden. Es braucht kein Loadbalancing, es ist völlig ausreichend, wenn die User „fest“ einem RDSH zugeordnet werden. Deswegen fest, weil die User ohne UPD ja kein konsistentes Profil hätten. Warum keine UPD? Ich brauche es in diesem Fall nicht und somit ist jedes zu lösende Problem das mit UPDs entstehen würden eines zu viel. Außerdem sind dann keine bisher automatisierten Offline-Scans mit Virenscanner, Thor usw. nicht mehr möglich, bzw. die UPDs müssten vorher gemountet werden. Wie lösen? Ich mache pro RDSH eine Sammlung. In dieser Sammlung sind die User für diesen RDSH und der zugehörige RDSH. Die User geben als Ziel den Namen des RDS-Connection-Broker an und dieser weist die User der entsprechenden Sammlung und somit dem RDSH zu. Sollte der User tatsächlich mal einem anderen RDSH zugewiesen werden werden, ändere ich einfach die Zuweisung, aber der User muss nichts anderes bei der Anmeldung machen. Denke ich hier richtig oder muss das anders konfiguriert werden, damit es sinnvoll ist? Schönen Abend

Guten Abend, entschuldigt, wenn ich diesen Thread nochmals rauskrame. Ich habe mir einige Videos von Manfred Helber und Sven Langenfeld angesehen. Unter anderem die Erklärungen zu den Remote-Desktop-Services. Da wurde mehrfach gesagt, dass der RDS-Lizenzserver nicht auf einem RDS-Sitzungshost supportet wird. Ich finde das hier: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/welcome-to-rds nicht. Aber wo wenn nicht da sollte es stehen. Ich meine, das kann ja keine Geheiminformation sein, die nicht dokumentiert ist. Die Info ist das eine, aber woher bekommen MVPs solche Informationen. Doku lesen reicht anscheinend nicht. Stimmt das und überwacht Ihr tatsächlich alle möglichen Kanäle, Blogs usw. um an solche Infos zu kommen? Danke und Grüße

So einfach? Prima! Sind denn die Remote-Postfächer nicht auf dem alten Exchange gespeichert die irgendwie übernommen werden müssen. Stehen all diese Infos in den AD-Attributen? Da Du explizit deinstallieren schreibst, sollte man den Server dann wohl nicht einfach offline nehmen, nehme ich an. Meinst Du die Variante wenn man "nur" Powershell verwenden will, also die Management-Shell isoliert zu installieren und, wenn man will, die GUI von Steve Goodman oder geht das jetzt irgendwie ohne das alles? Das wäre an mir durchgegangen. Vielen Dank

Guten Tag, man braucht ja einen lokalen Exchange wenn man z. B. die Konten zu Azure synchronisiert (AD Connect). Nun habe ich noch einen lokalen Exchange 2016, der keine Postfächer mehr hat und nur noch für die Verwaltung bzw. als Relay da ist. Inzwischen gibt es ja den Exchange 2019 für dieses Szenario kostenlos. Da der Exchange 2016 noch auf einen W2K12R2 läuft will ich den weg haben. Nun, ich kenne die Migration für einen normalen On-Prem Exchange, aber nicht für einen Hybrid, der eigentlich nichts mehr tut. Mir will es nicht gelingen ein "best practice" von Microsoft zu ergoogeln. Kann mich hier irgendwer etwas in die richtige Richtung schieben wie das zu machen ist (Link / Stichwort). Evtl. genau so wie eine "normale" Migration? Vielen Dank und Grüße

Hallo, gibt es eine Möglichkeit eine im Spamfilter (EOP) freigegebene Email wieder zurückzurufen? Microsoft selber macht das ja, bzw. man kann das aktivieren, dass zugestellte Emails deren Anhänge nachträglich als schadhaft erkannt werden wieder aus dem Posteingang entfernt werden. Aber kann ich das auch manuell auslösen? Danke und Grüße

Das wichtige Wort hier ist wohl *Zeitbeschränkungen*. Beim Zurücksetzen kann ich mich darüber hinwegsetzen, aber nicht über die Längen- und/oder Komplexitätsrichtlinien. So jedenfalls gerade getestet.

Guten Morgen, ich will mal versuchen alle Fragen zu beantworten. Ja, ganz sicher als lokaler User angemeldet. Ich will ja auch das Passwort des lokalen Administrator ändern. "net accounts" hatte ich zum damaligen Zeitpunkt noch nicht geprüft, zwischenzeitlich aber "net user Administrator". Da hat es dann auch Klick gemacht. Auflösung (wahrscheinlich) Wenn ich W2K22 über Lenovo XClarity installiere, gibt mir "net user Administrator" Kennwort änderbar 1 Tag in der Zukunft aus. Das letzte Setzen des Kennworts ist der Installationszeitpunkt. Somit müsste das minimale Kennwortalter auf 1 stehen. Nach einen gpupdate /force ist Kennwort änderbar nicht mehr 1 Tag in der Zukunft und ich kann das Kennwort ändern. "net accounts" habe ich erst nach dem gpupdate /force durchgeführt, ich kann nicht sagen was vorher war. Nach gpupdate /force wird die Domänenrichtlinie angezeigt. Nicht erklären kann ich mir, warum ich das Kennwort über die Computerverwaltung setzen konnte. Nach dem gpupdate /force verhält sich die Kennwortänderung über die Computerverwaltung gleich wie über STRG + ALT + ENTF. Das kann ich nun nicht nachvollziehen. Das Computerkonto ist in "Computers", die Kennwortrichtlinie ist auf Domänenebene verlinkt. Ich kann aber für *lokale* Konten keine Kennwörter vergeben die gegen diese Richtlinie verstoßen. Evtl. übersehe ich was, aber es sieht so aus als ob die Richtlinie auch für Computerkonten in Computers verarbeitet und durchgesetzt wird. Ich habe das gerade noch mit einer frischen W10 VM versucht, auch da ist es so. Testweise habe ich mal die Passwortlänge hochgesetzt ==> gpupdate /force ==> es werden keine Kennwörter für lokale Konten mit kleinerer Länge akzeptiert. "net accounts" zeigt mir dann auch die neue größere Länge an. Vielen Dank für eure Mühe

ISO, frisch aus einem Visual Studio Abo inkl. August Updates und dann die Oktober-Updates installiert. Aber die Installation erfolgte über XClarity von Lenovo. Ja, aber die Kennwortrichtlinie ist auch auf oberster Ebene verlinkt. Wenn das nur bei mir auftritt muss der Fehler ja auch zu finden sein. Ich werde noch etwas graben.

Komplexität: ein Historie: 24 umkehrbare Verschüsselung: nein max. Kennwortalter: 0 Kennwortlänge: 14 min. Kennwortalter: 0 nach 7 ungültigen Versuchen 20 Minuten gesperrt. Edit: Überall sonst geht es (W10, W11, W2K12R2, W2K16, W2K19). Irgendwas ist da verbogen. Danke und Grüße

Guten Abend, gegeben: W2K22 | Domänenmitglied | frisch installiert | Passwort für *lokales* Adminkonto (Administrator) soll geändert werden. Beim Versuch das Passwort über STRG + ALT + ENTF zu ändern erscheint immer die Meldung, dass das Passwort nicht geändert werden kann, weil es gegen die Domänenrichtlinien verstößt. Das ist aber ganz sicher nicht der Fall. Weder Länge, Komplexität, Historie, Teil des Anmeldenamens. Über die Benutzerverwaltung lässt sich das neue Passwort problemlos setzen. Weder direkt an der Konsole (auf dem Blech direkt angemeldet) oder über RDP. Funktionslevel der Domäne ist W2K12R2. Klar, ich kann das Passwort über die Benutzerverwaltung setzen oder auch vor dem Aufnehmen in die Domäne. Aber warum geht das nicht? Bug in W2K22? Grüße

Hier wird das erklärt: https://learn.microsoft.com/en-us/exchange/mail-flow/accepted-domains/accepted-domains?view=exchserver-2019 Wenn ich dich richtig verstehe willst du einfach beliebig viele Adressen für den Empfang haben. Wie hier beschrieben machst Du das über "shared" Postfächer oder einfache SMTP-Adressen bei den User. "Shared" Postfächer können auch senden, dann müssen diese aber lizenziert werden. Falls Dein Problem das Senden der ganzen Email ist, also deine Überwachung, kannst du ja das zentral von einem Account aus machen, der ja nicht unbedingt bei O365 liegen muss. Da SMTP Auth bei Microsoft in Ungnade gefallen ist, willst Du das evtl. sowieso außerhalb O365 senden. Grüße

OK danke, verstanden.

Auch das kann ich nachvollziehen, genau wie wenn man alles auf einzelne Server packt. Was würde dagegen sprechen zum Broker und RDWeb noch die Lizenzen zu packen? Ich will es nur verstehen? Grüße und Danke

Ja, zur Veröffentlichung. Es ist zwar noch ein Reverse-Proxy vor dem Gateway, aber das will ich beibehalten. Dass man das Gateway und WebAccess auf eine VM packt und sonst nichts, kann ich nachvollziehen. Aber warum ich den Broker zwar auf einen DC packen kann aber nicht zusammen mit dem Lizenz-Server auf eine VM, verstehe ich nicht .

Die Motivation ist, wie Du Dir denken kannst, einmal die Lizenzen für das OS zu sparen und keine zusätzlichen VMs zu haben die kaum etwas zu tun haben. Würdest Du das so machen, weil du mit anderen Szenarion schlechte Erfahrungen hast oder als Prophylaxe um Probleme zu vermeiden. Mein jetziger Gateway hat kaum etwas zu tun und WebAccess wird wahrscheinlich nur verwendet um die RDP-Datei für die Farm runterzuladen. Aber klar, wenn es sein muss, muss es sein.

Guten Tag zusammen, ich plane gerade eine RDS-Farm: ca. 100 User, 3 Session-Hosts. HA ist nicht notwendig. Wir haben folgende Rollen: RDS Connection Broker RDS Gateway 3x RDS Session Host RDS WebAccess RDS Lizenz-Server Microsoft schreibt dazu: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-roles?source=recommendations RDS Connection Broker kann auf einen DC. (Würde mir jetzt nicht so gefallen) RDS Gateway und RDS WebbAccess kann kombiniert werden. RDS Lizenz-Server kann auf einem File-Server installiert werden. Ich finde bei MS leider nicht was tatsächlich zusammen supportet wird und was gar nicht zusammen geht. Wäre es z. B. denkbar und gut alle Rollen (RDS Con. Broker, Gateway, WebAcess und Lizenz) außer die Session Hosts auf einen Server zu installieren? In meinem Szenarion wäre das: 1 x Server mit RDS Con. Broker, Gateway, WebAcess und Lizenz 3 x Server -> Session Host Derzeit sind alle User auf einem Server mit allen Rollen (W2K12R2). Nur das Gateway ist separat. Vielen Dank für eure Meinungen.

OK => https://docs.microsoft.com/de-de/powershell/module/exchange/set-sendconnector?view=exchange-ps Merker für mich: Man sollte sich dann wohl nicht auf die in der UI angebotenen Optionen verlassen.

Man muss da noch was ergänzen: Der Haken TLS im Empfangsconnector erlaubt "nur" TLS, erzwingt es aber nicht. Man kann trotzdem unverschlüsselt intern Mails versenden. Ohne separat angelegten Sendeconnector funktioniert auch der Versand von intern zu intern nicht bei Minimalhybid und Modern Topology. Man braucht einen Sendeconnector beim lokalen Exchange der z. B. als Smarthost nach firma.mail.protection.oulook.com routet. Dann braucht es in O365 auch einen Empfangsconnector. An vielen Stellen im Internet ist zu lesen, dass O365 "nur" noch Verbindungen mit TLS 1.2 annimmt. Das ist falsch. Richtig ist, dass verschlüsselte Verbindungen "nur" noch mit TLS 1.2 angenommen werden. Unverschlüsselt geht noch immer, steht auch hier (erster Hinweis): https://docs.microsoft.com/de-de/microsoft-365/compliance/prepare-tls-1.2-in-office-365?view=o365-worldwide Im Sendeconnector kann man nichts mit TLS einstellen. Wenn man aber das Logging aktiviert, kann man sehen, dass der Exchange STARTTLS verwendet. >> TLS protocol SP_PROT_TLS1_2_CLIENT negotiation succeeded using bulk encryption. Grüße

Damit das funktioniert hat, mussten ein paar Dinge gemacht werden. Nichts konnte ausgelassen werden. Alles ist notwendig. Evtl. hilft es auch jemandem anderen. Sophos blockiert standardmäßig Autodiscover extern. Die URLs von hier https://support.sophos.com/support/s/article/KB-000038173?language=en_US helfen nicht. Man muss autodiscover.firma.com und autodiscover.firma.mail.onmicrosoft.com in die Exceptions aufnehmen. Es ist unklar warum Sophos das blockiert. ExcludeHttpRedirect auf 0 (war 1), ExcludeLastKnownGoodURL auf 1, ExcludeExplicitO365Endpoint auf 0. Unklar wo die Keys, außer ExcludeExplicitO365Endpoint, herkommen. Wurden nicht absichtlich gesetzt. HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover gab es einen Unterschlüssel RedirectServers mit zwei Einträgen. Diesen löschen, wird beim Start von Outlook dann mit 6 anderen Einträgen neu generiert. Mit den zwei vorhandenen Schlüssel funktioniert es nicht. Split-DNS für Autodiscover entfernen. Die Profile bleiben auch so erhalten und die OST wird nicht neu generiert. MFA muss für die Zeit der Profiländerung deaktiviert werden. MFA funktioniert nur mit Office365 nicht mit 2016 Zusammen mit SSO muss der Nutzer dann nichts machen, außer Outlook starten. In manchen Profilen bleibt der Microsoft Anmeldedialog (OAuth?) auf und der Vorgang bleibt stehen. Dann muss darin auf „anderen Usernamen“ geklickt werden und die Email-Adresse eingegeben werden. Dann nämlich will sich Outlook mit dem @firma.local zu O365 verbinden. Windows 10/11 mit Office 365 macht keinerlei Probleme, das funktioniert einfach, auch wenn die Sophos Autodiscover blockiert. Windows 10 mit Office 2016 braucht die gleichen Streicheleinheiten. Die Registry-Keys für TLS 1.2 waren auf dem Exchange (W2K12R2) für den HCW nötig. Aber auf einem RDP Host nicht, bzw. ändern nichts. Schaden aber auch nicht, so wie es scheint. Grüße

Hilft leider nicht. Die Registry-Keys für TLS 1.2 habe ich gesetzt. Die wollte auf dem Exchange auch der HCW haben: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v2.0.50727] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v2.0.50727] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 Es scheint ein Office 2016 mit Windows 2012 R2 Problem zu sein . Wenn ich das Autodiscover.xml direkt aufrufe, erscheit zuerst eine Passwortabfrage und dann das xml mit Error 600 <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response> <Error Time="11:21:20.2318216" Id="1596708203"> <ErrorCode>600</ErrorCode> <Message>Ungültige Anforderung</Message> <DebugData/> </Error> </Response> </Autodiscover> Intern zeigt Autodiscover noch immer per Split-DNS auf den lokalen Exchange.

Guten Morgen, woran könnte es liegen, dass manche Clients (W2K12R2 RDP-Hosts mit Office 2016) sich nicht per Autodiscover zu Exchange-Online verbinden? Postfach ist migriert Batch ist abgeschlossen Outlook neu gestartet Der Client verbindet sich weiterhin mit dem lokalen Exchange. Folgender Key war bisher gesetzt, wurde jetzt aber entfernt. HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\outlook\autodiscover DWORD: ExcludeExplicitO365Endpoint Folgender Key soll man lt MS setzen, bringt aber auch nichts. https://docs.microsoft.com/en-US/outlook/troubleshoot/profiles-and-accounts/cannot-connect-web-service-not-working-migrated-to-office-365 HKEY_CURRENT_USER\Software\Microsoft\Office\<x.0>\Outlook\Autodiscover DWORD: ExcludeLastKnownGoodUrl Im lokalen DNS zeigt autodiscover.domain.de noch auf den lokalen Exchange. Aber manche Clients (vorwiegend W10 mit O365) machen den redirect. Habt Ihr einen Tipp? Grüße

Weil ich gerade im Sendeconnector nichts mit "TLS erzwingen" anklicken kann, war ich mir da nicht sicher ob das vom Empfangsconnector durchgereicht wird. Ich habe gar keine Hybrid-Connektoren . Da wurde vom HCW nichts angelegt. => Minimal-Hybrid mit Modern Topology. Evtl. liegt das aber daran, dass der lokale Exchange nicht direkt empfängt oder sendet. Der Exchange empfängt von einem Archivsystem und sendet dahin. Also ich hatte schon immer die akzeptierte Standarddomain auf "internes Relay" stehen und der einzige Sendeconnector sendet alles vom Adressraum "*" an einen Smarthost (Archivsystem). An den Smarthost natürlich nur was nicht der "eigenen Domain" entspricht.

So werde ich das probieren. Um alle Knoten im Kopf wegzuhaben, brauche ich immer ein vollständiges Bild im Kopf warum und wie alles miteinander funktioniert. Danke für die Tipps.

Ja, ein lokaler Exchange ist vorhanden, derzeit noch 2016 aber wird wahrscheinlich künftig ein 2019 werden. Ich klicke manchmal lieber als alles per Powershell zu machen. ==> Verwaltung von ExO. Beim jetzigen Exchange als lokales Relay habe ich noch einen Knoten im Kopf. Es gibt lokal keine Postfächer mehr und am liebsten würde ich auch die DB weghaben. Die liegt ja nur noch nutzlos rum. Das steht aber noch an. Liege ich so richtig: 1) Ich benötige zuerst bei den akzeptierten Domänen eine Domäne die ich dann als Absender verwende und auf "internes Relay" stelle. 2) Beim Empfangsconnector hake ich TLS und anonyme Benutzer an und gebe die Bereiche und den Port an. Somit sollte die Verbindung Client zu Relay verschlüsselt sein. 3) Der Sendeconnector sendet dann für den Adressraum "*" direkt an den MX oder über einen Smarthost an smtp.office365.com. Beim Smarthost kann ich "Standardauthentifizierung erst nach dem Start von TLS" anhaken, aber beim Senden an den MX nicht. Wenn ich den Authentifizierten Versand über den Smarthost mache, benötige ich einen User mit aktiviertem SMTP und den dann gültigen Limits wie 30 Nachrichten pro Minute. Wenn ich an den MX sende, kann ich TLS nicht anhaken. Irgendwas habe ich noch nicht verstanden .

Guten Tag, was ist "best practice" wenn lokale Anwendungen Emails versenden sollen? Gegeben ist Exchange mit Hybrid-Bereitstellung. Microsoft sieht 3 Möglichkeiten vor: https://docs.microsoft.com/de-de/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365 oder auch hier (etwas ergänzt) https://www.msxfaq.de/cloud/exchangeonline/multifunktionsgeraet_mit_exo.htm Am sympathischsten ist mir das mit dem Relay in Office 365. Alles funktioniert prima und die Limits von 30 Nachrichten pro Minute oder das Hantieren mit "send as" wie beim SMTP-Versand entfällt. Allerdings finde ich keine Möglichkeit verschlüsselte Verbindungen (TLS) zu erzwingen. Wenn der Client es macht dann geht es, ansosten nicht. Geht es irgendwie TLS zu erzwingen? Die Verbindung ist ja auf die feste IP beschränkt. Das bedeutet man muss im Netzwerk dafür sorgen, dass niemand Unsinn macht. Also z. B. die Verbindung über Port 25 nur von bestimmten Clients aus zulassen. Am besten würde mir die Kombination von O365 SMTP Relay gefallen das aber eine Authentifizierung erfordert. Gibt es das? Vielen Dank