DNS and NetBIOS names not resolving over a PPTP VPN using RRAS

Short question: How does one enable the resolution of DNS and NetBIOS
names on a remote network from a client over a PPTP VPN?

Backstory:

I have a PPTP VPN facilitated by a Windows Server 2003 machine with
RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
NetBIOS and DNS names other than the server's are not being resolved
even though they once were. In other words, the command 'net view
[RRAS server name]' will respond, however 'net view [any other
computer name on the VPN's network]' will not respond. I get the error
message "System error 53 has occurred. The network path was not
found." Virtually the same thing happens with DNS. 'ping [RRAS
server]' resolves nicely, but pinging anything else gets "Ping request
could not find host accounting. Please check the name and try again."

As I said, there was a time in the recent past that DNS and NetBIOS
resolved over the VPN connection. I’m not aware of any changes that
have been made that would affect this. I've tried setting the remote
gateway as the default gateway and even setting the DNS server on the
VPN's network as my primary DNS server and still can't get any DNS
names to resolve. However, using nslookup with the remote location's
DNS server will get each name in question to resolve. Hmmmm.

Oddly enough, I have an entirely different PPTP VPN connection (this
time the VPN facilitator is an ISA 2004 server) that behaves the way
that I want it to. DNS and NetBIOS names resolve with or without the
remote gateway being my default gateway and without the remote DNS
servers being on the list of my LAN interface’s DNS servers and with
the option to register my connection’s addresses in DNS left
unchecked. There is no discernable difference between the connectoids
for the two VPN connections.

Again, how does one get remote NetBIOS and DNS names to resolve
through a VPN connection? I thought I knew, but apparently I
don't. :-|

On May 26, 9:49 pm, [email protected] wrote:
> Short question: How does one enable the resolution of DNS and NetBIOS
> names on a remote network from a client over a PPTP VPN?
>
> Backstory:
>
> I have a PPTP VPN facilitated by a Windows Server 2003 machine with
> RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
> NetBIOS and DNS names other than the server's are not being resolved
> even though they once were. In other words, the command 'net view
> [RRAS server name]' will respond, however 'net view [any other
> computer name on the VPN's network]' will not respond. I get the error
> message "System error 53 has occurred. The network path was not
> found." Virtually the same thing happens with DNS. 'ping [RRAS
> server]' resolves nicely, but pinging anything else gets "Ping request
> could not find host accounting. Please check the name and try again."
>
> As I said, there was a time in the recent past that DNS and NetBIOS
> resolved over the VPN connection. I’m not aware of any changes that
> have been made that would affect this. I've tried setting the remote
> gateway as the default gateway and even setting the DNS server on the
> VPN's network as my primary DNS server and still can't get any DNS
> names to resolve. However, using nslookup with the remote location's
> DNS server will get each name in question to resolve. Hmmmm.
>
> Oddly enough, I have an entirely different PPTP VPN connection (this
> time the VPN facilitator is an ISA 2004 server) that behaves the way
> that I want it to. DNS and NetBIOS names resolve with or without the
> remote gateway being my default gateway and without the remote DNS
> servers being on the list of my LAN interface’s DNS servers and with
> the option to register my connection’s addresses in DNS left
> unchecked. There is no discernable difference between the connectoids
> for the two VPN connections.
>
> Again, how does one get remote NetBIOS and DNS names to resolve
> through a VPN connection? I thought I knew, but apparently I
> don't. :-|

I forgot to mention that using \\IP_Address\ from the VPN client to an
IP address on the remote netework is successful. That may have been
obvious, but I figured I'd say it anyway.

The RRAS with correct DNS and WINS settings should assign DNS and WINS to
VPN client. These search result may help.
Name resolution on VPN
Name resolution is big issue in VPN access. If your VPN server doesn't
setup correctly or the VPN client can't receive the VPN DNS and WINS
settings, ...
www.chicagotech.net/nameresolutionpnvpn.htm - Similar pages

VPN name resolution and browsing
Q: VPN name resolution and browsing. After I successfully connect to
the VPN Server remotely, I cannot browse the network, and see other
computers and ...
www.chicagotech.net/Q&A/vpn1.htm


--
Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on
http://www.HowToNetworking.com
<[email protected]> wrote in message
news:b5c38d07-9d87-4b1a-b38a-95ade2040ad7@z66g2000hsc.googlegroups.com...
Short question: How does one enable the resolution of DNS and NetBIOS
names on a remote network from a client over a PPTP VPN?

Backstory:

I have a PPTP VPN facilitated by a Windows Server 2003 machine with
RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
NetBIOS and DNS names other than the server's are not being resolved
even though they once were. In other words, the command 'net view
[RRAS server name]' will respond, however 'net view [any other
computer name on the VPN's network]' will not respond. I get the error
message "System error 53 has occurred. The network path was not
found." Virtually the same thing happens with DNS. 'ping [RRAS
server]' resolves nicely, but pinging anything else gets "Ping request
could not find host accounting. Please check the name and try again."

As I said, there was a time in the recent past that DNS and NetBIOS
resolved over the VPN connection. I’m not aware of any changes that
have been made that would affect this. I've tried setting the remote
gateway as the default gateway and even setting the DNS server on the
VPN's network as my primary DNS server and still can't get any DNS
names to resolve. However, using nslookup with the remote location's
DNS server will get each name in question to resolve. Hmmmm.

Oddly enough, I have an entirely different PPTP VPN connection (this
time the VPN facilitator is an ISA 2004 server) that behaves the way
that I want it to. DNS and NetBIOS names resolve with or without the
remote gateway being my default gateway and without the remote DNS
servers being on the list of my LAN interface’s DNS servers and with
the option to register my connection’s addresses in DNS left
unchecked. There is no discernable difference between the connectoids
for the two VPN connections.

Again, how does one get remote NetBIOS and DNS names to resolve
through a VPN connection? I thought I knew, but apparently I
don't. :-|

Also this one.
How to enable name resolution
For a VPN client to can resolve full computer name and NetBIOS name of
computers on a remote network automatically, you can enable broadcast name
resolution ...
http://www.howtonetworking.com/VPN/v...esolution1.htm


