cj_berlin

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.

...und immer schön auf Cross-Posts hinweisen: https://social.technet.microsoft.com/Forums/de-DE/d3b1f45b-de40-475d-bb5f-22d939088279/schema-erweiterung-bei-exchange-cu-updaten-an-verschiedenen-standorten?forum=exchange_serverde

Also bei mir ist die OST in AppData\Local

Aber aus PowerShell hast Du dich doch nicht ausgesperrt, oder?

Der Teil, der nicht problemlos funktioniert hat, kommt in diesem Szenario ja nicht zum Tragen.

Moin, die Alternative wäre: Manfred Helber und Sven Langenfeld sind nur Menschen und nicht unfehlbar. Oder Du hast doch etwas missverstanden. Kannst ja mal einen Link zu der Stelle auf YouTube posten, wo sie das angeblich sagen. Ich mache seit NT-Zeiten Windows-Terminaldienste und höre diese Aussage zum ersten Mal. Zumal - badummm...ts! - die "Express-Bereitstellung", bei der *alle* Rollen auf einem Server wohnen, durchaus supported ist EDIT: Dass es keine gute Idee ist, Infrastruktur-Rollen mit Workern koexistieren zu lassen, sollte außer Frage stehen

Moin, im Prinzip richtig, aber mach doch wenistens Roaming Profile für die User. Falls einer mal wirklich die Zuweisung geändert bekommt.

Moin, im Grunde bin ich bei @NilsK, würde beide Teile der Aussage jedoch gern etwas abschwächen: AD-Member funktionieren mit einem Third-Party-DNS wunderbar, wenn dieser für die AD-relevanten Zonen mein-ad.de und _msdcs.mein-ad.de unter keinen Umständen autoritative Antworten ausgibt und auf NS und SOA die Domain Controller zurück meldet alle Anfragen auf diese Zonen ungefiltert und unverändert an Domain Controller weiterleitet Und was "PiHole als Heimlösung" angeht... Nun, die Lösung besteht aus Hard- und Software. Dass ein Raspi als zentraler DNS-Server im Business-Umfeld keinen Platz hat, ist unstrittig. Aber PiHole ist ja auch nicht an Raspi gebunden, sondern kann auf einer VM oder auf einem x86 Commodity-Server ausgeführt werden. Die Software aber basiert auf denselben Standard-Technologien wie jeder andere DNS-Filter, inklusive solcher, die in Firewalls namhafter Hersteller verbaut sind.

Achtung! Genau das ist (nicht in Deinem Lab natürlich, in der realen Welt) der Trugschluss, dem mit am häufigsten aufgesessen wird. Wenn Du zwei VMs auf einem Host hast, und jede von ihnen hat so viele vCPUs wie der Host Hyperthreading-Kerne hat (*), und die VMs sind im Hypervisor gleich gewichtet, bekommt jede VM exakt 50% der CPU-Zeit, ganz gleich, wieviel die andere VM zu tun hat. Es kann aber durchaus ausreichend sein und im Betrieb nicht auffallen. Ist also von vornherein bekannt, dass eine VM CPU-mäßig mehr zu tun hat als die andere, kann es sich lohnen, die VMs zu gewichten. Das muss man aber akribisch dokumentieren und auch bei der Ressourcenplanung für die Weiterentwicklung der Plattform berücksichtigen. (*) genauer gesagt, VM1.ProcessorCount + VM2.ProcessorCount > Host.HTCoreCount so dass nicht beide VMs gleichzeitig CPU kriegen können.

Probleme mit der CPU-Überbuchung sind solange subjektiv wie Du für die VMs keine SLA zu erfüllen hast. Aber das typische Überbuchungsverhalten bei CPU sieht wie folgt aus: kaum CPU-Verbrauch laut Task-Manager am Host kaum CPU-Verbrauch laut Task-Manager im Gast und trotzdem ist die Performance im Gast ungenügend. Du kannst es auch messen, es gibt einen Perfmon-Counter namens "Hyper-V Hypervisor Virtual processor\CPU Wait time per dispatch" in Nanosekunden. Solange das nicht in Richtung halbe Millisekunde tendiert, sondern unter 200.000 bleibt, sollte alles soweit in Ordnung sein, zumindest aus Sicht der VMs... Und da es keine Möglichkeit gibt, den Host-Bedarf an CPU zu reservieren, kann es passieren, dass CPU-Überbuchungsprobleme sich zuerst als wahrgenommene Storage- oder Netzwerkprobleme äußern.

Das kannst Du nicht, zumindest keinen Mailbox-Server. Exchange muss ungehinderten Zugang zu mindestens einem schreibbaren Domain Controller haben, der in der gleichen AD-Site steht. Stichwort: Quarantäne. Nein, dann funktioniert ECP nicht mehr. Du kannst OWA aber für alle Postfächer deaktivieren.

