MurdocX

Ich glaube es wurde nicht bezweifelt das es nicht funktioniert, sondern nur auf die Zuverlässigkeit hingewiesen, die im Business-Betrieb bei regelmäßigen Prozessen höher sein sollte, als ein Skript bietet. Manchmal geht´s aber nicht anderst ;)

Vielleicht der "defaultUser0" der entfernt wurde?

sfc.exe /scannow Würde ich mal probieren. Schaden tut es nicht.

Ich würde nicht "Nein" sagen ;) Die Idee hier ist ja, dass wir nicht gegen Geld, sondern aus freien Stücken helfen.. unentgeltlich. Da du Profis fragst, bekommst du auch eine dementsprechende Antwort. Lass Dir aus meiner Erfahrung ( Mehrere größere Programme in PS geschrieben ) sagen, das die Hinweise schon stimmen. Besonders bei dem Thema Berechtigung gibt es immer mal wieder interessante Fehler, die Mal auftauchen und mal nicht. Das ist nichts was einfach "mal so" unbeaufsichtigt zuverlässig funktioniert. Als Anleitung: Get-ACL // Zum Abrufen der Berechtigung Neue ACL generieren und zu der Variable hinzufügen Neue ACL auf die Datei anwenden Hier gilt es als Besonderheit, wenn dein Rechner nicht im AD ist, du aber Berechtigungen aus dem AD vergeben möchtest "kann" es Probleme beim auflösen der SID geben. Anbei einen Beispielcode aus einer kleinen Skript-Anwendung, der so nicht 1 zu 1, aber als gutes Beispiel angesehen werden kann. # Vorbereiten! $objUser = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList ("DOMÄNE\$Benutzer") $colRights = [System.Security.AccessControl.FileSystemRights]'Modify' $InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::ContainerInherit -bor [System.Security.AccessControl.InheritanceFlags]::ObjectInherit $PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None $objType = [System.Security.AccessControl.AccessControlType]::Allow $objACE = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList ($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType) $acl = Get-Acl $FQUP $acl.AddAccessRule($objACE) # Setzen! $acl | Set-Acl $FQUP fAddMessage -Nachricht 'OK!'-OK If ($WriteActionsToLog) { $Actions = $Actions + "'OK!'" Out-File -FilePath "$PSScriptRoot\OrdnerCheck_$(Get-Date -UFormat '%Y-%m-%d')_Aenderungen.log" -InputObject $Actions -Encoding utf8 -Append }

Schon mal den WSUS in Action erlebt? Wenn vermeidbar, was es ja hier ist, würde ich keinen WSUS auf einen DC installieren. Je nach Umgebung mag das noch mehr oder weniger Auswirkungen haben. Installiere ihn auf dem SQL...

Du siehst die Gruppenmitgliedschaften eines Benutzers entweder über die Cmd oder über die MMC ADBC - > klicken auf das Benutzerobjekt > "Mitglied von". Benutzer werden normal nicht direkt auf Gruppenrichtlinien berechtigt. AGDLP-Prinzip ( https://en.wikipedia.org/wiki/AGDLP ) wird beachtet. Wenn über Gruppen eine klare Struktur aufgebaut wurde, dann benötigst du nicht mehr Informationen als die Gruppe selbst. Durch geschickte Gruppenbenennung kannst du ein effektives Berechtigungssystem bauen.

cscript C:\Windows\System32\slmgr.vbs /dli | Out-File -FilePath "C:\SlmgrOutput.txt" Google ist wohl "Out of Order"...

Das wäre doch wohl "zu einfach"... :D

Routing & RAS wurde seit Windows 2000 nicht mehr weiterentwickelt. Du solltest Dich um etwas "professionelleres" bemühen! Sophos bietet eine Appliance für den "home"-Betrieb und eine für den "business"-Betrieb abgespeckt. Die Letztere reicht vollkommen dafür aus. Es gibt noch pfSense etc. etc...

Mit Powershell bestimmt. Schau dir die cmdlets an.

Was macht denn Select-Object, highlyeducatedmen?

- entfernt -

Damals, schon bei iOS 8, habe ich bei selbst signierten Zertifikaten ein Profil anlegen müssen und in dessen das Root-Zertifikat der eigenen CA hineingepackt. Dann hat´s ohne Probleme funktioniert. Seither benutze ich aber nur noch CA´s denen Apple vertraut.

Hat Doso doch geschrieben.. Timing, danach Logging & run.

Arg, ich hab´s auch extra nachgeschlagen und hab ich einem MS-Blog-Artikel PS 3.0 gelesen. Wenn ich Ihn wieder finde, dann liefere ich nach ;) Man muss auch nicht immer recht behalten. Komme auch gut klar, wenn es PS 2 ist :) Danke für den Link

Gratuliere Zahni, du hast´s gelöst! :D

Danke für das Teilen der Antwort. Interessante Lösung! :thumb1:

Nein, seit Powershell 3.0 ?

Interessanter Fall. Die Netzwerkkonfiguration passt, sonst würde kein Zugriff auf eine Freigabe möglich sein, wie z.B. Sysvol. Ich vermute das veränderte Berechtigungen das Problem sind, welche genau kann ich aber auch nicht sagen. Lass mal hören was bei dem Case dann raus kam.

Ansätze durchgearbeitet? Ich verstehe nicht was du mir damit sagen willst, weil das schon in deinem ersten Post stand. Edit: Ah, du hast das im Zitat bearbeitet. Ok Wenn du eine andere Freigabe erstellst, können die Clients dann darauf zugreifen? Wie berechtigst du die Freigaben bzw. NTFS? Nutzt du IPSec zur Verschlüsselung der Kommunikation? In der FW konfigurierbar.

Ne, nicht zwingend :) Einige Suchbegriffe werden auch automatisch in englisch gesucht. Meiner Erfahrung nach lande ich treffsichere Ergebnisse, wenn ich diese direkt auf englisch suche.

Auf Englisch suchen ;)

Moin, zum einbinden der Treiber verwendet der WDS das TEMP-Verzeichnis. In der Powershell kannst du dein Temp-Verzeichnis händisch angeben, in der MMC aber nicht. Falls also beim importieren der Treiber oder ähnlichen Änderungen am Image oder Startimage Fehler auftreten, ist es ratsam das komplette Verzeichnis zu leeren und die gemounteten Reste auch zu entfernen. Vorgang: Starte mit erhöhten Rechten eine CMD und führe folgenden Befehl aus: dism /cleanup-mountpoints Entferne alle Reste aus "C:\Windows\Temp" Entferne alle Reste aus "C:\Users\%Username%\AppData\Local\Temp"

Doppelt hält besser? In meinem Post war noch der Treiber mit inkludiert, aber im Prinzip.. ja :D

Hab´s gefunden :) Ich dachte es ist ein VBS-Script, aber es ist ja Powershell. Immer wieder überraschend was alles noch für Cmdlets nachgeliefert wurden.