I can not ping a new dc on my domain nor can I join computers to the domain of a remote office

Do you get a "Ping request could not find host..." error? or timeouts?  What output do you get from a "netdiag"?

the ping from the work station times out
this is the output from the netdiag on the server
Computer Name: SRV-PIED-1DC
    DNS Host Name: srv-pied-1dc.Aristagroup.local
    System info : Microsoft Windows Server 2003 R2 (Build 3790)
    Processor : x86 Family 6 Model 23 Stepping 10, GenuineIntel
    List of installed hotfixes :
        KB915800-v9
        KB923561
        KB924667-v2
        KB925398_WMP64
        KB925876
        KB925902-v2
        KB927891
        KB929123
        KB930178
        KB932168
        KB933854
        KB936357
        KB936782
        KB938127
        KB938464-v2
        KB941569
        KB941838
        KB943055
        KB943460
        KB943545
        KB943729
        KB944338-v2
        KB944653
        KB945553
        KB946026
        KB948496
        KB950762
        KB950974
        KB951066
        KB951748
        KB952004
        KB952069
        KB952954
        KB954550-v5
        KB954600
        KB955069
        KB955839
        KB956572
        KB956802
        KB956803
        KB957097
        KB958644
        KB958687
        KB959426
        KB960225
        KB960803
        KB961063
        KB961064
        KB961371
        KB961501
        KB967715
        KB968537
        KB969805
        KB970238
        KB971633
        KB972260
        KB972260-IE8
        KB972636-IE8
        KB973346
        Q147222


Netcard queries test . . . . . . . : Passed
    [WARNING] The net card 'Broadcom NetXtreme Gigabit Ethernet #2' may not be working.



Per interface results:

    Adapter : Local Area Connection 2

        Netcard queries test . . . : Passed

        Host Name. . . . . . . . . : srv-pied-1dc
        IP Address . . . . . . . . : 100.101.50.4
        Subnet Mask. . . . . . . . : 255.255.0.0
        Default Gateway. . . . . . : 100.101.50.1
        Primary WINS Server. . . . : 100.101.50.4
        Dns Servers. . . . . . . . : 100.101.50.4
                                     100.100.50.4
                                     100.100.50.6


        AutoConfiguration results. . . . . . : Passed

        Default gateway test . . . : Passed

        NetBT name test. . . . . . : Passed
        [WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names is missing.

        WINS service test. . . . . : Passed

    Adapter : Local Area Connection

        Netcard queries test . . . : Failed
        NetCard Status:          DISCONNECTED
            Some tests will be skipped on this interface.

        Host Name. . . . . . . . . : srv-pied-1dc
        Autoconfiguration IP Address : 169.254.161.40
        Subnet Mask. . . . . . . . : 255.255.0.0
        Default Gateway. . . . . . :
        Dns Servers. . . . . . . . :



Global results:


Domain membership test . . . . . . : Failed
    [WARNING] Ths system volume has not been completely replicated to the local machine. This machine is not working properly as a DC.


NetBT transports test. . . . . . . : Passed
    List of NetBt transports currently configured:
        NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
        NetBT_Tcpip_{CE07EF2A-346C-448C-9357-857CFD6FFDFB}
    2 NetBt transports currently configured.


Autonet address test . . . . . . . : Passed


IP loopback ping test. . . . . . . : Passed


Default gateway test . . . . . . . : Passed


NetBT name test. . . . . . . . . . : Passed
    [WARNING] You don't have a single interface with the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names defined.


Winsock test . . . . . . . . . . . : Passed


DNS test . . . . . . . . . . . . . : Passed
          [WARNING] Cannot find a primary authoritative DNS server for the name
            'srv-pied-1dc.Aristagroup.local.'. [ERROR_TIMEOUT]
            The name 'srv-pied-1dc.Aristagroup.local.' may not be registered in DNS.
    PASS - All the DNS entries for DC are registered on DNS server '100.101.50.4' and other DCs also have some of the names registered.
    PASS - All the DNS entries for DC are registered on DNS server '100.100.50.4' and other DCs also have some of the names registered.
    PASS - All the DNS entries for DC are registered on DNS server '100.100.50.6' and other DCs also have some of the names registered.


Redir and Browser test . . . . . . : Passed
    List of NetBt transports currently bound to the Redir
        NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
        NetBT_Tcpip_{CE07EF2A-346C-448C-9357-857CFD6FFDFB}
    The redir is bound to 2 NetBt transports.

    List of NetBt transports currently bound to the browser
        NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
        NetBT_Tcpip_{CE07EF2A-346C-448C-9357-857CFD6FFDFB}
    The browser is bound to 2 NetBt transports.


DC discovery test. . . . . . . . . : Passed


DC list test . . . . . . . . . . . : Passed


Trust relationship test. . . . . . : Passed
    Secure channel for domain 'ARISTAGROUP' is to '\\dc1.Aristagroup.local'.


Kerberos test. . . . . . . . . . . : Passed


LDAP test. . . . . . . . . . . . . : Passed


Bindings test. . . . . . . . . . . : Passed


WAN configuration test . . . . . . : Skipped
    No active remote access connections.


Modem diagnostics test . . . . . . : Passed

IP Security test . . . . . . . . . : Skipped

    Note: run "netsh ipsec dynamic show /?" for more detailed information


The command completed successfully

Domain membership test . . . . . . : Failed
    [WARNING] Ths system volume has not been completely replicated to the local machine. This machine is not working properly as a DC.

I know what this says but what does it mean?

It means the server isn't a Domain Controller yet.

Taking a look at your IP configuration here:

        Host Name. . . . . . . . . : srv-pied-1dc
        IP Address . . . . . . . . : 100.101.50.4
        Dns Servers. . . . . . . . : 100.101.50.4
                                     100.100.50.4
                                     100.100.50.6

The lower two are the DNS servers back on your main site? I strongly recommend you remove 10.101.50.4 from this list until replication is complete (and the errors you have go away). Once it's done that you should feel free to add it back in if you wish.

I also noticed this:

        NetCard Status:          DISCONNECTED
        Host Name. . . . . . . . . : srv-pied-1dc
        Autoconfiguration IP Address : 169.254.161.40

If that interface is not in use, Disable it. You do not want a DC sitting there with that IP address, it will publish that (useless) address into DNS. Can be quite irritating :)

Check the Directory Service event logs (as well as System and Application), see if you're bumping into any errors there.

Chris

ok i disabled the other nic controller and remove 11.101.50.4 from the dns list.

Iget this warning in the directory service event veiwer
The Windows NT 4.0 or earlier replication checkpoint with the PDC emulator master was unsuccessful.
 A full synchronization of the security accounts manager (SAM) database to domain controllers running Windows NT 4.0 and earlier might take place if the PDC emulator master role is transferred to the local domain controller before the next successful checkpoint.
 The checkpoint process will be tried again in four hours.
 Additional Data
Error value:
8452 The naming context is in the process of being removed or is not replicated from the specified server.

I also got this one yesturday
Active Directory could not resolve the following DNS host name of the source domain controller to an IP address. This error prevents additions, deletions and changes in Active Directory from replicating between one or more domain controllers in the forest. Security groups, group policy, users and computers and their passwords will be inconsistent between domain controllers until this error is resolved, potentially affecting logon authentication and access to network resources.
 
Source domain controller:
 dc2
Failing DNS host name:
 c8fceac5-2014-412f-986a-89a9da187e23._msdcs.Aristagroup.local
 
NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur.  To log all individual failure events, set the following diagnostics registry value to 1:
 
Registry Path:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client
 

sorry i removed 100.101.50.4 from the dns list

Hmm I read your 100.'s as 10.'s before. You use 100 as your internal IP range? That is, you don't use a private IP range?

Anyway, can you open up the DNS console on 100.100.50.4 and 100.100.50.6 and manually verify that c8fceac5-2014-412f-986a-89a9da187e23 exists as a CNAME (Alias) record under the _msdcs folder for your domain?

Chris

we run a NAT on the firewall to reslove the ip addresses
I check the dns console in the 100.100.50.4 machine and that number is there but I am having an issue getting into the other machine at this time.

yes that number is in both dns servers at the main office