--
Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on
http://www.HowToNetworking.com
<[email protected]> wrote in message
news:[email protected]...
On May 26, 9:49 pm, [email protected] wrote:
> Short question: How does one enable the resolution of DNS and NetBIOS
> names on a remote network from a client over a PPTP VPN?
>
> Backstory:
>
> I have a PPTP VPN facilitated by a Windows Server 2003 machine with
> RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
> NetBIOS and DNS names other than the server's are not being resolved
> even though they once were. In other words, the command 'net view
> [RRAS server name]' will respond, however 'net view [any other
> computer name on the VPN's network]' will not respond. I get the error
> message "System error 53 has occurred. The network path was not
> found." Virtually the same thing happens with DNS. 'ping [RRAS
> server]' resolves nicely, but pinging anything else gets "Ping request
> could not find host accounting. Please check the name and try again."
>
> As I said, there was a time in the recent past that DNS and NetBIOS
> resolved over the VPN connection. I’m not aware of any changes that
> have been made that would affect this. I've tried setting the remote
> gateway as the default gateway and even setting the DNS server on the
> VPN's network as my primary DNS server and still can't get any DNS
> names to resolve. However, using nslookup with the remote location's
> DNS server will get each name in question to resolve. Hmmmm.
>
> Oddly enough, I have an entirely different PPTP VPN connection (this
> time the VPN facilitator is an ISA 2004 server) that behaves the way
> that I want it to. DNS and NetBIOS names resolve with or without the
> remote gateway being my default gateway and without the remote DNS
> servers being on the list of my LAN interface’s DNS servers and with
> the option to register my connection’s addresses in DNS left
> unchecked. There is no discernable difference between the connectoids
> for the two VPN connections.
>
> Again, how does one get remote NetBIOS and DNS names to resolve
> through a VPN connection? I thought I knew, but apparently I
> don't. :-|

I forgot to mention that using \\IP_Address\ from the VPN client to an
IP address on the remote netework is successful. That may have been
obvious, but I figured I'd say it anyway.

On May 27, 9:21 am, "Robert L. \(MS-MVP\)" <[email protected]>
wrote:
> Also this one.
> How to enable name resolution
> For a VPN client to can resolve full computer name and NetBIOSname of
> computers on a remote network automatically, you can enable broadcast name
> resolution ...
> http://www.howtonetworking.com/VPN/v...esolution1.htm
>
> --
> Bob Lin, MS-MVP, MCSE & CNE
> Networking, Internet, Routing, VPN Troubleshooting onhttp://www.ChicagoTech.net
> How to Setup Windows, Network, VPN & Remote Access onhttp://www.HowToNetworking.com<[email protected]> wrote in message
>
> news:[email protected]...
> On May 26, 9:49 pm, [email protected] wrote:
>
>
>
> > Short question: How does one enable the resolution of DNS and NetBIOS
> > names on a remote network from a client over a PPTP VPN?
>
> > Backstory:
>
> > I have a PPTP VPN facilitated by a Windows Server 2003 machine with
> > RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
> > NetBIOS and DNS names other than the server's are not being resolved
> > even though they once were. In other words, the command 'net view
> > [RRAS server name]' will respond, however 'net view [any other
> > computer name on the VPN's network]' will not respond. I get the error
> > message "System error 53 has occurred. The network path was not
> > found." Virtually the same thing happens with DNS. 'ping [RRAS
> > server]' resolves nicely, but pinging anything else gets "Ping request
> > could not find host accounting. Please check the name and try again."
>
> > As I said, there was a time in the recent past that DNS and NetBIOS
> > resolved over the VPN connection. I’m not aware of any changes that
> > have been made that would affect this. I've tried setting the remote
> > gateway as the default gateway and even setting the DNS server on the
> > VPN's network as my primary DNS server and still can't get any DNS
> > names to resolve. However, using nslookup with the remote location's
> > DNS server will get each name in question to resolve. Hmmmm.
>
> > Oddly enough, I have an entirely different PPTP VPN connection (this
> > time the VPN facilitator is an ISA 2004 server) that behaves the way
> > that I want it to. DNS and NetBIOS names resolve with or without the
> > remote gateway being my default gateway and without the remote DNS
> > servers being on the list of my LAN interface’s DNS servers and with
> > the option to register my connection’s addresses in DNS left
> > unchecked. There is no discernable difference between the connectoids
> > for the two VPN connections.
>
> > Again, how does one get remote NetBIOS and DNS names to resolve
> > through a VPN connection? I thought I knew, but apparently I
> > don't. :-|
>
> I forgot to mention that using \\IP_Address\ from the VPN client to an
> IP address on the remote netework is successful. That may have been
> obvious, but I figured I'd say it anyway.

On May 27, 9:21 am, "Robert L. \(MS-MVP\)" <[email protected]>
wrote:
> Also this one.
> How to enable name resolution
> For a VPN client to can resolve full computer name and NetBIOSname of
> computers on a remote network automatically, you can enable broadcast name
> resolution ...
> http://www.howtonetworking.com/VPN/v...esolution1.htm
>
> --
> Bob Lin, MS-MVP, MCSE & CNE
> Networking, Internet, Routing, VPN Troubleshooting onhttp://www.ChicagoTech.net
> How to Setup Windows, Network, VPN & Remote Access onhttp://www.HowToNetworking.com<[email protected]> wrote in message
>
> news:[email protected]...
> On May 26, 9:49 pm, [email protected] wrote:
>
>
>
> > Short question: How does one enable the resolution of DNS and NetBIOS
> > names on a remote network from a client over a PPTP VPN?
>
> > Backstory:
>
> > I have a PPTP VPN facilitated by a Windows Server 2003 machine with
> > RRAS. VPN traffic is forwarded through a firewall to the RRAS machine.
> > NetBIOS and DNS names other than the server's are not being resolved
> > even though they once were. In other words, the command 'net view
> > [RRAS server name]' will respond, however 'net view [any other
> > computer name on the VPN's network]' will not respond. I get the error
> > message "System error 53 has occurred. The network path was not
> > found." Virtually the same thing happens with DNS. 'ping [RRAS
> > server]' resolves nicely, but pinging anything else gets "Ping request
> > could not find host accounting. Please check the name and try again."
>
> > As I said, there was a time in the recent past that DNS and NetBIOS
> > resolved over the VPN connection. I’m not aware of any changes that
> > have been made that would affect this. I've tried setting the remote
> > gateway as the default gateway and even setting the DNS server on the
> > VPN's network as my primary DNS server and still can't get any DNS
> > names to resolve. However, using nslookup with the remote location's
> > DNS server will get each name in question to resolve. Hmmmm.
>
> > Oddly enough, I have an entirely different PPTP VPN connection (this
> > time the VPN facilitator is an ISA 2004 server) that behaves the way
> > that I want it to. DNS and NetBIOS names resolve with or without the
> > remote gateway being my default gateway and without the remote DNS
> > servers being on the list of my LAN interface’s DNS servers and with
> > the option to register my connection’s addresses in DNS left
> > unchecked. There is no discernable difference between the connectoids
> > for the two VPN connections.
>
> > Again, how does one get remote NetBIOS and DNS names to resolve
> > through a VPN connection? I thought I knew, but apparently I
> > don't. :-|
>
> I forgot to mention that using \\IP_Address\ from the VPN client to an
> IP address on the remote netework is successful. That may have been
> obvious, but I figured I'd say it anyway.

Thanks for your time,

