zaphod88
Goto Top

Win 10 Home: Selbst zurücksetzende Userprofile

Hallo zusammen,

ich suche nach einem Weg, um auf ca. 30 Laptops mit Windows 10 Home Gastzugänge anzulegen, bei denen entweder die vorhandenen Daten oder aber das vollständige Profil beim Abmelden gelöscht wird.

Es handelt sich um Laptops aus einem Rack, die an einer Schule im Informatikunterricht (Datenbanken/Access, IDEs) genutzt werden. Die Schüler melden sich auf einem Funktionsaccount "Schüler" an, dann mit ihren persönlichen Zugangsdaten an Office 365, damit der School/Work Account verbunden und Access aktiviert wird. Ich habe das "Schüler"-Konto der Gruppe "Gäste" zugeordnet - so weit, so gut. Nun werden aber natürlich die verbundenen Schul-Accounts beim Abmelden nicht automatisch gelöscht, sodass sich theoretisch der nächste Nutzer am Laptop in den Daten seines Vorgängers umtun kann, sofern der Vorgänger die Abmeldung vergessen hat. Außerdem können auch als Gast-Nutzer theoretisch einige Dinge am System verstellt bzw. geändert werden. Daher der Gedanke sich selbst zurücksetzender Profile.

Versucht habe ich

  • Toolwiz Time Freeze und Reboot Restore Rx. Beide schützen das System vor Veränderungen bzw. setzen es nach Neustart auf Ausgangszustand zurück. Beide werfen aber Bluescreens. Außerdem (zumindest bei Time Freeze) passt nach Neustart die Windows-Uhrzeit nicht mehr, was dann wieder für Probleme beim Surfen sorgt...
  • Mandatory Profiles - klappt nicht, weil nur Win 10 Home. So scheint es zumindest.
  • PS-Skript mittels Task Scheduler, das den %LOCALAPPDATA%\Microsoft\Packages\AADBrokerPlugin-Ordner löscht (irgendwo im Netz gefunden). Das tut aber auch nicht bzw. sorgt nur dafür, dass die Anmeldung erneuert werden muss. Eine Möglichkeit, den School/Work-Account zu löschen, gibt es scheinbar per PS nicht. Daher bleibt der erhalten und die Erneuerung der Anmeldung klappt auch ohne Passworteingabe.
  • PS-Skript mittels Task Scheduler, das den kompletten "Schüler"-Account löscht und neu anlegt. Da es sich um ein Gast-Profil handelt, sind auch die FirstLogon-Zeiten verkraftbar (10 Sekunden oder so). Hier fehlt mir aber der passende Trigger - der Task müsste ja beim Herunterfahren ausgeführt werden.

Auf meinem dienstlichen Win 10 Pro-Rechner wird das Gastkonto bzw. der Ordner in C:\Users bei jeder Abmeldung gelöscht und zur nächsten Anmeldung neu erstellt. Das ist ja im Prinzip das, was ich haben will. Seltsamerweise funktioniert das aber auf anderen Win 10 Pro-Rechnern (und auf den Home-Laptops) nicht, da bleibt das Profil nach der Abmeldung erhalten. Gibt es da vielleicht eine Art Regkey oder so, der das festlegt? Hat sonst noch jemand eine Idee?

Vielen Dank schonmal und einen guten Start ins Wochenende!

Content-ID: 1748256453

Url: https://administrator.de/forum/win-10-home-selbst-zuruecksetzende-userprofile-1748256453.html

Ausgedruckt am: 27.12.2024 um 18:12 Uhr

em-pie
em-pie 21.01.2022 um 22:20:04 Uhr
Goto Top
Moin,

Nimm den letzten Punkt und suche nicht nach „abmelden“ sondern „starten“. Könnte das Event Kernel Power oder so sein.

Ansonsten prüfe doch mal, ob du (trotz Windows Home) mit lokalen GPOs arbeiten kannst. Dann wäre ein Startskript sicherlich machbar.

Gruß
em-pie
zaphod88
zaphod88 22.01.2022 um 12:20:20 Uhr
Goto Top
Ich habe es mal mit dem Task beim Starten probiert. Das sieht - laut netplwiz - auch soweit gut aus. Allerdings wird der neu angelegte Benutzer auf dem Anmeldebildschirm nicht angezeigt. Wenn ich mich mit einem Administrator-Account an- und wieder abmelde, ist er aber da. Autologon läuft leider auch ins Leere - da wird ein temporäres Profil erstellt. Den Task habe ich als SYSTEM laufen, mit erhöhten Rechten - sollte doch eigentlich passen, oder?
em-pie
em-pie 22.01.2022 um 12:48:09 Uhr
Goto Top
Moin,

Lösche nicht den gesamten User, sondern nur dessen Profil. Geht via Powershell:

https://community.spiceworks.com/how_to/124316-delete-user-profiles-with ...

Hier nur statt die „Where“-Bedingung auf das Alter loszulassen nimmst du den konkreten User.
zaphod88
zaphod88 22.01.2022 um 17:48:06 Uhr
Goto Top
Okay, das sollte der Logik halber wohl helfen. Tatsächlich hatte ich dasselbe cmdlet auch schon am Wickel und versucht,als "Abmeldeskript" zu nutzen - habs aber wohl wieder verdrängt. face-smile Ich probiere das nächste Woche mal an den betreffenden Rechnern aus. Danke schonmal! Ich melde mich dann nächste Woche zurück, wenn noch Fragen auftreten sollten.
zaphod88
zaphod88 25.01.2022 aktualisiert um 14:24:31 Uhr
Goto Top
Ich habe es mal ausprobiert. Das Script selbst funktioniert einwandfrei, aber irgendwie scheint es hier noch ein Berechtigungsproblem zu geben:

