cj_berlin

Moin,
 
nein, LocalMachine überschreibt MachinePolicy, somit ist Deine resultierende Policy RemoteSigned, was Du auch lt. PowerShell-Ausgabe erlebst. Und hier beißt Dich etwas, was tatsächlich kontraintuitiv ist: Wenn Execution Policy über GPO gesetzt ist, kann sie nicht an der Kommandozeile übersteuert werden, auch wenn die GPO eine schwächere Einstellung hat als die resultierende Policy.
 
Check mal, warum etwas, was aus einem UNC-Pfad aufgerufen wird, als "Remote" angesehen wird - by default sind UNC-Pfade Teil der Zone "Lokales Intranet". Vielleicht wurde das Skript bereits bei der Übertragung NACH NETLOGON als "Remote" markiert...  vergiss es, habe es jetzt gelesen.
 
Alternative wäre, das signierende Skript zu "Trusted Publishers" hinzuzufügen.
EDIT: Das hinzufügen von "meine_domäne.de" zu der LocalIntranet-Zone scheint zu helfen.

Ja.

Moin,
 
eure Tests lügen nicht. Es hat schon seinen Grund, dass das standardmäßige Load Balancing-Verfahren sowohl in SET als auch in LBFO "switch-independent" heißt. Stacking ist dafür nicht erforderlich.

Moin,
 
Download vom WSUS ist auch ein "reliable HTTP transfer". Wenn die Clients nicht ins Internet sollen, Mode 99.
 
Mode 100 soll man eh nicht mehr verwenden.

Moin,
 
nein, diesen Unterschied hat es als funktionalen Unterschied nicht gegeben. Kann der User sich über RDP anmelden, wenn Du ihn in die lokalen Admins steckst? Kann ein anderer User, der Mitglied in "Remote Desktop Users" ist, sich über RDP anmelden?

Moin,
kannst du nicht. Musst über einen Smarthost rausschicken.

$schemaNC = ([ADSI]"LDAP://RootDSE").schemaNamingContext[0] $dS = New-Object System.DirectoryServices.DirectorySearcher $ds.SearchRoot = New-Object System.DirectoryServices.DirectoryEntry(('LDAP://{0}' -f $schemaNC)) $ds.SearchScope = [System.DirectoryServices.SearchScope]::Subtree $ds.Filter = '(&(objectClass=attributeSchema)(isMemberOfPartialAttributeSet=TRUE))' $null = $ds.PropertiesToLoad.Add('name') $ds.FindAll().ForEach({$_.Properties['name'][0]})  

Ich würde sagen, Du hast die Execution Policy auf dem Exchange Server hochgesetzt. Was gibt
 
Get-ExecutionPolicy -List zurück?

Moin,
 
ein RD-Lizenzserver müsste in der Gruppe "Terminalserver-Lizenzserver" Mitglied sein, damit Per-User-CALs funktioneren. Es sei denn, er ist auf dem Domain Controller installiert.
Erkennen, welche Rollen installiert sind, kann man m.E. nur indem man dort direkt enummeriert.

Schau mal, ob https://www.powershellgallery.com/packages/RDExSessionInfo/1.1.0.0 hilft. Ich habe es vor 8 Jahren geschrieben, weiß nicht mehr, was es ausgibt, aber ich meine, es war aus demselben Grund wie bei Dir....

Re Ausgabe von Get-Member: vergiss es einfach
Du kannst die Werte ins . Net-Objekt schreiben, und nur das sagt Dir die Ausgabe. Du kannst sie aber nicht ins Verzeichnis schreiben 
Re Bedingungen in Skripten verändern: das Zauberwort lautet "Parametrisierung".
Wenn Du dein Test-AD auf Teufel komm raus verbiegen willst, leistet Mimikatz DCShadow (online) oder DSInternals (offline) wertvolle Dienste.

Lege die Policy vielleicht einfach neu an, geht schneller. Und wenn es die DDCP ist, hilft 
dcgpofix /ignoreschema /target:DC  

"nimm das Remote-Zert" --> Den Dienst "IIS" in den Eigenschaften des Zertifikats zuweisen.
"In allen virtuellen Verzeichnissen blah..." --> Autodiscover URI siehst Du mit  Get-ClientAccessServer

Hi,
 
das sollte nach wie vor funktionieren: https://lizardsystems.com/terminal-services-manager/articles/how-to-grant-shadow-access-rights-for-users-without-grant-full-admins-rights-in-rds-servers/

Das hat in meiner Erfahrung mit "Event Log Readers" zu 100% funktioniert. Firewall?

Möglich ist es schon, schön ist anders. Meinst Du nicht, dass Du 60 Postfächer auch übers Wochenende umgestellt bekommst?
 
Um das ursprünglich Gewünschte umzusetzen, muss die Empfangsdomäne auf nicht authoritativ gesetzt werden und ein Sendeconnector für diese Domain angelegt werden, der auf Strato zeigt.

Ich meine den Server, der laut Autodiscover für den Zugriff auf die öffentlichen Ordner verwendet werden soll.

