MurdocX

Nein, denn es sind nur ACLs die auf eine SID verweisen. Sind in dem Ordner des Benutzers diese 285 Ordner und du kannst aber keine Dateien sehen? Falls ja, dann existiert dennoch ein Berechtigungsproblem. In dem Fall poste mal deine Berechtigungen (erweiterte Ansicht) auf den Ordner. Bist du Admin.. Ich vermute es könnte die UAC sein.

Vermutlich habt Ihr die "Access Based Enumeration" an, die die Dateien nicht anzeigen lässt, wenn keine Berechtigungen dafür mehr existieren. Übernimm den Besitz und die Berechtigung der Dateien. Sind diese vermutlich wieder sichtbar.

Alles auf Anfang: https://blogs.partner.microsoft.com/mpn/updates-program-change-announcements/ Microsoft zieht die Änderungen zurück.

Ahhhh! @daabm Mich ärgert gerade das ich darauf nicht gekommen bin

#requires -Version 3.0 [string]$FileFilter ='*.mrk' [string]$RootFolder = 'C:\Users\Doe\Documents\Powershell' [string]$LinkTargetOld = 'C:\Users\Doe\Documents\Ziel' [string]$LinkTargetNew = 'C:\Users\Doe\Documents\Ziel1' $FileList = Get-ChildItem -Path $RootFolder -Filter $FileFilter -File # Create shortcuts and remove file ForEach($FileItem in $FileList) { $Shortcut = $null [string]$NewFileName = $FileItem.Name.Replace('.mrk','.lnk') [string]$NewLinkTarget = $FileItem.Target.Replace($LinkTargetOld,$LinkTargetNew) $Shortcut = (New-Object -ComObject WScript.Shell).CreateShortcut("$RootFolder\$NewFileName") $Shortcut.TargetPath = $NewLinkTarget $Shortcut.Save() Remove-Item -Path $FileItem } Ich hab mir erlaubt eure Variante "etwas" gerade zu rücken. Also komplett neu geschrieben. Ihr seht den Unterschied... Probiert das mal auf dem Server. Von Deinem Skript bekommt man ja Augenkrebs

Sollen wir wirklich über jeden Befehl diskutieren? Sei mir nicht böse, aber darauf habe ich keine Lust u. Zeit. Dann dürfen Dir gerne die anderen weiterhelfen.

Bist du Dir im Klaren was "Vollzugriff" bedeutet? Dürfen Benutzer Berechtigungen ändern?

Mal einfach gefragt. Passt Ihr dann auch die Variablen oben $From, $To u. $Folder an?

Es geht nicht darum was euch der Explorer anzeigt, sondern was der Befehl liefert den ihr selber verwendet. # Befehl 1 [string]$lnkTarget = (Get-Item $lnk).Target # Befehl 2 in Abhängigkeit von Befehl 1 $lnkTarget = ($lnkTarget).Replace($from,$to) Wie soll der zweite Befehl was tauschen, wenn Ihr ihm nichts liefert. Selber habt Ihr getestet und es nichts bei raus. Ergo, ist die Eigenschaft 'Target' die Falsche. Ich habe hier keine MRK-Datei, um das Auslesen zu testen.

Der Befehl ist zusammenhängend. Alle zusammenhänge zusammengenommen, ergeben das was ich euch geschrieben habe Damit hat der Dateityp "MRK" wohl kein Target. Darin liegt der Fehler. Da Ihr Target wieder weiterverarbeitet, dieser aber leer ist, kommt auch unten nichts sinnvolles bei raus. Vielleicht geht ein manuelles umbenennen in lnk vorher? Probiert es mal aus.

Habt Ihr den Befehl für eine Datei schon mal händisch in die Powershell geschrieben und geschaut ob da überhaupt etwas raus kommt? (Get-Item -Path 'MeinPfad_ZurMrkDate.mrk').Target

