cj_berlin

Moin, der Upgrade-Weg ist genau richtig, Vermutlich hat sich da zeitlich etwas überschnitten - oder Du hast einen der virtuellen Verzeichnisse auf dem neuen Server vergessen. Ein heruntergefahrener Exchange-Server sollte kein dauerhafter Zustand sein, das macht mehr Probleme als Zertifikatswarnungen bei Usern.

Das ist natürlich unzutreffend, denn SQL-Lizenzen sind a. downgradefähig und decken b. viele Instanzen, solange sie auf der lzenzierten Hardware koexistieren. Kaum. Der SQL-Installer wird keine gleichnamige Instanz erstellen, nur wenn die bereits existierende Instanz gleichen Namens gerade nicht läuft oder deaktiviert ist. Generell sind zwei Dienste gleichen Namens in Windows eher schwierig.

Hmm. Die würde ja beim Ausstechen genauso verschoben werden wie beim Einstechen - wenn in der Realtiät exakt 8 Stunden (09:00-17:00) vergehen, dann auch in der Zeiterfassung (09:01-17:01) Aber dennoch muss es natürlich korrigiert werden. Der Hinweis von @NorbertFe auf die Konfiguration per GPO ist goldrichtig. Dennoch muss manchmal die betroffene Maschine rebootet werden, damit die Konfiguration greift.

Office 365 Tenant-to-Tenant Migration Tools | On Demand Migration (quest.com)

Da muss man ja miteinander reden... Ich dachte, wir machen hier IT

doch, doch: Besonders der zweite Satz im Kasten ist geil

Moin, ich würde, bevor ich weiter forsche, folgende Versuchsanordnung anfertigen: eine VM so installieren, wie Du Infrastruktur-VMs installierst, also vermutlich eher mit wenig drauf, aber inklusive Browser der Wahl. 2vCPU / 8GB RAM sollten reichen. syspreppen und klonen beide zum AD hinzufügen, in der gleichen OU platzieren auf einer VM nur die RDSH-Rolle hinzufügen und Lizenzierung konfigurieren. A/B-Vergleich. beispielsweise mit Video im Browser oder auch mit dem Task Manager, machen. Wenn hier bereits einer der von Dir beschriebenen Unterschiede besteht, kann man anfangen das gezielt zu untersuchen . PerfMon, ProcExp usw. Denn der einzige wirkliche Unterschied hier ist ja die Umschaltung von Hintergrund- auf Vordergrund-Verarbeitung mit der Aktivierung der RDSH-Rolle. Ich glaube allerdings nicht, dass diese Art Troubleshooting im Rahmen eines Internet-Forums sinnvoll begleitet werden kann. Eins kann ich Dir allerdings mitgebebn: Es ist kein Problem, das ALLE Server 2019-Terminalserver haben, da hätte ich Hunderte von Gegenbeispielen

Das ist natürlich unzutreffend. Wenn einem privaten Root-Zertifikat am Endpoint vertraut wird und der Endpoint die Möglichkeit hat, das Zertifikat und die Kette zu validieren, ist eine private PKI genauso gut oder schlecht wie eine öffentliche.

Hier nochmal als Referenz: MS16-072: Security update for Group Policy: June 14, 2016 - Microsoft Support

Dass der Computer die Policy lesen können muss.

Nö, einfach die Memo von 2016 nicht bekommen

Das denke ich bei Teams öfter...

Moin, die Anwendung Teams wird immer durch jeden einzelnen User selbst in seinem eigenen Benutzerprofil installiert, ob Du den MWI benutzt oder den anderen Installer. Der MWI bietet einfach nur die Basis für die erste Ausführung, ab da aktualisiert sich die Anwendung für jeden User unabhängig von den anderen - wenn einer sich täglich anmeldet (und Teams startet) und der andere nur einmal im Monat, werden die Anwendungsstände bei den beiden häufig unterschiedlich sein.

