Brian
Mon Oct 15 21:09:02 PDT 2007
Just a note for anyone else going through those instructions. I had a
near-disaster with part of this, and I don't understand the reason, but here
is what happened.
Changing the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\PublishIPAddresses registry entry was fine.
I also set the DNS server to listen on only the single interface. (I could
have sworn it was already that way, but it was listening on All and thus had
all three listed: LAN, WAN, & RAS IP's.) This also was fine.
However, my near-disaster occured with the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RegisterDNSRecords
value of 0. It was very strange. As soon as I put that value in the registry
& restarted NetLogon service, the entire network lost its ability to run
DB2-based applications where the EXE was on the DC (the server in question)
but the data was on our DB2 server. I could still log onto the DB2 server,
but even locally on the DB2 server, I could not run the DB2 applications or
even connect to the DB2 databases using the DB2 command-line!
Somehow, it had a severe and immediate effect on DB2 authentication (which
is AD-integrated). As soon as I changed the value to 1 or removed it (I have
tested both ways), the problem ended.
Of course, this was not immediately evident, because the problem did not
occur immediately, but when users needed to log onto the DB2 app or open a
new EXE. This was perhaps half an hour after the other change, and it took me
another hour to correlate the two, because I was working on a plethora of
issues that day.
Anyway, any ideas why that second registry entry would affect
Windows-integrated authentication on my DB2 server? I'm just happy that (I
think) I now have a permanent solution with the other two changes I made, but
that was a little scary for a while. I thought I had a corrupted
mission-critical DB2 DB!
"SuperGumby [SBS MVP]" wrote:
> implement the registry changes and other mods from KB292822 , the update
> files should already be installed (assuming the server is at current patch
> levels).
>
> Name resolution and connectivity issues on a Routing and Remote Access
> Server that also runs DNS or WINS
>
http://support.microsoft.com/kb/292822
>
> "Brian" <Brian@discussions.microsoft.com> wrote in message
> news:309C7D2D-5ECB-490E-B9E1-B69EFFA9BBF2@microsoft.com...
> >I have a Win2K SBS at host site. It is also my DNS server for all
> >workstations.
> >
> > I have two remote sites (4 PC's at each site) that connect via hardware
> > VPN.
> > All remote PC's have server's IP address as their only DNS server.
> >
> > When I ping the server by its name in DNS from one of the remote
> > workstations, I should get 10.1.1.1, but sometimes I get 10.1.1.33 (I
> > think
> > it is from the RRAS ip range) or the server's public IP address (it has
> > two
> > NICs).
> >
> > I do ipconfig /flushdns, and it may come back with any of the three
> > possibilities above. The same is true for nslookup. If it comes back with
> > the
> > public one, the Exchange client will fail.
> >
> > This may be Exchange-related (i.e. how to get the client to work when the
> > DNS name resolves to the server's public IP address) or it may be
> > DNS-related
> > (how to get my server to quit handing out its IP address to DNS clients
> > except its primary LAN IP address.
>
>
>