Your server will use the IP address advertised in DNS for the server rather than a NATed address. Configuring AD over NAT is quite complex.

Chris

huh?
So I set this up all wrong?

from everything I am reading I have this setup wrong seeing as I can not really change the ip scheme at the main office.  So i think i have to tare this all down and rebiuld it as it's own domain and then do a trust between them

There's no way to set up a VPN link between the two private networks?

It can be made to work, but it's definitely a complex configuration option, not something I'd recommend attempting unless you're familiar with how AD interacts with DNS.

Chris

ya I can do two private networks it just was not our first opption, because we did not know there was an issue with the replication of the dc over the vpn with nat.

now, How/can i take the dc that i have already connected to my domain and move it to a new domain with out rebuilding it or is rebiulding it the best opption?

This all needs to ship out tomorrow to the new office to be installed on monday.
so I have to figure this out quick

Demote it (DcPromo again), then remove it from the current domain, then promote it.

But I'd go with a single domain if you can at all, so a VPN would be my preferred option. Less administrative effort once it's up and running.

Chris

i can't change the ip setup at the main office, so i have to run the nat there and the remote office firebox automaticaly runs nat so i am stuck with this issue.

unless you have any other ideas i am willing to listen.

Hmm that is tricky, site to site VPN would be ideal, but you're a bit stuck. You'll have difficulty getting the trust to work over NAT as well unfortunately (same kind of issues as you're having getting it to talk to the domain).

We can try to get it to work over NAT? It's going to be tricky though, we need to stop the server getting the AD Integrated copy of your existing DNS zone and you have to deal with the issue both in the main office and at the branch. It makes for quite a lot of changes.

I think in your situation I'd set it up as a DC on the current domain and then push very hard to get the VPN established, replication will re-commence after the connection comes online. How easy that is does depend on your standing within the company though.

Chris

I have the VPN established.  So I should take the machine to the main office and make it a dc there then bring it back here and see if it will replicate?

If the VPN is up (without NAT) you can do it there. But at the main office then moving it works just as well.

Chris

there has to be a NAT at the mian office end

but if I move this and make it a dc and move it back wount i have the same issue later of no replication?

Hmm why does there have to be NAT? :) If you had two private address ranges (say 10.1.x.x in the main office and 10.2.0.x at the branch) then you can route those across a VPN without NAT.

Anyway, if you move to the main office, build it, then move it back to the branch without sorting out problems with DNS / network access then replication will fail.

Where does the NAT come into play exactly? What can we access on each side of the connection?

Chris

No the IP scheme in the main office is 100.100.50.0 SUB 255.255.0.0

this would be fast over the phone

Okay, but you wouldn't need to NAT that if you didn't want to. Just route whatever private IP range at the branch to the public range at the office over a VPN tunnel?

I realise it's not ideal, but the more I think about it the more difficult setting up AD over NAT in this scenario becomes. It works in very limited deployments, and it sounds like you have a bit more than a limited deployment (a couple of DCs and a few users).

Chris

Okay, but you wouldn't need to NAT that if you didn't want to. Just route whatever private IP range at the branch to the public range at the office over a VPN tunnel?

How?

I have no access right now to the router in the main office. it was provided by the isp and I don't even know what make it is.

What do you have there?

How many DCs? How many servers? And free servers? We could use Routing and Remote Access at a push.

Same question applies to equipment at the other end?

Chris

chris,

at the main office I have 2 dc's a file and print server and a stand alone server that runs Appx.
at the remote site ih one server doing it all dc, file and print and i am sure there was something else that i can't remember.

no free servers sorry
i have an exter cisco router that im not using, i think it is a 2600

I just need to finish off my dinner then lets see if we can make it work over NAT then.

Won't be long, hope that's okay (hungry :)).

Chris

and tired

Much better :)

I need to know where the NAT happens in this.

If you're at the branch site, is it possible to access individual Domain Controllers on the main site?

Chris

I'm not sure I follow.  The nat happens in my firewall at either end.

no I can not reach the domain controllers at the mian site from the remote

How many IP addresses can you access on your main site network?

For instance, if DC 1 is 100.100.50.4 and DC 2 is 100.100.50.6 can you ping both of those from the branch site?

Chris

Can we get to DC 1?

Chris

not from the server at the remote site but I can get there through a work station I have at the remote site.

to make changes yes

The DCs need to be able to talk, what's the difference between the server and workstation at the remote site?

Chris

the workstation at the remote site has been a member of the domain at the main site (it is my laptop) it also has its own mobil vpn in it so i can hit the main office.

Okay, so it's using the mobile VPN then?

The non-negotiable requirement of AD over NAT is that the two domain controllers can talk. The NAT configuration cannot be adjusted?

Chris

Given that you have something using a VPN, where does that VPN terminate / what provides it?

I'm wondering if we might install Routing and Remote Access on the remote DC, potentially allowing us to configure a site to site VPN tunnel.

Chris

wait,
fron the laptop I can do a remote desktop into my servers without using the mobil vpn just going over the vpn tunnel from the firewalls

Really? Well that's good news :)

What's the difference in IP configuration between the laptop and the server?

Chris

lets put it this way, I can get into any machine we need to from where i am.

It needs to go both directions unfortunately. So if the server at the remote site can get to the DCs in the main office, can the DCs in the main office access the server at the remote site?

Chris

server
ip 100.101.50.4
Sub 255.255.0.0
gateway 100.101.50.1

dns100.100.50.4
dns 100.100.50.6

workstation
ip100.101.50.2
sub 255.255.0.0
gateway 100.101.50.1

dns100.101.50.4
dns100.101.50.4
wins 100.101.50.4

no the server at the remote site does not see any machine at the main site

Can we try these?

On 100.101.50.4:

telnet 100.100.50.4 389

On 100.100.50.4

telnet 100.101.50.4 389

In both cases success is indicated by a blank screen, only an error message (failure to connect) is bad.

Chris

ok telnet from 100.101.50.4 got a black screen
telnet from 100.100.50.4 error could not open connection

That a promising sign.

From 100.101.50.4, try "telnet 100.100.50.6 389"?

Then from 100.101.50.4 try "telnet localhost 389", just to see if it's listening.

Chris

black screen for both

100.100.50.4 telnet localhost 389 was blank also

Okay, so now lets try from the workstation on the same remote network, so "telnet 100.101.50.4 389".

In case you're curious, 389 is the LDAP port, it's quite a simple test, but we need it to work from both sides.

Is there a Firewall between these two? Is it completely open?

Chris

between the remote workstation and remote server is open,  just a switch

"telnet 100.101.50.4 389 failed

That's interesting, I rather expected that one to work. Does it respond to ping when you're on that network?

Is it 2003 or 2008?

Chris

server 2003 laptop xp pro

Windows Firewall on either of them? Bit harder to enable that on 2003, but still possible.

Chris

ping to where?

Sorry, workstation to server (remote network) and server to workstation.

Chris

the laptop firewall was on i turned it off

ano it was on on the server also but i thought i had shut that off a while ago

but still no joy

Okay, ping and telnet again, first from workstation to server, then from the DC back at the main site to the remote server?

Chris

i can ping from the remote server to the laptop but not laptop to server that timesout

I have to assume that it's still blocking ICMP (required for Ping), Antivirus software?

Did telnet also fail?

Chris

ok i can telnet to the dc's on the main site from the remote server and fron the laptop

but i can not telnet from laptop to remote server

I can not telnet from the dc at the main site to the remote server

did I get eveything or did i miss one?

That's just annoying ;)

We know the server is listening because it worked on localhost. Ignoring the remote network for a while we need to get it working from the workstation and server.

If nothing obvious appears I'd be bringing out the packet sniffers now. Ever used one? Not the easiest thing in the world to explain.

Chris

no not really,  would it be easier if you had access to the machine?

Hmm possible, but I can't promise much ;)

Chris

im confused (understatement)
if the server at the remote site will not finish becoming a dc because of replication how are we going to get the workstaion to talk to the server.

The workstation only needs to establish a TCP connection with the server, an indication that the server will accept the connections.

Lets just have another check of that port. Run this one on the remote server:

netstat -ano | FindStr :389