Du hast zwei Anforderungen formuliert, die sich gegenseitig ausschließen: Internet + VPN --> es wird also eine Identität benötigt, um eine Verbindung zum AD herzustellen, ob nun alt oder neu. OS platt machen --> damit beraubst Du die Maschine erst mal ihrer Identität, und die Katze beißt sich in den Schwanz. Im LAN geht das, denn da kannst Du im Betankungsnetz 802.1X abschalten, und eine Maschine ohne bekannte Identität kann mit dem AD sprechen. Ansätze wären: Du verzichtest aufs Plattmachen --> dann können AD-Migrationstools, die diesen Namen verdienen, auch einen Domänenwechsel über VPN durchführen. Bereinigen kann man manchmal auch ohne Plattmachen. Du musst aber irgendwas erfinden, um zu inventarisieren, was denn da alles installiert und konfiguriert ist. Du holst die Geräte rein --> siehe "im LAN geht das". Du bastelst Dir einen USB-Bootstick, der bereits für jede Maschine ein Zertifikat inklusive Private Key und eine Offline AD Join-Datei enthält. Diesen schickst Du natürlich nicht an die User, sondern fährst von einem zum nächsten und installierst die Geräte neu. Mit dem Offline Join und dem eingespielten Zertifikat können sie eine AlwaysOn VPN-Verbindung aufbauen und kommen wieder mit der Infrastruktur in Kontakt. ACHTUNG! Dies ist keine Empfehlung, sondern einfach etwas, was technisch machbar ist.

Sehe ich in diesem Fall anders. Die drei wichtigsten Punkte wurden ja bereits geliefert: die vorhandene on-prem-Umgebung soll weg und ersetzt durch etwas, was es noch nicht gibt (kein Investitionsschutz also) Clients hüpfen die meiste Zeit im Internet herum (auf VPN und lokaler AD-Mitgliedschaft basierende Konzepte sind also schon mal aus Security-Sicht nicht das Gelbe vom Ei) Es sind nur 100x Clients, jede größere Investition in (Infrastruktur + Arbeitszeit + Lernen) ist also vermutlich pro Stück zu teuer. Und insbesondere SCCM ist *immer* eine größere Investition. Und ich bin weiß G'tt kein "Cloud-First-CoolAid-Trinker".

Moin, Betriebssystem-Betankung übers Internet kannst Du knicken. Auch das Sichern und Zurückspielen von Benutzerprofilen übers Internet kannst Du knicken. Wenn Du das ganze rein on-prem abwickeln willst, müssen die Leute oder zumindest die Geräte für einen Tag reinkommen. Was Du hingegen machen kannst - entsprechende Lizenzierung vorausgesetzt - ist vorher schon die "Well Known Folders" auf OneDrive umstellen und die Geräte ins Azure AD aufnehmen statt ins AD. Dann schickst Du jedem User einen USB-Stick zu, von dem er bootet. Daraufhin wird sein Rechner plattgemacht und anschließend ins Azure AD und Intune eingerollt. Das entsprechende Image musst Du natürlich vorbereiten, kann man im Zweifel mit MDT machen. Dann meldet sich der User mit seinem Azure AD Account an, hat dann "sein" OneDrive gleich verbunden, und da liegen auch schon seine Daten. Aber das wäre ein ganz anderes Projekt, als was Dir so vorschwebt. Lohnt sich langfristig aber vermutlich mehr.

Moin, die interessentere Frage ist ja, was übernommen werden soll. Grundsätzlich ist für die Neubetankung und Aufnahme in die neue Domäne ja egal, ob die Maschine vorher in der alten Domäne Mitglied war. Und die Clients sauber aus der alten Domäne zu nehmen, ist doch allenfalls Kosmetik. Sollen Benutzerprofile gerettet werden? Oder gar irgendwelche Datenbestände, die außerhalb der Benutzerprofile auf den Maschinen gespeichert sind?

In meiner Welt: So wie bisher, mit einer Ergänzung: Niemals etwas händisch konfigurieren, sondern jeden Schritt skripten. Dann hast Du, wenn bespielsweise ein Update oder ein Virus Deinen Server zerschießt, eine verlässliche Möglichkeit, ihn wiederherzustellen. Am Anfang ist die Lernkurve etwas steiler, aber am Ende hast Du etwas in der Hand und hast auch noch was gelernt dabei. Und ein Wort der Warnung: Je nachdem, was da installiert und konfiguriert ist, wird ein In-Place-Upgrade möglicherweise auch mit einer Vollversion scheitern.