RE: [ActiveDir] Raid 1 tangent -- Vendor Domain
That's a command line guy for you... :o) The thing is that I type in a very odd way two, my whole right hand just one or two fingers from my left hand. People tend to get a bit confused when they see me type. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Gent Sent: Saturday, July 22, 2006 7:29 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Raid 1 tangent -- Vendor Domain joe, you must type really, really fast - Original Message - From: "Albert Duro" <[EMAIL PROTECTED]> To: Sent: Saturday, July 22, 2006 7:06 PM Subject: Re: [ActiveDir] Raid 1 tangent -- Vendor Domain > no debate from me. I was just asking. Thank you for the lesson. > > - Original Message - > From: "joe" <[EMAIL PROTECTED]> > To: > Sent: Saturday, July 22, 2006 9:48 AM > Subject: RE: [ActiveDir] Raid 1 tangent -- Vendor Domain > > >> Mirrors don't scale. >> >> Microsoft's deployment doc mostly just talks about using mirrors (small >> nod >> to RAID 10/0+1) so everyone thinks that they should build their Corporate >> DCs on mirrors, usually 3 - OS, Logs, and DIT. Very few people if anyone >> would build a corporate Exchange Server on mirrors... Why not? The DB is >> the >> same under both of them... What is critical to Exchange? IOPS and that >> means >> spindles. If something is really beating on AD and the entire DIT can't >> be >> cached, IOPS are critical to AD as well. The main difference is that AD >> is >> mostly random read and Exchange is heavy writing and reading. The >> exception >> to this is the edge case of Eric's big DIT[1] in which he dumped 2TB of >> data >> into AD in a month at which point he did something that few people see, >> pushed the IOPS on the log drive through the roof. >> >> In a smaller environment (very low thousands), or for a low use DC (small >> WAN site), or a DC with a DIT fully cached a RAID-1 drive for DIT will >> probably be sufficient, you will note that the only numbers mentioned in >> the >> deployment guide are about 5000[2]... That usually means a small DIT and >> it >> is extremely likely that a K3 DC will cache the entire DIT. Plus the >> usage >> is probably such that the IO capability of two spindles will likely be >> ok. >> Let me state though that even in a small user environment if there was an >> intensive directory based app or a buttload of data that pushes the DIT >> into >> GB's instead of MBs I would still be watching my disk queueing pretty >> close >> as well as the Read and Write Ops. >> >> AD admins who aren't running directory intensive apps (read as Exchange >> 2000+) usually don't see any issues but then again most aren't looking >> very >> closely at the counters because they haven't had a reason too and even if >> they had some short lived issues they probably wouldn't go look at the >> counters. At least that has been my experience in dealing with companies. >> I >> will admit that prior to implementing Exchange when I did AD Ops with a >> rather large company I didn't once look at the disk counters, didn't >> care, >> everything ran perfectly well and about the only measure of perf was >> replication latency and does ADUC start fast enough and it always was >> fine >> there unless there were network related issues or a DC was having >> hardware >> failure. >> >> Enter Exchange... Or some other app that pounds your DCs with millions of >> queries a day and tiny little bits of latency that you didn't previously >> feel start having an impact. You won't feel 70-80ms of latency in >> anything >> you are doing with normal AD tools or NOS ops, not at all. You will feel >> that with Exchange (and other heavy directory use apps), often with >> painful >> results unless it isn't consistent and the directory can unwind itself >> again >> and hence allow Exchange to then unwind itself. >> >> Now let me point out, I don't deal with tiny companies for work, small to >> me >> is less than 40-50k. The smallest I tend to deal with is about 30k. I >> usually get called to walk in to Exchange issues where Exchange is >> underperforming or outright hanging, sometimes for hours at a time. There >> can be all sorts of issues causing this such as >> >> O poor disk subsystem design for Exchange (someone say got fancy with a >> SAN >> layout and really didn't know what they were doing seems to be popular >> here) >> >> >> O hardware/drivers on the Exchange server just aren't working properly >> and >> the drivers are experiencing timeout issues (for some reason I want to >> say >> HBA here) >> >> O poor network configurations and odd load balancing solutions, etc that >> generate a whole bunch of say keep alive traffic on the segment that no >> one >> had any idea about because no one understood the solution nor took time >> to >> look at the network traces. Or maybe >> the
Re: [ActiveDir] Raid 1 tangent -- Vendor Domain
joe, you must type really, really fast - Original Message - From: "Albert Duro" <[EMAIL PROTECTED]> To: Sent: Saturday, July 22, 2006 7:06 PM Subject: Re: [ActiveDir] Raid 1 tangent -- Vendor Domain no debate from me. I was just asking. Thank you for the lesson. - Original Message - From: "joe" <[EMAIL PROTECTED]> To: Sent: Saturday, July 22, 2006 9:48 AM Subject: RE: [ActiveDir] Raid 1 tangent -- Vendor Domain Mirrors don't scale. Microsoft's deployment doc mostly just talks about using mirrors (small nod to RAID 10/0+1) so everyone thinks that they should build their Corporate DCs on mirrors, usually 3 - OS, Logs, and DIT. Very few people if anyone would build a corporate Exchange Server on mirrors... Why not? The DB is the same under both of them... What is critical to Exchange? IOPS and that means spindles. If something is really beating on AD and the entire DIT can't be cached, IOPS are critical to AD as well. The main difference is that AD is mostly random read and Exchange is heavy writing and reading. The exception to this is the edge case of Eric's big DIT[1] in which he dumped 2TB of data into AD in a month at which point he did something that few people see, pushed the IOPS on the log drive through the roof. In a smaller environment (very low thousands), or for a low use DC (small WAN site), or a DC with a DIT fully cached a RAID-1 drive for DIT will probably be sufficient, you will note that the only numbers mentioned in the deployment guide are about 5000[2]... That usually means a small DIT and it is extremely likely that a K3 DC will cache the entire DIT. Plus the usage is probably such that the IO capability of two spindles will likely be ok. Let me state though that even in a small user environment if there was an intensive directory based app or a buttload of data that pushes the DIT into GB's instead of MBs I would still be watching my disk queueing pretty close as well as the Read and Write Ops. AD admins who aren't running directory intensive apps (read as Exchange 2000+) usually don't see any issues but then again most aren't looking very closely at the counters because they haven't had a reason too and even if they had some short lived issues they probably wouldn't go look at the counters. At least that has been my experience in dealing with companies. I will admit that prior to implementing Exchange when I did AD Ops with a rather large company I didn't once look at the disk counters, didn't care, everything ran perfectly well and about the only measure of perf was replication latency and does ADUC start fast enough and it always was fine there unless there were network related issues or a DC was having hardware failure. Enter Exchange... Or some other app that pounds your DCs with millions of queries a day and tiny little bits of latency that you didn't previously feel start having an impact. You won't feel 70-80ms of latency in anything you are doing with normal AD tools or NOS ops, not at all. You will feel that with Exchange (and other heavy directory use apps), often with painful results unless it isn't consistent and the directory can unwind itself again and hence allow Exchange to then unwind itself. Now let me point out, I don't deal with tiny companies for work, small to me is less than 40-50k. The smallest I tend to deal with is about 30k. I usually get called to walk in to Exchange issues where Exchange is underperforming or outright hanging, sometimes for hours at a time. There can be all sorts of issues causing this such as O poor disk subsystem design for Exchange (someone say got fancy with a SAN layout and really didn't know what they were doing seems to be popular here) O hardware/drivers on the Exchange server just aren't working properly and the drivers are experiencing timeout issues (for some reason I want to say HBA here) O poor network configurations and odd load balancing solutions, etc that generate a whole bunch of say keep alive traffic on the segment that no one had any idea about because no one understood the solution nor took time to look at the network traces. Or maybe the infamous Full/100 on one end and half/100 on the other. Whatever. O Applications that beat the crap out of Exchange that weren't accounted for in the design well or at all... such as Blackberry or Desktop Search or various Archive solutions O Poorly written event sinks, disclaimer type products that query AD themselves for additional info fit nicely into this category (hint do not deploy one of these unless you understand the queries it generates) O DCs being too far away say like an Exchange server in the US hosting APAC users. If you are running Exchange, you put Exchange and the DCs for the domains of any users on that Exchange server on the same physical subnet. And if you have a multidomain forest, strongly consider shortcut trusts between the domains that the Exchange servers
Re: [ActiveDir] Raid 1 tangent -- Vendor Domain
no debate from me. I was just asking. Thank you for the lesson. - Original Message - From: "joe" <[EMAIL PROTECTED]> To: Sent: Saturday, July 22, 2006 9:48 AM Subject: RE: [ActiveDir] Raid 1 tangent -- Vendor Domain Mirrors don't scale. Microsoft's deployment doc mostly just talks about using mirrors (small nod to RAID 10/0+1) so everyone thinks that they should build their Corporate DCs on mirrors, usually 3 - OS, Logs, and DIT. Very few people if anyone would build a corporate Exchange Server on mirrors... Why not? The DB is the same under both of them... What is critical to Exchange? IOPS and that means spindles. If something is really beating on AD and the entire DIT can't be cached, IOPS are critical to AD as well. The main difference is that AD is mostly random read and Exchange is heavy writing and reading. The exception to this is the edge case of Eric's big DIT[1] in which he dumped 2TB of data into AD in a month at which point he did something that few people see, pushed the IOPS on the log drive through the roof. In a smaller environment (very low thousands), or for a low use DC (small WAN site), or a DC with a DIT fully cached a RAID-1 drive for DIT will probably be sufficient, you will note that the only numbers mentioned in the deployment guide are about 5000[2]... That usually means a small DIT and it is extremely likely that a K3 DC will cache the entire DIT. Plus the usage is probably such that the IO capability of two spindles will likely be ok. Let me state though that even in a small user environment if there was an intensive directory based app or a buttload of data that pushes the DIT into GB's instead of MBs I would still be watching my disk queueing pretty close as well as the Read and Write Ops. AD admins who aren't running directory intensive apps (read as Exchange 2000+) usually don't see any issues but then again most aren't looking very closely at the counters because they haven't had a reason too and even if they had some short lived issues they probably wouldn't go look at the counters. At least that has been my experience in dealing with companies. I will admit that prior to implementing Exchange when I did AD Ops with a rather large company I didn't once look at the disk counters, didn't care, everything ran perfectly well and about the only measure of perf was replication latency and does ADUC start fast enough and it always was fine there unless there were network related issues or a DC was having hardware failure. Enter Exchange... Or some other app that pounds your DCs with millions of queries a day and tiny little bits of latency that you didn't previously feel start having an impact. You won't feel 70-80ms of latency in anything you are doing with normal AD tools or NOS ops, not at all. You will feel that with Exchange (and other heavy directory use apps), often with painful results unless it isn't consistent and the directory can unwind itself again and hence allow Exchange to then unwind itself. Now let me point out, I don't deal with tiny companies for work, small to me is less than 40-50k. The smallest I tend to deal with is about 30k. I usually get called to walk in to Exchange issues where Exchange is underperforming or outright hanging, sometimes for hours at a time. There can be all sorts of issues causing this such as O poor disk subsystem design for Exchange (someone say got fancy with a SAN layout and really didn't know what they were doing seems to be popular here) O hardware/drivers on the Exchange server just aren't working properly and the drivers are experiencing timeout issues (for some reason I want to say HBA here) O poor network configurations and odd load balancing solutions, etc that generate a whole bunch of say keep alive traffic on the segment that no one had any idea about because no one understood the solution nor took time to look at the network traces. Or maybe the infamous Full/100 on one end and half/100 on the other. Whatever. O Applications that beat the crap out of Exchange that weren't accounted for in the design well or at all... such as Blackberry or Desktop Search or various Archive solutions O Poorly written event sinks, disclaimer type products that query AD themselves for additional info fit nicely into this category (hint do not deploy one of these unless you understand the queries it generates) O DCs being too far away say like an Exchange server in the US hosting APAC users. If you are running Exchange, you put Exchange and the DCs for the domains of any users on that Exchange server on the same physical subnet. And if you have a multidomain forest, strongly consider shortcut trusts between the domains that the Exchange servers are in with the domains the users are in. O DCs underperforming The last is almost always, heck, I will say in 98% of the cases I have had to investigate, related to DC disk configuration and it is always a mirrored setup. In fact, almo
RE: [ActiveDir] RootDSE requires admin privileges
Nope. Not ICF or any other firewall on on these Virtual PC machines.
Yours, Sakari
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: 22. heinäkuuta 2006 21:02
To: Send - AD mailing list
Subject: RE: [ActiveDir] RootDSE requires admin privileges
Windows or 3rd party firewall related??
--
Dean Wells
MSEtechnology
t Email: [EMAIL PROTECTED]
http://msetechnology.com
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ActiveDir-
> [EMAIL PROTECTED] On Behalf Of Sakari Kouti
> Sent: Saturday, July 22, 2006 11:39 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] RootDSE requires admin privileges
>
> Hi Joe,
>
> I installed NetMon on that workstation and it seems that nothing gets
> out on the wire with the failure case. And quite normal LDAP searches
> in the success case.
>
> I also did a little more testing and found out that the user doesn't
> need to be a domain admin for the script lines to work. A local admin
> in the workstation is enough (but still the same user).
>
> Then I installed a second similar XP workstation in the forest, and it
> doesn't have this problem.
>
> So it seems that something funny has happened in the first workstation
> that breaks ADSI. Probably not worth to explore any further.
>
> Yours, Sakari
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ActiveDir-
> [EMAIL PROTECTED] On Behalf Of joe
> Sent: 21. heinäkuuta 2006 3:31
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] RootDSE requires admin privileges
>
> Hey Sakari, do you have a trace showing the ADSI failure and its
> resulting success if run by DA that you can post?
>
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti
> Sent: Thursday, July 20, 2006 6:26 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] RootDSE requires admin privileges
>
> Hi,
>
> I wonder if anyone else has run into a situation, where normal ADSI
> rootDSE binding doesn't work, unless the user is a domain admin?
>
> The following two-line script is a sample:
> Set objDSE = GetObject("LDAP://rootDSE") WScript.Echo
> objDSE.Get("defaultNamingContext")
>
> The first line produces the error 800401E4 (invalid syntax), if an end
> user runs the lines on an XP SP1 workstation in my tiny dev forest.
>
> - If the same user logs on to a DC (everyone is allowed to log on to
> them in this case) and runs the lines, they work fine.
>
> - If the same user is put in Domain Admins, the lines work fine even on
> the previously mentiones XP workstation.
>
> - If the same user (without being an admin) starts LDP on the XP
> workstation, she'll get the rootDSE information in LDP.
>
> This is only a two-DC dev forest (with one root domain and one child
> domain), but I wonder if this could happen in production too? The DCs
> are Windows Server 2003, and not even SP1, because they originate from
> a project I did early last year, and now returned to it. Even though
> the DCs were frozen for quite a while as Virtual PC images, replication
> works quite fine and the tombstone lifetime is 10 years.
>
> Yours, Sakari
> 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
> 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
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
Re: [ActiveDir] Managing Third-Party Users
Federation is the way of the future in these scenarios. I'm spending about 50% of my time at work these days helping to build out our federation infrastructure and imagine that we'll be using it extensively. We are already doing some type of federation thing with over 30 vendor-hosted apps internally (benefits, travel, surveys, etc.). However, none of these implemenations are currently using any of the standard federation protocols (SAML, WS-Fed) and suffer from expensive implementations, no reusability between implementations and dubious security. We are also looking at hosting some services internally for clients and partners and using federation as a way to allow them to authenticate with their own credentials. The big challenges right now are that with both SAML and WS-Fed as the dominate protocols out there (and WS-Fed much further behind in terms of adoption rates, but gaining due to the popularity of AD and the low cost of ADFS compared to many solutions), it is hard to say you only want to do ADFS/WS-Fed. Our approach is to try to support both for the "outbound" scenario, where our users are accessing a partner resource, although we are still trying to pick a SAML 2 product yet. We'll probably be more picky about WS-Fed for the opposite scenario as our guys like to use Windows token-based websites (like SharePoint) for custom dev and only ADFS has a really flexible solution for supporting this. The big challenges are that right now, things are still pretty "early adopter", so it is hard to find a lot of partners that are ready to go with their infrastructure. There isn't much expertise out there with these products yet either, so people are stumbling quite a bit. In our "inbound" scenario, we are looking at needing to set up an alternate account store to host the accounts of partners who aren't "federation-capable" yet, so that's a drag. I'm not sure the team building that app has realized yet that the cost and complexity of the identity and access management work for that account store will likely outstrip the cost of dev and maintenance on the app itself by an order of magnitude. They aren't I&AM people, so they are just realizing that users of the store will need features like password change, password reset and password expiration notifications. BTW, we are using ADAM for the account store and setting it up as a separate federation account partner. Another thing worth noting is that we already have a well-established process for provisioning accounts for external users and contractors in the corp forest and we'll continue to use that in scenarios where it is appropriate. However, we'll try to do as little as possible of that sort of thing when simple access to a few web apps is all that's needed. All in all though, I'm pretty excited about the technology, especially ADFS. It combines my three favorite tech things, I&AM, web programming and .NET, so what's not to love? :) Joe K. - Original Message - From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Saturday, July 22, 2006 12:05 PM Subject: [ActiveDir] Managing Third-Party Users My trusted directory resource, I don't remember if this came up on a previous post. but don't recall seeing the topic. As things become more and more integrated w/ some form of ldap authentication against a common directory, the necessity for managing outside vendors, contractors, etc is becoming a larger and larger task. If you're in a situation where the vendor has a large population of users that require access . with incredible churn, this becomes a big issue. I'm curious what, if anything, anyone else is doing to use some sort of federated system so that user management is left at the hands of the third-party companies. I'm curious also if anyone is aware of any consulting groups that have done this sort of thing w/ an agnostic approach that can fit most environments. I'd love to get an idea of where the industry is heading with this sort of thing. I'm sure the topic probably came up at DEC which I didn't have the luxury of attending. Thanks all! marcus c. oh | cox communications, inc. | 404.847.6117 | marcusoh.blogspot.com 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
RE: [ActiveDir] RootDSE requires admin privileges
Windows or 3rd party firewall related??
--
Dean Wells
MSEtechnology
t Email: [EMAIL PROTECTED]
http://msetechnology.com
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ActiveDir-
> [EMAIL PROTECTED] On Behalf Of Sakari Kouti
> Sent: Saturday, July 22, 2006 11:39 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] RootDSE requires admin privileges
>
> Hi Joe,
>
> I installed NetMon on that workstation and it seems that nothing gets
> out on the wire with the failure case. And quite normal LDAP searches
> in the success case.
>
> I also did a little more testing and found out that the user doesn't
> need to be a domain admin for the script lines to work. A local admin
> in the workstation is enough (but still the same user).
>
> Then I installed a second similar XP workstation in the forest, and it
> doesn't have this problem.
>
> So it seems that something funny has happened in the first workstation
> that breaks ADSI. Probably not worth to explore any further.
>
> Yours, Sakari
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ActiveDir-
> [EMAIL PROTECTED] On Behalf Of joe
> Sent: 21. heinäkuuta 2006 3:31
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] RootDSE requires admin privileges
>
> Hey Sakari, do you have a trace showing the ADSI failure and its
> resulting success if run by DA that you can post?
>
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti
> Sent: Thursday, July 20, 2006 6:26 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] RootDSE requires admin privileges
>
> Hi,
>
> I wonder if anyone else has run into a situation, where normal ADSI
> rootDSE binding doesn't work, unless the user is a domain admin?
>
> The following two-line script is a sample:
> Set objDSE = GetObject("LDAP://rootDSE") WScript.Echo
> objDSE.Get("defaultNamingContext")
>
> The first line produces the error 800401E4 (invalid syntax), if an end
> user runs the lines on an XP SP1 workstation in my tiny dev forest.
>
> - If the same user logs on to a DC (everyone is allowed to log on to
> them in this case) and runs the lines, they work fine.
>
> - If the same user is put in Domain Admins, the lines work fine even on
> the previously mentiones XP workstation.
>
> - If the same user (without being an admin) starts LDP on the XP
> workstation, she'll get the rootDSE information in LDP.
>
> This is only a two-DC dev forest (with one root domain and one child
> domain), but I wonder if this could happen in production too? The DCs
> are Windows Server 2003, and not even SP1, because they originate from
> a project I did early last year, and now returned to it. Even though
> the DCs were frozen for quite a while as Virtual PC images, replication
> works quite fine and the tombstone lifetime is 10 years.
>
> Yours, Sakari
> 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
> 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
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Any poor implementation is going to hurt you but I would argue that you are better off with a poor BIND/QIP DNS implementation than a poor Windows DNS implementation just because of the whole dependency loop thing. If you can adequately state your needs to a UNIX DNS group they can usually fullfill those needs and things should work fine. I guess MSFT could help out with this and make it so there was a way to staticly specify the required records for replication in flat files on DCs in the event there is a failure. At least this gets you up and running to the point where replication is working again and you can start working on the original DNS issue that caused the mess. Once DNS is functioning properly again you turn off the side road with the static entries. Again for me the part that hurts is if AD and AD DNS running on a DC is down, you really don't have a clue what caused what and have to start looking at everything. Most people aren't equipped to look at everything and quickly narrow it down to the key components. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Saturday, July 22, 2006 10:24 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? The downside is that your logic on this one is very hard to argue with. At the heart of the matter you are saying (allow me to paraphrase) that the issue is the dependency of one system on another which is dependent on the former. Yep, that's hard to argue with because you are right. The part that gets me is that I've seen it the other way. A BIND, or QIP implementation that was done horribly and offered way less simplicity (aka troubleshooting "hand-holds" - digression: I firmly believe that IT systems should be designed like sewer systems - with maintance access points built in along the way. The results of not doing that are similar ;) and the results were a less stable system than with delegated ad-integrated zones that only the Windows environment relied on. Oddly, that Windows environment is the gateway to the rest of the environments for the users, but hey, that's not part of this conversation now is it? Anyhow, I see your point and that's an interesting point to consider and one that is certainly tough to argue with. My only counter at this point is that either DNS system is going to be dependent on those that design and deploy it and if you're like many companies of mid to large size, your DNS is distributed and managed by those of the platform it runs on. In many instances if you run *nix, it'll be on the *nix platform, if by Windows, then by Windows support. Worse to me is if it's done by the network (phys) folks. May as well give it to the guard shack. :) On 7/22/06, joe <[EMAIL PROTECTED]> wrote: :) The main thing I don't like is AD Integrated. There is something fundamentally wrong with having your directory replication completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system I like the idea of multiple masters, I am tepid on the security (I haven't seen nor heard of anyone who has been attacked this way in 6 years of asking around), I am outright against the replication model. Aside from that, I was tainted by seeing UNIX DNS products running great at large scales and seeing Microsoft DNS screwing up to no end at medium scales. I fully realize it could have been a function of the people running it but one key time I saw it was in a pretty large company that had UNIX DNS in a complicated layout that worked great for hundreds of thousands of machines and a Microsoft DNS being used for the hundreds of DMZ machines in a very simple layout which had Microsoft resources helping with it and guess which DNS system I was hearing issues about and that was constantly having AD failures because of DNS? Again I fully realize it very likely could have been the people involved but some of those people were MSFT people so it shouldn't have been that difficult to get it working right. Everytime they tried to pull me in to work on the AD issues I simply said, fix your DNS and get on the corporate standard and then I will look at what your problems are. If I had to work do ops in an environment where MSFT DNS was my only option it i
[ActiveDir] Managing Third-Party Users
My trusted directory resource, I don’t remember if this came up on a previous post… but don’t recall seeing the topic. As things become more and more integrated w/ some form of ldap authentication against a common directory, the necessity for managing outside vendors, contractors, etc is becoming a larger and larger task. If you’re in a situation where the vendor has a large population of users that require access … with incredible churn, this becomes a big issue. I’m curious what, if anything, anyone else is doing to use some sort of federated system so that user management is left at the hands of the third-party companies. I’m curious also if anyone is aware of any consulting groups that have done this sort of thing w/ an agnostic approach that can fit most environments. I’d love to get an idea of where the industry is heading with this sort of thing. I’m sure the topic probably came up at DEC which I didn’t have the luxury of attending. Thanks all! marcus c. oh | cox communications, inc. | 404.847.6117 | marcusoh.blogspot.com
RE: [ActiveDir] Raid 1 tangent -- Vendor Domain
Mirrors don't scale. Microsoft's deployment doc mostly just talks about using mirrors (small nod to RAID 10/0+1) so everyone thinks that they should build their Corporate DCs on mirrors, usually 3 - OS, Logs, and DIT. Very few people if anyone would build a corporate Exchange Server on mirrors... Why not? The DB is the same under both of them... What is critical to Exchange? IOPS and that means spindles. If something is really beating on AD and the entire DIT can't be cached, IOPS are critical to AD as well. The main difference is that AD is mostly random read and Exchange is heavy writing and reading. The exception to this is the edge case of Eric's big DIT[1] in which he dumped 2TB of data into AD in a month at which point he did something that few people see, pushed the IOPS on the log drive through the roof. In a smaller environment (very low thousands), or for a low use DC (small WAN site), or a DC with a DIT fully cached a RAID-1 drive for DIT will probably be sufficient, you will note that the only numbers mentioned in the deployment guide are about 5000[2]... That usually means a small DIT and it is extremely likely that a K3 DC will cache the entire DIT. Plus the usage is probably such that the IO capability of two spindles will likely be ok. Let me state though that even in a small user environment if there was an intensive directory based app or a buttload of data that pushes the DIT into GB's instead of MBs I would still be watching my disk queueing pretty close as well as the Read and Write Ops. AD admins who aren't running directory intensive apps (read as Exchange 2000+) usually don't see any issues but then again most aren't looking very closely at the counters because they haven't had a reason too and even if they had some short lived issues they probably wouldn't go look at the counters. At least that has been my experience in dealing with companies. I will admit that prior to implementing Exchange when I did AD Ops with a rather large company I didn't once look at the disk counters, didn't care, everything ran perfectly well and about the only measure of perf was replication latency and does ADUC start fast enough and it always was fine there unless there were network related issues or a DC was having hardware failure. Enter Exchange... Or some other app that pounds your DCs with millions of queries a day and tiny little bits of latency that you didn't previously feel start having an impact. You won't feel 70-80ms of latency in anything you are doing with normal AD tools or NOS ops, not at all. You will feel that with Exchange (and other heavy directory use apps), often with painful results unless it isn't consistent and the directory can unwind itself again and hence allow Exchange to then unwind itself. Now let me point out, I don't deal with tiny companies for work, small to me is less than 40-50k. The smallest I tend to deal with is about 30k. I usually get called to walk in to Exchange issues where Exchange is underperforming or outright hanging, sometimes for hours at a time. There can be all sorts of issues causing this such as O poor disk subsystem design for Exchange (someone say got fancy with a SAN layout and really didn't know what they were doing seems to be popular here) O hardware/drivers on the Exchange server just aren't working properly and the drivers are experiencing timeout issues (for some reason I want to say HBA here) O poor network configurations and odd load balancing solutions, etc that generate a whole bunch of say keep alive traffic on the segment that no one had any idea about because no one understood the solution nor took time to look at the network traces. Or maybe the infamous Full/100 on one end and half/100 on the other. Whatever. O Applications that beat the crap out of Exchange that weren't accounted for in the design well or at all... such as Blackberry or Desktop Search or various Archive solutions O Poorly written event sinks, disclaimer type products that query AD themselves for additional info fit nicely into this category (hint do not deploy one of these unless you understand the queries it generates) O DCs being too far away say like an Exchange server in the US hosting APAC users. If you are running Exchange, you put Exchange and the DCs for the domains of any users on that Exchange server on the same physical subnet. And if you have a multidomain forest, strongly consider shortcut trusts between the domains that the Exchange servers are in with the domains the users are in. O DCs underperforming The last is almost always, heck, I will say in 98% of the cases I have had to investigate, related to DC disk configuration and it is always a mirrored setup. In fact, almost always it is the deployment guide recommendation of mirror for OS, mirror for logs, and mirror for DIT. Then you look at the perf and you see that the counters on the DIT disk are in the nose bleed seats and you are getting maybe 150 ops per second through the
RE: [ActiveDir] RootDSE requires admin privileges
Hi Joe,
I installed NetMon on that workstation and it seems that nothing gets out on
the wire with the failure case. And quite normal LDAP searches in the success
case.
I also did a little more testing and found out that the user doesn't need to be
a domain admin for the script lines to work. A local admin in the workstation
is enough (but still the same user).
Then I installed a second similar XP workstation in the forest, and it doesn't
have this problem.
So it seems that something funny has happened in the first workstation that
breaks ADSI. Probably not worth to explore any further.
Yours, Sakari
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: 21. heinäkuuta 2006 3:31
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] RootDSE requires admin privileges
Hey Sakari, do you have a trace showing the ADSI failure and its resulting
success if run by DA that you can post?
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti
Sent: Thursday, July 20, 2006 6:26 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] RootDSE requires admin privileges
Hi,
I wonder if anyone else has run into a situation, where normal ADSI
rootDSE binding doesn't work, unless the user is a domain admin?
The following two-line script is a sample:
Set objDSE = GetObject("LDAP://rootDSE")
WScript.Echo objDSE.Get("defaultNamingContext")
The first line produces the error 800401E4 (invalid syntax), if an end
user runs the lines on an XP SP1 workstation in my tiny dev forest.
- If the same user logs on to a DC (everyone is allowed to log on to
them in this case) and runs the lines, they work fine.
- If the same user is put in Domain Admins, the lines work fine even on
the previously mentiones XP workstation.
- If the same user (without being an admin) starts LDP on the XP
workstation, she'll get the rootDSE information in LDP.
This is only a two-DC dev forest (with one root domain and one child
domain), but I wonder if this could happen in production too? The DCs
are Windows Server 2003, and not even SP1, because they originate from a
project I did early last year, and now returned to it. Even though the
DCs were frozen for quite a while as Virtual PC images, replication
works quite fine and the tombstone lifetime is 10 years.
Yours, Sakari
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
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
RE: [ActiveDir] Raid 1 tangent -- Vendor Domain
"- stop using mirrors damnit) ."[1] can you please explain that? What's wrong with mirrors? [1] joe, speaking particularly in the context of Exchange 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
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
:) The main thing I don't like is AD Integrated. There is something fundamentally wrong with having your directory replication completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system I like the idea of multiple masters, I am tepid on the security (I haven't seen nor heard of anyone who has been attacked this way in 6 years of asking around), I am outright against the replication model. Aside from that, I was tainted by seeing UNIX DNS products running great at large scales and seeing Microsoft DNS screwing up to no end at medium scales. I fully realize it could have been a function of the people running it but one key time I saw it was in a pretty large company that had UNIX DNS in a complicated layout that worked great for hundreds of thousands of machines and a Microsoft DNS being used for the hundreds of DMZ machines in a very simple layout which had Microsoft resources helping with it and guess which DNS system I was hearing issues about and that was constantly having AD failures because of DNS? Again I fully realize it very likely could have been the people involved but some of those people were MSFT people so it shouldn't have been that difficult to get it working right. Everytime they tried to pull me in to work on the AD issues I simply said, fix your DNS and get on the corporate standard and then I will look at what your problems are. If I had to work do ops in an environment where MSFT DNS was my only option it is quite likely that I would work to become an expert on it and it is also possible I would work on it and finally just say screw this and I am going to sit down at night and write my own version of DNS or use BIND. That way I can have full control of what is going on and not wonder what the hell is going on or what changed in the last rev such that now my AD can't work because DNS isn't working because my DC is flaking out because AD isn't working. Etc etc etc. I guess what I am saying, a string of dependencies no matter how long or how short really shouldn't loop back upon itself. You shouldn't have to be sitting there wondering if AD broke DNS or DNS broke AD and what you have to fix to make it all work again. If I am running DNS on another platform or at least on a Windows machine with no dependence on the domain and I see that DNS and AD are broken I know right where I need to start working without thinking very hard about it. The KISS philosphy is there for a reason, ops people especially in the middle of a blowup should not be required to think hard. The hard thinking needs to occur in the design and prior to things blowing up. When something blows up it should be a matter of putting it back together. Obviously it isn't always going to be that way but purposely putting something together that is going to require that hard thinking when it blows for sure doesn't make much sense to me. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Friday, July 21, 2006 11:37 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Now don't go getting misty eyed and thinking that I'm coming over the joe-side of thinking when it comes to DNS and Microsoft. But aye, it has it's shortcomings and could be much better. Perhaps they need a real competitor vis a vis Firefox and IE to get things jumping? Hmm. :) On 7/21/06, joe <[EMAIL PROTECTED]> wrote: Hehe Bingo... keep playing and one day you may even think how nice it is to not have DNS on DCs at all or even on Microsoft Is that heresy here? If so I will say three Hail Kwan's and sprinkle some ground up Intel chip dust on myself... ;o) Dean wonders why I hate DNS. :) http://www.gilsblog.com/index.cfm?commentID=60 -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Al MulnickSent: Thursday, July 13, 2006 3:32 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? See how quickly thinking changes? :) I almost think this is a better reason not to have AD-integrated DNS. Shall have to ponder a bit more, but
RE: [ActiveDir] DNS Issue
Hi Steve Binary version is 5.2.3790.1830 (srv03_sp1_rtm.050324-1447) Clearing the cache does not fix the issue. Thanks David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Linehan Sent: 22 Jul 2006 0:56 To: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] DNS Issue What version of the DNS binary are you running and if you clear the cache instead of restart DNS does it resolve the issue? Thanks, -Steve From: [EMAIL PROTECTED] on behalf of Wyatt, David Sent: Fri 7/21/2006 4:39 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] DNS Issue We have a single Windows 2003 SP1 forest/domain. DCs run AD integated zones. We have Forwarders configured for a domain e.g. test.com with 2 IP addresses entered for the DNS servers in test.com. We have seen a strange issue where queries for a host in the sub-domain nyc.test.com fail (even when doing an nslookup directly from the DC). When we restart the DNS service on the DC resolution succeeds for a host in nyc.test.com. After time it appears resolution fails again. Another observation is when (after time) name resolution fails for a host in nyc.test.com and we explicitly add nyc.test.com as another Forwarder and without restarting the DNS service names in nyc.test.com resolves. Remove the forwarding to nyc.test.com and resolution fails! Any ideas? Regards David This message contains confidential information and is intended only for the individual or entity named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as an invitation or offer to buy or sell any securities or related financial instruments. GAM operates in many jurisdictions and is regulated or licensed in those jurisdictions as required. 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
RE: [ActiveDir] Domain Trusts.
you might want to describe to us what your actual goal is for creating a non-fully trusted domain in your AD forst. Maybe you can reach a similar goal by using the fairly powerful capabilities in AD to delegate administration of objects within a domain. You can also use these features to hide specific parts of AD from the rest of the organization and thus create a "semi-isolated" units within a single AD domain. Note that there is no way to fully isolate any objects within a domain or forest from domain or enterprise admins - if you do need full administrative isolation, you have to create multiple forests. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: Saturday, July 22, 2006 12:45 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Domain Trusts. 1-yep 2-yep Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server - Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile : +31-(0)6-26.26.62.80 * E-mail : From: [EMAIL PROTECTED] on behalf of Matt HargravesSent: Sat 2006-07-22 00:35To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Domain Trusts. So basically there's no way to have a domain in a forest that doesn't fully trust every other domain in the forest?The only way to have a non 2-way trust is to make a separate forest?
RE: [ActiveDir] Vendor Domain
> Will the application run off of an ADAM instance instead of a full blown forest? That was going through my mind as well - why would the vendor want to use a NOS AD for his application? Again, there must be some reason for this. joe makes great points rgd. the support issues of an application which is fully integrated into the NOS AD, but is managed by a different team - possibly the vendor himself. So knowledge about the planned support model will certainly help to discuss justification of a separate forest. Clearly, that should include management of that extra forest itself (who is responsible for backing up that forest and ensuring operation of the DCs etc.). /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, July 20, 2006 10:55 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Vendor Domain My first reaction is that that is pretty nebulous and hazy. I don't think they can compare whatever it is they do to a respirator and have validity, I think that would be talking apples and olive pits. Overall it sounds like a move to reduce support and troubleshooting costs by having a known fixed environment in which their app will run. It could even mean that they have bad decisions (and coding) in the software itself that has hard requirements to that specific layout so they don't have to code for a more generic setup. Certainly the concern that AD may not be stable is a valid one from a vendor doing managed service support standpoint as it is something I have encountered in the field myself. More environments than not that I have walked into to deploy Exchange the AD folks thought AD was perfectly fine and were surprised when Exchange dragged their DCs under water and I have to go through their design and figure out what exactly isn't optimal (hint usually the disk subsystems - stop using mirrors damnit). But if the customer is willing to accept that risk as a caveat to the support model then the vendor should be able to support it. This can and usually should have some level of impact on costing and possibly support levels and penalties (if they exist). It is cheaper to run support on a fixed known setup than it is to support something you didn't design and can't exercise control over. You as a customer would need to accept that as well. But it really comes back to whether the product will work in a generic environment at all and if the vendor is willing to put in the time to figure out their exposure and write the contract (and bill) to suitably cover for it. Taking this back to an Exchange example which is more familiar to many folks. Take the example where you want email and you bring someone in to create and run an Exchange service for you. You aren't managing or supporting it, it is all them, you simply give them the requirements. If they have a cookie cutter separate domain/forest solution it is something they have worked out and tested and understand and can best support. In general I think it is better for you and think it is good for you to strongly consider allowing them to run it that way because of the issues with Exchange and the resulting administration mess. It is tough to fight it because there aren't a lot of options outside of Exchange with the features people want... If you have strong feelings against that separate forest and want the vendor to forgo their own design, which does happen, they can and usually will run it from your forest however you have got to expect cost increases. You are basically telling the respirator company (to use that bad analogy) that you want the respirator to work in an entirely different way than the product you picked out of the catalog. The prices increases are to cover real costs incurred by the vendor to cover a changed support model and cover for the extra design work that they would need to be involved in to support your environment. In addition, you would need to accept the caveats on service that they may need to put into place to protect themselves from lawsuits that are actually the fault of something they don't control. An example would be any issues that end up having a root cause back in the AD that you control releases them from SLA penalties and allows them to charge back costs associated with it. A specific example is say where you have company A running a mail service for you out of your directory and you allow local site admins to have extensive control over their users and one of the admins decided to give himself a 10GB quota and then uses it and kills the free space on the Exchange server causing the vendor to scramble resources to cover for the resulting issues. That absolutely needs to be charged back to the company and not the vendor. Even if you have separate groups in the same company running AD and Exchange those are things that get fights going over because the Exchange team is budgeted to cover E
RE: [ActiveDir] root admin account able to be locked out?
Title: root admin account able to be locked out? Jorge (and joe), Thanks for your reply on this issue! Mike Thommes From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Tuesday, July 18, 2006 3:43 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] root admin account able to be locked out? My experience with this is the default ADMINISTRATOR can be locked out (wait before shouting!) what I mean is that if you have a lockout threshold of lets say 5, the lockoutTime attribute will show the lockout date and time the account was locked. In ADUC (using another custom admin account for example) you will see the default ADMINISTRATOR is locked you will even see and event ID 644 mentioning the account lockout HOWEVER here it comes... while the default ADMINISTRATOR is locked, it will unlocked automatically by the SYSTEM (DC) AS SOON AS the correct password is used (even before it is unlocked after the unlock period) jorge Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server - Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile : +31-(0)6-26.26.62.80 * E-mail : From: [EMAIL PROTECTED] on behalf of Thommes, Michael M. Sent: Tue 2006-07-18 20:27 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] root admin account able to be locked out? Hi AD Gurus! We have penetration testing going on and I saw a security event log entry that showed our root admin account getting locked out. I was surprised because I thought this account could never get locked out. In addition, we had a scheduled job that runs under the credentials of this root account that ran successfully a couple of minutes *after* the supposed account was locked. (We have the standard 30 minute lockout time.) I think the reason that this happened was that the penetration testing really didn’t lock out the root account but did lockout the local SID 500 account that exists on all servers (including domain controllers). This is my belief. My officemate says there is no such account on a DC and that the root account could have been locked out for a short period of time but then made active again when AD saw what the account was or that the security log entry is just bogus. Can someone offer a little insight into this (nope, no dinners or cash riding on this debate!). Thanks much! Mike Thommes
Re: [ActiveDir] Replmon vs. dssite.msc
If I understand correctly, replmon shows connection object info that was retrieved from the dc itself. dssite.msc shows the connection object info from the dc the snap-in is focused on. please correct me if i've misunderstood M@ On 7/19/06, Noah Eiger <[EMAIL PROTECTED]> wrote: Hi – I am trying to promote a new DC in a branch location. I also want this to be the bridgehead for IP at this Site. The promo seems to have worked, but there are some replication problems. Why would replmon show different replication partners than the Active Directory Sites and Services (dssite.msc) snap-in? I am running both tools on the same machine and have confirmed that they connect to the same machine. Thanks. -- nme -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006 [EMAIL PROTECTED])
