wznutzer

Falls jemand später mal noch den Thread liest, die Excludes für Roaming Profiles sind wohl hier angegeben: HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:ExcludeProfileDirs Gibt es andere Gründe als die Größe der OST? Lt. meinen Erfahrungen hat Outlook (auch mit den neuesten Versionen) immer mal wieder kleine Hänger wenn der Cache-Mode abgeschaltet ist. Nicht schlimm, aber wenn es besser geht, warum nicht?

Bei mir auch . Wird nicht auch AppData komplett bei den Roaming Profiles hin und her kopiert? Ich muss mir das doch mal wieder genau anschauen, wenn auch nur um das Wissen mal wieder aufzufrischen. Es ist schon einige graue Haare her als ich das das letzte Mal genutzt habe . Edit: Du hast Recht. Gerade nachgelesen, AppData\Local wird per Default ausgeschlossen.

OK Danke. Also bleibt nur der harte Weg die Cmdlets, Befehle oder Registry Keys einzeln zu recherchieren. Um die zu den GPOs zugehörigen Keys rauszufinden könnte das Tool RegistryChangesView von Nir Sofer hilfreich sein.

Was meinst Du? Die Probleme die meist mit wechselnden PCs, unterschiedlichen Updateständen, Mehrfachlogins aufgetreten sind, eher nicht. Aber die langen Login/Logout Zeiten bleiben. Alleine schon die *.ost vom Outlook ist teilweise mehrere GB groß. Das bedeutet, bei jedem Login/Logout einen Nachteil. Aber nur einen Vorteil wenn der User mal wirklich den Server wechseln soll. Ich rechne damit, dass das nach einer erstmaligen Zuordnung kaum noch, evtl. 10 Mal im Jahr, vorkommt. Sowohl Ordnerumleitung als auch FSLogix habe ich angeschaut. Aber auch hier ist das Hauptargument, dass ich das nicht brauche und ich damit rechne, dass ich evtl. 10 User pro Jahr umziehen muss. Sollte meine Annahme aber nicht stimmen, wäre FSLogix die erste Wahl. Das kann ja auch mit dem Suchindex und den O365 Sachen umgehen und ein kleines Progrämmchen um bestehende Profile zu migrieren ist ja auch dabei. Das wäre Plan B. Mir ging es in erster Linie darum, ob mein Verständnis der Zuordnung richtig ist. Vielen Dank für eure Anmerkungen

Guten Tag, ich würde gerne Einstellungen von Serverinstallationen oder auch Arbeitsplätzen automatisieren. Ich meine weniger die Automatisierungstools wie Ansible, Puppet, sondern eher low level mit einem Powershell-Script. Gerne auch etwas anderes. Es will mir nicht gelingen eine Referenz-Doku von Microsoft zu finden in der das beschrieben ist. Gibt es das überhaupt oder gibt es nur den steinigen Weg alles einzeln zu recherchieren und die einzelnen Programme zu nutzen die es sowieso schon in der Eingabeaufforderung (z. B. netsh, powercfg, wmic) gibt? Schöne Grüße

Guten Tag, Roaming-Profile . Ich bin ja nur der 20% Admin, aber wenn das noch so funktioniert wir damals unter NT 4.0 (oder war es schon W2K?), lieber nicht. Oder funktioniert das zwischenzeitlich robust und problemlos? Aber klar, Du hast Recht. Man braucht einen Plan in der Tasche um ein Profil zu kopieren. Auf meiner "Musst Du Dir mal anschauen Liste", steht da der User Profile Wizard von ForensIT. Ansonsten funktionierte bei mir schon folgende Vorgehensweise: Backup mit Veeam Profil per Anmeldung anlegen lassen File-Restore mit Veeam Aber das ist natürlich nur praktikabel wenn die Neuzuordnung wenige Male im Jahr vorkommt. Ansonsten bin ich auch für Tipps dankbar wie man problemlos Profile kopieren kann. Vielen Dank und eine schöne Woche

https://youtu.be/qmvM-yzLWiY?t=452 Bei mir funktioniert das problemlos (Lizenz + Session Host auf einer VM). Nur bei einem Neustart erscheint eine Meldung, dass kein Lizenzserver vorhanden ist. Das liegt aber daran, dass einige Dienste auf "verzögert" stehen. Nach spätestens 3 Minuten ist alles OK. Das mit der QuickStart-Bereitstellung ist allerdings ein ziemlich gutes Argument . Danke euch.

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