cj_berlin

Moin,
 
erstens, bei all seinen Verdiensten für die PowerShell-Community, ist nicht alles, was Adam Bertram sich überlegt hat, als "best practice" zu bezeichnen. Zweitens, es gibt sehr viele Entwickler, die zu PowerShell nicht von CMD/VBS/bash, sondern von C++/C#/etc. gekommen sind, wo starke Typdefinitionen vorgeschrieben sind. Diese Leute versuchen, das Bekannte auch in PowerShell durchzusetzen, meistens mit mäßigem Erfolg, weil PowerShell sich strikt weigert, ein "strongly typed language" zu werden.
 
WENN Deine Funktion immer denselben Typ zurückgibt, kann es IntelliSense verbessern, wie Du auch bemerkt hast, wenn Du diesen auch in der Definition der Funktion angibst.
 
Wer funktionale Programmierung lange und in großem Stil betrieben hat, wird vermutlich zustimmen, dass es an sich eine sehr gute Idee ist, wenn jede Funktion immer den gleichen Ergebnistyp zurückgibt. Das schreibt auch Uncle Bob irgendwo in "Clean Code", wenn ich mich recht erinnere. Nur ist es in Skriptsprachen in der Regel eher hinderlich, solche Restriktionen aufzuerlegen. Aber wenn Dein Skript- oder Moduldesign das hergibt, gibt es Dir ein zusätzliches Quentchen Sicherheit, wenn Du weißt, was Du von welcher Funktion zurück bekommst.

Moin,
 
deaktivieren, das DSRM-Kennwort kennen, beim Recovery zuerst im DSRM den RID-500 wieder aktivieren und dann im Recovery-Prozess damit arbeiten, falls und wo notwendig.
 
Das ganze Thema akribisch dokumentieren, üben und die Dokumentation an einem Ort aufbewahren, den man ohne AD erreicht.

Moin,
 
die gesendeten Mails werden mit dem eigenen Zertifikat des Absenders verschlüsselt. Ich würde jetzt mutmaßen, dass aus welchen Gründen auch immer dieses verschütt gegangen ist. Für den Versand ist es irrelevant, da die Instanz der Mail, welche rausgeht, mit dem Zertifikat des Empfängers verschlüsselt ist.
EDIT: Wenn das alte Gerät noch da ist, einfach inkl. Private Key exportieren und auf dem neuen importieren.

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