How can I get GPOs updated through the VPN

Read the solution from here:
 
https://www.experts-exchange.com/questions/21304901/Windows-cannot-obtain-the-domain-controller-name-for-your-computer-network-return-value-59.html 

Thanks, I will check that post and will get back as soon as possible with an update.

DFS shares (that include the sysvol/GPO's records and netlogon records) are not shared out as you might have originally thought. They use Netbios to broadcast out by default. As you probably know, netbios broadcasts are not routable. This means they will not go through a VPN tunnel. But, you can change that. DFS can now use DNS.

DFS through DNS:
http://support.microsoft.com/kb/244380

Really interesting answer, ChiefIT. Thanks.

I was focusing on testing the previous answer from dstewartjr, but, should I assume that even changing the ICMP size cap or adding those two registry keys to the computers, (what is supposed to enable the VPN connected workstation to reach the DC) the GPOs would still not be reached because of the DFS shares limitation?

If this is the case, I guess I should just do both things to test it and ensure this can work:
A)solve the speed test on the workstation side while trying to connect to the DC and
B) make the DFS works with DNS instead of using netbios broadcast.
Is this right?

But this raises another question: if this is the case, how all those wokstations located on IP-VPN sites connected to the main office have been getting the GPOs, provided there is no DC in these sites??
I can not test it right now, since we moved some months ago to a MPLS cloud based network, so no more IP-VPN is in use, but before that, many sites were connected with the main office through an IP-VPN solution, and most of these sites does not have a local DC. Should I assume these computers did never get the GPO updates?

Thanks for your answers.  

I have just tested using a VPN connection and my computer can perfectly reach the shares:

\\<domaincontroller>\netlogon
\\<domaincontroller>\sysvol
\\<domaincontroller>\sysvol\<domain>\policies

or using the domain name instead the domaincontroller:

\\<domain>\netlogon
\\<domain>\sysvol
\\<domain>\sysvol\<domain>\policies

Would this mean that in my case DFS is already using DNS, so the B) part will not be a problem? or this behavior is expected and has nothing to do with the "gpupdate /force" actions in the backend?

Thanks for your help guys.

I have also learned (from MS TechNet) that: "Distributed File System (DFS) Replication is a replication service that is available for replicating SYSVOL to all domain controllers in domains that have the Windows Server 2008 domain functional level. DFS Replication was introduced in Windows Server 2003 R2. However, on domain controllers that are running Windows Server 2003 R2, SYSVOL replication is performed by the File Replication Service (FRS)."

Since all my DCs are running W2003 Server, I would assume that DFS is not in use, but FRS. (Sorry I was not clear on the DC OS versions before).

Could anyone give me some light at these points? How could I be sure the SYSVOL folders are reachable by the "gpupdate" process? Please notice I already confirmed that the folder is reachable from the workstation. This is getting more complicated than what I thought...

All I want to achieve is to be able to run a simple "gpupdate /force" over a VPN connection, I am sure there should be a way to get it working..I will focus for now on the DC connection test failure, since this is clearly interfering with the rest of the process. Would appreciate some further input about the second point DFS/FRS.

Thanks again all for your help!

You have all very good points. Let's see if I can provide answers:

The DFS shares for both Sysvol and netlogon are a part of the FRS replication set between domain controllers. Then, the site's DCs shares them out via netbios.

So, you are correct in saying that FRS plays an important role in DFS sharing.

But, in your case, you don't have a DC on some VPN sites. So, there is no DC to pass out the GPOs from the sysvol share. So, you can either do one of two things>

1) you can create a WINS or LMhost connection between DC1 of site A and your remote computer.
2) or you can make DFS route over DNS.


This same issue with netbios not being routable, will effect things like the master browser service. So, you may or may not see some computers in "my network places", or you may not have access to some file shares or netshares.

A bunch of us had a debate, not long ago about the importance of WINS and Netbios Broadcasts. We came up to some pretty cool conclusions. You can live without Netbios, but a lot of domain features rely upon netbios, still. Have a look.

