cj_berlin

Ketzerisch zurückgefragt - du hast die ganzen Videos auf Microsoft Learn bereits konsumiert, und es reicht Dir nicht? Dann solltest Du lieber die Anreise auf Dich nehmen und einen echten Kurs besuchen...

Ist sie nicht. Nur wird das Address Book verwendet, um den Zugriff auf den Kalender zu nehmen.

Moin, es gibt AD-Berechtigungen (wie z. B. Send-As), Postfachberechtigungen (wie z.B. Elemente löschen) und Ordnerberechtigungen (wie z.B. eigene Elemente bearbeiten). Erstere werden im AD hinterlegt, der Rest im Postfach selbst gespeichert.

Bitte auf Cross-Posts hinweisen! https://social.technet.microsoft.com/Forums/de-DE/ee406ec5-9ec0-4467-9317-14917b2eb51c/wie-kann-man-im-sccmmem-2021-3000-bosch-testtablets-die-separat-von-2000-notebooks-software?forum=systemcenterde

Ich wäre für Modell (wie oben bereits angemerkt)

Collections basierend auf Modell?

Man kann sie "zusammenpacken", aber die begrenzende Collection muss halt alle umfassen. Dann lass Dir von den globalen Admins eine Deinen Bereich umfassende Collection bereitstellen.

Moin, schau Dir Black Ice an. Das sollten sie können.

Naja, im Zweifel "Alle Desktop & Server Clients" - dafür ist sie im Prinzip ja auch da.

Moin, da Du beschlossen hast, zwar große Screenshots zu posten, aber möglichst alles Relevante wegzuretuschieren,ist es schwierig, aber in 99% der Fälle ist bei sowas die begrenzende Sammlung falsch.

Das ist richtig. Die Frage war eher im Sinne von "ist euch generell klar, dass man einem Server nicht einfach so einen zweiten Namen geben kann?" gemeint.

Moin, habt ihr denn generell alles unternommen, damit das mit dem Alias funktioniert? Strict Name Checking, SPNs für Kerberos usw. usw.

Ich lege auch keinen Wert darauf, immer älter zu werden, aber wenn man mir zum Geburtstag gratuliert, bedanke ich mich trotzdem Meine Aussage damals bezog sich ja darauf, dass ich nichts "für den Award" machen würde, was ich nicht aus sonst an Community-Arbeit machen würde. Und das ist auch heute noch so.

Moin, ja, das geht.

Danke

Moin, mein bisheriges Verständnis war, dass es nicht vorgesehen ist.

Es ging nicht darum, das in Dein Skript einzubauen, sondern zu schauen, wo das Problem ist. Somit antwortet die VDS-Schnittstelle offensichtlich wie sie soll. Die Storage-Cmdlets nutzen aber nicht die native API, sondern WMI, somit liegt das Problem offenbar dort.

Moin, liefert auf den betroffenen Maschinen der Befehl LIST VOLUME in DISKPART das erwartete Ergebnis?

Moin, es gibt drei APIs für den Zugriff auf AD: LDAP, ADSI (im Prinzip ein COM-Wrapper für LDAP) und ADWS (zwar keine REST-, aber immerhin eine Web-API).

Moin, RDWeb und RDG haben nichts miteinander zu tun. Wenn Du RDWeb nach extern veröffentlichen möchtest, machst Du es wie mit jeder anderen Webanwendung. Das, was Du beschreibst, funktioniert auch, wenn RDG und RDWeb auf derselben Maschine laufen, wie z.B. beim SBS.

Hot off the press:

certutil -accept würde mir einfallen. Oder zu Fuß mit certlm.msc.

Aber es geht doch eigentlich eher um Reife als um Größe! Auch in einer Umgebung mit 30 Usern wäre eine separate VM für AADC dringend anzuraten, wenn dort der Begriff "Tier 0-System" eine technische Umsetzung erfahren hat und gelebt wird - Admin-Trennung, PAW, Netzsegmentierung usw. Das Argument ist aber nur in der Theorie so einfach und klar. In der Praxis sieht es doch so aus: Wenn man nach der Installation NICHTS gemacht hat, um die Umgebung zu härten, sind DCs durch die DDCP wenigstens etwas besser geschützt als normale Server, für die nichts höheres an Schutz gilt als für Workstations. Immerhin kann man sich als nicht-Domain-Admin nicht aus Versehen dort anmelden. Zurück zum aktuellen Thread: Der OP mutet schon so an, als wäre ansatzweise Tier 0-Schutz in der Umgebung vorhanden. Ist dem wirklich so, dann würde ich allein schon aus Backup-/Restore-Gründen für eine separate Maschine plädieren. Beim Backup muss man aber genau so aufpassen wie beim Backup der Domain Controller - wer einen System State-Backup eines AADC-Servers ergattern kann, ist in 5 Minuten DA, wenn sie weiß, was sie tut.

Moin, unpopular opinion: In Kleinstumgebungen, wo Server nach wie vor als "Pets" statt als "Cattle" behandelt werden, ist ein DC sogar der beste Ort für Azure AD Connect, denn dort ist immerhin die Wahrscheinlichkeit noch am Geringsten, dass jemand per Zufall Adminrechte bekommt, der es nicht soll. Die SQL-Instanz, die nur lokale Verbindungen akzeptiert, ist wurscht. Das schwerwiegendste Argument ist in meinen Augen tatsächlich das von @MurdocX angeführte Backup-/Restore-Thema. Du nimmst Dir damit im Prinzip die Möglichkeit, AADC nach einem fehlgeschlagenen Update per VM Restore wieder ans Laufen zu bringen. Das muss jeder für sich selbst bewerten. Ich würde sogar argumentieren, dass man in diesem Fall den "DC + AADC" am besten gar nicht erst sichern sollte.

Moin, zum Glück ist es nicht per GPO möglich. Du kannst es immer als Skript oder geplanten Task verteilen, aber das Kennwort musst Du *irgendwie* mitgeben. Dazu gibt es viele Ansätze, die zu diskutieren diesen Thread sprengen würde. Und am Ende des Tages sind sie alle unsicher.