Let me see if I understand the situation correctly. Supposedly,
whatever DNS and WINS wettings are on the VPN server will be inherited
by all VPN clients. What if the VPN server has more than one network
card? Which interface will the information be inherited from? As one
article on ChicagoTech.net said "If name resolution does not work from
the VPN server, it will not work for VPN clients." However, in my
situation, the RRAS server is functioning perfectly in every other
way.

Also, when I attempted to manually set the DNS server properties in
the VPN connection, I noticed that they were not there since the
connectoid is a CMAK creation. I'm quickly becoming less and less
enchanted with CMAK. Moving on... I created a new VPN connection the
old-fashined way and manually set the DNS server settings with no
success.

Here's what puzzles me. I have a separate DHCP server on the remote
network. I set up RRAS with the relay agent turned on. My DHCP server
shows that the RRAS server likes to grab 9 DHCP leases at a time. That
is in-line with my understanding of RRAS; it's supposed to do that,
right? However, when I look at the status of the VPN connection on a
client machine to see what IP address it is connecting to, it shows an
IP address that is definitely NOT my VPN server. The IP address is
acually one of the 9 that RRAS server too from DHCP. I double-checked
to make sure that my eyes were not deceiving me.

That made me think that maybe there was some mistake in how I set up
the DHCP relay agent. I checked and noticed two interfaces in the
relay agent console; "Local Area Connection" and "Internal". Not
knowing exactly what Internal did, I disabled it (yeah, bad
troubleshooting practice. I know, I know...). An ipconfig /all reveals
that the server has two interfaces, one is the LAN connection and the
second is a "PPP adapter RAS Server (Dial in) Interface" and it seems
to be using one of the 9 DHCP addresses that it got from the DHCP
server. Okay, so should that interface have DNS/WINS info put in it?
It's not in my network connections folder nor can I tweak it in netsh
because netsh doesn't show it.

Flustered, I turned off the DHCP relay agent, made a static pool of
addresses and retried. Same symptoms. The PPP adapter uses the first
IP in the static pool, client machines grab up the rest and no DNS or
NetBIOS is resolving over the VPN. Argh. Should I install DNS and WINS
on the VPN server? Why did this work at one point in the past but not
now? Stray Alpha particles?

I'm stonewalled. Anyone have any ideas? <X_x>

<[email protected]> wrote in message
news:c2fd66e1-4161-449b-b2c5-13172b3958e6@l28g2000prd.googlegroups.com...
Let me see if I understand the situation correctly. Supposedly,
whatever DNS and WINS wettings are on the VPN server will be inherited
by all VPN clients.

[Phil] No.

What if the VPN server has more than one network
card?

[Phil] Not relevant

Which interface will the information be inherited from?

[Phil] It is not "inherited". The client get its config from DHCP combined
with the DHCP Relay Agent.

connectoid is a CMAK creation. I'm quickly becoming less and less
enchanted with CMAK. Moving on... I created a new VPN connection the

[Phil] Never used CMAK, was never interested in it,..so I can't help you
with that.

Here's what puzzles me. I have a separate DHCP server on the remote
network. I set up RRAS with the relay agent turned on. My DHCP server
shows that the RRAS server likes to grab 9 DHCP leases at a time.

[Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4 L2TP)
plus one for the RRAS "internal" interface which gives you 9.

IP address that is definitely NOT my VPN server.

[Phil] Not supposed to be

The IP address is acually one of the 9 that RRAS server too from DHCP.

[Phil] Supposed to be

the DHCP relay agent. I checked and noticed two interfaces in the
relay agent console; "Local Area Connection" and "Internal".

[Phil] Supposed to be that way. This is probably the Root of all your
trouble. I think for the DHCP Relay Agent to work correctly it needs to be
set to Local Area Connection because that is the interface that "faces" the
DHCP Server that the agent needs to do all of its "agent-ing" with. But I
could be wrong,...try that first, if it doesn't work set it to "internal".

second is a "PPP adapter RAS Server (Dial in) Interface" and it seems
to be using one of the 9 DHCP addresses that it got from the DHCP
server. Okay, so should that interface have DNS/WINS info put in it?

[Phil] No. Supposed to be *left alone*

Flustered, I turned off the DHCP relay agent,

[Phil] Turn it back on

made a static pool of
addresses and retried. Same symptoms. The PPP adapter uses the first
IP in the static pool, client machines grab up the rest and no DNS or
NetBIOS is resolving over the VPN. Argh.

[Phil] Get rid of the Pool

Should I install DNS and WINS on the VPN server?

[Phil] No. I believe the Root of your problem was the interface that the
DHCP Relay Agent was associated with. It is really fairly
simple,...correctly configure the DHCP Relay Agent,...and the Clients get
the same IP Config from the same DHCP Scope as all the other machines on the
same IP segment on the LAN,...that's it,..it's that simple,...so the more
complex your "solution", the less likely it is the correct solution.

The DHCP Relay Agent is not required the get an IP#,...you can get that
without the Agent. But you need the Agent to get DHCP Options (like WINS,
DNS, etc). Without the Agent all you get is the IP#.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

On May 27, 4:45 pm, "Phillip Windell" <[email protected]> wrote:
> <[email protected]> wrote in message
>
> news:c2fd66e1-4161-449b-b2c5-13172b3958e6@l28g2000prd.googlegroups.com...
> Let me see if I understand the situation correctly. Supposedly,
> whatever DNS and WINS wettings are on the VPN server will be inherited
> by all VPN clients.
>
> [Phil] No.
>
> What if the VPN server has more than one network
> card?
>
> [Phil] Not relevant
>
> Which interface will the information be inherited from?
>
> [Phil] It is not "inherited". The client get its config from DHCP combined
> with the DHCP Relay Agent.
>
> connectoid is a CMAK creation. I'm quickly becoming less and less
> enchanted with CMAK. Moving on... I created a new VPN connection the
>
> [Phil] Never used CMAK, was never interested in it,..so I can't help you
> with that.
>
> Here's what puzzles me. I have a separate DHCP server on the remote
> network. I set up RRAS with the relay agent turned on. My DHCP server
> shows that the RRAS server likes to grab 9 DHCP leases at a time.
>
> [Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4 L2TP)
> plus one for the RRAS "internal" interface which gives you 9.
>
> IP address that is definitely NOT my VPN server.
>
> [Phil] Not supposed to be
>
> The IP address is acually one of the 9 that RRAS server too from DHCP.
>
> [Phil] Supposed to be
>
> the DHCP relay agent. I checked and noticed two interfaces in the
> relay agent console; "Local Area Connection" and "Internal".
>
> [Phil] Supposed to be that way. This is probably the Root of all your
> trouble. I think for the DHCP Relay Agent to work correctly it needs tobe
> set to Local Area Connection because that is the interface that "faces" the
> DHCP Server that the agent needs to do all of its "agent-ing" with. ButI
> could be wrong,...try that first, if it doesn't work set it to "internal".
>
> second is a "PPP adapter RAS Server (Dial in) Interface" and it seems
> to be using one of the 9 DHCP addresses that it got from the DHCP
> server. Okay, so should that interface have DNS/WINS info put in it?
>
> [Phil] No. Supposed to be *left alone*
>
> Flustered, I turned off the DHCP relay agent,
>
> [Phil] Turn it back on
>
> made a static pool of
> addresses and retried. Same symptoms. The PPP adapter uses the first
> IP in the static pool, client machines grab up the rest and no DNS or
> NetBIOS is resolving over the VPN. Argh.
>
> [Phil] Get rid of the Pool
>
> Should I install DNS and WINS on the VPN server?
>
> [Phil] No. I believe the Root of your problem was the interface that the
> DHCP Relay Agent was associated with. It is really fairly
> simple,...correctly configure the DHCP Relay Agent,...and the Clients get
> the same IP Config from the same DHCP Scope as all the other machines on the
> same IP segment on the LAN,...that's it,..it's that simple,...so the more
> complex your "solution", the less likely it is the correct solution.
>
> The DHCP Relay Agent is not required the get an IP#,...you can get that
> without the Agent. But you need the Agent to get DHCP Options (like WINS,
> DNS, etc). Without the Agent all you get is the IP#.
>
> --
> Phillip Windellwww.wandtv.com
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------