Here is an example of exactly what you are looking at:
https://www.experts-exchange.com/questions/23660342/Stations-not-pulling-correct-information-for-proxy-from-GPO.html

The importance of Netbios and the debate we had:
https://www.experts-exchange.com/questions/23517111/Need-confirmation-on-disabling-features.html
 
Setting up a WINS/WAN configuration to accomodate DFS and the master browser service:
http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/net/chptr3.mspx?mfr=true

Oh, and the debate over netbios and WINS importance:
https://www.experts-exchange.com/questions/23520831/Using-WINS-Resolution-and-Net-BIOS-in-a-windows-2003-AD-without-a-local-exchange-server.html?sfQueryTermInfo=1+chiefit+kct+netbio+win

And you will see sooo many people have run into this issue: (this was a bit funny)
https://www.experts-exchange.com/questions/23968417/Cannot-access-share-over-internet-from-Vista-machine.html

Thanks again, ChiefIT.
It will take me some time to read and analyze all this interesting info, and will be difficult to find that time within my already tight schedule of less-interesting things to do!... but I will do it, even after hours, I think this is a pretty interesting topic that I want to fully understand.

The original question was focused on VPN connected workstations (over AirCard, DSL, cable Internet links) trying to run a "gpupdate /force". Even your interesting comments made me think about how those former IP/VPN sites (with many workstations), with direct connectivity with the main site where the DCs are, were retrieving the GPOs updates, I would need to concentrate on the initial topic.

I can't help thinking about these VPN features that enable the VPN connection previous to the logon to the domain, which in theory would solve all my problem (actual login, actual GPO update, right?). After reading all your comments, I am wondering why in that case these topics (DFS shares limitation, netbios, WINS, etc...) don't apply. Would we not be in the same situation?

Also, why can I perfectly get to these SYSVOL and NETLOGON shared folders just fine from my VPN connected computer if I do it from the OS (Start>Run>\\domain\sysvol or \\domain\netlogon)? From your comments, that shoul dnot work, right?

I would certainly like to understand these two points better.

And basically, making one step back, is there any quick win that I could apply to my environment to ensure these guys working through the CheckPoint VPN get the GPOs updated?

If not, I would approach this problem as a much more serious one than I thought. I just thought that I should not be the only one with this problem, and that many organizations using VPN connections for their mobile force would have faced the same situation, so more clear and tested solutions were already out there.

Thanks again for all your help.

Those are good points:

And for some reason, Netbios cache will work for a period of time and then the connections will die on you. You are correct in thinking that you may see no problems for some time and then all of a sudden you get hit with it. Or you may have sites that work perfectly for some time and then die on you.

You are also correct in assuming that you are not the only one. I see problems with netbios connections on a daily basis in EE. In fact, this is the majority of my points with EE, how to get the browser to work over a remote site.

Once I found out that DFS shares also are effected, as well as remote procedure call and fax/printers, I had to investigate these things further. I found out that many IT admins considered this a minor inconvenience until one day they simply got sick of it and requested help.

Group policies, if done locally are saved on the local computer. So, people bring their laptops to work and get the group policies, the policies stay on the computer when they go home. Saved or cached passwords allow you to logon to the domain in the event that the DC is not contactable through the VPN connection. So, you might find that you can logon to the domain even though the netlogon service is not working through the VPN connection.

I am looking for ways to negate netbios. Like Microsoft, who tried to replace netbios with DNS translation, I haven't been able to get every component or service to work without it.  

I see...

But ultimately, those cool festures that Cisco VPN or CheckPoint clients offer, to provide you with a "real domain login" instead of loging on locally and then running the VPN, are really doing its job?

From your detailed explanations, it looks like these features would not work, since it would be trying to use those DFS shares using non-routable protocols, right?

