December 1, 2016 at 8:56 am #13796
We have a Folder Redirection defined in a GPO. We also have the ‘wait for network’ setting enabled in another GPO. Both GPO’s are applied correctly, confirmed with several tools.
Still we see error 1274.
The machine is a W2k12R2 Citrix server.
What can cause this issue?
Han.December 1, 2016 at 3:55 pm #13797
What that’s telling you is that you need to log in twice as the user in order for Folder Redirection to take effect. That message is not really an error so much as its telling you that Folder Redirection is one of those extensions that require a foreground refresh (i.e. a re-logon) in order to take effect.December 1, 2016 at 10:06 pm #13798
First of all thank you for your time trying to help me.
Maybe I’m missing something but it is my understanding that if you have the computer setting “Always wait for the network at computer startup and logon” enabled in a GPO and one can confirm that this setting is applied with tools like gpresult, registry, etc, there is no need to logon twice because this setting is forcing foreground processing. Still we are seeing error 1274.
Am I missing something?
Han.December 3, 2016 at 11:24 am #13799
First question is, are your users experiencing that Folder Redirection doesn’t apply at first logon? If so, are these new user accounts that have never logged into that server? If so, I suspect this has to do with the new user profile creation process, but I probably need to understand more what you’re seeing. You are correct in assuming that the “always wait for network…” policy forces all foreground processing to be synchronous, however, note that if you apply a Folder Redirection policy to a user who is logged in, then when background processing kicks off, you will see that 1274 error simply because the Folder Redirection CSE is telling you it can’t apply in the background. So you may not actually be seeing an error so much as information.
DarrenDecember 7, 2016 at 12:36 am #13802
I’ll try to describe the relevant part of the environment.
Users connect to a Citrix XenApp farm. The Citrix servers are rebooted every night which is quite common. The Citrix servers are virtualized on Hyper-V and are provisioned by Citrix Provisioning Services (CPS). It is configured in such a way that the Citrix VMs servers boot from an small ISO which causes them to contact CPS which in turn presents a VHD from which the Citrix VMs ultimately boot. This process means that changes that happen during the day, e.g. temporary files written, are discarded when the VMs reboot at night.
When a user logs on the Citrix software takes care of downloading the appdata part of the user profile to the Citrix server before the desktop is presented. On top of that some folders like desktop, documents etc. are redirected to a file server.
So maybe one could say that in a way users are always logging on to a fresh OS. But I must say I’m not certain if this is a correct assumption.
I.m.h.o this should mean that since the “always wait for network…” is a machine policy, it gets applied at VM boot.
I have confirmed that the policy is applied.
Question remains why do I see Folder Redirection warnings?
So should I care about these warnings?
Is testing folder redirection as simple as writing something to a redirected folder and monitoring the file server to see if it gets there?
Han.December 13, 2016 at 4:02 pm #13813
Folder Redirection only processes in the foreground (i.e. at user logon). I suspect you are seeing these messages coming from periodic background refresh. There may be some issues here in your virtual environment that I’m missing, that are causing FR to not process on the first logon. Enabling the gpsvc.log trace file might show in detail the order that things are happening. You could also verify that synchronous processing is going to happen before you log on as the user. Our GP Health Reporter freeware tool returns that information when you run it against a target system.
DarrenDecember 27, 2016 at 8:35 am #13823
I’ve used GP Health Reporter to have a look at several terminal servers and I found some strange results:
On more than one TS GP Health Reporter reports a GPC/GPT version mismatch for ALL GPO’s…
When looking with ADSIEdit and Explorer (gpt.ini) at the version numbers of an affected GPO they match!!
When inspecting the version numbers manually I used the same DC as reported by GP Health Reporter.
Also GPResult does not report any issues and DFSR/sysvol health is reported good by dcdiag.
Ran the GP Health Reporter as Administrator.
Any idea what can cause this?
Han.December 30, 2016 at 2:40 pm #13831
It’s a known issue on Win7 and 2008_R2–the place that Health Reporter reports which GPC and GPT versions have been processed got broken by MS with some past update and we haven’t updated GP Health Reporter yet to reflect that. I am hoping to get an update for it out soon after the new year starts.
You must be logged in to reply to this topic.
- Understanding the Registry Policy Archive File
- Hijacking Administrative Templates
- What Does Group Policy Do When It Can’t Contact a DC?
- Sending GPOs Down the Wrong Track–Redirecting the GPT
- Group Policy Security– Tinkering with External Paths