>> [Phil] It is not "inherited". The client get its config from DHCP combined
with the DHCP Relay Agent. <<

That would make sense. I was a bit confused by the following
however...

Quoth ChicagoTech.net:
"
Name resolution Issue in a VPN client

To assign the DNS and WINS to a VPN client for name resolution, you
should configure VPN server with the IP addresses of the appropriate
DNS and WINS servers. The VPN client inherits the DNS and WINS
configured on the VPN server. If name resolution does not work from
the VPN server, it will not work for VPN clients.
"

Does that mean that DNS/WINS information is inherited only when the
VPN client gets a static IP from the RRAS server? On the surface,
there seems to be a contradiction in what I'm hearing.


>> [Phil] Never used CMAK, was never interested in it,..so I can't help you
with that. <<

How do you deploy VPN connectoids to clients? Or maybe that's
something that you don't have to do in your situation.


>>[Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4 L2TP)
plus one for the RRAS "internal" interface which gives you 9.<<

Oddly enough, I've got 1 WAN Miniport (PPPOE), 128 PPTP ports, 128
L2TP ports, and 1 Direct Parallel port.


>> the DHCP relay agent. I checked and noticed two interfaces in the
relay agent console; "Local Area Connection" and "Internal".

[Phil] Supposed to be that way. This is probably the Root of all
your
trouble. I think for the DHCP Relay Agent to work correctly it needs
to be
set to Local Area Connection because that is the interface that
"faces" the
DHCP Server that the agent needs to do all of its "agent-ing" with.
But I
could be wrong,...try that first, if it doesn't work set it to
"internal". <<

Just to make sure that we're on the same page; I see "Local Area
Connection" and "Internal" when I select the "DHCP Relay Agent"
heading under "IP Routing" in the RRAS console. Both were set to
"Relay mode: Enabled". For giggles, I disabled "Internal" but that
didn't change anything.

There's a second setting that affects DHCP. If you right-click >>
properties the RRAS server in the RRAS console and then select the
"IP" tab you'll see at the bottom a place where you can select the
interface that is used for getting DHCP for clients. The local area
connection on the LAN is the selected interface. "Internal" is not a
choice here; Only the local area connection and then a 1394 adapter
(Firewire card).


>> Flustered, I turned off the DHCP relay agent,

[Phil] Turn it back on <<

I turned it back on and am successfully getting DHCP to VPN clients.



>> [Phil] Get rid of the Pool <<

Done.


>> [Phil] No. I believe the Root of your problem was the interface that the
DHCP Relay Agent was associated with. It is really fairly
simple,...correctly configure the DHCP Relay Agent,...and the Clients
get
the same IP Config from the same DHCP Scope as all the other machines
on the
same IP segment on the LAN,...that's it,..it's that simple,...so the
more
complex your "solution", the less likely it is the correct solution.<<

Okay, so the only configuration change from my original options is
that under "DHCP Relay Agent" the interface named "Internal" has been
disabled. In the "IP" tab of the RRAS server, the local area
connection is selected as the DHCP interface, but it was selected all
along anyway. That hasn't changed.

I agree about how it should be simple. It just seems that everything
gets more complex than it is. :)



>> The DHCP Relay Agent is not required the get an IP#,...you can get that
without the Agent. But you need the Agent to get DHCP Options (like
WINS,
DNS, etc). Without the Agent all you get is the IP#. <<

I wasn't aware of that.

Could this be a problem with my DHCP server? It's just a LinkSys RV082
that acts as the Gateway, DNS, DHCP, and space heater. That would be
curious since all clients on the LAN get DHCP with options just fine.

Any and all help from anyone and their extended family would be
appreciated. :)


Thanks,