Chris

netstat -ano | FindStr :389
                    ^
           what is that

Pipe, it sends the output from netstat -ano into the FindStr command, allows us to filter the output.

The reason for that is that if the server is running the DNS service you'll find it has a tremendously long list of ports if you just run "netstat -ano".

Chris

no where is it on the keyboard?

never mind

ok what do you want to know from to output

Found it? :) I could only tell you where on the UK keyboard anyway :)

Chris

isn't there a way to copy this out and paste it in here for you to see?

It should show something like

  TCP    100.101.50.4:389   *:*  LISTENING

Or:

  TCP    0.0.0.0:389   *:*  LISTENING

Chris

Yeah, right click in the Command Prompt window and select Mark, select an area then hit Return. That gives you it on the clipboard, Control + V / Paste will let you pop it into here.

Chris

TCP    0.0.0.0:389   *:*  LISTENING

C:\Documents and Settings\Administrator.ARISTAGROUP>netstat -ano | FindStr :389
  TCP    0.0.0.0:389            0.0.0.0:0              LISTENING       396
  TCP    100.101.50.4:389       100.101.50.4:1060      ESTABLISHED     396
  TCP    100.101.50.4:1060      100.101.50.4:389       ESTABLISHED     1972
  TCP    100.101.50.4:4254      100.100.50.6:389       TIME_WAIT       0
  TCP    100.101.50.4:4255      100.100.50.6:389       TIME_WAIT       0
  TCP    127.0.0.1:389          127.0.0.1:1044         ESTABLISHED     396
  TCP    127.0.0.1:389          127.0.0.1:1045         ESTABLISHED     396
  TCP    127.0.0.1:389          127.0.0.1:1047         ESTABLISHED     396
  TCP    127.0.0.1:389          127.0.0.1:1072         ESTABLISHED     396
  TCP    127.0.0.1:1044         127.0.0.1:389          ESTABLISHED     1472
  TCP    127.0.0.1:1045         127.0.0.1:389          ESTABLISHED     1472
  TCP    127.0.0.1:1047         127.0.0.1:389          ESTABLISHED     1472
  TCP    127.0.0.1:1072         127.0.0.1:389          ESTABLISHED     1396
  UDP    100.101.50.4:389       *:*                                    396

C:\Documents and Settings\Administrator.ARISTAGROUP>

Good stuff, we can see that it's listening for traffic on TCP Port 389 from pretty much everywhere. That confirms that the server is sitting there waiting for someone to talk to it.

We need to establish what happens to requests from the workstation you have on that network when they're sent to the server.

As a slight aside, if you haven't already you may try updating network card drivers. It would be frustrating to try lots more different things only to find there's an issue with the network driver.

Equally, if you have any AV software installed, or any third party firewalls installed they should be removed, to make the configuration as simple as we can.

Chris

this is, as far as i can tell uptodate on all drivers and there is nothing but server server 2003 on the machine. it is a blank canvas.

So how do we test from the WS to the Server?

ok itis in now what?

is there a way you can throw this back into the que so maybe someone lse will pick it I really need the help to get this going

Now you have to capture the traffic on the interface. Select Capture then Options, you should have a drop down list for interfaces (network cards), hopefully you don't have many in that list.

Tick all the boxes in the Display Options box, then click Start.

You should see thing filling up the top box, what we're interested in is anything in the Source column from your workstation.

Leave that running and try the telnet command from your workstation. If you don't see anything in Wireshark from your workstation then the problem with the two not talking is your workstation rather than the server.

Did that make sense?

Chris

ok what do you want to know

I've popped a note into one of the shared threads we have, it's worth a shot otherwise I'll pick it  up with you in the morning. If no one else responds feel free to drop any thoughts or questions into the thread and I'll (attempt to) address them in the morning.

Chris

Did you see any coming from your workstation?

Chris

there is stuff going back and forth between the server and worstation

should I send you the file

Including traffic with the workstation listed as Destination?

Chris

ok i take it back there are packets going from the workstation to the server but not the server to the workstation

here is the file I hope

ok that didn't work

how do i attach a file

hi
the windows firewall is off
How do I force the replication?

I am reviewing notes of past:

I see that your browser is bound to two ethernet addresses:

NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
NetBT_Tcpip_{CE07EF2A-346C-448C-9357-857CFD6FFDFB}

This means you have dual nics, (where one may be disabled but still bound), or you have a VPN connection. Multihomed DCs can sure cause problems unless configured right. It will also appear like everything is fine and dandy when running a dcdiag or netdiag report.

Please advise: (VPN or dual NICs) also advise (disabled second NIC or enabled)

dual nics but one is disables and a vpn tunnel but that is setup on the external firewall (watchguard x29e)

After bringing a new DC on line, you should register your SRV records, then force replicate those to other DCs. The server will do this automatically, but I think it can take up to 8 hours per server to do so.

To register your DNS records:
Go to the command prompt and type:

IPconfig /flushdns
IPconfig /registerdns  (to register the Host A record)
Net Stop netlogon      
Net start netlogon        (restarting the netlogon service will register the SRV records.


To force replicate, and save yourself time:
a) go to the Active Directory Sites and Services Snapin
b) navigate to Default First Site>>Servers
c)Pick the server you want to replicate TO and expand it
d)right click what is showing (NTDS site?) and select "replicate now"

ok maybe I'm doing this wrong but there is nothing in the details pain for the remote server

which server do I want to replicate from? the dc1 at the mian site or the server at the remote site?

For netbios and your dual nics, you may be bound to the wrong nic as the primary nic for Netbios. Netbios is used for distribution of distributive file shares (this includes group policy and the netlogon share), as well as the browser service (that populates "My Network Places"). Netbios is further used for file and print sharing.

What we need to do is to remove the ability of that nic to be bound by certain domain services.

Example, DHCP, DNS, Netbios, and a default gateway.  Examples on how to do so are on this thread.

https://www.experts-exchange.com/questions/23806816/How-do-I-enable-DHCP-on-only-one-network-interface.html


Once done making sure that second nic is not a problem, go to the command prompt and type this twice:
NBTSTAT -RR

This is what I think is happening:

Since we checked for port blockage via a firewall, I no longer think a software firewall is a problem on the server.

This leads me to a second potential problem:

Prior to disabling the second NIC, it registered its SRV records and Host A records within DNS. Netbios also bound to it as the primary NIC for Netbios translation. Since the disabled NIC was registered in DNS and probably is the primary netbios bind, you may see these issues.

So, if you are unable to replicate between servers, it looks like the other NIC was primary before disabling it.

There is a patch for this, then we will need to straighten out DNS records as well as the netbios binding.

This thread has the how to:
https://www.experts-exchange.com/questions/23356031/There-are-currently-no-logon-servers-available-to-service-the-logon-request.html

i think I got the hot fix in
i followed the setps for the foroced rep but there is no opption for replication on the server I need to replicat to

also so you know DHCP is comming from my firewall not the server. I don't know if that matters.

Computer Name: SRV-PIED-1DC
    DNS Host Name: srv-pied-1dc.Aristagroup.local
    System info : Microsoft Windows Server 2003 R2 (Build 3790)
    Processor : x86 Family 6 Model 23 Stepping 10, GenuineIntel
    List of installed hotfixes :
        KB915800-v9
        KB923561
        KB924667-v2
        KB925398_WMP64
        KB925876
        KB925902-v2
        KB926139-v2
        KB927891
        KB929123
        KB930178
        KB932168
        KB933854
        KB936357
        KB936782
        KB938127
        KB938464-v2
        KB941569
        KB941838
        KB943055
        KB943460
        KB943545
        KB943729
        KB944338-v2
        KB944653
        KB945553
        KB946026
        KB948496
        KB950762
        KB950974
        KB951066
        KB951748
        KB952004
        KB952069
        KB952954
        KB954550-v5
        KB954600
        KB955069
        KB955839
        KB956572
        KB956802
        KB956803
        KB957097
        KB958644
        KB958687
        KB959426
        KB960225
        KB960803
        KB961063
        KB961064
        KB961118
        KB961371
        KB961501
        KB967715
        KB968537
        KB969805
        KB970238
        KB971633
        KB972260
        KB972260-IE8
        KB972636-IE8
        KB973346
        Q147222


