GPO not applying over VPN (openvpn)

I cannot get GPO to apply to a machine over a VPN.  We are using OpenVPN that is part of our corporate firewall.  The openvpn client on the remote machine is configured to connect to the corporate network on computer start-up.  With this configuration I can joint the domain, manually run scripts to map network drives, log on with domain credentials and i can even ping the remote machine from the corporate lan.  But GPO is not applying.  I modified a policy and enabled detect slow links.  Do I need to do this on every policy or just one in that OU?

Also note that the remote machine gets an IP address in a different range than the corporate LAN and the firewall/openvpn server handles routing (LAN ip 192.169.x.x and VPN 172.16.x.x).    I can do a tracert from both ends and get there in 2 hops so I don't see routing an issue.  Is there some other setting in Windows 2000 AD/DC that needs to be set to allow GPO over a different IP than the DC itself?

OpenVPN installs a TAP-Win32 adapter in the client machine and the DNS address is set to the IP address of the DC.  

From the remote machine I can ping both lan IP and lan FQDN.

Any Suggestions?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Have you tried running gpupdate /force on the remote computer then rsop?  
PlazaPropAuthor Commented:
Yes.  it seems like it is updating.  There are no errors in the command prompt window.  It says that both have completed.  

Checking the event log shows event id 1054: Windows cannot obtain the domain controller name for your computer network (An unexpected network error occurred.) , Group Policy processing aborted.

The computer time is only 1 min. difference so that is not the issue.

Since I can log in with domain credentials I am assuming that I shouldn't have to worry about any specific TCP or UDP port to be open on the firewall (both software and hardware firewalls). what about ICMP?

Is it possible that it's trying to update policies via the primary ethernet connection (ISP) DNS server as opposed to the TAP Win-32 adapter which the VPN is on?

I can connect to the domain controller by using \\\sysvol\  - so seeing the DC is OK.

If I do an NSLOOKUP, the authoritative answer is coming from the DC.

RSOP only allows me to run for the localmachine\localuser and not domain\domainuser.  The computer policy does not apply and the error given is "an unexpected network error occurred".

A couple places I have read make references to ICMP and slow links.. So I am looking in to that also.

PlazaPropAuthor Commented:
Right after I posted the last message I found this article:

Below is the relevant section which I followed and it seems to be working so far because a couple of the policies applied. Some others are not applying but I have read that somethings like software installations and scripts will not run.  Which is part of what I need to do, at least be able to run scripts.

This "slow link detection" can be disabled via group policy, but how
do we push an updated policy to clients that can't update their group
policy information??  (!)

  The solution to this, other than re-enabling ICMP in some way, is to
set the registry key manually on the clients - which can be done
remotely even if the block is in place.  The value you need is named
"GroupPolicyMinTransferRate" and it needs to be set in two separate
places, which are listed below.  This value needs to be set to (DWORD)
ZERO to disable slow link detection.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Open in new window

The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

One thing...

The subnet for your remote site should be listed under Sites and Services.
If the remote site is really part of your main site, then the subnet should be enumerated there.
If you choose to install a DC in the remote site, then you should create a name for it, seperate from your main site, and assign the subnet there.

The problem you are having may be that the DC authenticates people ok, but cant process policies because it doesnt know what site your remote boxes are in...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
PlazaPropAuthor Commented:
In AD Computers and users the computer was added when I joined the domain over the VPN.  Then I created a new OU to house that group of computers.   I was unable to ping using FQDN so I added the firewall IP address as for WINS resolution for the top level domain (we have only 1) and the computer now shows up in DNS with the VPN IP address. Now I can ping that machine by IP, computer name, and FQDN.

 In Sites and Services I defined our local subnet and paired with with the default-first-site-name (our local lan).  Then I created a new site called "remote-sites" and defined the subnet for the VPN IP range and paired it with the remote-sites.  There is no DC at the remote site/sites.

The defaultipsitelink includes both sites.  

Or should I have associated the VPN IP address range with the default site?
If you dont have a DC in the remote site...then you should associate it with the Default site and not bother with a link or anything...

Sites are defined because they have a DC and the links are defined in ordrer to teach them how to replicate in your topology.

Better yet---spin up a DC in the remote site..
PlazaPropAuthor Commented:
The user portion of the GPO was applying but not the Computer portion.  After further investigation I found that computer GPO will not apply because these are processed at start up and since the VPN doesn't actually connect till after start, this makes total sense. I suppose the only way to get a full GPO is to establish the VPN connection on the edge with a router the way there is already a "live" network connection. (or install a DC but this option doesn't make since with 21 locations with only 1 to 3 computers)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows 2000

From novice to tech pro — start learning today.