@ulf_sch, no GPOs were changed.
Initially, I stopped and disabled Offline Files service on the affected computers to allow logons.
Then I experimented. I reset the Offline Files cache by setting the registry entry I described, re-enabling the Offline Files service and rebooting. Also described here as Method 2: https://support.microsoft.com/en-us/help/230738/how-to-re-initialize-the-offline-files-cache-and-database-in-windows-x.
I had wondered if that would help, and another post here suggested that it did, although in a different context.
I found users could work normally, and redirected folder data was syncing to the server. However, a drive mapped (by Group Policy Preferences) to a DFS share did not work. The drive was present but couldn't be browsed. If I browsed the DFS root, I found
the only DFS share present was the folder redirect share, and that only because Offline Files was on and it was offline but cached. On the affected machines, I ran a script that unmapped the drive and then remapped it to the non-DFS share to which DFS redirects:
NET USE S: /D
NET USE S: \SERVER\SHARE
I'm running the script from the Startup folder of the Start menu since it is (I hope) a temporary hack, only 4 computers were involved, and I didn't have confidence that what worked on one machine would work on all of them. I left Group Policy alone for
the unaffected machines. On a large site, I'd probably use Group Policy to reset Offline Files, enable the service, and remap the drive, and then scope it to affected machines one at a time and verify it worked.
Generally speaking, the remainder of the DFS shares come back after a while, and I suspect that it's when Offline Files decides to online the shares. That seems to take a while after logon on affected machines. On non-affected machines, I don't think the
shares are ever offlined.