refresh ad

  • Thread starter Thread starter jas0n
  • Start date Start date
J

jas0n

is it possible to get a DC to completely refresh its active directory
information via a command? this DC is also global catalogue for this
site.

ive had a few issues with it after a failed hard drive out of the raid
array (it seemed to rebuild ok) ... ive just a lingering doubt! that if
possible id like it to do a complete refresh of ad and global catalogue
info

or is it a matter of dcpromo it down and back again?
 
circa Mon, 6 Dec 2004 00:31:15 -0000, in
microsoft.public.win2000.active_directory, jas0n ([email protected])
said,
is it possible to get a DC to completely refresh its active directory
information via a command? this DC is also global catalogue for this
site.

ive had a few issues with it after a failed hard drive out of the raid
array (it seemed to rebuild ok) ... ive just a lingering doubt!

Is there a reason for the doubt, or is it just a kind of
superstition. If the latter, then I'd say just learn to live with it.
;-)
that if
possible id like it to do a complete refresh of ad and global catalogue
info

If by "complete refresh" you mean "rebuild", then see below...
or is it a matter of dcpromo it down and back again?
Yup.
Laura
 
circa Mon, 6 Dec 2004 00:31:15 -0000, in
microsoft.public.win2000.active_directory, jas0n ([email protected])
said,

Is there a reason for the doubt, or is it just a kind of
superstition. If the latter, then I'd say just learn to live with it.
;-)

you asked! ..... see below
Yup.
Laura
;) .... ive just got a really odd situation, mainly with regards to the
vpn tunnel from this site to the main head office where the intranet
home page/internet proxy/exchange servers live.

here's a copy of a post to another group just to give you an idea of the
'strangeness':-

a long one ....

ive a site having odd network behavoir relating to its vpn connection to
head office. its an adsl vpn using a cisco series 800 router.

internet, intranet & email access is via the vpn link to head office.

initially it was fairly intermittant, had clients complaining of outlook
synchronising failing due to network problems (they work offline and
synch with server across the vpn)

also, IE6 wasnt always able to get to its home page which is an intranet
server. internet access via the proxy is also intermittant.

then it pretty much seemed to be all systems on this site, including the
server now have this problem.

heres what ive done so far:-

replaced adsl filter
replaced cables
replaced adsl router
had config for this site removed, redone, confirmed on the main head
office pix
had config scrutinized.confirmed/redone on the adsl router
confirmed line tests with isp are coming back good.
virusscans with uptodate mcafee enterprise 8.0i dats 1dec, none found
spyware, crapware detection on all systems on site, none found
confirmed windows updates for all critical uptodate and all recommended
relevant to the systems.
replaced network switches (was a planned upgrade anyway)
replaced network cables in the rack to get correct length (many were way
too long!)
replaced server network card and network cable.
hosts files on all machines are default with just the 127.0.0.1
localhost entry


the site laptops have cisco vpn software to dial in from home or through
network broadband .... if you use the network broadband option and
establish a vpn with head office everything is ok and internet, intranet
and email flows.

so .... again thinking this is still an issue with head office pix/vpn
concentrator have been through the mill with the guys contracted to look
after it yet they are adamment it is not anything to do with that side
.... they also have been logging stuff on the adsl cisco box and come up
blank there.

even when having these issues we can always ping, trace to the head
office side so the vpn is up ... its as though something is blocking web
and mail traffic somewhere but not pings, etc.

anyway, i then installed the cisco vpn software onto desktop machines to
start getting them some access to head office for these services

the weird part .....

once installed, these systems can then access the problem services - we
dont even use the software to connect via vpn, we just install it but
dont run it .... .what gives, what is being replaced that is allowing
access ??????????

_______

since that post one of the hard drives failed in the raid array for the
single DC/global catalogue onsite ..... its replaced and up and running
fine.