- Task ist angelegt als "Beim Starten". Ausführender Benutzer ist SYSTEM, mit erhöhten Privilegien. Executionpolicy ist im Argument auf Bypass gesetzt.

Das Script an sich:

Get-WmiObject -class Win32_UserProfile | where {$_.LocalPath -like "C:\Users\Schueler"}   
$schueler | Remove-WmiObject

Wie gesagt, es funktioniert alles, wenn ich es im lokalen Administratorkonto im Task Scheduler manuell ausführe oder auch, wenn ich den Rechner aus dem lokalen Admin heraus neu starte. Wenn ich aber aus dem Schüler-Konto den Rechner reboote, klappt es nicht. Ich habe mal das Transcript angeworfen, da kommt dann folgendes raus:

PS>TerminatingError(Remove-WmiObject): ""  
Remove-WmiObject : 
In C:\Users\<localadmin>\Desktop\resetschueler.ps1:3 Zeichen:13
+ $schueler | Remove-WmiObject
+             ~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Remove-WmiObject], FileLoadException
    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.RemoveWmiObject
Remove-WmiObject :
In C:\Users\<localadmin>\Desktop\resetschueler.ps1:3 Zeichen:13
+ $schueler | Remove-WmiObject
+             ~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Remove-WmiObject], FileLoadException
    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.RemoveWmiObject

Hast Du da noch eine Idee?
em-pie
em-pie 25.01.2022 um 16:35:47 Uhr
Goto Top
Hast Du da noch eine Idee?

C:\Users\<localadmin>
Warum legst du das Script auf den Desktop eines User ab?
Himmel-Arsch...
entweder einen Ordern auf c:\ anlegen, z.B. C:\_SCRIPTS und dort deine resetschueler.ps1 ablegen oder - weil du so nur EIN Script pflegen musst:
Wenn ihr irgendweo einen zentrale (File-)Server habt, lege dort eine Freigabe alá scripting an, sodass du dann über \\myServer\scripting\resetsschueler.ps1 an das Script kommst
Hier sollten alle User wenigstens Lese-Rechte haben...
zaphod88
zaphod88 26.01.2022 aktualisiert um 08:25:03 Uhr
Goto Top
Ui, sorry. Das war nur die falsche Log-Datei. Ich hatte es vorher schon in C:\_scripts verschoben. Das Problem besteht aber weiterhin:

PS>TerminatingError(Remove-WmiObject): ""  
Remove-WmiObject : 
In C:\_scripts\resetschueler.ps1:3 Zeichen:13
+ $schueler | Remove-WmiObject
+             ~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Remove-WmiObject], FileLoadException
    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.RemoveWmiObject
Remove-WmiObject :
In C:\_scripts\resetschueler.ps1:3 Zeichen:13
+ $schueler | Remove-WmiObject
+             ~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Remove-WmiObject], FileLoadException
    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.RemoveWmiObject
zaphod88
zaphod88 27.01.2022 aktualisiert um 09:41:33 Uhr
Goto Top
Okay, ich habe das Problem eingegrenzt. Scheinbar liegen unter %APPDATA% irgendwo Verknüpfungen aus dem Windows-Store, die sich mittels
Remove-WmiObject
(oder
Remove-Cimistance
) nicht per Powershell oder cmd löschen lassen, solange der zu löschende User derselbe ist, der als letzter am Rechner angemeldet war. Daher habe ich beim Start einen Autologon für den "alten" Schüleraccount konfiguriert, der direkt wieder abgemeldet wird. Dabei wird der neue User erstellt, der alte deaktiviert/gelöscht und der neue User als neuer Autologon-User gesetzt. Da es sich um Gastuser handelt, bekommen die User beim Autologon des alten Users auch den Desktop gar nicht erst zu sehen - d.h. der "alte" Zugang wird an- und direkt wieder abgemeldet. Ist zwar nicht ideal, scheint aber soweit zu funktionieren:

Start-Transcript -Path "C:\scripts\log4.txt" -Append  
Set-Location "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"  
$schuelerold = Get-ItemProperty -Path . -Name "LastUsedSchueler" | Select LastUsedSchueler -ExpandProperty LastUsedSchueler  
[int]$schuelernumold = [convert]::ToInt32(($schuelerold -split "r")[1])  
$schuelernumnew = $schuelernumold + 1
[string]$schuelernew = "Schueler" + [convert]::ToString($schuelernumnew)  
$schuelernew
New-LocalUser -Name $schuelernew -NoPassword  -AccountNeverExpires -UserMayNotChangePassword 
$locuser = [ADSI]"WinNT://./$schuelernew,User"  
$locuser.PasswordExpired=0
$locuser.SetInfo()
Set-LocalUser "$schuelernew" -PasswordNeverExpires $true  
net localgroup Gäste $schuelernew /add
(Get-WmiObject -class Win32_OperatingSystem).Win32Shutdown(4)
Disable-LocalUser -Name $schuelerold
Get-WmiObject -Class Win32_UserProfile | where {$_.Localpath -eq "C:\Users\" + $schuelerold} | Remove-WmiObject  
Set-ItemProperty -Path . -Name "LastUsedSchueler" -Value $schuelernew   
Set-ItemProperty -Path . -Name "DefaultUserName" -value $schuelernew -Type String  
Set-ItemProperty -Path . -Name "AutoAdminLogon" -value "1" -Type String  
Stop-Transcript