gpresult - INFO: The user does not have RSoP data.

[Cerulean]

When doing a 'gpupdate', this is what happens:

Updating policy...



Computer policy could not be updated successfully. The following errors were encountered:



The processing of Group Policy failed. Windows attempted to read the file \\company.local\SysVol\company.local\Policies\{98D407C7-829A-4E34-91CF-9FDB0781A4BC}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:

a) Name Resolution/Network Connectivity to the current domain controller.

b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).

c) The Distributed File System (DFS) client has been disabled.

User Policy could not be updated successfully. The following errors were encountered:



The processing of Group Policy failed. Windows attempted to read the file \\company.local\SysVol\company.local\Policies\{98D407C7-829A-4E34-91CF-9FDB0781A4BC}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:

a) Name Resolution/Network Connectivity to the current domain controller.

b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).

c) The Distributed File System (DFS) client has been disabled.


To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

When doing a 'gpresult /R' or 'gpresult /H blah123.html', this is what happens:

INFO: The user does not have RSoP data.

I don't know what changed on the network or in GPOs to do this, but I have no doubt some consultant (whom I don't even know of, working through a consultant co-worker) did something. Last week gpresult was working fine, this week it has been giving the above. Any ideas?

I have noticed that as of the beginning of this week, when I login as any user, their profile from \\abc-persona.company.local\Profiles\%username%\ no longer gets copied to C:\Users\%username%\ -- no Desktop, Favorites, Documents, etc. All it has now is like 3 folders (Link, Searches, and something else). Does this sound like caching got turned off?

 

[gimp]

I don't think you can turn off cachine for roaming profiles.
Unless you're doing folder re-direction, which would be a different beast I haven't toyed with.

So, as the user, can you access those file shares if you access them via Windows Explorer?
That would be the first very simple troubleshooting step.

 

[Cerulean]

So, as the user, can you access those file shares if you access them via Windows Explorer?

Yes.

We have an O: drive automatically mapped to \\abc-persona.company.local\Profiles\%username%, and even if I do O: and then a gpresult command, I still get the same message.

And yes, profile redirection is happening. That has always happened, its just that 1 week ago it was doing that + caching / storing a copy in C:\Users\%username%\ (almost as if it were a symlink).

The VDIs are on a pure-SSD datastore, whereas the abc-persona.company.local\Profiles is on a big 10-disk 15k SAS RAID10 datastore.

 

[gimp]

I haven't done profile or folder redirection, so I'm no help there.
We only have roaming profiles at a couple sites.

Can they browse to the sysvol share that the gpresult error is talking about?

 

[k1pp3r]

Can you UNC to the sysvol share? And is the policy in there?

Also check what their logon server is and that is where you want to check the sysvol on the DC

 

[Cerulean]

Well hot diggity. :|

User can access \\company.local\SYSVOL\ and proceed to \\company.local\SYSVOL\company.local\Policies. I looked up the GUID of one group policy in question (at the time of writing) for not working like it should, so I thought "hmm, I wonder if the two DCs are not replicating the GPs"

We have one DC at 172.16.99.75, and DC#2 at 172.16.99.25. I browsed to \\172.16.99.75\SYSVOL\company.local\Policies and compared it to that at \\172.16.99.25\SYSVOL\company.local\Policies -- the group policy in question is in one, but not the other. The DC that it isn't in is also \\company.local\SYSVOL\company.local\Policies (because it wasn't there either).

I suppose fixing this would probably also fix gpresult/gpupdate. Will be back with news later.

 

[Grentz]

I was going to say, this is a replication error between DCs most likely.

Your policy is not getting applied, hence you are seeing the profile issues, but the profile issue is not the root cause.

The GP policies are off of those files, and when they are not in sync between DCs you will have issues. It usually comes down to issues with DFS, which AD uses a form of to replicate between DCs. You can see details on this using dcdiag. DNS issues can often lead to replication issues as well.

Do note that there are two forms of AD replication, the DFS model that is in use by more modern domains, and FRS (file replication system) in use by older domains.

 

[gimp]

machines will connect to any DC that's included in a site.
So if you have 5 DCs within the same site, any machine could communicate to any of the 5 for authentication and group policy refresh.
Therefore, when you do a \\company.local you could be hitting either DC.

It just so happend that those machines, including yours, were hitting the one with the missing policies

 

[Eickst]

I was going to say, this is a replication error between DCs most likely.

Your policy is not getting applied, hence you are seeing the profile issues, but the profile issue is not the root cause.

The GP policies are off of those files, and when they are not in sync between DCs you will have issues. It usually comes down to issues with DFS, which AD uses a form of to replicate between DCs. You can see details on this using dcdiag. DNS issues can often lead to replication issues as well.

Do note that there are two forms of AD replication, the DFS model that is in use by more modern domains, and FRS (file replication system) in use by older domains.

This^ Check the event logs on your DC's for replication errors.