You have to do everything all at once. The is no "little
bit-one-step-at-a-time" thing.
Come in during off hours when no one is there. Bring friends with
comfortable shoes that like don't mind running around the whole building.
College interns may be useful for that.
Reconfigure the LAN Router. This includes the "networks", the "routing"
Change all the statically assigned devices first.
Then change all the scopes,...which may require deleting and creating
scopes.
Reboot all the units that use DHCP.
--
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.
-----------------------------------------------------
"Len B" <gonehome@optusnet:con:au> wrote in message
news:eLHMP%(E-Mail Removed)...
>I haven't yet expanded the PDC's LAN so I haven't changed anything on the
>PDC. I hadn't intended to until I get this one sorted.
>
> Am I understanding you correctly or are you meaning a different subnet
> mask?
> --
> Len
> __________________________________________________ ____
>
> "adamc135" <(E-Mail Removed)> wrote in message
> news:366C3B78-DAE4-4D56-AE3D-(E-Mail Removed)...
>> Did you update the PDC's subnet mask to .192?
>>
>> That's the only reason I can think of that would cause the server to
>> revert.
>>
>> "Len B" wrote:
>>
>>> I have a WAN of 2 LANs both with a 32 IP address space - one is 96-127,
>>> other 128-160
>>>
>>> I have been granted permission to increase the size of both to 64 IPs -
>>> 64-127 and 128-191
>>>
>>> So far I have made changes only to first LAN. I replaced the scope in
>>> its
>>> DHCP server. This seems to be working fine except that the server on the
>>> second LAN (the PDC for the WAN) gets its routing wrong and any traffic
>>> aimed at the new addresses (64-96) gets lost.
>>>
>>> The PDC Route table contains the entry
>>> 10.154.3.96 255.255.255.224 10.154.3.131 10.154.3.130
>>> which I changed to
>>> 10.154.3.64 255.255.255.192 10.154.3.131 10.154.3.130
>>> which fixes the issue but the change does not survive a reboot.
>>>
>>> I considered adding the change (64) as a persistent route but I figure
>>> doing
>>> that will just add an entry conflicting with the incorrect entry (96).
>>> At
>>> the moment I have a batch file that I run to correct the table.
>>>
>>> Because this happens, I figure that there must be more to do than just
>>> replacing the scope. So I am reluctant to change the scope on the PDC
>>> until
>>> I figure out the first one. Any ideas?
>>>
>>> TIA
>>> --
>>> Len
>>> __________________________________________________ ____
>>>
>>>
>>>
>
>