"vdz" <v**@discussions.microsoft.com> wrote in message
news:B83FC556-3DDC-4DD6-8BF2-D6FE4BF4A61C@microsoft.com...
> Hi All,
>
> I have had this server up and running well for a couple of months. Last
> week-end we had to shut it down for 2 days for maintenance. But now, it
> does
> not seem to work as before. I doulbe checked everything is back (services,
> servers..) but when I connect VPN, it does not give me an internal IP
> address, I copied and pasted below the ipconfig /all.
>
> C:\Users\dvu.WECONNECT\Desktop>ipconfig /all
>
> Windows IP Configuration
>
>   Host Name . . . . . . . . . . . . : HP2D183DV
>   Primary Dns Suffix  . . . . . . . : weconnect.local
>   Node Type . . . . . . . . . . . . : Hybrid
>   IP Routing Enabled. . . . . . . . : No
>   WINS Proxy Enabled. . . . . . . . : No
>   DNS Suffix Search List. . . . . . : weconnect.local
>                                       net.au.local
>                                       au.local
>
> PPP adapter Swish VPN Connection:
>
>   Connection-specific DNS Suffix  . :
>   Description . . . . . . . . . . . : Swish VPN Connection
>   Physical Address. . . . . . . . . :
>   DHCP Enabled. . . . . . . . . . . : No
>   Autoconfiguration Enabled . . . . : Yes
>   IPv4 Address. . . . . . . . . . . : 169.254.140.190(Preferred)
>   Subnet Mask . . . . . . . . . . . : 255.255.255.255
>   Default Gateway . . . . . . . . . : 0.0.0.0
>   DNS Servers . . . . . . . . . . . : 10.3.3.10
>   Primary WINS Server . . . . . . . : 10.3.3.10
>   NetBIOS over Tcpip. . . . . . . . : Enabled
>
> As you can see I cannot get an internal IP address (10.3.3.0 / 24) nor
> default gateway (10.3.3.1).
>
> This server was configured with DHCP to assign IP addresses.
>
> Any help would be much appreciated

"Kevin Longley" wrote:

> What is the status of your internal dhcp server?
> "vdz" <v**@discussions.microsoft.com> wrote in message
> news:B83FC556-3DDC-4DD6-8BF2-D6FE4BF4A61C@microsoft.com...
> > Hi All,
> >
> > I have had this server up and running well for a couple of months. Last
> > week-end we had to shut it down for 2 days for maintenance. But now, it
> > does
> > not seem to work as before. I doulbe checked everything is back (services,
> > servers..) but when I connect VPN, it does not give me an internal IP
> > address, I copied and pasted below the ipconfig /all.
> >
> > C:\Users\dvu.WECONNECT\Desktop>ipconfig /all
> >
> > Windows IP Configuration
> >
> >   Host Name . . . . . . . . . . . . : HP2D183DV
> >   Primary Dns Suffix  . . . . . . . : weconnect.local
> >   Node Type . . . . . . . . . . . . : Hybrid
> >   IP Routing Enabled. . . . . . . . : No
> >   WINS Proxy Enabled. . . . . . . . : No
> >   DNS Suffix Search List. . . . . . : weconnect.local
> >                                       net.au.local
> >                                       au.local
> >
> > PPP adapter Swish VPN Connection:
> >
> >   Connection-specific DNS Suffix  . :
> >   Description . . . . . . . . . . . : Swish VPN Connection
> >   Physical Address. . . . . . . . . :
> >   DHCP Enabled. . . . . . . . . . . : No
> >   Autoconfiguration Enabled . . . . : Yes
> >   IPv4 Address. . . . . . . . . . . : 169.254.140.190(Preferred)
> >   Subnet Mask . . . . . . . . . . . : 255.255.255.255
> >   Default Gateway . . . . . . . . . : 0.0.0.0
> >   DNS Servers . . . . . . . . . . . : 10.3.3.10
> >   Primary WINS Server . . . . . . . : 10.3.3.10
> >   NetBIOS over Tcpip. . . . . . . . : Enabled
> >
> > As you can see I cannot get an internal IP address (10.3.3.0 / 24) nor
> > default gateway (10.3.3.1).
> >
> > This server was configured with DHCP to assign IP addresses.
> >
> > Any help would be much appreciated
>
>

"Ace Fekay [Microsoft Certified Trainer]" wrote:

> In news:6CD2938A-A0AD-4201-9C58-BFB9C56A4214@microsoft.com,
> vdz <v**@discussions.microsoft.com>, posted the following, which I replied to down below...:  Hello vdz
> > Thank you Ace for your response.
> >
> > What type of maintenance was performed? defragmenting and also
> > relocating servers.
> > Is the RRAS server a DC? (It's highly recommended NOT to be). Yes it
> > is on DC :(
> > Is the RRAS servers also the DHCP server? Again Yes,
> > What errors do you see in the Event logs of the servers? Nothing
> > about RRAS.
> >
> > I will enable vpn log see how I go.
> >
> > Regards,
>
> Vdz,
>
> A DC being a RRAS server with multiple NICs is not recommended. It can cause numerous issue. Looking forward to the logs.
>
> Also, just to read up on why I say this, please read the following.
>
> ---
> Multihomed DCs WILL cause numerous issues. It's highly recommended to single home all DCs and use a non-DC for the multihoming purposes. If it is the internet gateway, it is recommended to purchase an inexpensive, or cable/DLS router, or even better, a Cisco or similar firewall to perform the task, which if it is compromised by an internet attacker remotely, can further compromise the rest of the internal network.
>
> Also if attempting to use ICS on a DC, this further complicates matters with DC functionality, and cannot be fixed with the following steps outlined in this article.
>
> To explain why will require a little background on AD and DNS:
>
> First, just to get this out of the way, if you have your ISP's DNS addresses in your IP configuration (DCs and clients), they need to be REMOVED. If the ISP's DNS is in there, this will cause additional problems. I usually see errors (GPOs not working, can't find the domain, RPC issues, etc), when the ISP's DNS servers are listed on a client, DCs and/or member servers, or with multihomed DCs. If you have an ISP's (or some other outside DNS server or even using your router as a DNS server) DNS addresses in your IP configuration (all DCs, member servers and clients), they need to be REMOVED and ONLY use the internal DNS server(s). This can be very problematic.
>
> Basically, AD requires DNS. DNS stores AD's resource and service locations in the form of SRV records, hence how everything that is part of the domain will find resources in the domain. If the ISP's DNS is configured in the any of the internal AD member machines' IP properties, (including all client machines and DCs), the machines will be asking the ISP's DNS 'where is the domain controller for my domain?", whenever it needs to perform a function, (such as a logon request, replication request, querying and applying GPOs, etc). Unfortunately, the ISP's DNS does not have that info and they reply with an "I dunno know", and things just fail. Unfortunately, the ISP's (or your router as a DNS server) DNS doesn't have information or records about your internal private AD domain, and they shouldn't have that sort of information.
>
> Also, AD registers certain records in DNS in the form of SRV records that signify AD's resource and service locations. When there are multiple NICs, each NIC registers. IF a client, or another DC queries DNS for this DC, it may get the wrong record. One factor controlling this is Round Robin. If a DC or client on another subnet that the DC is not configured on queries for it, Round Robin will kick in offering one or the other. If the wrong one gets offered, it may not have a route to it. On the other hand, Subnetmask Priortization will ensure a querying client will get an IP that corresponds to the subnet it's on, which will work. To insure everything works, stick with one NIC.
>
> Since this DC is multi-homed, it requires additional configuration to prevent the public interface addresses from being registered in DNS. This creates a problem for internal clients locating AD to authenticate and find other services and resources such as the Global Catalog, file sharing  and the SYSVOL DFS share and can cause GPO errors with Userenv 1000 events to be logged, authenticating to shares and printers, logging on takes forever, among numerous other issues.
>
> But if you like, there are some registry changes to eliminate the registration of the external NIC or simply use the internal networking routing to allow access. Here's the whole list of manual steps to follow.
>
> Another problem is the DC now becomes part of two Sites. This is another issue that can be problematic.
>
> But believe me, it's much easier to just get a separate NAT device or multihome a non-DC then having to alter the DC. If the both NICs are internal, I would suggest to pick a subnet, team the NICs and allow your internal routers handle the traffic between subnets - Good luck!
> ---
>
> Ace
>

"Ace Fekay [Microsoft Certified Trainer]" wrote:

> "vdz" <v**@discussions.microsoft.com> wrote in message news:65F91D9C-7B92-4AC5-B480-CB113ADCF916@microsoft.com...
> > Hello Ace,
> >
> > Thanks a lot for your info about RRAS on a DC. Actually I m just inherited
> > this network.
> > First, after reboot server a couple of times, it seems OK now.
> > Secondly, moving forward how can I stop this server? according to your
> > helpful info, it should not be on a DC, and that explains very well what has
> > happened within the network sometimes Exchange cannot communicate with thiis
> > DC etc.
>
>
> Glad you got that part working. As for communication issues, I'm not surprised. First rule of thumb is to have at least both NICs pointed to the internal IP of the DNS and remove any ISP's addresses, if there are any.
>
> I can understand inheriting a mess, such as this. It's common. :-)
>
> I can post a series of steps to FORCE a multihomed DC to work, but honestly, I would either install another server as a member server, and make that your RRAS/VPN server, or simply get a Cisco, Netscreen, Sonicwall, etc, of your choicing, firewall that will also handle VPN, and they are MUCH MORE secure than Windows PPTP VPNs. Then simply disable RRAS and disable the additional NIC and let the DC be a DC. I prefer the Cisco ASA series myself, but that's up to you.
>
> Ace
>