Netcard queries test . . . . . . . : Passed



Per interface results:

    Adapter : Local Area Connection 2

        Netcard queries test . . . : Passed

        Host Name. . . . . . . . . : srv-pied-1dc
        IP Address . . . . . . . . : 100.101.50.4
        Subnet Mask. . . . . . . . : 255.255.0.0
        Default Gateway. . . . . . : 100.101.50.1
        Primary WINS Server. . . . : 100.101.50.4
        Dns Servers. . . . . . . . : 100.100.50.4
                                     100.100.50.6


        AutoConfiguration results. . . . . . : Passed

        Default gateway test . . . : Passed

        NetBT name test. . . . . . : Passed
        [WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names is missing.

        WINS service test. . . . . : Passed


Global results:


Domain membership test . . . . . . : Failed
    [WARNING] Ths system volume has not been completely replicated to the local machine. This machine is not working properly as a DC.


NetBT transports test. . . . . . . : Passed
    List of NetBt transports currently configured:
        NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
    1 NetBt transport currently configured.


Autonet address test . . . . . . . : Passed


IP loopback ping test. . . . . . . : Passed


Default gateway test . . . . . . . : Passed


NetBT name test. . . . . . . . . . : Passed
    [WARNING] You don't have a single interface with the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names defined.


Winsock test . . . . . . . . . . . : Passed


DNS test . . . . . . . . . . . . . : Passed
    PASS - All the DNS entries for DC are registered on DNS server '100.100.50.4' and other DCs also have some of the names registered.
    PASS - All the DNS entries for DC are registered on DNS server '100.100.50.6' and other DCs also have some of the names registered.


Redir and Browser test . . . . . . : Passed
    List of NetBt transports currently bound to the Redir
        NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
    The redir is bound to 1 NetBt transport.

    List of NetBt transports currently bound to the browser
        NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
    The browser is bound to 1 NetBt transport.


DC discovery test. . . . . . . . . : Passed


DC list test . . . . . . . . . . . : Passed


Trust relationship test. . . . . . : Passed
    Secure channel for domain 'ARISTAGROUP' is to '\\dc1.Aristagroup.local'.


Kerberos test. . . . . . . . . . . : Passed


LDAP test. . . . . . . . . . . . . : Passed


Bindings test. . . . . . . . . . . : Passed


WAN configuration test . . . . . . : Skipped
    No active remote access connections.


Modem diagnostics test . . . . . . : Passed

IP Security test . . . . . . . . . : Skipped

    Note: run "netsh ipsec dynamic show /?" for more detailed information


The command completed successfully

Yes, of course it matters.

DHCP should be hosted on your domain controller. The reason is, if DHCP is hosted on your router, DNS is probably hosted as well.

A router hosting DNS will not hold the SRV records for the domain. Also DHCP on your Windows server will pass down, (to the DHCP clients), the preferred DNS servers, the default gateway, the preferred WINS server, the time server. SO, your clients may not see your server.

NOW that still shouldn't be a problem with domain server to domain server communications. Your domain servers are simply not seeing each other.

I think your server to server problems are a result of that second nic registering its SRV records prior to being disabled.

i tried following that thread but i think i missed something

I still did not get the forced replication part because there is no option under the remote server for replication

This is looking better:

Netbios is now bound to one nic. That is good.

I also see that you only have ONE preferred DNS server with the IP of 100.100.50.4 This is where I could use Chris' help. He is awesome at DNS.

It is my opinion that your SRV and HOST A records for the IP of:
100.100.50.4

were registered to the wrong NIC. So, we have to remove those improper records.

Please verify your SRV records and HOST A records>
http://support.microsoft.com/kb/816587

You could choose to remove the records and re-register them by the command lines of :

IPconfig /flushdns
IPconfig /registerdns
net stop netlogon
Net start netlogon

and force replicate:

I also just noticed something:

        Dns Servers. . . . . . . . : 100.100.50.4
                                     100.100.50.6

Your preferred DNS servers for this server are 100.100.50.4 and 100.100.50.6

Your correct IP should be 100.((101)).50.4 and 100.((101)).50.6  right?

Change that on the NIC.

I have not been able to force to replication because there is no option for it under the remote server

I also just noticed something:
        Dns Servers. . . . . . . . : 100.100.50.4
                                     100.100.50.6
Your preferred DNS servers for this server are 100.100.50.4 and 100.100.50.6
Your correct IP should be 100.((101)).50.4 and 100.((101)).50.6  right?
 The 100.100.50.4 and .6 dns servers are at the main office I was told to set ti this way to help the replication. obviously this did not work.  I will change it to 100.101.50.4 which is the remote server

IPconfig /flushdns
IPconfig /registerdns
net stop netlogon
Net start netlogon

I Ran this already twice but again I can not do the forced replication becaus eI can not find the option

omputer Name: SRV-PIED-1DC
    DNS Host Name: srv-pied-1dc.Aristagroup.local
    System info : Microsoft Windows Server 2003 R2 (Build 3790)
    Processor : x86 Family 6 Model 23 Stepping 10, GenuineIntel
    List of installed hotfixes :
        KB915800-v9
        KB923561
        KB924667-v2
        KB925398_WMP64
        KB925876
        KB925902-v2
        KB926139-v2
        KB927891
        KB929123
        KB930178
        KB932168
        KB933854
        KB936357
        KB936782
        KB938127
        KB938464-v2
        KB941569
        KB941838
        KB943055
        KB943460
        KB943545
        KB943729
        KB944338-v2
        KB944653
        KB945553
        KB946026
        KB948496
        KB950762
        KB950974
        KB951066
        KB951748
        KB952004
        KB952069
        KB952954
        KB954550-v5
        KB954600
        KB955069
        KB955839
        KB956572
        KB956802
        KB956803
        KB957097
        KB958644
        KB958687
        KB959426
        KB960225
        KB960803
        KB961063
        KB961064
        KB961118
        KB961371
        KB961501
        KB967715
        KB968537
        KB969805
        KB970238
        KB971633
        KB972260
        KB972260-IE8
        KB972636-IE8
        KB973346
        Q147222


Netcard queries test . . . . . . . : Passed



Per interface results:

    Adapter : Local Area Connection 2

        Netcard queries test . . . : Passed

        Host Name. . . . . . . . . : srv-pied-1dc
        IP Address . . . . . . . . : 100.101.50.4
        Subnet Mask. . . . . . . . : 255.255.0.0
        Default Gateway. . . . . . : 100.101.50.1
        Primary WINS Server. . . . : 100.101.50.4
        Dns Servers. . . . . . . . : 100.101.50.4


        AutoConfiguration results. . . . . . : Passed

        Default gateway test . . . : Passed

        NetBT name test. . . . . . : Passed
        [WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names is missing.

        WINS service test. . . . . : Passed


Global results:


Domain membership test . . . . . . : Failed
    [WARNING] Ths system volume has not been completely replicated to the local machine. This machine is not working properly as a DC.


NetBT transports test. . . . . . . : Passed
    List of NetBt transports currently configured:
        NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
    1 NetBt transport currently configured.


Autonet address test . . . . . . . : Passed


IP loopback ping test. . . . . . . : Passed


Default gateway test . . . . . . . : Passed


NetBT name test. . . . . . . . . . : Passed
    [WARNING] You don't have a single interface with the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names defined.


Winsock test . . . . . . . . . . . : Passed


DNS test . . . . . . . . . . . . . : Passed
    PASS - All the DNS entries for DC are registered on DNS server '100.101.50.4' and other DCs also have some of the names registered.


Redir and Browser test . . . . . . : Passed
    List of NetBt transports currently bound to the Redir
        NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
    The redir is bound to 1 NetBt transport.

    List of NetBt transports currently bound to the browser
        NetBT_Tcpip_{6A63F841-6FC2-42E7-A353-B526EC3C39EF}
    The browser is bound to 1 NetBt transport.


DC discovery test. . . . . . . . . : Passed

DC list test . . . . . . . . . . . : Passed

Trust relationship test. . . . . . : Passed
    Secure channel for domain 'ARISTAGROUP' is to '\\dc1.Aristagroup.local'.

Kerberos test. . . . . . . . . . . : Passed

LDAP test. . . . . . . . . . . . . : Passed

Bindings test. . . . . . . . . . . : Passed

WAN configuration test . . . . . . : Skipped
    No active remote access connections.

Modem diagnostics test . . . . . . : Passed

IP Security test . . . . . . . . . : Skipped

    Note: run "netsh ipsec dynamic show /?" for more detailed information


The command completed successfully

in the active directory site and service under sites, default first site name, servers, srv-pied-1dc (the remote server) under NTDS Setting the are no servers listed

Let's refer back to this:

I have not been able to force to replication because there is no option for it under the remote server

I also just noticed something:
        Dns Servers. . . . . . . . : 100.100.50.4
                                     100.100.50.6


The DC needs to see itself within DNS as a DC before it will replicate with other servers.

It appears like we are looking at four servers, maybe more:

I will need to get a feel for you network to better understand how to help you.

The server we are working on is
100.101.5.4, (is this correct?) (Does this server have DNS on it?)
an alternative server is
100.101.5.6, (is this correct?) (Does this server have DNS on it?)
100.100.5.4, (is this another server?)
100.100.5.6, (is this another server?)

**Please note, with the subnet mask of 255.255.0.0, your DCs are on a different subnet as your DNS servers.

I see a couple problems we are working on all at once.

Effects client to server communications:
1) you have DHCP on the router. This will effect the DHCP client stations since the router will not hold the SRV records.

Effects server to server communications:
2) you must have the preferred DNS server correct on both DCs for them to register the SRV records and Host A records correctly. Otherwise these servers will not see themselves, not to mention each other.
3) Once you get the SRV records correct, you will need to restart the FRS service or get file replication to start between servers. We may have to remove the SRV records and host A records.
4) Both NICS may have registered in DNS SRV and Host A records. So, your server is confused on how to communicate with itself.

