|
Yeah I "chatted" with the EHLO blog guys over the whole
MONAD thing in their comments. From what it sounded like, they still forget that
people run more than one Exchange Server on a single Gbit subnet so assume
unlimited bandwidth between the management stations and the Exchange Servers.
The SBS people should be thrilled to death. Folks doing work with very large
orgs or over very slow lines may not be as thrilled with the architecture they
described. Though probably most won't understand the issues because they expect
Exchange to be slow. That expectation is actually useful in customer sites...
Things can run incorrectly for a long time and people just expect that that is
the way Exchange is supposed to run. They don't complain until it out and out
breaks.
WMI
is deprecated in E12. EMS (the Exchange Management Shell, today’s “official”
name for the Exchange version of PowerShell/Monad) gives one access to lots and
lots of information. So does the next version of <mumble>. Further this
deponent sayeth not, not being exactly clear which version of my NDAs apply
(having signed 4, so far, around E12).
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Al Mulnick
Sent: Wednesday, May 31, 2006 10:07
AM
To: [email protected]
Subject: Re: [ActiveDir]
How To Determine What GC a Server is Using?
That's golden joe. You certainly gave a very detailed
taste of what it looks like in a real-world environment. Couple of thoughts
might also be warranted here:
1) If you're not monitoring GC performance and you're running
Exchange, think again.
2) Size doesn't matter; what I mean by that is that the size
of your organization is not as important as the volume of messages and the size
of the GAL - it's all how you use it (-;
3) memory - always a good thing to have
4) you may notice that there's an excellent troubleshooting
guide for Exchange performance that talks about GC interaction and some things
to look for. Best to have a look in addition to this.
5) 64 bit + memory can be a nice thing
6) joe wrote a script and admitted it? AND used it? I'm
floored. :)
Exchange 12 fixes what? Are you repeating that something's
fixed in the next version of an office server? Hmm... Maybe I'm just
getting old and jaded, but I feel like I've heard a vendor say, "oh, that's
fixed in the next version" a few times before. I'm still waiting
patiently for the ability to change the overquota message. And no, the kb
that describes how to do this is not acceptable in case you're wondering.
I shouldn't have to write code or write a service to make this type of
functionality work. It's a message in the DLL for crying out loud.
Read it from somewhere else and let it be changeable (it's been asked for
by companies since before Exchange 4.0 even released; it was promised as a fix
for just about every version of Exchange release since and never REALLY made
it. Instead there's a variation on changing the mdbsz.dll called writing a
service. Hmm... I'll wait to see what makes it into the final product when
it comes to fixes [1] </rant>) http://msexchangeteam.com/archive/2004/04/20/117024.aspx is
the reference to it at the moment. I'm sure there's updates somewhere on
the net.
[1] Bonus question: anyone know what the difference
between beta, RC and GA code is?
On 5/30/06, joe <[EMAIL PROTECTED]> wrote:
Unfortunately this is something I have had more than desired
experience in.
The "official" way to get the current GCs/DCs being used
by Exchange is the
ESM Directory Access Tab for a given Exchange Server.
This leverages the
Exchange_DSAccessDC WMI provider. Unfortunately this
mechanism has a rather
nasty bug in it that I found and have been "debating"
with MSFT with since
last summer[1]. Basically you can't trust the
information you are being told
unless you have just stopped and restarted the
Exchange Management Service
(MSExchangeMGMT). As I believe I mentioned before
I heard two main things
1. WMI was never intended to be used for
monitoring Windows machines and
services.
2. This is all fixed in Exchange
12.
I am not sure, but I don't think everyone in MSFT feels that #1 is
accurate
though that is the response that came from the Exchange Dev and
Exchange PSS
folks.
So the other mechanism that is available is
to crank you your DSACCESS
events and scrape out the associated events from
the log. However, this
won't tell you what is being used, simply what has
been detected and is
valid for use.
So that leaves as the only true
mechanism either using netstat or network
sniffing to work out what GCs are
currently in use.
My recommendation to folks who are having issues with
Exchange reporting GCs
as failing is to set up a script that calls out to
the GCs in a site on a
regular basis and queries them and checks the response
time. Response times
should be low, preferably subsecond but depending on the
quality of the
script, may not be able to see anything below a couple of
seconds due to
script interpretation or firing up the connection etc.
However, if you are
seeing 4 servers reporting a 2 second delay and one
reporting 7 second
delays... There you go, that is a good candidate to check
out. I have
successfully used that to track down several issues with
GCs.
If you just want to get into the real troubleshooting, the first
thing I
look at when I hear that Exchange GCs are supposedly causing problems
is to
look at the disk counters, primarily I look at at the disk queues for
the
DIT file and the read operations. Exchange tends to really push AD to the
limit for disk read access and a GC that normally looks fine and
actually
works fine for 99% of the apps could crumple under Exchange load.
Keep in
mind that you will not normally catch a problem in a GC by using LDP
or ADUC
to see how long it takes to pull up an object. Exchange is sending
tens of
thousands or millions of queries per day and the slightest delay
could have
severe impact on Exchange even if you don't see anything when
using ADUC or
LDP or in fact, anything else. So back to disk subsystem, the
commonly
accepted way to build DCs/GCs is to use 3 RAID-1 arrays which is
what is in
the deployment guide. I can't begin to state how much I dislike
that design.
I have seen it cause more issues than help but then I work on
larger orgs. I
am far more apt to push a RAID-0 or RAID-0+1/10 or even RAID-5
than RAID-1
to get the spindles so the IOPS (mostly read ops) can be handled.
joe
[1] Actually it is less debate and more
MSFT PSS folks avoiding me.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Steve Linehan
Sent: Friday, May 26, 2006 11:15 AM
To: [email protected]; [email protected]
Subject:
RE: [ActiveDir] How To Determine What GC a Server is Using?
Actually the
article should probably be updated to use the built-in tasklist
tool since
it is targeted as Windows Server 2003. The only nice thing
about
the event log is that it gives you a historic record and if he is
loosing
connections to the GCs it will mark them as bad so if he can not get
to the
machine quick enough to get the netstat output he would have a
historic
record that the list of viable GCs changed. If this
corresponds to his
outage it would give him a good idea of which GC it
was. That being said
yes I wish that regtrace was documented more
but I like Joe am a directory
guy and only dabble in Exchange when someone
points the finger at the
directory. I will pass the comments on to
the Exchange support and dev
teams but I do believe part of this is being
addressed in the next version
of the product. I know I know the
dreaded next version cop out.
:-)
Thanks,
-Steve
________________________________
From:
[EMAIL PROTECTED]
on behalf of Al Mulnick
Sent: Fri 5/26/2006 8:12 AM
To: [email protected]
Subject: Re: [ActiveDir] How To Determine What GC a Server is
Using?
I might point out that in that KB there should be a link to
tlist for
download. You know, just to make sure it's on the machine in
question.
I suspect there's also not a lot of reason to read the event log
first when
netstat -ao would be able to tell you which servers (2003
expected) the
Exchange server is talking to on GC ports. Piping it to
something like FIND
or GREP would further reduce the information
domain.
Contact PSS for interpretation? Can't there be a DCR to make that
better and
the user more self-sufficient? :)
BGINFO is not something
to rely on for Exchange troubleshooting. I know it
was assumed in
the post, but BGINFO while a great and useful tool, is going
to talk about
the session information which may or may not be the same as
what Exchange is
using. It would be coincidence if it was the same. Mostly.
-ajm
On 5/25/06, Steve Linehan <[EMAIL PROTECTED]>
wrote:
>
>
>
>
>
> The following method will
show you what GCs Exchange has discovered and
believes are viable servers:
http://support.microsoft.com/kb/316300/en-us
.
While this will not tell you the exact GC Exchange is using, it could
be
using multiple GCs, it will help you narrow down the list. You
could then
use a network capture or look at netstat -ao, assuming Windows
2003, which
will list the current connections and the process ID that owns
them. If
this still does not help you track it down you can
enable Regtrace and have
PSS help interpret the
output.
>
>
>
> Thanks,
>
>
>
>
-Steve
>
>
>
>
>
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Stu Packett
> Sent: Thursday, May 25, 2006 10:09
PM
>
> To: [email protected]
>
Subject: RE: [ActiveDir] How To Determine What GC a Server is
Using?
>
>
>
>
> To: [email protected]
> Subject: RE: [ActiveDir] How To Determine What GC a Server is
Using?
>
>
>
>
>
>
>
> I got
'mad.exe' results, but not those specific port numbers. Would
the
port number be different for all servers?
>
>
>
________________________________
>
> From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
] On Behalf Of Tony Murray
> Sent: Thursday, May 25, 2006 7:25 PM
>
To: [email protected]
>
Subject: RE: [ActiveDir] How To Determine What GC a Server is Using?
>
> How about "netstat -b" ? Look for mad.exe connecting to port
3268 (or
3269 for SSL).
>
>
>
>
Tony
>
>
>
>
________________________________
>
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Stu Packett
> Sent: Friday, 26 May 2006 1:13 p.m.
>
To: [email protected]
>
Subject: RE: [ActiveDir] How To Determine What GC a Server is
Using?
>
>
>
> Isn't the 'Login Server' the same as the
Domain Controller? If I do a
'set.exe' from a command prompt, I
get the same info as "LOGONSERVER". What
I need specifically, is
the Global Catalog server (unless I'm going about
this
incorrectly).
>
>
>
________________________________
>
> From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
] On Behalf Of Blair, James
> Sent: Thursday, May 25, 2006 5:51 PM
>
To: [email protected]
>
Subject: RE: [ActiveDir] How To Determine What GC a Server is
Using?
>
> Stu,
>
>
>
> Download and
configure BGINFO and check to "Login Server" attribute...
>
>
>
> http://www.sysinternals.com/Utilities/BgInfo.html
>
>
James Blair
>
>
>
>
>
>
________________________________
>
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Stu Packett
> Sent: Friday, 26 May 2006 10:34 AM
> To:
[email protected]
>
Subject: [ActiveDir] How To Determine What GC a Server is Using?
>
>
We have a strange situation here where one of our Exchange servers keeps
getting 8026 and 2102 errors. This causes our users on that
Exchange server
to temporarily lose connection to the Exchange
server. Also, my Unity
server just failed over to the secondary
Unity server at exactly the same
time my last Exchange 8026 error
happened. This leads me to believe I may
have a problem with a
global catalog server. Is there a way to determine
what GC each
server is using?
>
> Thanks in advance. This communication,
including any attachments, is
confidential. If you are not the intended
recipient, you should not read it
- please contact me immediately, destroy
it, and do not copy or use any part
of this communication or disclose
anything about it. Thank you. Please note
that this communication does not
designate an information system for the
purposes of the Electronic
Transactions Act 2002.
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List
archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List
FAQ : http://www.activedir.org/ListFAQ.aspx
List
archive: http://www.activedir.org/ml/threads.aspx
|
