Office App pinning not working with redirected folders

[HCHTech]

I've run into a problem with some (not all) users at a clients where they have a domain and are redirecting the user folders (Desktop, Documents, Appdata\Roaming) to a server share (running Server 2022). Basically, the problem users can't pin documents to the Office app icons on the taskbar. If you do this, it looks like it is working, but right-clicking on the (for example, Word) icon does not show any pinned documents or recent documents. The icon itself works to run Word, just not the pinning business. I've also noticed that if I REMOVE an office icon from the task bar, I cannot re-add it. Uninstalling an reinstalling office lets me re-add it.

The server share was created according to a Microsoft technote - I don't have the reference handy but can find it if that would help). The folder redirection is being done with a single GPO that applies to everyone.

In searching for this problem, I've found the note to create the "Inkfile" registry key and following "IsShortcut" data, but this didn't work (and doesn't exist for the users where the pinning is working as expected). I've checked the permissions on the user share and they are the same comparing a working user and a non-working user (That domain user and the SYSTEM user have full access, no other accounts have any access). I've tried uninstalling and reinstalling Office (Microsoft365), but that doesn't help either. I've done sfc/scannow and DISM repairs, also no help. All users are on Win10 Pro 21H2. All users have the same antivirus and EDR, and nothing is being flagged.

This isn't a common problem, apparently as my searching has reached a dead end. I'm out of ideas. Has anyone run into this or thought of something clever I can check next?

Oh, one more thing that may be relevant. A few users have reported that occasionally one or more taskbar icons show up as a blank white rectangle on a reboot - still working, just not graphically correct. Usually it just fixes itself after a fashion, and sometimes another reboot will fix it. Other times, it hangs around for a few days and then is suddenly better. These users are not the users with the pinning problem, so I have written this off as just some timing issue with the folder redirection.

 

[Blues]

I am thinking I remember something like this where is was due to the system not reading a file or having a bad file in the AppData folder so it might be due to that redirect or corruption in that folder which could be caused from the redirect. You could try forcing the computer to rebuild that folder or try making it local for any problem users to test.

 

[HCHTech]

You could try forcing the computer to rebuild that folder

Is this as simple as just deleting the contents of the server-based appdata directory for a user? The taskbar icons are underneath that a bit:

\\SERVER\UserDataShare$\User\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar

Maybe just delete the contents of the TaskBar folder?

 

[Blues]

Unfortunately no as we have no way of knowing that there is no cached resource so I would ensure both server side and cached are gone, though I would copy/back up the folder, this should force the rebuild.

 

[HCHTech]

Hmm - ok, stuff to try. I could try disabling offline file sync, which would force the network copies to be used in all cases. The local cached copies are stored at c:\windows\csc, but it doesn't appear that directory is accessible by the user - I'll have to check out the security settings on that. I wonder if disabling offline sync will just clear this on it's own. Also, from the server directly, a domain admin account also doesn't have access to the individual user shares, unusual but by-design I guess. What a pain. I'm wondering if it just makes sense to disable redirection altogether for this user, making sure everything works again, then re-enabling redirection. Gotta love these trial & error projects!

 

[YeOldeStonecat]

Back when I used to do folder redirection of user folders....I had found a powershell script I'd run to fix those permissions if they were setup by someone else and the domain admin did not have access to the folders. No way I was managing that client without having access to all user folders.

Adjust creds and paths as necessary.....like "ADDOMAINNAME" is short name of local active directory.
I haven't used this since....Server 2012r2 most likely, but hopefully it still works on modern server OS's.
I used to only do Docs/Desktop/Pics/Favorites when I did redirection, didn't like doing appdata due to quirks if users used mixed computers.

*******************************************************************
ChangePermissions.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir= "E:\ServerFolders\Folder Redirection"

$Principal="ADDOMAINNAME\Administrator"

$Permission="F"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Permission.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
#display filename and old permissions
write-Host -foregroundcolor Yellow $file.FullName
#uncomment if you want to see old permissions
#CACLS $file.FullName

#ADD new permission with CACLS
CACLS $file.FullName /E /P "${Principal}:${Permission}" >$NULL

#display new permissions
Write-Host -foregroundcolor Green "New Permissions"
CACLS $file.FullName
}
}

 

[HCHTech]

didn't like doing appdata due to quirks if users used mixed computers.

Thanks for the script - I'll check this out - it looks like you are just adding the Domain Administrator with full permissions to all redirected folders. In my case, this is already the case, if you look at the actual permissions on those folders, so I'm not sure why I can't open the AppData folder from the server when logged in as domain admin. I thought it might have something to do with making the redirected folders hidden or something. I CAN access the rest of the redirected folders as domain admin, so it also might just be something special Windows does to the AppData folder itself that gets challenged somehow with a redirect.

Redirecting Appdata\Roaming in addition to the other folders makes the user experience the same (including the taskbar) regardless of where they log in. At their own office computer, at another shared office computer, remotely to the RDS server, remotely to their office computer, etc. etc. When it works, anyway. That was the original goal of this design, and mostly it works. Some occasional....quirks, like you say.

 

[Blues]

The quirk of the permissions was something I recall from redirects as well where despite inherited permission settings and other settings individual folders would often be locked to the user and would need to force permissions to propagate with scripts like what @YeOldeStonecat posted.

 

[HCHTech]

@YeOldeStonecat : In this section:
$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Permission.ToUpper()"."`n `

what is the 'n supposed to be? Something didn't copy correctly...

 

[YeOldeStonecat]

Gimme til tomorrow to find it.....guess the double copy 'n paste went bad....

 

[HCHTech]

No problem - it appears I can do the same thing with SysInternals PSEXEC. I think we're on the right track with the permissions not having been set correctly or later scrambled. It fits the symptoms.

 

[YeOldeStonecat]

Double checked....I just opened the .PS1 file on a server I ran it on years ago..and that's what it has. I'm not sure what the 'n is...I found the script somewhere probably 12 or more years ago (probably on Reddit)...and have used it a good handful of times.

 

[HCHTech]

This is definitely a permissions issue. I did reset some of them and added domain admin with full privileges to everything using PSEXEC, but that didn't change the problem user's symptom. I moved their user back out of the OU that had the GP assigned so it would go back to local data until I figure this out - the pinning worked immediately once the data was local again.

I think I'm going to try and find out what exact permissions are needed for the pinning to work - if that's even a thing that is possible to find out. And, maybe it's not possible to replicate that on a server share, I don't know. It seems like if something was setup wrong on the main share, then no one would work, but in fact it works just fine for 25 users, but 2 or 3 others have this problem. I'm starting to think it might be easier to N&P their LOCAL machines as a troubleshooting step.

It even occurred to me that because the folder under which the taskbar stuff lives is named INTERNET EXPLORER, that this whole thing might have something to do with the decommissioning of IE.