On May 27, 8:59 pm, [email protected] wrote:
> On May 27, 4:45 pm, "Phillip Windell" <[email protected]> wrote:
>
>
>
> > <[email protected]> wrote in message
>
> >news:c2fd66e1-4161-449b-b2c5-13172b3958e6@l28g2000prd.googlegroups.com...
> > Let me see if I understand the situation correctly. Supposedly,
> > whatever DNS and WINS wettings are on the VPN server will be inherited
> > by all VPN clients.
>
> > [Phil] No.
>
> > What if the VPN server has more than one network
> > card?
>
> > [Phil] Not relevant
>
> > Which interface will the information be inherited from?
>
> > [Phil] It is not "inherited". The client get its config from DHCP combined
> > with the DHCP Relay Agent.
>
> > connectoid is a CMAK creation. I'm quickly becoming less and less
> > enchanted with CMAK. Moving on... I created a new VPN connection the
>
> > [Phil] Never used CMAK, was never interested in it,..so I can't help you
> > with that.
>
> > Here's what puzzles me. I have a separate DHCP server on the remote
> > network. I set up RRAS with the relay agent turned on. My DHCP server
> > shows that the RRAS server likes to grab 9 DHCP leases at a time.
>
> > [Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4L2TP)
> > plus one for the RRAS "internal" interface which gives you 9.
>
> > IP address that is definitely NOT my VPN server.
>
> > [Phil] Not supposed to be
>
> > The IP address is acually one of the 9 that RRAS server too from DHCP.
>
> > [Phil] Supposed to be
>
> > the DHCP relay agent. I checked and noticed two interfaces in the
> > relay agent console; "Local Area Connection" and "Internal".
>
> > [Phil] Supposed to be that way. This is probably the Root of all your
> > trouble. I think for the DHCP Relay Agent to work correctly it needs to be
> > set to Local Area Connection because that is the interface that "faces" the
> > DHCP Server that the agent needs to do all of its "agent-ing" with. But I
> > could be wrong,...try that first, if it doesn't work set it to "internal".
>
> > second is a "PPP adapter RAS Server (Dial in) Interface" and it seems
> > to be using one of the 9 DHCP addresses that it got from the DHCP
> > server. Okay, so should that interface have DNS/WINS info put in it?
>
> > [Phil] No. Supposed to be *left alone*
>
> > Flustered, I turned off the DHCP relay agent,
>
> > [Phil] Turn it back on
>
> > made a static pool of
> > addresses and retried. Same symptoms. The PPP adapter uses the first
> > IP in the static pool, client machines grab up the rest and no DNS or
> > NetBIOS is resolving over the VPN. Argh.
>
> > [Phil] Get rid of the Pool
>
> > Should I install DNS and WINS on the VPN server?
>
> > [Phil] No. I believe the Root of your problem was the interface that the
> > DHCP Relay Agent was associated with. It is really fairly
> > simple,...correctly configure the DHCP Relay Agent,...and the Clients get
> > the same IP Config from the same DHCP Scope as all the other machines onthe
> > same IP segment on the LAN,...that's it,..it's that simple,...so the more
> > complex your "solution", the less likely it is the correct solution.
>
> > The DHCP Relay Agent is not required the get an IP#,...you can get that
> > without the Agent. But you need the Agent to get DHCP Options (like WINS,
> > DNS, etc). Without the Agent all you get is the IP#.
>
> > --
> > Phillip Windellwww.wandtv.com
>
> > The views expressed, are my own and not those of my employer, or Microsoft,
> > or anyone else associated with me, including my cats.
> > -----------------------------------------------------
> >> [Phil] It is not "inherited". The client get its config from DHCP combined
>
> with the DHCP Relay Agent. <<
>
> That would make sense. I was a bit confused by the following
> however...
>
> Quoth ChicagoTech.net:
> "
> Name resolution Issue in a VPN client
>
> To assign the DNS and WINS to a VPN client for name resolution, you
> should configure VPN server with the IP addresses of the appropriate
> DNS and WINS servers. The VPN client inherits the DNS and WINS
> configured on the VPN server. If name resolution does not work from
> the VPN server, it will not work for VPN clients.
> "
>
> Does that mean that DNS/WINS information is inherited only when the
> VPN client gets a static IP from the RRAS server? On the surface,
> there seems to be a contradiction in what I'm hearing.
>
> >> [Phil] Never used CMAK, was never interested in it,..so I can't help you
>
> with that. <<
>
> How do you deploy VPN connectoids to clients? Or maybe that's
> something that you don't have to do in your situation.
>
> >>[Phil] Normal. You probably have 8 RRAS ports (probably 4 PPTP & 4L2TP)
>
> plus one for the RRAS "internal" interface which gives you 9.<<
>
> Oddly enough, I've got 1 WAN Miniport (PPPOE), 128 PPTP ports, 128
> L2TP ports, and 1 Direct Parallel port.
>
> >> the DHCP relay agent. I checked and noticed two interfaces in the
>
> relay agent console; "Local Area Connection" and "Internal".
>
> [Phil] Supposed to be that way. This is probably the Root of all
> your
> trouble. I think for the DHCP Relay Agent to work correctly it needs
> to be
> set to Local Area Connection because that is the interface that
> "faces" the
> DHCP Server that the agent needs to do all of its "agent-ing" with.
> But I
> could be wrong,...try that first, if it doesn't work set it to
> "internal". <<
>
> Just to make sure that we're on the same page; I see "Local Area
> Connection" and "Internal" when I select the "DHCP Relay Agent"
> heading under "IP Routing" in the RRAS console. Both were set to
> "Relay mode: Enabled". For giggles, I disabled "Internal" but that
> didn't change anything.
>
> There's a second setting that affects DHCP. If you right-click >>
> properties the RRAS server in the RRAS console and then select the
> "IP" tab you'll see at the bottom a place where you can select the
> interface that is used for getting DHCP for clients. The local area
> connection on the LAN is the selected interface. "Internal" is not a
> choice here; Only the local area connection and then a 1394 adapter
> (Firewire card).
>
> >> Flustered, I turned off the DHCP relay agent,
>
> [Phil] Turn it back on <<
>
> I turned it back on and am successfully getting DHCP to VPN clients.
>
> >> [Phil] Get rid of the Pool <<
>
> Done.
>
> >> [Phil] No. I believe the Root of your problem was the interface thatthe
>
> DHCP Relay Agent was associated with. It is really fairly
> simple,...correctly configure the DHCP Relay Agent,...and the Clients
> get
> the same IP Config from the same DHCP Scope as all the other machines
> on the
> same IP segment on the LAN,...that's it,..it's that simple,...so the
> more
> complex your "solution", the less likely it is the correct solution.<<
>
> Okay, so the only configuration change from my original options is
> that under "DHCP Relay Agent" the interface named "Internal" has been
> disabled. In the "IP" tab of the RRAS server, the local area
> connection is selected as the DHCP interface, but it was selected all
> along anyway. That hasn't changed.
>
> I agree about how it should be simple. It just seems that everything
> gets more complex than it is. :)
>
> >> The DHCP Relay Agent is not required the get an IP#,...you can get that
>
> without the Agent. But you need the Agent to get DHCP Options (like
> WINS,
> DNS, etc). Without the Agent all you get is the IP#. <<
>
> I wasn't aware of that.
>
> Could this be a problem with my DHCP server? It's just a LinkSys RV082
> that acts as the Gateway, DNS, DHCP, and space heater. That would be
> curious since all clients on the LAN get DHCP with options just fine.
>
> Any and all help from anyone and their extended family would be
> appreciated. :)
>
> Thanks,

Ack! I forgot to mention that when I "ipconfig /all" on a VPN client
machine, it correctly shows that I have the remote network's DNS
server as that VPN tunnel's primary DNS server. The options are
arriving, but could the packets be stripped out over the VPN?

<[email protected]> wrote in message
news:81e008a3-f81c-4b4c-acf9-<[email protected]...

<Could this be a problem with my DHCP server? It's just a LinkSys RV082
<that acts as the Gateway, DNS, DHCP, and space heater. That would be
<curious since all clients on the LAN get DHCP with options just fine.

<Any and all help from anyone and their extended family would be
<appreciated. :)

The fact that you are running your LAN using a Linksys for DNS and DHCP
sets of alarm bells. Are you also running a domain controller? If you are
you should not be using the Linksys for DNS or DHCP.

Netbios name resolution does not usually work on a WAN link without
WINS. This is because LAN broadcasts do not cross the WAN link, and Netbios
on the LAN uses broadcasts by default.

