MurdocX

Du hast die Lunte schon vorher gerochen

Ausnahme beim Aufrufen von "Remove" mit 1 Argument(en): "Die Struktur der Sicherheitskennung ist unzulässig. " In C:\Program Files (x86)\WindowsPowerShell\Modules\localaccount\1.6\localaccount.psm1:590 Zeichen:35 + $group.remove("WinNT://$($Name[0]),user") + ~~~~~~~~ + CategoryInfo : NotSpecified: (:) [], MethodInvocationException + FullyQualifiedErrorId : CatchFromBaseAdapterMethodInvokeTI Die Aussage passt nicht ganz zu deiner Fehlermeldung Wie schon oben erwähnt, ist das Modul auf jedem PC mit Powershell 5.1 schon vorhanden. Da muss kein Modul für installiert werden und braucht es auch für eine gute Funktionalität nicht.

Ich tippe mal ins Blaue und darauf, dass du unter "C:\Temp" keine Schreibberechtigung hast und unter "Documents" eben schon.

Nur aus meiner Erfahrung raus.. Hast du schon mal probiert den Server nicht "SERVER" zu nennen, sondern z.B. "SRVABC"?

Wie ist denn der aktuelle Stand? Was wurde von den Vorschlägen umgesetzt?

Freut mich zu hören. Danke für die Rückmeldung.

Nein. Deine Modul-Hilfe ist nur nicht auf dem aktuellen Stand. Das soll jetzt hier nicht das Thema werden. Die Online-Doku von MS ist im Zweifel immer die Aktuelle. Hast du Dir meine Lösung angesehen? EDIT Kann es sein, dass du das Modul "localaccounts" installiert hast? Die Fehlermeldung bezieht sich auf das Modul. Das gibt es in der PSGallery. Du solltest den hauseigenen Befehl von dem Modul "Microsoft.PowerShell.LocalAccounts" verwenden. PS C:\Users\...> Find-Command -Name Remove-LocalGroupMember Name Version ModuleName Repository ---- ------- ---------- ---------- Remove-LocalGroupMember 1.6 localaccount PSGallery Remove-LocalGroupMember 2016.5.7.2 ARTools PSGallery Remove-LocalGroupMember 1.3 LocalMachine PSGallery Lösche das mal: "C:\Program Files (x86)\WindowsPowerShell\Modules\localaccount"

Mich irritiert das Bei der Fehlermeldung steht "Remove-LocalGroupMember -Group Administratoren -Member "S-HHLA-Server ..." oben aber "Server-Installation". Übersehe ich hier was oder willst du den Befehl im kompletten nicht posten? EDIT - Anhang Die Fehlermeldung ist prinzipiell richtig, denn du übergibst nur das Objekt als String. Ich hab hier mal ein Beispiel. Dieses Beispiel erzeugt das Objekt "LocalPrincipal" für den Benutzer "Setup". Genau das was dein "Remove-LocalGroupMember" Cmdlet unter "Member" benötigt. PS C:\Users\ICH> $User = Get-LocalGroupMember -Group Administratoren -Member Setup PS C:\Users\ICH> $User.GetType() IsPublic IsSerial Name BaseType -------- -------- ---- -------- True False LocalPrincipal System.Object PS C:\Users\ICH> Remove-LocalGroupMember -Group Administratoren -Member $User EDIT 2 In den Beispielen von Microsoft ist zu erkennen, dass für Domänen Gruppen, also solche die im AD erstellt werden der Domänenkürzel vor den Gruppennamen gestellt werden muss. Hier also z.B.: Remove-LocalGroupMember -Group Administratoren -Member "MeineDomäne\Server-Installation" Vermutlich kann er dann deinen String in das Objekt parsen.

Der Fehler zeigt leider nicht deinen Befehl. Könntest du diesen hier im kompletten zur Analyse posten? Ich glaube sonst kommen wir nicht weiter.

Diese Frage sollte schon beantwortet werden und ist es immer noch nicht. Ich brings nochmal in den Vordergrund. Das ist Dir wahrscheinlich untergegangen...

Dann könnte Dir für die Aktivierung dieser Link weiterhelfen. https://www.thomas-krenn.com/de/wiki/Windows_Server_Evaluierungsversion_in_Vollversion_umwandeln

Ja, das klingt für mich auch nicht sinnig. Was möchtest du denn damit erreichen?

