This message was deleted.
# microsoft-fslogix
s
This message was deleted.
b
@Tim Riegler also noticed that running
Copy code
gpupdate /force /target:user
after login will populate the user policy
f
Same issue W2016/CVAD1912, workaround with WEM to refresh policy at user logon
b
@François-Xavier Rigaud is that a check box that I'm missing, or is it an external task that you manually setup?
s
Im so glad to read this. I thought it was me
@François-Xavier Rigaud how do you do that refresh in WEM?
f
@BobFrankly @stormlight External task
b
okay, thanks, I'll try that.
@stormlight add to the msdn link at the top of the thread. Make it heard
s
will do, Is there a command switch to say No to when GPupdate force asks for a user to log off because of certain changes
b
same thing I'm wondering 😛
f
cmd /C echo N | gpupdate /Target:User /Force
s
that goes all in one line in the path line?
r
So is it not applying users gpo at all?
b
ray: nope
if I move the machine to an OU where FSL doesn't have active policies, and reboot, the issue disappears
ofc, then you don't have FSL
r
Going to check mine. When did this occurr? Was it related to any Citrix 1912 upgrades?
So fslogix related then if you move it and it works then stops. Hmmm
b
I've seen it with two separate FSL versions. 2.9.7237.48865 and 2.9.7205.27375
r
Or bad admx files?
b
I'm building my image with MDT
r
Sadly I build manually for now
b
I've got two build paths....one that uses BISF to capture the image to PVS , and I see the issue in that one, but not the non-pvs build
but it's also possible that the issue doesn't produce for single logins, as the PVS capture is the only one that has multiple testers
#tooManyVariables
r
Yes sounds that way
b
which is why I'm looking for others who are dealing with this. Looking for commonality
f
MCS image here
b
@François-Xavier Rigaud are you using citrix optimizer at all?
f
@BobFrankly Yes
b
I should deactive that in my build oh, that hasn't made it into my task list yet...
@Ray Davis Do share your results. I'm curious how many cases of this there are hiding out there
r
I will share not a problem.
😁 1
r
wasn't this the problem with cloud cache?
b
Dunno, but I don't have cloud cache configured in this env
r
then never mind. 🙂
r
I hope it's not another fslogix issue. Seems to be some buggy software lately.
b
new devs joining the stable since the MS takeover...it would make sense
r
😢😭
b
I'm still trying to get my env into a function test with this, but user policies are kind of a big thing
r
Yes that's a huge deal. Once I get home I'll double check.
b
I give you permission to leave now 😎
r
LMAO
d
Are you absolutely sure it’s related to FSL? Do you have loopback mode enabled? Try to reproduce it by disabling one policy after the other. Check with gpresult after each. I’ve seen similar issues and it was because of one bad policy.
b
@Dennis first login without an FSL disk created gets policy. second login WITH the FSL disk doesn't. Trash the FSL disks for the user, and the policy is back on that first login. I'm not saying it's definitely FSL, but that's where the indicators are pointing, and I'm not the only one to report it. That said, I AM still doing further troubleshooting.
t
@Dennis I'd imagine if it was one bad policy there wouldn't be nearly as many people reporting it. We just went through all of ours again (due to that lock debacle last week), and nothing else has changed.
n
Is this only seen on 2016/2019? I haven’t seen this issue in W10, though I’m on FSL 2.9.7117.27413 (1907).
d
Hmmm, weird... I can’t remember seeing this before or was it never noticed???
e
Saw the same today, latest version & ws19, no cloud cache. I thought ghe customer screwed up the system cause not GPOs applied. Did an automated rebuild before leaving for the day. Will test the WEM external task.
r
I am running 2.9.7342.30109 and I have users GPO
This verison isnt released yet, I am running it to fix my random reboots. I will check my other versions as well.
On full PROD 2.9.7237.48865 W2K16
e
Confirmed, before
j
Same problem 😞
on Windows 2019
n
Which version of FSL are you running?
j
2.9.7237.48865. I have same error on gpresult but GPO seems applied. No errors in GroupPolicy event viewer
b
if your experience lines up with the rest, you probably got GPO applications on first login while the FSL disk was being built, but not on any subsequent logins
t
Is it verified that policies are in fact not applying? Or are policies applying, just not showing up in the gpresults?
b
I added policy, didn't see the expected impact, and checked gpresults. That's what sent me down this rabbit hole to begin with
tossing the profile got the policy applied, but obviously that's not a sustainable solution 😛
t
Ok. Figured it was worth the ask / validation,
b
absolutely. a wealth of information may help us corner this thing
b
I don’t appear to be having the problem with WS2019
r
What would cause this in some and not others? Bad downloads to the installer?
I could see if maybe one or two have bad gpo applied. But every other user?
t
That's my point! What's the commonality?
e
Since its happening on all OS'es it might be a Windows Update thing. Latest FSlogix version and patches breaks the GPO as stated.
Did a new build with 2.9.7117.27413 without Feb 2020 WU and now GPO works, even Search 🙂
n
And that's why I'm still on 7117 (1907). I'll upgrade once the rest of you work out the bugs. 😄
👍 2
😂 1
e
MS should create Stable, Dev and Beta 🙂
n
We ARE Microsoft's Stable, Dev, and Beta testers...
😫 2
t
@Eric are you using Cloud Cache? That was the main reason we moved to the latest version. Otherwise, we'll have to look into rolling back our image. Nice job!
e
Luckily not, I know your reason. Just fully patched with CU 02/2020 and it still works. But as you said this one is very strange. I have customers running with all kinds of versions and OS, but just this week did we get that GPO issue on WS2019. So I prefer to go stable, will downgrade customer today and let yah know.
👍 1
t
How'd the downgrade go? I'm seeing really inconsistent results. First login is universally good, then after that it's a crap shoot. Some logins may work (1 or 2, typically), then it will stop, then another login later in the day (same profile) and GPOs will show back up.
🤨 1
Downgraded to 2.9.7117.<whatever>, and the gpresults are working correctly again. We will be rolling this to Prod tonight.
😲 1
b
I also downgraded to 2.9.7117.27413, and I'm seeing user policies apply in single user testing.
in testing last week, it looked like turning off inheritance blocking for my XenApp OU also changed user policy application, even though the user policies and loopback were within the OU. Are any of you who are seeing the issue using Inheritance Blocking on your OU?
f
Inheritance blocking with replace loopback processing mode
b
so that's 3 of us...
@François-Xavier Rigaud Can you try kicking down to 2.9.7117 ?
t
Prod looks good today. GPOs are being applied correctly with 2.9.7117.
b
Seems like we're narrowing it into: "newer FSLogix versions don't apply user policy after first login, IF the machine OU is nested in an 'Inheritance Blocking' OU" But I'd like to see a few more proof cases.
f
@BobFrankly Sure, will test it tomorrow Little worried about downgrading Prod as we are using CC
b
Francois: outside of missing user policies, is your env stable? Just gathering details to try to corner this thing 😛
t
@François-Xavier Rigaud we use CC too...and the latest version on 2016 was causing other problems. There is another thread in this channel I have about that debacle...
f
Yes, only thing that does not work is "Attempt RW/Fall Back RO" for concurrent connections (absurd login time)
t
Ahhh...we have published desktop and only allow a single session.
f
In case the server goes down, one may fall to RO
t
In case which server goes down? The file server hosting CC? Or a XA host?
f
@Tim Riegler VDA, in case of deadlock for example It's another topic but I am open to suggestions to handle this scenario
t
Ah, that was the problem we were having with the latest FSL on Server 2016. We use Windows file servers, so were able to run a script to remove open file locks on those so users can log back in. We also use the frx tool to prevent login if profile is locked.
f
@Tim Riegler Thanks !
b
FWIW, we’re using loopback with replace, not blocking inheritance, using I2.9.7237.48865 with VHD location (not CC) and not having issue.
b
@Brandon Mitchell so your users get user policy?
b
@BobFrankly correct, user GPOs are applying.
b
so that holds with the theory so far, thank you for sharing
f
Downgraded integration to 2.9.7117.27413, GPOs works
b
thank you Francois
b
Has anyone tried to remove the block inheritance?
b
I did. User policy applied after doing so with one of the newer versions, dont recall which.
e
I had issues without block on latest version running WS19