DNS name resolution usually does work because the remote will get the IP
address of the DNS server when it connects. However this assumes that you
are running a DNS server on your LAN, not just a DNS relay through a NAT
device (such as your Linksys).

On May 27, 9:27 pm, "Bill Grant" <not.available@online> wrote:
> <[email protected]> wrote in message
>
> news:81e008a3-f81c-4b4c-acf9-...
>
> <Could this be a problem with my DHCP server? It's just a LinkSys RV082
> <that acts as the Gateway, DNS, DHCP, and space heater. That would be
> <curious since all clients on the LAN get DHCP with options just fine.
>
> <Any and all help from anyone and their extended family would be
> <appreciated. :)
>
> The fact that you are running your LAN using a Linksys for DNS and DHCP
> sets of alarm bells. Are you also running a domain controller? If you are
> you should not be using the Linksys for DNS or DHCP.
>
> Netbios name resolution does not usually work on a WAN link without
> WINS. This is because LAN broadcasts do not cross the WAN link, and Netbios
> on the LAN uses broadcasts by default.
>
> DNS name resolution usually does work because the remote will get the IP
> address of the DNS server when it connects. However this assumes that you
> are running a DNS server on your LAN, not just a DNS relay through a NAT
> device (such as your Linksys). Reply Reply to author Forward Rate this post:var rh_cc4ac4a6bf232192 =new RAT_RatingHolder('cc4ac4a6bf232192', '0', ''); //-->Text for clearing space
>
> Cancel
>
>
>
>
>
> Send Discard
>
>
>
>
>
> From:[email protected]:
>
> Cc:Followup To:Add Cc|Add Followup-to|Edit SubjectSubject:
>
> Validation:
>
> For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon.Send Discard
>
>
>
>
>
>
>
>
>
>
>
> You mustSign inbefore you can post messages.
>
> To post a message you must firstjoin this group.
>
> Please update your nickname on thesubscription settingspage before posting..
>
> You do not have the permission required to post.
>
> var msg = G2_cardManager._getMessage("cc4ac4a6bf232192"); msg._init("cc4ac4a6bf232192", "#[email protected]", true, "over", true,false, "", 1); msg._setPrev(G2_cardManager._getCard("msg_ea2909e3704de6e5"), 1); msg._addPreLoadHook(function() { this._setPostNeedsCaptcha(true); this.._setIsUsenet(true); this._setBottomPosting(true); }); //-->

This is just a workgroup environment for a small office. (Side Note: a
budget has been set aside for a domain controller for next year.
Yay! )

>> Netbios name resolution does not usually work on a WAN link without
WINS. This is because LAN broadcasts do not cross the WAN link, and
Netbios
on the LAN uses broadcasts by default. <<

What I'm used to is that 'net view' will not bring back netbios names
on a remote network, but 'net view [machineName]' will behave as
expected. It behaves that way on another connection.


>> DNS name resolution usually does work because the remote will get the IP
address of the DNS server when it connects. However this assumes that
you
are running a DNS server on your LAN, not just a DNS relay through a
NAT
device (such as your Linksys). <<

The LinkSys is acting as a DNS server. I'm assuming its just a caching
server that sends recursive queries when it has no cached rseponse. It
also has what is essentially an A record for the RRAS server. No, I'm
not happy about the LinkSys's DNS offerings, but I know that this
worked at some point in the recent past. I remember because I was
deleriously happy that I could resolve DNS and NetBIOS over the link
and was planning out the next task that I would tackle. Then I noticed
that all was not behaving as I had wished. >_<

Remember, nslookup works fine... most of the time. I say 'most of the
time' because on occasion not even nslookup resolves names across the
VPN. ::bangs head on desk:: I'm not sure why. This whole setup seems
flaky.

Net view depends on the computer browser service, which in turn depends
on LAN broadcasts. You could try enabling LAN broadcasts in RRAS if it is
running on W2k3. I have never used it but it reportedly works. The remote
then looks just like another machine on the LAN and name resolution and net
view should work.

If that doesn't work I would say that you are stuck until you get a
domain set up.

If you are only running a workgroup and no local DNS I doubt that you
will ever get DNS to work properly from the remote. The remote need to have
the IP address of the DNS server and also the correct domain suffix. And the
DNS needs to actually have a record pointing to the client's IP address.

Similarly I doubt that you would ever get browsing to work properly with
only a workgroup, even with WINS. The problem is the way that the client
tries to find a browse list without broadcasts. It sends a message to WINS
looking for the domain master browser. If you don't have a domain, you don't
have one of those!

On May 28, 12:24 am, "Bill Grant" <not.available@online> wrote:
>> Net view depends on the computer browser service, which in turn
depends
on LAN broadcasts. You could try enabling LAN broadcasts in RRAS if it
is
running on W2k3. I have never used it but it reportedly works. The
remote
then looks just like another machine on the LAN and name resolution
and net
view should work. <<

Broadcasting is enabled on the RRAS server. Recall my symptoms: A "net
view" from a VPN'd client only shows the Windows machines on the
client's LAN (that's fine). I can't even do a "net view
[computerName]" across the VPN **except** for the RRAS machine that
I'm VPN'd into. "Net view [IPAddress]" works for all machines on the
remote LAN. I'd like a VPN client to be able to go to the the run
command and use a UNC path with the remote computer's name to get to
that machine's shares.

>> If that doesn't work I would say that you are stuck until you
get a
domain set up. <<

Alot of what I'm doing for this office seems like I'm just hacking it
together until I can get the domain set up. =)

>> If you are only running a workgroup and no local DNS I doubt that you
will ever get DNS to work properly from the remote. The remote need to
have
the IP address of the DNS server and also the correct domain suffix.
And the
DNS needs to actually have a record pointing to the client's IP
address. <<

I think that the RV082 is a DNS server. Client machines on the LAN can
and do register their names in the LinkSys. Remember, nslookup using
the RV082 as it's name server will correctly resolve DNS names. Also
recall that in the past I have had success at this. I just can't seem
to repeat it or figure out what (if anything) was different about the
circumstances surrounding the success.

>> Similarly I doubt that you would ever get browsing to work properly with
only a workgroup, even with WINS. The problem is the way that the
client
tries to find a browse list without broadcasts. It sends a message to
WINS
looking for the domain master browser. If you don't have a domain, you
don't
have one of those! <<

But if I put a WINS server in DHCP optino 44, I would still be able to
reliably UNC to specific machines. In theory anyway. I'd be happy with
that until next year. At least I could use scripts that rely on
NetBIOS names.


More and more I'm beginning to suspect that the LinkSys is flaky. Over
the past months, LinkSys products have lost my favor. Shame on Cisco
for not bringing their subsidiary's quality up.

Unless someone can offer some more insight, I might just install DNS /
WINS. It can't hurt anything... (famous last words).