You may have to demote this server and re-promote it once the preferred DNS servers are correct. This will re-register the SRV records correctly ON THAT DC. Then, replicating that out will allow other servers to see it as a domain server.

This is what I am assuming, and my assumptions need to be exact before we can fix this:

IP Address . . . . . . . . : 100.101.50.4  Is the server we are working on. It hosts AD and DNS
IP address 100.101.50.6, is your PDCe and currently hosts your FSMO role holders as well as AD and DNS.

If so, add 100.101.50.6 as a secondary preferred DNS server, then see if you can replicate to it.

The reason you are not seeing any other servers in AD sites and services is because you promoted this server without the preferred DNS server list on the nic being correct. So, one you have this as your preferred DNS servers on the nic:

100.101.50.4  === primary
100.101.50.6  ===Secondary

It will see the second server upon a promotion. So, you may have to:

FOR THE SERVERS:
1)  make these two as your preferred DNS server,
2)  demote and repromote the server
3) register your SRV records and HOST A  in DNS by the four command lines provided above
4) Force replicate between the two preferred DNS servers as explained above
5) run DCdiag /v to check out results
NOW FOR THE CLIENTS:
6) install and configure DHCP on one/ or both of these servers to provide to the clients.
7) Disable the router's ability to provide DNS
8) authorize your windows server to provide DNS.

hi welcome back

Ok one I made some changes while you were gone to try to get this to work.
The server we are working on is
100.101.5.4, (is this correct?) (Does this server have DNS on it?)   THIS IS THE REMOTE SITE SERVER IT'S IP ADDRESS NOW IS 192.168.111.4 IT DOES HAVE DNS ON IT.
an alternative server is
100.101.5.6, (is this correct?) (Does this server have DNS on it?)THIS IS WRONG
100.100.5.4, (is this another server?)THIS IS WRONG
100.100.5.6, (is this another server?) THIS IS WRONG
THE OTHER SEVERS ARE 100.100.50.4 THIS IS THE SCHEMA MASTER OF THE ARISTAGROUP.LOCAL DOMAIN,  IT IS A DC.  IT HAS DNS BUT NO DHCP.
     100.100.50.6 THIS IS A SECOND DC ON THE ARISTAGROUP.LOCAL DOMAIN,  IT IS A DC.  IT HAS DNS BUT NO DHCP.

**Please note, with the subnet mask of 255.255.0.0, your DCs are on a different subnet as your DNS servers.
NOTING THIS AND THE CHANGES I MADE I NEED TO MAKE SOME MORE CHANGES OR PUT IT BACK WHERE IT WAS

I also tried to imploment DHCP on the remote site server but it does not seem to work  

do you want me to put the ip structure back the way it was before?

100.100.50.4 THIS IS THE SCHEMA MASTER OF THE ARISTAGROUP.LOCAL DOMAIN,  IT IS A DC.  IT HAS DNS BUT NO DHCP.
100.100.50.6 THIS IS A SECOND DC ON THE ARISTAGROUP.LOCAL DOMAIN,  IT IS A DC.  IT HAS DNS BUT NO DHCP.
 with this info what is the best IP structure to use to make this work?  Knowing that I can not change the Ip structure of the dommain at the main site, Aristagroup.local

ok based on what you said i put the ip structure back the way it was.
I think that was the right thing to do, I hope

so now we have
100.101.50.4 remote site server
100.100.50.4 dc main office
100.100.50.6 dc main office

No.

You want this new servers' preferred DNS server to be itself, unless it is not a DNS server. Then, pick the local site's DNS server as its preferred DNS server.

Standard practice is to make every DC a DNS server. Then, you make itself as the preferred DNS server and another local site DNS server as the secondary preferred DNS server. Then, site to site replication occurs.

***We don't want a remote site to be the preferred DNS server.

With that said, I don' t know how you have your DCs set up with respect to your DNS servers. So, this will be difficult to fix, since I am working off of assumptions.

that i understand

so now we have
100.101.50.4 remote site server dns points to itself only
100.100.50.4 dc main office dns points to itself and 100.100.50.6
100.100.50.6 dc main office dns points to itself and 100.100.50.4

ChiefIT
I now also have dhcp running on the remote office server and on one of the main office servers.
on the second dc at the main office do i make the dhcp match exactly to the first dhcp server?

Ken

ChiefIT

sorry but you lost me at fixing the srv records.  how do i check that?

the machine woun't let me demote it. not as the last dc in the domain or not the last dc in the domain.

i got it
dcpromo /forceremoval

ChiefIT

Ok I demoted the server (this is the remote server and the only server at this site) and checked all the dns and dhcp settings, they are:
IP 100.101.50.4
sun 255.255.0.0
gateway 100.101.50.1
dns 100.101.50.4
wins 100.101.50.4

DHPC has the same settings in it.

I 'm not going to promote this to a dc intil I get a responce from you (hopefully earlyish AM) to make sure that there are no ip changes or anything else that needs to change before hand.

also what is a global catalog and why do i need it?

Thanks for all your help
Ken

basically the global catalog is a partial replication of every AD object on the domain.

As Technet puts it:
http://technet.microsoft.com/en-us/library/cc728188(WS.10).aspx

"The global catalog is a distributed data repository that contains a searchable, partial representation of every object in every domain in a multidomain Active Directory forest. The global catalog is stored on domain controllers that have been designated as global catalog servers and is distributed through multimaster replication. Searches that are directed to the global catalog are faster because they do not involve referrals to different domain controllers."


Also from technet:
http://technet.microsoft.com/en-us/library/cc758330(WS.10).aspx

To enable or disable a global catalog

   1. Open Active Directory Sites and Services.
   2. In the console tree, click the domain controller where you want to enable or disable the global catalog.
      Where?
          * Active Directory Sites and Services/Sites/site that contains the domain controller that you want to disable or enable/Servers/domain controller
   3. In the details pane, right-click NTDS Settings, and then click Properties.
   4. Select the Global Catalog check box to enable the global catalog, or clear the check box to disable the global catalog.

Your IP settings look good:

--go to the command prompt and type IPcofnig /register DNS
--Make sure this is a DNS server befor you promote it
--Promote it into the domain
--go to the command prompt and use the four lines to register the DNS settings and restart the netlogon service.
--force replicate between the two servers