The main problems I am trying to solve for our mobile force are the GPO updates (they basically don't get any change I may make in the GPOs) and the Windows password expiration (they don't get a pop-up message asking them to change it before it expires). For the GPO one, I am right now focused on getting a "gpupdate/ force" running as a post script in the VPN connection (which triggered this current interesting discussion). And for the password one (much more noisy and impacting for the users and the management, HelpDesk calls, etc...) we are actually basically playing proactively and calling the users in advance, before the password expire, using some weekly reports run in the AD.

But I can't help thinking about there should be much more elegant, professional, effective, and easy to manage way of handling these scenarios, since mobility is nowadays a reality out there, and I am sure there are more organizations with a mobile force that are always on the road, like in my case.

Coming back to the first proposed solution posted before by dstewartjr (as detailed in the post
https://www.experts-exchange.com/questions/21304901/Windows-cannot-obtain-the-domain-controller-name-for-your-computer-network-return-value-59.html), I have not been able to get that detailed information in my userenv.log file, even thought I changed the UserEnvDebugLevel all the way to 196610 (supposedly the most verbose logging mode available).
All I get when I run a gpupdate /force when in the VPN, is this:

USERENV(5b8.c94) 11:26:56:609 ProcessGPOs: DSGetDCName failed with 59.
USERENV(5b8.370) 11:27:13:109 ProcessGPOs: DSGetDCName failed with 59.

But I don't see those entries referred to the failed oversized ping. (Am I missing something about the logging level??)
In the EventViewer, though, I still get the messages:

Event Type:      Error
Event Source:      Userenv
Event Category:      None
Event ID:      1054
Date:            2/20/2009
Time:            11:27:13 AM
User:            NT AUTHORITY\SYSTEM
Computer:      <COMPUTERNAME>
Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.

Anyway, I moved forward trying to analyze further the DSGetDCName failure. I decided to use NLTEST.EXE to reproduce the behavior of the DSGetDCName API. So, while in the VPN, I run:

C:\Documents and Settings\<username>>nltest /DSGETDC:<domainname>
           DC: \\<CORRECT DC NAME>
      Address: \\<CORRECT DC IP>
     Dom Guid: *********-abfa-4a56-bf04-4568f81a9e90
     Dom Name: <CORRECT DOM NAME>
  Forest Name: <CORRECT FOREST NAME>
 Dc Site Name: <CORRECT DC SITE NAME>
        Flags: PDC DS LDAP KDC TIMESERV WRITABLE DNS_FOREST
The command completed successfully

I am confussed now. It looks like the API is running and getting all the correct info just fine.
So why when the same API is run from the "gpupdate /force" process it fails and is not able to get the Domain Controller information??

Any ideas?? Thanks again guys.

Did you modify these?
 
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
"GroupPolicyMinTransferRate"=dword:00000000


Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System]
"GroupPolicyMinTransferRate"=dword:00000000  

also read the resolution here:
 
http://support.microsoft.com/kb/910206 

You should also configure this
 
http://support.microsoft.com/default.aspx?scid=kb;en-us;244474 

Hi again, guys.
This is getting more interesting.
I have just done all the changes suggested in the registry, and have run again a "gpupdate /force" from the workstation while connected through the VPN, and the logged message in the userenv.log is different now, but it looks like it is still not totally working:

USERENV(454.128) 11:41:59:500 ProcessGPOs: GetNetworkName failed with 10091.
USERENV(454.128) 11:42:27:625 GetGPOInfo:  Local GPO's gpt.ini is not accessible, assuming default state.
USERENV(454.b90) 11:42:34:453 ProcessGPOs: DSGetDCName failed with 59.
USERENV(454.128) 11:42:53:765 ProcessGPOs: Extensions Microsoft Disk Quota needs to run in ForeGround. Skipping after setting forceflag.
USERENV(454.128) 11:43:19:875 ProcessGPOs: Forced option changed policy mode.

The funny thing is that the output from the "gpupdate /force" asked me for a reboot, after supposedly having uploaded the policies, so it looks like it DID something:


C:\Documents and Settings\USER>gpupdate /force
Refreshing Policy...

