RSOP data not being created / policy not applied

tsunami55tsunami55 Member Posts: 7 ■□□□□□□□□□
Hey guys,

I've gotta weird problem maybe someone can help. This is a little long please stay with me.

we have a single domain running off of a win server 2003 dc, We have remote sites connecting over VPN, the VPN servers are draytek vigour routers, the VPN type is ipsec tunnel.

all site computers are part of a workgroup (not the domain) and
All site users were connecting to a terminal server at head office through the VPN's. I decided to connect one site up to the domain instead of using terminal services. This meant that the site was going across the wire for DNS resolution and domain logon. This wasn't a problem (very few workers at the site) and it all worked well i.e. logons work fine name resoution was fast etc. Until i realised group policy wasn't being applied to the remote computers. I ran the RSOP.msc tool on a remote system it said that RSOP data is unavailable possible reasons include

'The policy object does not exist”. “RSoP data invalid. Likely causes are, data is corrupt, data has been deleted or data has never been created.'

I've checked remote systems can contact the dc no problem, resolve internal and external names no problem, nslookup can resolve srv records no problem and systems can connect to the sysvol folder. Computer accounts are being created in AD as well. The vpn servers arn't under heavy load or anything. one weird thing is that on occation when i run nslookup on a remote system sometimes this gets forwarded to the prisoner.iana server (which to my knowledge catches name resolution leaks for private subnets). the Routing tables are fine though.

the main office subnet is
the remote office subnet is
typical remote system tcp/ip config is

I.P -
netmask -
gateway - (vpn server as well)
dns server -

I don't have an awful lot of freedom with this. I was going to try a 2003 box as a router but I can't really mess with the hardware, only the configuration. All computers based at main office work flawlessly.

few extra details if helpful.

No DC's at sites
No Site / subnet objects created in AD S&S
netbios broadcasts are forwarded by routers
tight budget - can't spend any money, just wondering if anyone had any ideas??

All help as always is appreciated

A+, N+, MCP - 270, 290, 294 Working on 291


  • sprkymrksprkymrk Member Posts: 4,884 ■■■□□□□□□□
    If you run a gpresult on one of the clients, does it show up as a slow link (<500kb)? That can cause some group policy processing issues but still allow dns and such to work. Actually, if it detects a slow link, it's still supposed to do most everything except stuff like software distribution.

    Have you checked the client event logs? How about trying to run gpupdat /force on one of the clients and see if kicks up an error?

    You may also want to run a netdiag and see what the output is for a client.
    All things are possible, only believe.
  • tsunami55tsunami55 Member Posts: 7 ■□□□□□□□□□
    Hey thanks for the response,

    I don't think this is caused by slow link, we don't push software thru policy, it's only security rights and homepage settings for IE etc.

    the event logs show a usernv error

    Windows cannot query for the list of Group Policy objects. A message that describes the reason for this was previously logged by this policy engine.

    the entry this refers to mentions it cannot find a DC to logon to however i know this not to be true as i can access sysvol etc remotely also i can query all common srv records with nslookup

    netdiag describes no errors and gpupdate /force says it completed successfully, this is SO FRUSTRATING
    A+, N+, MCP - 270, 290, 294 Working on 291
  • AhriakinAhriakin Member Posts: 1,799 ■■■■■■■■□□
    A lot of repetition but when I get stumped I like to do everything from scratch - As it's easy to do stop/restart netlogon service on the DC as this will force it to re-register it's service records, it's not likely to have been an issue but like I said, easy to do and worth ruling out. I'd remove a machine from the domain manually, doublecheck the account is gone from the DC, then add it again. Make absolutely sure the new machine account is showing correctly on the DC, run SET from a command prompt on the PC and verify your DC is listed as the logon server. Check the DNS server on the DC and make sure the PC is registered correctly, ping both from each other by name. Check your Site topology on the DC, make sure the correct links are in place and that they do reflect the quality of your links. Make sure the time on the DCs and remote PCs are sync'd (they should be automatically but again make sure). Make sure you don't have any odd modifications to the security settings on your GPOs, that they aren't just applied to certain machine or user groups.
    Nothing concrete I know, just a quick check list of what I'd try if I was in front of them.

    Are those VPNs always-on site-site tunnels or remote-access, just wondering if some latency in the tunnel startup could be causing issues for some machines when they try to logon, or when the DC tries to contact them and they haven't initiated a tunnel to the head-end site?
    We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
Sign In or Register to comment.