also, when I replaced the network card in the server it went back to
having problems connecting over the vpn for intranet and internet access
- yet a re-install of the cisco client software again brought that back
to a working state .... its almost as though some sort of binding or tcp
stack has failed and that the cisco software puts this right.

if i were a gambling man id have bet my socks on it being virus /
malware related but having been through the site thoroughly with
virus/malware/windows updates and coming up clean anyway it was really
annoying!
 
The best way to accomplish this is to remove the GC attribute, reboot. Then
DCPROMO down the DC. Clean up the sites and services server object. Then
DCPROMO the server back into the domain. Some people recommend using a
different name, I say go ahead and use the same name.

Todd Myrick
 
To avoid fragmentation Cisco VPN Client will reduce the MTU to 1300 on all
adapters. I hope this is the key to your problem.

Andrei Ungureanu
www.eventid.net

it could well be ... one of the first things the folk who look after the
cisco adsl router did was to alter the mtu on it to improve performance
from an adsl line so i was told .... this was before swapping the router
for another known working one.

we have lots of sites they look after all going through the same vpn
concentrator/pix setup and the other sites were not experiencing this
issue ....

i say were not .... i have been informed that 2 other sites are
exhibiting similar issues so for an interim measure i told them to
install the cisco client vpn software until we can identify it - i'll
have to check it solved their issues tomorrow.

so, i guess its a call into the adsl provider in the morning and get
their take on mtu settings for their network considering the adsl which
is theirs terminates on a large leased line pipe which is also theirs
....

should they be the people to dictate the correct mtu or is it a matter
between adsl router and receiving vpn concentrator?
 
In
jas0n said:
it could well be ... one of the first things the folk who look after
the cisco adsl router did was to alter the mtu on it to improve
performance from an adsl line so i was told .... this was before
swapping the router for another known working one.

we have lots of sites they look after all going through the same vpn
concentrator/pix setup and the other sites were not experiencing this
issue ....

i say were not .... i have been informed that 2 other sites are
exhibiting similar issues so for an interim measure i told them to
install the cisco client vpn software until we can identify it - i'll
have to check it solved their issues tomorrow.

so, i guess its a call into the adsl provider in the morning and get
their take on mtu settings for their network considering the adsl
which is theirs terminates on a large leased line pipe which is also
theirs ...

should they be the people to dictate the correct mtu or is it a matter
between adsl router and receiving vpn concentrator?

ADSL is a known issue with reduced MTUs. PPPoE requires an 8 byte header
that reduces the MTU to 1492 from the default TCPIP packet size of 1500. It
can't be changed in the ADSL modem/router. For a corporate infrastructure I
would suggest to look into SDSL, a lease line, or even cable, which do not
require this overhead.

To test your current MTU settings, see this link:
MTU - How to test and how to set in registry:
http://gw.renner.bei.t-online.de/windowsxp/mtu.htm

Some info on ADSL PPPoE and MTUs:

Optimal MTU configuration for PPPoE ASDL Connections:
http://www.mynetwatchman.com/kb/ADSL/pppoemtu.htm

Troubleshooting MTU Size in PPPoE Dialin Connectivity-ADSL - Cisco ...:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a0080093bc7.shtml


--
Regards,
Ace

G O E A G L E S !!!
Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
In

ADSL is a known issue with reduced MTUs. PPPoE requires an 8 byte header
that reduces the MTU to 1492 from the default TCPIP packet size of 1500. It
can't be changed in the ADSL modem/router. For a corporate infrastructure I
would suggest to look into SDSL, a lease line, or even cable, which do not
require this overhead.

To test your current MTU settings, see this link:
MTU - How to test and how to set in registry:
http://gw.renner.bei.t-online.de/windowsxp/mtu.htm

Some info on ADSL PPPoE and MTUs:

Optimal MTU configuration for PPPoE ASDL Connections:
http://www.mynetwatchman.com/kb/ADSL/pppoemtu.htm