<[email protected]> wrote in message
news:81e008a3-f81c-4b4c-acf9-ef0c9e9550dc@u12g2000prd.googlegroups.com...
On May 27, 4:45 pm, "Phillip Windell" <[email protected]> wrote:

>> [Phil] It is not "inherited". The client get its config from DHCP
>> combined
with the DHCP Relay Agent. <<

>That would make sense. I was a bit confused by the following
>however...
>Quoth ChicagoTech.net:

I don't know. I never use RRAS that way. I use it with DHCP (the real DHCP)
and the Relay Agent.

>> [Phil] Never used CMAK, was never interested in it,..so I can't help you
with that. <<
>How do you deploy VPN connectoids to clients?

I don't "deploy" connectiods. They are too simple and too few of them to
bother.

>> the DHCP relay agent. I checked and noticed two interfaces in the
relay agent console; "Local Area Connection" and "Internal".

[Phil] Supposed to be that way. This is probably the Root of all
your
trouble. I think for the DHCP Relay Agent to work correctly it needs
to be
set to Local Area Connection because that is the interface that
"faces" the
DHCP Server that the agent needs to do all of its "agent-ing" with.
But I
could be wrong,...try that first, if it doesn't work set it to
"internal". <<

Just to make sure that we're on the same page; I see "Local Area
Connection" and "Internal" when I select the "DHCP Relay Agent"
heading under "IP Routing" in the RRAS console. Both were set to
"Relay mode: Enabled". For giggles, I disabled "Internal" but that
didn't change anything.

There's a second setting that affects DHCP. If you right-click >>
properties the RRAS server in the RRAS console and then select the
"IP" tab you'll see at the bottom a place where you can select the
interface that is used for getting DHCP for clients. The local area
connection on the LAN is the selected interface. "Internal" is not a
choice here; Only the local area connection and then a 1394 adapter
(Firewire card).

>> Flustered, I turned off the DHCP relay agent,

[Phil] Turn it back on <<

I turned it back on and am successfully getting DHCP to VPN clients.

>> [Phil] Get rid of the Pool <<

Done.

> Could this be a problem with my DHCP server? It's just a LinkSys RV082
> that acts as the Gateway, DNS, DHCP, and space heater. That would be
> curious since all clients on the LAN get DHCP with options just fine.

You should:
1. Throw out the Linksys box. (optional)
2. Let the RRAS box *be* the Router (optional)
3. Run DHCP, DNS, WINS on the Domain Controller
4. Do not make the RRAS box the Domain Controller.
5. All hosts on the LAN use the DC for the DNS
6. The DC/DNS then uses the ISP's DNS in the Forwarders List within the DNS
Service Config


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

>> You should:
1. Throw out the Linksys box. (optional) <<

Or at least remove all vital systems from it and keep it as the
router, an extra switch (it has VLANs, which I use), emergency VPN
entrypoint, and of course a space heater.


>> 2. Let the RRAS box *be* the Router (optional) <<

I can't do that in this scenario. At least not yet. Maybe next year.


>> 3. Run DHCP, DNS, WINS on the Domain Controller <<

Remember that this is a workgroup, not a domain. But I can put DHCP,
DNS, and WINS on the RRAS server.


>> 4. Do not make the RRAS box the Domain Controller. <<

Not applicable, but I'm curious to know why RRAS and DCs don't mix
well.


>> 5. All hosts on the LAN use the DC for the DNS <<

Or, in my scenario, I could translate that to "All hosts on the LAN
use the workgroup server for DNS"



>> 6. The DC/DNS then uses the ISP's DNS in the Forwarders List within the DNS
Service Config <<

Sounds relatively simple. As long as no-one objects to piling DHCP,
DNS, WINS, and RRAS on the same box I say it's a go.

Does everyone seem to agree that the LinkSys is a strong suspect in
this debacle or does something else smell fishy?

I still can't figure out why at some times in the past this worked.
>_<

<[email protected]> wrote in message
news:719ac353-80cd-4778-878f-0a1b33178a77@p39g2000prm.googlegroups.com...
>>> 3. Run DHCP, DNS, WINS on the Domain Controller <<
>
> Remember that this is a workgroup, not a domain. But I can put DHCP,
> DNS, and WINS on the RRAS server.

That is going to be your biggest hinderance to anything you want to do.
Domain Controllers are "free" as long as you have the machine and OS to do
it.

>>> 4. Do not make the RRAS box the Domain Controller. <<
>
> Not applicable, but I'm curious to know why RRAS and DCs don't mix
> well.

RRAS boxes, almost by definition, are multi-homed. DCs should never be
multhomed (except SBS scenarios).

272294 - Active Directory Communication Fails on Multihomed Domain
Controllers
http://support.microsoft.com/default...b;en-us;272294

191611 - Symptoms of Multihomed Browsers
http://support.microsoft.com/default...b;EN-US;191611

> Does everyone seem to agree that the LinkSys is a strong suspect in
> this debacle or does something else smell fishy?

If you have a less-than optimal infrastructure and have "issues",...then the
issues may not be worth fighting with until you correct to a better
infrastructure (like getting rid of a workgroup in favor of a AD Domain).
Often when the infrastructure is improved the "issues" just simply "go
away". That is why many of my posts almost seem to ignore the original
question and go straight for what I consider to be the more important
"flaw",...and if the flaw is corrected, sometimes the orginal question
become irrelevant.

> Sounds relatively simple. As long as no-one objects to piling DHCP,
> DNS, WINS, and RRAS on the same box I say it's a go.

They all have a low foot print. Running DHCP, DNS, and WINS on the DC is a
very common practice. Do not use RRAS on the DC box. It does hurt if RRAS
is installed,..just don't use it for anything,...that is back to the
multihoming issue again.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

"Phillip Windell" <[email protected]> wrote in message
news:[email protected]...
> They all have a low foot print. Running DHCP, DNS, and WINS on the DC is
> a very common practice. Do not use RRAS on the DC box. It does hurt if
> RRAS is installed,..just don't use it for anything,...that is back to the
> multihoming issue again.

I meant to say "...it does *not* hurt..."

But you may want it to not be installed so you avoid the temptation to do
something with it.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

>> That is going to be your biggest hinderance to anything you want to do.
Domain Controllers are "free" as long as you have the machine and OS
to do
it. <<

Yeah. I figured as much. The place that I'm doing some work for is
rather small (8 employees) and on a very limited budget. They've been
convinced of the need for Active Directory and are going to budget for
it next year. I'd like to nab a new server with Server 2008 and
starting a domain with it (the granular password policies have won me
over =) ), but until then my plan was to hobble by on a workgroup. I
didn't like the idea of starting a domain now and then grafting in
Server 08 later. Maybe my wories are unfounded.


>> RRAS boxes, almost by definition, are multi-homed. DCs should never be
multhomed (except SBS scenarios). <<

