• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 230
  • Last Modified:

AD subnets VPN

I need to set up a remote location that authenticates AD to the DC at the main office. There is no on-site DC. I have the VPN setup to the remote office. On the firewall I have DHCP giving the secondary DNS to the Main office DC. Should this work? Do I need to add anything about the co-locations subnet at the DC in the main office?
0
WIZU2
Asked:
WIZU2
2 Solutions
 
Julian123Commented:
I'd recommend the following:
1. Ensure your primary DNS server is an AD-integrated DNS server in addition to your secondary. Typically, folks use DCs as DNS servers but this isn't required (it could be an AD-integrated DNS server that isn't also a DC). The best practice is that the DNS server has all the records used by workstations to find domain controllers to authenticate and having DNS be AD-integrated helps ensure that will happen.
2. Set up your AD sites and services subnet to associate the subnet used by the remote office with the DC at the main office. This ensures that machines in that remote office will connect to the DC(s) in the main office and not some other DCs that could be in another remote office (if you have one).


Thanks!
0
 
WIZU2Author Commented:
I know how to add the additional subnets, but how do you make it associate?
0
 
N-WCommented:
On the firewall I have DHCP giving the secondary DNS to the Main office DC. Should this work?

I highly recommend you point both primary and secondary DNS to the main office's DNS servers. If you have the primary DNS as an external source (your ISP's DNS, Google DNS, etc) then lookups for internal domain resources (file shares, printers etc) will often fail.

I know how to add the additional subnets, but how do you make it associate?

When you create the new subnet, you need to select the required site like this:
ADSS
So to associate the 192.168.1.0/24 subnet with the "HQ" site, you would just select HQ and hit OK.
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
SandeshdubeySenior Server EngineerCommented:
Also ensure correct dns setting on DC/clients as this

Best practices for DNS client settings on DC and domain members.
http://abhijitw.wordpress.com/2012/03/03/best-practices-for-dns-client-settings-on-domain-controller/

To associate the subnet with a site see this:
http://www.activewin.com/win2000/step_by_step/active_directory/adsites.shtml
0
 
WIZU2Author Commented:
Ok the second DC at the remote location is in a different time zone? The DC is pulling the time from the main office. How do I fix that issue?
0
 
N-WCommented:
The second DC should only "pull" UTC time from the DC holding the "PDC Emulator" FSMO role. This allows you to set a different timezone on the secondary DC and it should automatically calculate the correct time to display.

Has the correct timezone been set on the second DC?
0
 
WIZU2Author Commented:
I set the second DC at the remote location to the right time zone. But now the DC at main office is complaining about the time difference event ID 1925.
0
 
N-WCommented:
Are you able to post the full event error message?

ID 1925 usually refers to DNS lookup issues regarding AD replication.

It may be worth resetting the NTP configuration on your secondary DC too:
net stop w32time
w32tm /unregister (enter this command twice if presented with an error)
w32tm /register
net start w32time
w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time

Open in new window

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell┬« is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now