Morning guys,

> also so you know DHCP is comming from my firewall not the server.
> I don't know if that matters.

It isn't until we have the workstation talking to the server. The source of addressing is unimportant as long as it's giving out the right information.

> Your preferred DNS servers for this server are 100.100.50.4 and 100.100.50.6
> Your correct IP should be 100.((101)).50.4 and 100.((101)).50.6  right?

That would be by my instruction :)

AD couldn't care less which DNS servers are used as long as the DNS servers can answer questions about the AD domain.

Given that replication hasn't completed (the server was not fully operational as a DC) setting the server to use DNS on known-good servers seems sensible. Once replication completes fully that can be changed again if desirable, but it is not a requirement.

In a sense, the correct DNS server is the one that provides the right answers, that may or may not be the local DNS service.

I'm still concerned that the local workstation cannot talk to the server. There's no point in fiddling with AD sites and services, service records, or anything above the transport layer until systems can talk to the server and the server can talk to the others.

So what state are we in now? The remote server is no longer a DC?

Chris

Hi Guys

Ok Again I am confused. do I want the remote server's dns to point only to itself or to the main office dns server also?

Ken

Is it still a Domain Controller?

Chris

no at this time it is not a domain controller I demoted it last night (early this morning)
This is where it is now

Ok I demoted the server (this is the remote server and the only server at this site) and checked all the dns and dhcp settings, they are:
IP 100.101.50.4
sun 255.255.0.0
gateway 100.101.50.1
dns 100.101.50.4
wins 100.101.50.4

DHPC has the same settings in it.

I 'm not going to promote this to a dc intil I get a responce from you

Change the DNS servers back to the two on the main site again? :)

It won't have any DNS data because that's held in AD and it doesn't have a copy any more.

Chris

ok now we have
IP 100.101.50.4
sun 255.255.0.0
gateway 100.101.50.1
dns 100.100.50.4
dns 100.100.50.6
wins 100.100.50.4
Wins 100.100.50.6

DHPC has the same settings in it.

Is this right?

the DNS domain Name in DHCP should be aristagroup.local  Correct? the nams of the main site domain.

Yep, that will do nicely (including the name in DHCP).

Make sure it can look up names, can you run these two on the remote server:

nslookup -q=srv _ldap._tcp.aristagroup.local
nslookup -q=srv _ldap._tcp.pdc._msdcs.aristagroup.local

And just one to make sure it can find public names:

nslookup www.google.com

Chris

they all worked

Excellent :)

Can we see if you can access file shares on the two DCs? This will do:

\\100.100.50.4
\\100.100.50.6

I almost dread to ask, but try the same from the two DCs in the main site, this time to:

\\100.101.50.4

The worry is they won't be able to, but we should try :)

Chris

Er, that's "Start, Run", then the path above in each case (just a UNC, same as \\servername).

Chris

chris
I think you still have something backwards
100.100.50.4 and 6 are at the main site.
100.101.50.4 is the only server at the remote site.

there are only three (3) dc's in this network
 

I know that :)

So, from 100.101.50.4, try Start, Run "\\100.100.50.4" and Start, Run, "\\100.100.50.6".

Then from each of the DCs at the main site, try Start, Run, "\\10.101.50.4".

Chris

I can get into all three dc's

oh ok sorry i miss under stood

from 100.100.50.4 to 100.101.50.4  no network provider accepted the given network path

Still exhibits all the symptoms of being firewalled, quite frustrating.

Well, we can try promoting it to DC, but it'll suffer the same issues as before, the fundamental issue with it failing to allow network access is still present.

Chris

from 100.100.50.6 to 100.101.50.4  no network provider accepted the given network path

the windows firewas got turned on again probably durring the demote
I can connect now

Oh good, that really is good news.

Right... DC Promo again then? :)

Chris

from 100.100.50.4  and 6 to 100.101.50.4 connects

additional dc on an existing domain correct? just making sure

Yep, that's the one.

Chris

operation failed
 the specified user already exist

Okay, if you don't mind then, drop it out of the domain, back to a workgroup.

Then check the AD domain for a computer account for the remote server, if you find one, get rid of it.

Then join the domain again, and finally go for promotion once more.

Chris

it never went into the domain
can I just delete the account from the ad domain or is there something special i have to do?

I think I goofed
I thought that doing the DCpormo would automaticaly make it join the domain so i did not do that first.
now as i understand it I have to join the domain fisrt the dcpromo

so join the domain then run dcpromo right?
should I chang the name of the remote server first to help avoid confusion or would this just make it worse?

Yep, please do :)

Make sure the computer account doesn't exist in the current domain, but you shouldn't need to rename, the identity is a bit deeper than the name.

Chris

when I try to delete to account srv-pied-1dc(the remote server)from the ad domain it says the it is a container and contains other objects.
Delete any way?

Can we make sure it isn't a DC first?

On the DC back on your main site...

Start, Run, ntdsutil
metadata cleanup
connections
connect to server <WhateverTheMainDCIsCalled>
quit
select operation target
list domains
select domain <Number>
list sites
select site <Number>
list servers in site

This may list the server at the remote site. Does it? If it does...

select server <TheRemoteServer>
quit
remove selected server
quit
quit

With that done you should be able to delete the computer account (if it still exists). Then you can join to the domain and promote again.

Chris

server connection dc1.aristagroup.local illegal syntax

It's fussy about that...

you tried it like this?

connect to server dc1.aristagroup.local

Chris

that worked

select operation target:select domain 0
No current sitedomain - dc=aristagroup,dc=local
no current server
no current naming context


IS THIS RIGHT?

Yep, the aim is to populate the site and the server selections. We only want to select a server if the remote server is listed, because we only need to do this if AD still thinks it's a DC.

Chris

ok it found three servers

yes the remote server is listed

Okay, so if one of those is the remote server, use:

Select Server <WhateverNumberItIs>

Then we want to Remove that server.

Presumably you used "dcpromo /force" to demote this?

Chris

yep it wouldn't do it any other way

ok done

Okay, no problem. This just cleans up the aftermath of that approach, otherwise we'll run into problems later on.

Chris

Fantastic, you should find that the computer account no longer exists in AD Users and Computers?

And check AD Sites and Services, see if there's an entry for it there. If there is delete it provided it doesn't have an NTDS Settings folder underneath.

Chris

Chris

it is not listed in user and computers and I deleted it from sites and services
now what?
Ken

Join the remote server to the domain again, then attempt to promote it to a DC once more.

Chris

dc promo was successful restarting the server.

Okie dokie, keep an eye on the event logs. After it comes back up, try that round of accessing \\100.100.50.4 and \\100.101.50.4 we did before.

Chris

chris
it works from 100.101.50.4 to 100.100.50.4 with no user name or password
it works from 100.101.50.4 to 100.100.50.6 with no user name or password
it works from 100.100.50.4 to 100.101.50.4 with no user name or password
it DOES NOT works from 100.100.50.6 to 100.101.50.4 -> \\100.101.50.4 is not accessable.

Well... it's a start...

How are the Event Logs looking?

Chris

on which end?

The remote server primarily, but the DCs back at the main site as well.

Chris

remote end
there were some dns errors at first but that seems to have sorted itself out
replication has started (what happens if that gets interupted durring the replication?)
other wise it looks good

on the main site dc
there are a couple of warnings in the director service log from about 15 min ago nothing recent
other wise it looks good also

It resumes if it's interrupted :)

We may as well sort out a few other things while it's thinking about stuff.

Head to AD Sites and Services, select sites, right click an dmake a new one. It'll need a name, but I'm sure you won't have a problem there :)

Then select Subnets, right click and add a subnet. That'll be 100.101.0.0 with the subnet mask 255.255.0.0 (or the mask length of 16). Add that subnet to the new site.

If you don't have a site and subnet configured for your main site, add one for that as well.

Still in AD Sites and Services, find your new server and move it into the new site (should be a right click, Move job). Finally, open Properties for NTDS Settings under your new server, tick the Global Catalog box.

All those changes need to replicate, so we still need to give it a bit of time, lots of checking of the event logs.

Chris

on the remote site?