Strangely, this RRAS box isn't multi-homed. Well, technically it is.
There's an onboard NIC and a PCI NIC, but the onboard NIC doesn't have
the drivers installed and for the life of me I can't track down the
model and make of either the MoBo or the onboard NIC. Argh.

And yes, I am intrigued by SBS 2008 and may get that for this place
next year.



>> If you have a less-than optimal infrastructure and have "issues",...then the
issues may not be worth fighting with until you correct to a better
infrastructure (like getting rid of a workgroup in favor of a AD
Domain).
Often when the infrastructure is improved the "issues" just simply
"go
away". That is why many of my posts almost seem to ignore the
original
question and go straight for what I consider to be the more important
"flaw",...and if the flaw is corrected, sometimes the orginal
question
become irrelevant. <<

>_<

Maybe I should consider promoting the lone Server 03 box to a DC now
and get it over with. I know this isn't quite the newsgroup to get
into this discussion, but it may be fruitful to ask what I'm about to
ask... (It isn't against the rules to hijack your own thread, is it?
=) )

What do you (and anyone else of course) think about setting up a
domain on a solitary 2003 DC for a while before adding a 2008 DC? I
had only hoped to start a new domain / forest / the-whole-9-yards at
2008 forest functional level and not worry about preparing a schema,
demoting one server, raising the funcional level and all that. Also,
I'm not too sure about the reliability of having just one DC. Hmmm...



> Sounds relatively simple. As long as no-one objects to piling DHCP,
> DNS, WINS, and RRAS on the same box I say it's a go.

If I can't promote the server to a DC easily (there's other issues at
play, including insufficient disk space, wonky partition sizes, and
the like) I'll put DNS, WINS, and DHCP on the workgroup server and see
what happens.


Thanks for the insight, Philip (and everyone else)! Keep the thoughts
comin' =)

<[email protected]> wrote in message
news:[email protected]...
> Strangely, this RRAS box isn't multi-homed. Well, technically it is.
> There's an onboard NIC and a PCI NIC, but the onboard NIC doesn't have
> the drivers installed and for the life of me I can't track down the
> model and make of either the MoBo or the onboard NIC. Argh.

As long as you are only using one nic,..that is all that matters.

> Maybe I should consider promoting the lone Server 03 box to a DC now
> and get it over with. I know this isn't quite the newsgroup to get
> into this discussion, but it may be fruitful to ask what I'm about to
> ask... (It isn't against the rules to hijack your own thread, is it?
> What do you (and anyone else of course) think about setting up a
> domain on a solitary 2003 DC for a while before adding a 2008 DC? I
> had only hoped to start a new domain / forest / the-whole-9-yards at
> 2008 forest functional level and not worry about preparing a schema,
> demoting one server, raising the funcional level and all that.

You could do it. It's up to you (or them?).

> Also, I'm not too sure about the reliability of having just one DC.
> Hmmm...

Well there are only 8 users. It isn't that big a deal to start over from
scratch. Besides, that's why on the 8th day God invented NTBackup with
System State. No tape drive?,...use a USB external HD and do a Backup to
File. (*.bkf) Store the USB-HD off site so it isn't lost if the building
burns down. If you really feel bold, keep two USB-HD and alternate between
them (just like keeping two tapes)

I setup a Doctor's office with only one DC. Their business critical
database is backed up off site over the Internet by an organization that
specializes in doing just that for medical facilities. There is also a
weekly copy of the database backed to file (*.bkf) up to a different
partition on the server locally. There is really nothing else to save on the
server worth worring about other than a few user accounts that can't just
"start over" if required. So, a few inconvieniences there if the server was
lost,..but in the end they would survive. The Server is single-homed, DNS,
WINS, DHCP. The Firewall is a "mid-level" Watchgaurd box that is capable of
acting as a VPN Server if they want to do that (instead of using RRAS).

> If I can't promote the server to a DC easily (there's other issues at
> play, including insufficient disk space, wonky partition sizes, and
> the like) I'll put DNS, WINS, and DHCP on the workgroup server and see
> what happens.

Needs to be a Domain Member for DNS and DHCP to not get messy,..WINS doesn't
matter so much. All three of those can be a hassle to "move" afterwards.
Wait and let them be "born" where they are going to "live". They hardly use
any disk space worth mentioning anyway.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

>> You could do it. It's up to you (or them?). <<

Me. Definitely me. I hope this doesn't sound arrogant, but I don't
tell my mechanic how to install a cam shaft and neither should non-IT
people dictate too closely how I implement the technology that makes
the business work. Its in my best interst to make them successful,
after all. =)


>> Well there are only 8 users. It isn't that big a deal to start over from
scratch. Besides, that's why on the 8th day God invented NTBackup
with
System State. No tape drive?,...use a USB external HD and do a Backup
to
File. (*.bkf) Store the USB-HD off site so it isn't lost if the
building
burns down. If you really feel bold, keep two USB-HD and alternate
between
them (just like keeping two tapes) <<

Actually, my concerns were more about the inner workings of Active
Directory. I have heard on occasion that there are some perils
associated with only having one DC since DCs by nature want to
replicate with a partner. Oh, and we already have two 500GB external
USB HDs that we rotate offsite weekly. Woot!

Although, I've heard that system state backup doesn't always restore
perfectly. Or it will restore, but strange and mysterious things will
crop up that are usually attributed to the SysState restore. Oh well.



>> Needs to be a Domain Member for DNS and DHCP to not get messy,..WINS doesn't
matter so much. All three of those can be a hassle to "move"
afterwards.
Wait and let them be "born" where they are going to "live". They
hardly use
any disk space worth mentioning anyway. <<

My concerns over disk space revolve around AD related stuff like
SYSVOL. The System partition was set up a bit too small and I don't
think AD can fit on it. Yes, HDs are cheap, but I'd have to
repartition it (no software too do that) or buy a pair of HDs and
transfer an image over (again, no software). Oh, did I mention that I
live 1,000 miles away from this place? =) Hooray for VPNs and RDP. I
still need to get them to buy a single unit KVM over IP switch... but
I digress.


Thanks for the insight, Phillip.

<[email protected]> wrote in message
news:[email protected]...
>>> You could do it. It's up to you (or them?). <<
>
> Me. Definitely me. I hope this doesn't sound arrogant, but I don't
> tell my mechanic how to install a cam shaft and neither should non-IT
> people dictate too closely how I implement the technology that makes
> the business work. Its in my best interst to make them successful,
> after all. =)

That is absolutely true in philosophy, but I only wish it was true in real
life. In my years at it the decisions usually come from the Executive
areas who don't know technology but do know "marketing",...so decisions are
based on marketing hype and misunderstandings. But then you get blamed if
it doesn't live up the the "hype"

> Thanks for the insight, Phillip.

No problem, good luck with it all!

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------