In der privilegierten Powershell:

Reset-ComputerMachinePassword -Server DC -Credential domain\administrator

C:\Windows\System32\tdlrecover.exe -reregister -resetlayout -resetcache

Evtl. hier noch mal in der Registry gucken:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage2 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband 

Es gibt auch noch folgenden Hinweis, wenn gar nix geht:

reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules /va /f
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System /va /f

• SQLExpress auf einen Server (nicht DC) in der Ziel Domäne installiern
• ADMT dort installieren
• in der Powershell mit ad folgendes ausführen: admt key /option:create /sourcedomain:alte.domain /keyfile:C:\Temp\PWKey /keypassword:*
• pwdmiga auf dem Quell DC installieren (einmal neustarten)
• Vertrauensstellung zwischen den Domänen herstellen
• Administrator der neuen Domäne zu den Built-In Administratoren der alten Domain hinzufügen
• ADMT ausführen und Nutzer mit Gruppen migrieren

Exchange

• Mailflow regeln…
• Enable-MailUser
• alter Exchange EWS Proxyemndpunkt aktivieren
• prepare-moverequest pro user ausführen (siehe unten)
• Migrationsjob im neuen Exchange starten
• Mailflow regeln…

$Local = Get-Credential
$Remote = Get-Credential
.\Prepare-MoveRequest.Ps1 -Identity test.user@newdomain -RemoteForestDomainController dc.olddomain -RemoteForestCredential $Remote -LocalForestDomainController dc.newdomain -LocalForestCredential $Local -UseLocalObject -OverwriteLocalObject

Methode 1: Update deinstallieren

Nach dem Deinstallieren von (KB4480970 (Rollup) oder KB4480960 (Security) oder KB4480966) funktioniert sollte der Zugriff wieder funktionieren!

Methode 2: User aus der Gruppe der Administratoren (bzw. anderen administrativen Gruppen wie Hauptbenutzer, Sicherungs-Operatoren etc.) entfernen (bevorzugt)

Das entfernen des Users aus administrativen Gruppen am Server sollte gegen das Problem helfen.

Methode 3: Workaround wenn der User Administrator am Server ist und dies auch bleiben muss.

Wenn der User der auf das W7 zugreift ein Administrator auf dem System ist welches das Share anbietet folgendes auf dem Server welcher das Share anbietet, in einer elevated cmd ausführen:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Danach zwingend ein Reboot durchführen!

Es tritt also nur auf wenn der User Administrator auf dem System ist welches das Share hostet, solange er normaler User ist, ist alles OK, also hat MS hier das was bisher nur für die administrative Shares galt, nun auf andere Shares ausgeweitet. Ist also genau genommen kein Fehler sondern nur eine Ausweitung der Sicherheit auf normale Shares.