Troubleshooting MTU Size in PPPoE Dialin Connectivity-ADSL - Cisco ...:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a0080093bc7.shtml

thanks for the links .... that cisco link seems to describe the
situation im getting with the web traffic ... i'll be getting this
looked at in some detail later today.

cheers all.
 
In
jas0n said:
thanks for the links .... that cisco link seems to describe the
situation im getting with the web traffic ... i'll be getting this
looked at in some detail later today.

cheers all.

Let us know how you make out.

Ace
 
In

Let us know how you make out.

Ace

our cisco support thinks the isp has implemented some sort of security
on its network thats affecting icmp or mtu discovery ..... maybe ....
they're not really sure yet.

both sides are going to attempt to find out, should have been today but
looks like it'll be tomorrow now.
 
In
jas0n said:
our cisco support thinks the isp has implemented some sort of security
on its network thats affecting icmp or mtu discovery ..... maybe ....
they're not really sure yet.

both sides are going to attempt to find out, should have been today
but looks like it'll be tomorrow now.

Interesting, didn't know that would affect a Cisco router/PIX. And you
confirmed the config is identical to the other routers?

Ace
 
In

Interesting, didn't know that would affect a Cisco router/PIX. And you
confirmed the config is identical to the other routers?

Ace

its all over my head as far as this is going now .... they were swapping
out the pix last I heard this afternoon and were then going to try same
config / different pix and then a roll back to previous versions to try
and nail the problem .... then onto different versions of ios, etc ...

the isp is insisting their network is not the cause - pings to external
ip of router tends to be fine with no packet loss and fairly quick
responses, yet internal pings via the vpn tunnel end up with much higher
response times and varying degree's of packet loss - the site router and
cables, etc have all been replaced so hopefully it will be the pix and
we can all get back to a nice stable network!
 
In
jas0n said:
its all over my head as far as this is going now .... they were
swapping out the pix last I heard this afternoon and were then going
to try same config / different pix and then a roll back to previous
versions to try and nail the problem .... then onto different
versions of ios, etc ...

the isp is insisting their network is not the cause - pings to
external ip of router tends to be fine with no packet loss and fairly
quick responses, yet internal pings via the vpn tunnel end up with
much higher response times and varying degree's of packet loss - the
site router and cables, etc have all been replaced so hopefully it
will be the pix and we can all get back to a nice stable network!

Interesting, Let me know how they make out.

Ace
 
the isp is insisting their network is not the cause - pings to
Interesting, Let me know how they make out.

Ace

will do ... they are still working on it ....

i did notice in my own travels the main dc which is also the server all
wins servers replicate wins with has wins disabled for some reason ...

.... now i dont know all that much about wins but my guess is that a
network configured with wins servers / (dhcp hands out the local wins
server address too) .... all replicting with the main one wont take too
kindly to it being disabled ...

either way it didnt look right to me so have asked the question as to
why and am awaiting response
 
In jas0n <[email protected]> made a post then I commented below
:: will do ... they are still working on it ....
::
:: i did notice in my own travels the main dc which is also the server
:: all wins servers replicate wins with has wins disabled for some
:: reason ...
::
:: ... now i dont know all that much about wins but my guess is that a
:: network configured with wins servers / (dhcp hands out the local wins
:: server address too) .... all replicting with the main one wont take
:: too kindly to it being disabled ...
::
:: either way it didnt look right to me so have asked the question as to
:: why and am awaiting response

Where is WINS disabled?

As long as WINS is specified in IP properties, or thru DHCP Options (044 for
the WINS server, and 046 for Node type of 0x8), then all will use it. If
WINS is in multiple locations, all machines in that location should use the
local WINS server. Setup partnerships between the WINS server by choosing
the central location as the WINS partnership "hub" and have it partnered up
with the other WINS server.

But then again, if MTUs are a factor, communication maybe hindered.

Ace
 
Back
Top