Hier gibt es eine Menge Optimierungspotential :) Fangen wir mal oben an. Wofür wird diese Zeile gebraucht? $obj = New-Object -ComObject WScript.Shell Warum wandelt Ihr Objekte in Strings um, wenn Ihr weiter unten über Get-Item wieder das gleiche Objekt erstellt? ... | select -ExpandProperty FullName (Get-Item $lnk).DirectoryName Wichtig, Wichtig u. Wichtig: Für Euch und für andere die das Debuggen müssen. Bitte keine Kürzel wie "select" wählen, wenn es ausgeschrieben ein "Select-Object" ist. Das Gleiche gilt für "write" das ein "Write-Output" ist.

Einen kleinen Vorschlag möchte ich bringen: param( [string]$Arg = "uptime", [string]$warn = 0, [string]$crit = 0 ) würde ich eher in: param( [string]$Arg = "uptime", [int]$warn = 0, [int]$crit = 0 ) ändern. Denn 0 ist eher ein Integer, als ein String. ($warn, $crit) Hier kannst du mehr Klarheit und weniger Fehleranfälligkeit in dein Skript bringen. Auch würde ich die Variablen ausschreiben. Es kann nicht schaden, Dir und Anderen mehr Sicherheit im Umgang mit den Paramentern bringen. Vielleicht schaut man das Skript in 2 Jahren das nächste Mal erst an. Ergänzung Alternativ, falls diese Parameter nur 0 oder 1 können (True, False), solltest du einfach [switch] verwenden. param ( [string]$Arg = 'uptime', [switch]$Warning, [switch]$Critical ) Wobei das auch nochmal vereinfacht werden kann. [Parameter(Mandatory,HelpMessage='Aktueller Sicherheitsstatus (Warning,Critical) wird erwartet.')] [ValidateSet('Warning','Critical')] [string] $Status

Mein Link, zweiter Post. ...

Je nach was die Anforderung ist und welche Hilfestellung wirklich gebraucht wird benutze ich das Ein oder eben das Andere. Gerne nutze die kurze Hilfestellung, damit ich kurz und prägnant weiß welche Daten in dem Parameter wirklich übergeben werden muss.

Kurze Rückmeldung: Es gab mehrere die keine Anmeldebestätigung bekommen haben. Das wird aktuell geprüft.

Auch in den Advanced Parameter kann eine Hilfe hinterlegt werden: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_functions_advanced_parameters?view=powershell-6 [Parameter(HelpMessage='', HelpMessageBaseName, HelpMessageResourceId)]

Was hast du diesbezüglich schon gemacht?

Schau mal hier: https://social.technet.microsoft.com/Forums/en-US/bada23c1-43d8-47e2-b88d-367e14afd199/kb3156387-is-keep-failing-on-windows-10-10010240x?forum=win10itprogeneral net stop wuauserv cd %systemroot%\SoftwareDistribution ren Download Download.old net start wuauserv Bitte nächstes Mal auf dein Crossposting hinweisen: https://www.drwindows.de/windows-10-desktop/159181-sfc-scannow-findet-fehler-kb4507453-2.html

Leider nichts angekommen. Möchte ich mich nochmal anmelden, steht das ich das schon getan hätte. Ich habe die jetzt einfach angeschrieben, dann werde ich sehen was kommt.

Das sehe ich genauso. Wenn man keine Infos bekommt, muss man einfach vom schlimmsten Fall ausgehen

Ich nämlich auch nicht.

Habt ihr eine Bestätigungsmail bekommen?

Das ist Richtig, dennoch weiß keiner welche Lösungen du angewandt hast. Ein erneutes Erwähnen schadet demnach, meiner Meinung nach, nicht. Ich hatte das Problem auch schon mal und konnte es über diesen Befehl lösen. Ein neues Profil sollte auch funktionieren, wie @testperson schon erwähnte.

Den fand ich gut Generell muss man ja sagen, dass der @bmeyer1706 nicht erwähnt hat für welches Betriebssystem. Also, wenn wir im schlimmsten Fall von Windows 7 ausgehen, dann haben wir dort die Powershell 2.0. Deshalb wären beide Lösungen für 2.0, wie für 3.0 gerechtfertigt.