Moin,
in diesem Fall kannst Du den Exchange nach Anleitung deinstallieren. Allerdings wird dabei der Installer auch das mail-Attribut bei den Usern löschen, so dass Outlook-Autokonfiguration nicht mehr funktioniert. Daher am besten das mail-Attribut bei allen Usern vor der Deinstallation exportieren und danach wieder auf den vorherigen Wert setzen.

Moin,
 
das, was Du suchst, nennt sich "Conditional Access Policies" und wird als Teil von "Entra ID Premium" angeboten. Je nachdem, was ihr gebucht habt, könnte es bereits drin sein (M365 E3/E5/Business Premium) oder auch nicht (Business Basic/Standard). Intune musst Du nicht zwingend nutzen, aber wenn Du Endgeräte in die Cloud statt ins AD joinen willst, hilft es schon enorm. Generell spielt die Geräteverwaltung in den Conditional Access erst hinein, wenn Du Policies definieren willst, die "Firmengeräten" anderen Zugriff gewähren als "privat verwalteten Geräten"-

Moin,
 
wenn es Dir um die Leistung von Echtzeit-Anwendungen geht, brauchst Du QoS, VLANs helfen da kaum. Allerdings ist es bei Softphones immer schwer zu sagen, ob Aussetzer auf Netzwerk oder doch auf die CPU/Interrupts/andere lokale Ressourcen zurückzuführen sind. Da hilft eigentlich nur ein Hardphone derselben Marke und schauen, wie sich das verhält.
In puncto Performance helfen VLANs eigentlich nur dann, wenn Du Anwendungen hast, die mit Broadcasts arbeiten, und diese das Netz mit den Broadcasts fluten. Doch auch da kann es passieren, dass diese Anwendung überall benötigt wird

Moin,
 
https://learn.microsoft.com/de-de/sql/database-engine/install-windows/rename-a-computer-that-hosts-a-stand-alone-instance-of-sql-server?view=sql-server-ver16

Select-Object -ExpandProperty primaryGroupToken
oder (Get-ADGroup $targetGroup -Properties PrimaryGroupToken ).PrimaryGroupToken
 

Dein Problem ist. vermute ich jetzt mal, dass die bordeigenen Tools aus Vor- und Nachnamen einen "Full Name" zusammenfügen, diesen dann aber stillschweigend in *zwei* Attribute schreiben: name (CN) und displayName. DisplayName wäre ja völlig OK, das kann mehrfach vergeben sein, auch innerhalb einer OU, aber der CN halt nicht.
 
Lösungsansätze: 
 
wenn die Fehlermeldung kommt, ergänze den Full Name um irgendwelche Zeichen, lege damit den Benutzer an und benenne anschließend den Display Name richtig um. lege alle neuen User in einer separaten OU an und verschiebe sie anschließend. Wird das Verschieben verweigert, bennene den CN durch Ergänzung um irgendwelche Zeichen. lege für Namensvetter eine Unter-OU Deiner User-OU an Benutze NICHT die GUI-Tools, sondern PowerShell für die Benutzeranlage, dann kannst Du gleich zuerst abfragen, ob es den User schon gibt und dann entsprechend CN und DisplayName explizit mit unterschiedlichen Werten füllen, und auch den sAMAccountName und den UPN nach einer Vorschrift gestalten.  
 
In einer prominenten öffentlichen Behörde hat man vor ca. 11 Jahren einen neuen Pressesprecher eingestellt, der aber so einen Allerweltsnamen hatte. Und man hat seine *angenommene* e-Mail-Adresse bereits im Anzeigeblatt veröffentlicht, *bevor* er durch den Onboarding-Workflow gelaufen ist und festgestellt wurde, dass es einen Beamten mit diesem Namen und dieser Mail-Adresse dort bereits seit Jahren gibt. Den Rest der Geschichte gibt es allerdings nur mündlich  

Moin,
 
als erstes begreifst Du diese Situation bitte als Chance, endlich vom "God Mode" wegzukommen und alle Rechte nur an Domain Admins zu vergeben. Leg eine Gruppe "Profile Admins" an, berechtige die und packe die Admin-Accounts da rein, die das auch machen sollen. Selbst wenn im ersten Schritt dieselben Accounts da drin sind wie in den Domain Admins. Dies nur nebenbei, hilft Dir bei der Berechtigungsvergabe erst mal nicht weiter.
 
Vermutlich stört UAC die Berechtigungsvergabe. Versuche es über die Dollar-Freigabe das Laufwerks, auf dem die Freigabe liegt. Oder mit dem lokalen "Administrator"-Account des File-Servers. Oder Du schaltest kurz UAC ab.

Moin,
auch wenn diese POP3-Puller schon immer verpönt waren und das Konzept in mehr als einer Hinsicht Sch**ße ist, ist anhand der geschilderten Anamnese nicht eindeutig, dass es nur daran liegt.
Hol doch mal eine signierte, aber nicht verschlüsselte Mail direkt mit einem POP3-Client vom Hoster ab und schau, wie der Header bzw. die Struktur aussieht. Vielleicht ist es bereits der Hoster, der das zerhaut. In diesem Fall hast Du wirklich keine Wahl, die Mails statt zum Hoster entweder direkt an den Exchange oder, besser, an einen Gateway davor zustellen zu lassen. "Gateway davor" kann ein Online-Dienst sein, muss nicht zwingend on-premises sein.