SBS 2K and Domain replication

[akakillroy]

I am having trouble with my servers and am wondering if its due to the fact that I have a W2K SBS and a regular W2K server I am trying to replicate with.

Strange things happen, like when I have set up the separate networks (in this case 192.168.1.x (SCFCU1) and 192.168.2.x (SCFCU2)) occasionally a workstation in the 192.168.1.x network will mistakenly connect to the SCFCU2 (192.168.2.x) server.

The only way out is to remove that workstation from AD and then re-add it.

I am also having weird issues when writing to the SCFCU1 server (192.168.1.x network) with MS Word and other application saying there is an out of disk space issue or out of memory issue, they wait a few seconds and try again then it works.

Thanks for your support!

 

[vbrocks]

What subnet mask are you using for each one?

Could be a stuck bit in your hardware somewhere ...
Is it always the same computer that switches servers?

 

[akakillroy]

192.168.1.0/24 255.255.255.0
192.168.2.0/24 255.255.255.0

That is what I have in the AD Sites and Services

Main Branch
Subnet
192.168.1.0/24 255.255.255.0
SCFCU1
NTDS Settings
SCFCU2
IP Default transport

Branch1
Subnet
192.168.2.0/24 255.255.255.0
SCFCU2
NTDS Settings
SCFCU1
IP Default transport


I also need to turn off IPSEC because my routers (when I move the SCFCU2 server to the branch, right now its in-house with the SCFCU1 server (which is the SBS)) will not pass IPSEC packets so the server cant talk over the routers :-(

Let me know what other information you need.

Thanks!

 

[akakillroy]

Forgot to say, the other problem is not specific to any one system, has happened to three systems thus far.

I do get an odd error when I do a DCDiag

Everything passes except I get an error:

Starting frssysvol
There are errors after the SYSVOL has been shared
The SYSVOL can prevent the AD from starting
.................................. SCFCU2 passed test frssysvol

Thanks

 

[vbrocks]

Do you use dhcp, and if you do, how do you have it set up?

 

[akakillroy]

No, not using DHCP. I specify the IP at the workstation.

Something else I am discovering too is that we use to have an old Windows NT Server (Domain server) I took it out of the loop, although there are registry entries in the workstations still for the old domain server (SWRDC1) our new server is SHELLCU. I am wondering if something was not done correctly when we removed the OLD domain controller, and the workstations are seeking it.

 

[vbrocks]

You should remove any mention of the previous NT PDC in the lmhosts file and the hosts file.

 

[akakillroy]

hosts file is clean, lmhosts is non existant. only the .sam (sample one is there on there server). Will check all the workstations next.

 

[akakillroy]

hosts file on all the local machine were wrong, however none of them pointed to the swr_dc1 server (old domain controller). I have aDELL BISO update to do this evening, we are on A09 and the newest is A10. Also we are going to run a FULL Dell system diagnostics tonigh and let it run all night and see what happens.

 

[vbrocks]

If both servers are on the same segment (In-House) they should have the same network ID 192.168.2 etc...
Some workstations in the segment where they are installed will still be able to talk to both servers now, even though the network IDs are different because they use broadcasting and multicasting. This may be part of the problem.

 

[akakillroy]

So what you are saying is even though I have both server on different networks, the fact that they are both local, workstations WILL try to connect to be closest server on the domain? So by moving the server to its final destination would solve the problems I am having. Is there anything I can check that will help the problem as it is now?

The way it is now, I have to take the workstation out of the domain (place it in a workgroup) then delete the computer from active directory, wait for replication to take place (wish I could force it) then add the computer back into the domain, then that fixes it for a while.

 

[vbrocks]

What are the network configuration settings on the workstations that have the problem?

 

[akakillroy]

They are all Windows XP machines, P4 1.4GH 20GB Drives 256MB Ram. They are ALL static IP address in the 192.168.1.x network with 255.255.255.0 netmasks.

I ended up demoting the second server (SCFCU2) to a domain controller, then I had to go to each machine effected (not all had problems) and I had to take them out of the domain, delete their machines names from Active directory, then re-add them to the domain just to get them to login again.

I found a artical on MS that clearly shows you can do what I am attempting to do, but for some reason since they are on two separate networks we are having problems.

SCFCU1 (SBS on 192.168.1.3) and SCFCU2 (W2K Server 192.168.2.3)

I currently gateway the two networks through my Linux server/firewall, 192.168.1.1, but when I move the SCFCU2 server to the branch it will be gatewayed through the router there on 192.168.2.1, then the SCFCU1 server will stay gatewayed through 192.168.1.1 Linux box, or even maybe the router changed to 192.168.1.1. We were having trouble initaly getting the two server to talk over the routers, so we though IPSec was the problem so I brought the server back in.

 

[vbrocks]

There is a way to make the router pass ipsec through ..

IP forwarding must be enabled for the following IP protocols and UDP port..

IP protocol ID of 51. Inbound + outbound filters set to pass AH traffic.
IP protocol ID of 50. In + out Filters set to pass ESP traffic.
UDP port 500. In + out Filters set to pass ISAKMP traffic.

Firewall ... Only when using transport mode

Router would have to create and maintain all the SAs associated with each connection.

 

[akakillroy]

I will have to talk to my router guy about that, however we did find out something interesting though:

Our main system connects to an HP3000 system, and out here at the branch I could PING all day long to every IP at the main branch (192.168.1.x from 192.168.2.x), however in order to talk to and connect directly to the 3000 from the branch we had to add a gateway to the 3000 network of 192.168.1.18 (our WAN router there) to reach 192.168.2.x/24 network. This allowed us to connect directly to the 3000 from the branch. My support tech with Summit Inf Sys, said that was very ODD. So it sounds like there is something going on at the local gateway (192.168.1.1) (its a linux box) that is filtering information between the two networks. By all rights the way things are set up I should not have to add a route / gateway at the 3000 server to the router that connects the branch, it should be passed through the local gateway.

My thoughts are that we need to make both routers the gateway address rather than the linux box there at the main branch to be the gateway, and the router as it is on 192.168.1.18 and is a regular node on the network there.

This is all giving me a headache.

 

[akakillroy]

Well here is what we found out.

Apparently the Linux box (192.168.1.1 Gateway) was filtering some traffic if not all traffic that was preventing communications (other than PING and telnet) between the servers. We have masquerading set up to allow acsess to specific workstations on the network to get acsess to the INTERNET, however it was filtering all other traffic. once we made an alteration to the iptables of the linux box we are now communicating. I am not sure if this would have been causing the ODD problems we have been encountering though.

Here is a couple of the lines from the tables that we changed.

We had this is ALL the the Masquerade lines:

-A POSTROUTING -s 192.168.1.2 -j MASQUERADE

and we changed it to this:

-A POSTROUTING -s 192.168.1.2 -d ! 192.168.0.0/16 -j MASQUERADE

 

[akakillroy]

However I demoted the second server out of the domain, and I am being told that once a server has been deoted its very iffy when you try to promot it again.