It shouldn't matter, but I'd do it back at the main site (doesn't matter which DC).

If you still have Default-First-Site-Name feel free to rename that (forgot to note that earlier).

Chris

i'm makeing a new site?
Head to AD Sites and Services, select sites, right click an make a new one. It'll need a name, but I'm sure you won't have a problem there :)
WHAT IS this name for?

You can call it whatever you like. Your network clients will use it to figure out which domain controllers they should use to log on, and your DCs will use them to figure out replication.

For example you might have:

London - 100.100.0.0 255.255.0.0 (with DC1 and DC2)
Berlin - 100.101.0.0 255.255.0.0 (DC3)

The subnet masks you use should match those you assigned to the network interfaces on your Domain Controllers, so change them if I don't have them right.

Chris

Then select Subnets, right click and add a subnet. That'll be 100.101.0.0 with the subnet mask 255.255.0.0 (or the mask length of 16). Add that subnet to the new site.
HUH?

Your server has this IP address and subnet mask doesn't it? 100.101.50.4 and 255.255.0.0? If so, your network address for that site is 100.101.0.0, which is the value you should enter in the New Subnet along with subnet mask above.

You should have the option to select your new site in the lower box.

Chris

i'm not finding were to put in the addres and subnet.

AD Sites and Services should have a Subnets folder?

Chris

ok now i found it was looking in to deep

Good morning guys.  Just checking in:

@Chris: Chris, what I found out was he had two nics disabled prior to registering the SRV records. Netbios bound to the disabled nic as the primary. I am also sure the disabled nic had the same IP as the enabled one. Hence, the server's confusion on Netbios and DNS. I also saw DHCP was hosted on the Router, therefore giving fits to the clients trying to get in touch with the server via DNS. When we got further into this, there was a little confusion between me and Ken as to whom was supplying DNS and to what preferred DNS server to go with. We also discussed making this remote server a global catalog.

I started falling asleep at my desk, and I think you came in almost immediately afterwards. What's going on since I caught some shuteye?

@Ken:

Good morning

only the dc1 has the global catalog thing cheched off should it be on both dc's at the main site?

Morning Chief :)

Yep, make all of your servers into Global Catalogs please.

Chris

hello ChiefIT
Sorry to keep you up so late I figured I lost you at around 1:30am
I'll let chris bring you up to date

Ken

what am I looking for in the event veiwer just errors and warnings or what?

Anything that might indicate something is going wrong. Especially important in the Directory Service log.

Lets see if the new server has Sysvol and Netlogon. From DC1, start, run, \\dc3\netlogon and \\dc3\sysvol.

Those are used to replicate logon scripts and group policies. Very important to have these working.

Lets take a look at DNS as well. Running this should return all 3 of your DCs:

nslookup -q=srv _ldap._tcp.aristagroup.local

Does it?

You should also find that you have folders for each of your sites under aristagroup.local\_sites now.

Chris

\\dc3\netlogon and \\dc3\sysvol.
shouldn't DC3 be the name of that server srv_pied_1dc

yeah, it should, sorry, forgot what you called it :)

Chris

While we're at it... technically underscores are illegal in DNS names, so if you get a chance, renaming the DC so it doesn't have any would be good. I don't recommend doing that right now though, more bother than it's worth at this stage.

Chris

ok under netlogon we have:
Map-y-drive.cmd
under sysvol:
aristagroup.local

actually they are -'s not_'s  is that still a problem

Great, that suggests it managed to complete replication and should be acting as a proper DC now.

Lets take look at DNS on that server, open up the console, expand Forward Lookup Zones and see if aristagroup.local is there? It should be if replication is behaving itself.

Chris

No, hyphens (-) aren't a problem, they're absolutely fine :)

Chris

yes it is there with all of my users

Excellent. If you wish, you can change the TCP/IP settings on that server to look at 100.101.50.4 as Preferred DNS, leave one of the remote DCs there as Alternate (or both of them if you use the Advanced options).

The same change can be made to DHCP.

Chris

what about WINS

Did you install WINS on this server? If you did, have you set up Push/Pull replication with the existing WINS servers?

Chris

should I add the remote server to the DNS list on the DC at the main site? or would that just be over kill?

It would be overkill in my opinion. You have two DNS servers there already.

Chris

Chris
yes I Put in wins.  I thought it was you that said I needed it.  Sorry I hope it dosn't mess up anything.
Ken

Not at all, it's fine. I don't like NetBIOS, I tend to disable it. But if you keep it enabled then WINS is ideal.

Lets configure replication, back to the main site again, open up the WINS console. You should see a Replication folder in there (I hope, from memory). There should be something like an option to add a new Push/Pull partner.

We want....

DC1 to push/pull to DC2 and srv-pied-dc1
DC2 to push/pull to DC1 and srv-pied-dc1
srv-pied-dc1 to push/pull to DC1 and DC2

Quite a lot of them, but if you're going to have it enabled they should all talk about their records.

Chris

Oh and that will mean connecting the WINS console, or visiting the WINS console on each of the three servers.

Chris

how do I check the wins for the push pull config?

The folder for replication in the WINS console. Or do you mean test that it works?

Chris

i have because we have an old nt server still running and it uses it.

That brings up another issue/ or not  if i have a trust between the nt server and the ad i don't need to change anything for the trust now do i?

No, nothing needs changing for NT. Just need the replication of WINS data sorted out.

Do you also need / want to replicate WINS with the NT server? Is that a PDC or BDC?

Chris

pdc that i hope to take down soon

Does it also run WINS? Or does it just use one of your other DCs?

If it does, it would be beneficial to set up a push/pull partner for that server as well.

Chris

i only have wins running on DC1 not DC2 i guess I should add it

Just tell the NT server to use DC1 and DC2 as WINS servers, that would do nicely.

So we just need Push/Pull replication between the three WINS servers to keep them happy.

Chris

for some reason I have file server and print server running on DC1 but it is not my file and print server I have a stand alone for that Should I take it off?

I'd leave it alone, it's pretty harmless, just gives you a few management tools.

Chris

do i add the wins replication on both ends or just one?

Both, we're aiming for full-mesh, every DC talks to every other DC about WINS.

Chris

@Chris:

Did we address DHCP on the router, so the clients are confused as to who provides DNS?

ChiefIT

DHCP is now in the servers

As far as I'm aware we're running DHCP on the server. But I haven't done anything with the clients yet, still prodding the server, it all still needs to be tested.

I was going to go for....

1. Finish configuring WINS
2. Configure DHCP updates to DNS (Credentials / Lease durations, etc)
3. Configure Aging and Scavenging in DNS
4. Verify Replication / Domain state (DCDiag / NetDiag / RepAdmin)
5. Test client connectivity at remote site

Chris

I will have to add Wins and DHCP to DC2 at the main site when I go back there. the server needs the disk I have to do the install

WINS, no problem. You have to be a bit careful with DHCP, you can have two DHCP servers, but you they can't hand out the same information or you'll get conflicting or overlapping IP addressing.

Chris

That's what I like about you Chris:

You are thorough and fix & test everything. What better expert assistance could you ask for?!?!

ok then I woun't put in dhcp on DC2
is it any consolation thatI can brows the entire network and see all my users

I was just thinking how lucky I was the get both of you to work on this with me.  you two are some smart cookies.

Me, I'm just smart enough to cause trouble.

WINS should help a lot with Browsing. All set with the replication there?

Chris

ok so what do we do now?
you know I'm going to rewrite all this into a instruction document so it is easy to understand so I don't have this proble again.

I beleive so

I have a wins error on DC1
the connection was aborted by the remote wins. remote wins may not be configured to replicate witht he server.

Bur this came in 15 min ago and there is no error on the remote side.  I think it was just from the lag time of me setting up the remote servers wins.

Okay, lets visit DHCP again.

You have DHCP running on DC1 (Main Office) and DC1 (Remote Office) now?

What Scope did you set up? Did you add any Exclusions?

Unless you have a lot of people coming in and out of your network, can we set the Lease Duration to 16 days on each server?

Chris

Re: WINS. See if that one comes back, it could be, as you say, lag in the configuration.

Chris

dc1 100.100.50.150 ->200
srv-pied-1dc 100.101.50.2 ->254  exclustion 2 ->11