Es liest sich so, als hättest du eine Evaluation-Edition. https://windowswizardry.wordpress.com/2016/11/18/fixing-the-automatic-shutdown-annoyance-of-windows-server-20162012/

Wir nehmen für Backups ein einfaches NAS. Eine Bandsicherung lohnt sich da nicht. Die Geräte (Synology,QNAP) können die Daten auch in andere Gebäude spiegeln. Unser Backup (Veeam) könnte das das z.B. auch.

Hallo Sumimasen, willkommen an Board. Siehe: Quelle: https://docs.microsoft.com/de-de/windows-server-essentials/migrate/step-2--install-windows-server-essentials-as-a-new-replica-domain-controller Für 21 Tage wird er zugelassen, dann nicht mehr. Das betrifft deine beiden vorhanden Versionen. Mit der Standard sollte es gehen, wenn der Foundation der Inhaber aller Rollen bleibt, was hier ja kein Thema ist.

Also verstehen kann ich das Ansinnen schon, durch die regelmäßige Vergabe von neuen Passwörtern das Account-Sharing einzudämmen. Das müsste dann aber m.M.n. sehr oft passieren. Im Endeffekt ist es eine Sache der Gewöhnung bei den Mitarbeitern. Der Effekt wird über die Zeit seinen "Schrecken" verlieren und der gewünschte Effekt bleibt aus. Ich kenne auch Fälle in dem das Account-Sharing gewünscht/benötigt wird. Der Tipp von Mark auf der Cim war gut. Passwörter auf mehr Zeichen erhöhen und gleichzeitig dem Mitarbeiter erklären, dass er sich einen Satz ausdenken soll. Seit dem gibt es keine Diskussion mehr über lange Passwörter. Dann muss das Passwort auch nicht so oft gewechselt werden. Das sich das BSI vom Passwortwechsel entfernt ist auch gut, denn die Vorschriften basieren auf einer falschen Annahme.

Du musst das Verteilen von DHCPv6 an der Fritzbox unterbinden. DNS macht nur der erste DC, bis der zweite erfolgreich promotet wurde.

Das hier hat mir Google ganz schnell geliefert https://www.tecchannel.de/a/windows-server-2012-hochverfuegbarkeits-setup-fuer-remote-desktop-connection-broker,2039444,4 https://www.petri.com/configure-rds-collections-using-powershell Du darfst gerne mitarbeiten für Deine Lösung.

Irgendwie verstehe ich dein Problem nicht ganz. Könntest du es in Ruhe nochmal bitte erklären?

Wenn du mehr als 1 RD Sessionhost hast, dann ja.

Hallo Daish, ich habe folgende Fragen an Dich: Wann und wo kommt der Fehler? Benötigst du den Verbindungsbroker überhaupt? Was ist beim RDS eine Standardinstallation für dich? Um welches Betriebssystem handelt es sich?

Gibt es denn DEN Standard um ein AD zu kompromittieren? Neee Das ist nicht wie bei einem Client einfach von USB/CD/DVD booten und die Viren entfernen. Das ist wie mit Schimmel an der Wand. Man weiß zwar wie man ihn los wird, aber erst mal nicht wie tief er schon in der Wand ist und damit immer wieder kommt. Ich bin der gleichen Ansicht. Laut einer Statistik von Microsoft wird ein unbemerkter Zugriff erst im Schnitt nach einem Jahr bemerkt/aufgedeckt. Wer weiß wie lange der Zugriff schon besteht.

Ich hatte letztens eine Triade von Installationen hinter mir, die im Setup oder danach abgeschmiert sind. Unter Anderem auch mit diesem Fehler des öfteren. Bei dem Computer waren die RAM-Riegel defekt. Nimm einen RAM-Test deines Vertrauens.

Hänge mal bitte bei Olafs "Out-File" ein "-Encoding utf8" dahinter. Funktioniert es dann? Edit: Microsoft unterscheidet zwischen "UTF8NoBOM" und "UTF8". Mir erschließt sich der Unterschied nicht. // Powershell 6.0 + Die Powershell 5.1 hat default ein Encoding: Out-File -> Unicode Set-Content -> Default -> ANSI Die Powershell 6.0 + Out-File -> UTF8NoBOM Set-Content -> UTF8NoBOM Das sollte hier Klarheit in das Verhalten bringen.

Set-Content und Out-File nehmen default, laut Microsoft Zitat: "The default value is UTF8NoBOM". Das bestätigt deine Annahme. @epsodus Welche Kodierungen haben deine XML-Dateien?