cj_berlin

vor 3 Stunden schrieb wznutzer:

 

RD-Gateway

Das Gateway ist die einzige Rolle die auf jeden Fall ein öffentliches Zertifikat benötigt.

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 

vor 38 Minuten schrieb NorbertFe:

Is gar nicht mal so cool, die neue Technik. ;)

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.

vor 34 Minuten schrieb NorbertFe:

Ja aber 2019 geht afaik noch mit ntfrs rein. Erst ab 2022 geht das nicht mehr.

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

vor 25 Minuten schrieb GTRDRIVER:

1 WTS pro User halte ich für nicht notwendig  - aber ich spreche dir deine Erfahrungen nicht ab. Citrix steht nicht zur Verfügung wir haben komplett auf Hyper-V gewechselt und sind damit recht zufrieden.

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.

vor 21 Minuten schrieb GTRDRIVER:

 

Ab welcher Zahl macht es sinn auf einen 2. oder 3. Virtuellen WTS aufzusplitten ?

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:

1. 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.
2. 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.

vor 7 Stunden schrieb Squire:

das /prepareschema muss in der Domäne stattfinden, in der der Schema Master ist

Negativ. Nur in dem Forest und mit Schema Admin-Credentials.

vor 7 Stunden schrieb Squire:

Nebenbei bemerkt - nicht jedes CU erfordert ein Schema Update - wenn, dann ist das in den Notes oder auf dem Exchange Blog angegeben

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.

vor 38 Minuten schrieb tesso:

Warum passiert sowas immer zur falschen Zeit?

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

vor 35 Minuten schrieb Dutch_OnE:

 

Kann ich irgendwie erkennen, welches die aktive ist, also was praktisch noch auf welchem Server aktiv ist.

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

vor 15 Minuten schrieb wznutzer:

 

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.

Also bei mir ist die OST in AppData\Local  

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

vor 5 Stunden schrieb wznutzer:

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?

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.