the ip structure at the main site is a bit of a mess so I only gave a small dhcp scope that I know was clean.

question?

Sorry, bit distracted :)

Increasing the Lease duration, will that be okay? A longer lease helps DNS keep neat and tidy, but it's only suitable if you don't have a lot of people moving in and out of the network.

Chris

not a problem

16 days is enough

Right, that moves us onto how DHCP updates DNS.

Because you now have more than one DHCP server it's important that we make both DHCP servers update using the same credentials (with the same account).

First things first, we need an account for them to use.

I have strict naming conventions for my networks, so I would use an account called svc-dnsupdate. Feel free to name the account however you want, it's just going to be a standard user account, nothing special.

Then we need to head to the DHCP console, open the properties for the server, select the Advanced Tab and then Credentials. Enter the user name and password you assigned to the account. Repeat this on the other DHCP server.

Chris

the remote server wount let me put in the user in credentials

Error message?

If you open up AD Users and Computers on that system, can you see the account?

Might take a bit of time to replicate now it's in a different site.

Chris

the user hassen't shown up yet in users and group on the remote server yet

unknown user and password

Okay, not to worry. Head to AD Sites and Services once again (back on DC1 at the main site). Select the Inter-Site Transports folder. You should see DEFAULTIPSITELINK there? Open it's properties and change Replicate Every to 10 minutes.

Staying in there, find your new DC, it should have a connector under NTDS Settings, right click one that says From Server: DC1 and select Replicate Now.

Chris

it is not here it was here earlyier but I can't find it now

The DC?

Chris

it is under the IP folder

Oh that, yeah, sorry :)

Chris

I got it but it will only go down to 15 min

not a problem at all

15 is good enough, considerably better than 180 minutes. Replicate now can be used when things need to go faster, like with this new account.

Chris

so how do i kick start the replication?
Ken

Find the connector under NTDS Settings, right click on it and select Replicate Now. You need one for the new server that comes from one of the DCs at the main site.

Chris

one or more of these AD dir connection are between controllers in different sites ad will try to replicate

now what?

the user still has not shown up on the remote server

ok not to be a bother but is there anything really pressing that needs to be done or can i pack this stuff up and send it to its new home?

Sorry, was cooking my curry :)

Send it off, it'll pick up replication from there. If the user still hasn't appeared then it'll be a bit troubling.

Chris

cool  hey you are the best
I'm not sure where in here to accept the solution because this thing is so long. any sugestions?

I'd keep it open until it's working on the new site if I were you, but it's up to you.

There's not much in it between each post, but I'd go for a split with Chief. Otherwise, pick a post each from wherever you wish :)

Lets do Aging and Scavenging, it will only take a moment and doesn't need anything doing on the remote DC.

1. Head to DC1 (main site) and open up the DNS Console.
2. Expand Forward Lookup Zones and select the Properties for your Forward Lookup Zone.
3. Click Aging
4. Tick the box at the top to enable Aging on the zone
5. Change No-Refresh to 4 days
6. Change Refresh to 4 days
7. Click OK to that one and close the properties for the zone.
8. If you have any Reverse Lookup Zones, repeat the process for those.
9. Right click on the server level and open Properties
10. Select Advanced
11. Tick enable automatic scavenging
12. Set the Scavenging Period to 1 day

This only needs doing on DC1, you don't need to make this change on any other DC.  It's done to keep DNS neat and tidy, and is designed to work with the DHCP Lease interval we set earlier on.

Everything else is testing, which will need doing once it's on-site.

Chris

agian your are the best
Thanks for all your help
This is to be set up again on manday so I will probably looking for help late on monday or early tuesday
thanks again to Both ChiefIT and Chris

Ken

Chris:

Just a thought. If we set the 16 day DHCP lease duration and a 4/4 and 1 DNS scavaging, will the records scavage before the lease is renewed?

ok so what do I have to change? the dhcp or the scavange time? and what should it be changed to?

Hi Guys

So What needs to change? Dhcp or the scavage?  and changed to what?

Thanks again for keeping up on this and all your help.
I really did learn alot.
Ken

Hi Guys

So do I have to change something?

Sorry, was fast asleep :)

For those timings to make sense I need to explain a bit about DHCP leasing (as well as when it updates DNS).

When you first get a lease from DHCP it is written into DNS (because that's what the default settings say to do).

While the lease itself lasts for 16 days clients will attempt to Renew their lease half way though (8 days). The DHCP server will send a Refresh request to DNS at this point, conveniently during the Refresh interval we set. This process of extending the lease continues as long as the client is able to request the extension.

So given that DHCP leases are valid for some multiple of 50% of the lease duration (which is the Renewal Interval), setting the Aging intervals match the Renewal Interval works rather well. Records that are completely removed from DHCP are removed from DNS in a timely fashion, where the ones that stay around maintain themselves.

All the systems configured with static addresses are happy in this scenario, they send a refresh once every 24 hours, so they get 4 chances to refresh (during the Refresh interval).

Chris

sorry guys  I didn't mean to post the same qestion so many times that was an accident.  my connection or something was not working properly and I thought the post did not go through.after the third one i gave up.

have a good weekend i will check in late monday.

Ken

Hi ChiefIT and Chris-Dent

The server came back on the domain without any problems.  It is now in it final location.
Is there anything else that I need to do to it or is it good to go?

Thanks
Ken

You might consider the browser service and SMB shares.

So, you may consider a WINS connection between them.

The master browser service is responsible for populating a list of computers and shares in "My Network Places". If  you want those populated on both sites, (for both sites), then consider WINS.

I think we talked about this briefly. If you need more information on this let me know.

Any other ideas Chris?

Morning Ken,

That sounds great :)

A final run of DCDiag is always good, otherwise, just needs a bit of an eye kept on it :)

Chris

Hi ChiefIT and Chris
I Have Wins running already.
what is the (browser service and SMB shares)

Ken

These guys are great.

Ken,

As a follow up, the browser service populates a list of computers and shares in my network places. It also is used for printer and share access.

The way it works is this. Computers will logon, and send out a broadcast that says, "I am here and these are the files and printers that I have to share". It also sends information, like what operating system it is and the role it plays on the network. Then, thereafter, the computer will check in every 15 minutes. The OS information and role infromation are used to determine what computer will be elected as the master for the domain or site. That master is called the domain master browser, or site master browser.

WINS is used to send that Netbios broadcasted information between sites, since Netbios is not a routable protocol.  The site master browsers, will send/recieve the netbios information from the domain master browser's site using WINS. This is the reason for the WINS connection between the Site's PDCe's or the PDCe and second site's DC.

Basically, anything with a broadcast can usually be attributed to Netbios broadcasts. This includes Distributive File services, and Server Message Block shares (also referred to as SMB shares).

In Fact WINS and Netbios are used for these services:

1) DFS (Distributive file shares will share out Group policies)
2) Browser service (The browser service internally uses netbios broadcasts and going to different subnets uses WINS)
3) Fax service
4) license logging service
5) netlogon
6) messanger
7) performance logs and alerts
8) Print spooler
9) RPC locator
10) server service
11) system management server
12) WINS of course


****Explaination of SMB shares:
http://en.wikipedia.org/wiki/Server_Message_Block

The reason for WINS is because your netbios broadcasted data will not route. This means it will not go through a VPN tunnel, across to different subnets, over Network Address translation, (or basically site to site). This is why I recommended you look into WINS. Since you have WINS up and working, you will probably see a list of computers and shares between both sites.

I have an NT4 article that explains the master browser service, and how it elects computers to a T. I thought you might like to read it.

http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/net/chptr3.mspx?mfr=true

Even though this is an NT4 article, the browser service hasn't changed much at all since NT4. However, there is an added process called Netbios over SMB. Netbios over SMB is done simultaneously with Netbios over TCP. The first one with the answer wins when deciding between the two processes.

The ports that these processes use are:

Netbios over TCP and WINS:
Port 137 TCP for WINS and Netbios
Port 138 UDP netbios datagram port
Port 139 UDP netbios datagram port.

Netbios over SMB:
Port 139 UDP Netbios datagram port
Port 445 TCP/UDP Netbios over SMB port