address space change ==> problems logging on !!
I have installed a new Smoothwall firewall with a new DHCP server to use the class B address space (we were using the C class but it has become really small).
I have run the new firewall and stopped the old one and I have changed the fixed IP address of all the servers to move to the new address space, but now I have a big problem with the workstations with DHCP address. They take a reeeeeaaally long time to log on users and, moreover, the permissions from the windows 2000 server that were applied succesfuly before the address space change don't apply at all after the change.
Even applying fixed IPs to workstations makes them to take long time to boot.
I need help please !.
I have run the new firewall and stopped the old one and I have changed the fixed IP address of all the servers to move to the new address space, but now I have a big problem with the workstations with DHCP address. They take a reeeeeaaally long time to log on users and, moreover, the permissions from the windows 2000 server that were applied succesfuly before the address space change don't apply at all after the change.
Even applying fixed IPs to workstations makes them to take long time to boot.
I need help please !.
Is there an IPSEC policy that is trying to negotiate and failing?
Check your DNS. Slow login can be caused by a DNS namespace problem and, since you changed your IPs, it's the first place I would look.
Good Luck :-)
Good Luck :-)
Pay close attention to the SRV records and any records that point to your Domain contollers.
Oh... one other thing I should point out....Check that your workstations are still using the correct DNS IP.
Is this static or DHCP assigned?? So you might have to change the settings in one or the other places if you haven't already.
Is this static or DHCP assigned?? So you might have to change the settings in one or the other places if you haven't already.
Another thing you may want to check is the firewall settings for the internal network. You should be allowing both TCP and UDP on port 135, 137-139, and 445 as well as other possibly. Turn the firewall off for the internal network and see if this issue is still occuring.
A request to close this question has been made. However, I will not honor this request without knowing why the request is being made, what closure mechanism (accept an answer, delete with refund, PAQ with refund, etc) is desired. I am not likely to grant a refund on this question unless a solution is posted by the questioner.
Experts, please give me your feedback as well on how this question should be finalized.
Thanks.
SpideyMod
Community Support Moderator @Experts Exchange
Experts, please give me your feedback as well on how this question should be finalized.
Thanks.
SpideyMod
Community Support Moderator @Experts Exchange
I like the idea of not giving a refund unless the poster gives up the solution that worked.
I'm not big on the points system, still that's how it's done here. So folks should either award the points their offering or post up the answer that worked for them in order to get a refund.
So many do neither.
I'm not big on the points system, still that's how it's done here. So folks should either award the points their offering or post up the answer that worked for them in order to get a refund.
So many do neither.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.