Würde ich gerne, aber dafür musste ich im vergangenen Jahr zweimal zu viel in Umgebungen auf DFS-R hochstufen, wo bereits 2019er DCs drin waren. Wie kamen sie da rein? Tatsache ist jedoch, dass sowohl in 2019 als auch in 2022 der FRS als Dienst noch existiert - removed oder nicht

Hmmm.... Das ist ein frischer 2019er beim Versuch, DC in einer frisch instanziierten 2008R2-Domäne zu werden: Was wohl passieren wird, wenn ich auf "Installieren" klicke?.. EDIT: Na klar, 2008R2 hat ja schon DFS-R initialisiert, wenn er der erste DC war. OK, muss noch weiter zurück - da habe ich aber kein Template für :-(

Doch, nur ohne SYSVOL halt.

Nope, NTFRS war in 2016 deprecated und in 2019 removed. Also genau genommen Server 1709, falls das jemand als DC hatte

Nicht ein WTS pro User, sondern ein zweiter gleich ab dem ersten User. Citrix und Hyper-V schließen sich nicht aus, das eine ist Desktop-Bereitstellung, das andere ist ein Hypervisor. Citrix unterstützt alle drei.

In meiner Welt: Ab 1. Ein Terminalserver ist ein Client, er kann kaputtgespielt, von Malware befallen oder durch ein Update erst mal außer Gefecht gesetzt werden, und die Leute müssen arbeiten. Entweder Du hast einen Mechanismus am Start, um ihn binnen weniger Minuten neu bereitzustellen (Citrix kann das, Microsoft nicht), oder Du brauchst mehrere. So einfach ist das. Performance-technisch kommt es - ebenfalls in meiner Welt - auf zwei Dinge an: Bekommen die Terminalserver Hostgrafik durchgeschleift? Dann kann die dafür verwendete Technik bedingen, wieviel GPU eine einzelne VM max bekommen kann, und das bildet die Grundlage für das Sizing. Was ist das gesunde Maß an vCPU-Zuteilung in Bezug auf den Rest der Virtualisierungsplattform? Eine VM sollte nicht mehr als die Hälfte der vorhandenen NUMA-Knoten auslasten (so als Richtwert). Hast Du also zwei CPU á 16 Kerne, werden es vermutlich insgesamt 4 NUMA Nodes sein, und es sollte keine VM mehr als 16 vCPUs bekommen. Das Maß aller Dinge bei Terminalservern ist immer noch die Physik. Da habe ich durchaus schon dreistellige Sitzungszahlen pro Host gehabt, die sich mit Virtualisierung und Aufteilung auf mehrere VMs - selbst unter Reservierung von 100% der Ressourcen - nicht haben abbilden lassen.

Klar, wenn sie eine neue Gruppe erstellen, sind sie ja erst Mal Owner

Moin, was ist denn mit dem Alias (mailNickname) - ist dieser identisch zwischen User und Gruppe, oder ist der von der Gruppe identisch mit dem sAMAccountName des Users?

Moin, Gangl könnte sowas haben, ansonsten kann man derartige Kleinigkeiten auch per VBA schnell programmieren. Falls Du ein paar Tausend User hast, die Du mit dieser Funktion beglücken möchtest, würde Gangl das bestimmt auch als Sonderentwicklung machen.

Negativ. Nur in dem Forest und mit Schema Admin-Credentials. Das ist übrigens eine Aussage, die genauso gefährlich ist wie formal zutreffend Obwohl es in der Tat CUs ohne Schema Upgrade gegeben hat, ist die Organization Preparation mit jedem CU notwendig, und auch hier werden möglicherweise forestweite Objekte und Berechtigungen verändert, so dass Replikation über alle Domains und Standorte abgewartet bzw. erzwungen und abgewartet werden muss.

Gegenfrage: Wann ist für sowas die richtige Zeit?

Moin, nein, SQL übernimmt gar nichts von irgendeiner anderen Instanz. Du könntest Dir die Verbindungen anzeigen lassen (SELECT * FROM sys.dm_exec_sessions) oder die Server-Logs auswerten.