User Policy Refresh has completed.
Computer Policy Refresh has completed.

Certain Computer policies are enabled that can only run during startup.

OK to Reboot?. (Y/N)n

C:\Documents and Settings\USER>

Then, to complete the funny history, the eventvwr, is still shows the same message after the "gpupdate /force" that it used to show:

Event Type:      Error
Event Source:      Userenv
Event Category:      None
Event ID:      1054
Date:            2/21/2009
Time:            11:42:34 AM
User:            NT AUTHORITY\SYSTEM
Computer:      NOAMNNYRUBIOJ04
Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.

BUT: it used to show two messages like this, and now is just logging ONE, while immediately registering an INFORMATION entry stating:


Event Type:      Information
Event Source:      SceCli
Event Category:      None
Event ID:      1704
Date:            2/21/2009
Time:            11:43:19 AM
User:            N/A
Computer:      NOAMNNYRUBIOJ04
Description:
Security policy in the Group policy objects has been applied successfully.

So, basically, it looks like something is being done, but still some other things are not working totally fine.
How could I isolate the pending point? What am I missing here? Could it be the fact that I did not accept to reboot after refreshing the new set of policies? I would assume that that would just postpone some of the new policies to be applied, but apart from that.... also, the ERROR is logged in the eventvwr BEFORE the INFORMATION (successfull GPO applied) entries.

Any ideas about how to proceed from here to complete this interesting and really important test?

Thanks again guys.

Read here?


http://www.eventid.net/display.asp?eventid=1000&eventno=1441&source=Userenv&phase=1

thanks dstwartjr, I will check this... (interesting site, btw,,!).
I will get back if I find something. I was also thinking about doing some tests, deploying some new policy and try to get from my VPN connected workstation. But even if I get it (what would be awesome) I would like to fully understand the remaining errors.
If anybody has some input, I would appreciate it.
Thanks guys,

1054 event ID usually always means a multihomed DC. Along with that comes a few issues. You have a VPN connection and a LAN connection to the DC. There are a couple of configuration WOES you need to know about. One is DNS registration of the SRV records (SRV records point the way to your authentication server), another is supplying DHCP on the one NIC so you don't get an outside IP address of your LAN, and the third is Netbios binding to the internal NIC.

These are things that can be set to prevent the confusion on your server. Consider the fact that your server has to IPs on two different subnets and trying to communicate with both sides.

You may have already made the changes on this server. But, it never hurts to review. Please review the answer and followup comments on this thread:
https://www.experts-exchange.com/questions/23806816/How-do-I-enable-DHCP-on-only-one-network-interface.html

I have been in touch with the CheckPoint Secure Client suppor team and we have noticed after reproducing the issue and checking the FW logs and CheckPoint client logs that the requests never get out from the client computer. This has been their recommendation/workaround:
Error: "SPI: Encryption failed packet is from physical ip address but OM is active".
 
 
Cause
 
WINS was configured in TCP/IP properties of SecureClient machine in addition to the Office Mode settings configured to update WINS settings.
 
 
Solution
 
Currently Check Point can only offer the following workaround:
 
Do not configure WINS in TCP/IP properties so there is no conflict with the Office Mode settings. Since Office Mode generates a virtual interface on the client; a hard coded WINS server would not be recognized by the virtual IP used by the Office Mode mechanism.  

Any comment? I will try to follw these suggestions this coming week.

Thanks again and sorry for  my late update... running crazy with too many things...

That's definitely worth for being hold in the EE answer pool. Please keep us informed if WINS was the culprit.
Do they mean WINS in local NIC settings, or the settings for the virtual NIC created in Office Mode?

They said in the local NIC settings.
Actually I tried removing the WINS settings from the local NIC settings and it did not work, so they proposed then to basically disable the DHCP for that NIC and try with a static configuration with no WINS settings at all (the DHCP was configuring a WINS server by default on the IP config).
I will test later today and will definitely update here.

Any updates?