| Author | Messages | |
BrianB
Posts:95
 | | 12/02/2008 11:16 AM |
| All,
We have what MS calls a disjointed namespace for our AD environment.
Empty Root Domain - AD-Root.V.E
Resources Domain - AD.V.E
Global catalogs are on all DC's in the child domain.
No GC's in the root.
We are installing Exchange which heavily utilizes Universal groups
within the forest for Exchange Admins to perform admin functions.
When performing the last step which is prepare domain for the local
domain that Exchange will be installed into, we receive the error "User
not found." I tried to run the application as different privileged
users. I also tried to run the app in the root domain and had the same
error, "User not found."
We found an article that stated that a GC needed to be contacted in the
root domain, of we needed to prepare the entire forest for Exchange
which is undesirable. We only want to prepare the local domain where
Exchange will be installed.
So... I enable a GC in the root and, behold, it worked.
Now, for various reasons, our team is mixed in their desire to enable
GC's in the forest root. If we need to enable one, so be it but we are
looking for an explanation as to why one is needed in the root when we
have them in the child. If GC's are supposed to have a subset of
everything object in the forest and enable Universal group membership
lookups, why would we need additional GC's in the root?
Additionally, we have two sites. Each Domain crosses the two sites. So
to illustrate: AD-Root.v.e and AD.v.e both exist in both sites. If we
enable only only one GC in the opposite site from us, the application
still fails with the same error. However if we enable only one GC in our
site, the application works. So it seems that it does not span sites to
find a GC either.
We called our MS rep and he stated that we had a disjointed namespace in
the design and that we had to enable a GC in the root and that the GC's
in the child were not sufficient to look up the Universal Group
Membership. BTW: The Universal group exists in the root with members
from the child domain.
So... if a GC, is a GC, is a GC.... Why do we need one in the root
domain with so many in the child? Why do we need a GC in the same site?
Is there something I am missing here?
I did find an blog post by Joe located below, explaining a disjointed
namespace and it does not seem that MS is telling us the same thing.
http://blog.joeware.net/2006/07/17/449/
HELP!!!
| | | |
| listmail
Posts:763
| | 12/02/2008 11:24 AM |
| Your MS Rep is misinformed. Any GC can enumerate the universal groups of the
forest.
This is almost certainly related to the fact that Exchange doesn't like to
use the standard location services to find DCs/GCs, it reads the config
container directly and tries to figure it out on its own. Otherwise any GC
that is published in DNS for the site would be used because that is the
normal location services mechanism. This has nothing to do with disjoint
namespace and even if it did, MSFT needs to fix it because they have stated
that disjoint namespaces are fully supported. That was something I had to
get clarified with them all the way back in 2000.
Feel free to send my email to your MS Rep.
On the part of a GC is a GC is a GC.... not really. Due to implementation
details around linked attributes there are differences between GCs that are
DCs of different domains. For example if you have Dom1 and Dom2 and you have
GC1Dom1 and GC2Dom2 and you have Dom1\User1 who is in Dom1\LocalGroup1 and
Dom2\LocalGroup2, enumeration of Dom1\User1 memberof attribute WILL BE
DIFFERENT on GC1Dom1 and GC2Dom2. There are other subtleties there as well.
None of which should affect Universal group direct membership though.
--
O'Reilly Active Directory Fourth Edition -
<http://www.joeware.net/win/ad4e.htm> http://www.joeware.net/win/ad4e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 11:08 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Disjoint namespace and GC lookups
All,
We have what MS calls a disjointed namespace for our AD environment.
Empty Root Domain - AD-Root.V.E
Resources Domain - AD.V.E
Global catalogs are on all DC's in the child domain.
No GC's in the root.
We are installing Exchange which heavily utilizes Universal groups within
the forest for Exchange Admins to perform admin functions.
When performing the last step which is prepare domain for the local domain
that Exchange will be installed into, we receive the error "User not found."
I tried to run the application as different privileged users. I also tried
to run the app in the root domain and had the same error, "User not found."
We found an article that stated that a GC needed to be contacted in the root
domain, of we needed to prepare the entire forest for Exchange which is
undesirable. We only want to prepare the local domain where Exchange will be
installed.
So... I enable a GC in the root and, behold, it worked.
Now, for various reasons, our team is mixed in their desire to enable GC's
in the forest root. If we need to enable one, so be it but we are looking
for an explanation as to why one is needed in the root when we have them in
the child. If GC's are supposed to have a subset of everything object in the
forest and enable Universal group membership lookups, why would we need
additional GC's in the root?
Additionally, we have two sites. Each Domain crosses the two sites. So to
illustrate: AD-Root.v.e and AD.v.e both exist in both sites. If we enable
only only one GC in the opposite site from us, the application still fails
with the same error. However if we enable only one GC in our site, the
application works. So it seems that it does not span sites to find a GC
either.
We called our MS rep and he stated that we had a disjointed namespace in the
design and that we had to enable a GC in the root and that the GC's in the
child were not sufficient to look up the Universal Group Membership. BTW:
The Universal group exists in the root with members from the child domain.
So... if a GC, is a GC, is a GC.... Why do we need one in the root domain
with so many in the child? Why do we need a GC in the same site? Is there
something I am missing here?
I did find an blog post by Joe located below, explaining a disjointed
namespace and it does not seem that MS is telling us the same thing.
http://blog.joeware.net/2006/07/17/449/
HELP!!!
| | | |
| michael1
Posts:386
| | 12/02/2008 11:39 AM |
| http://technet.microsoft.com/en-us/library/bb288907.aspx describes what
Exchange setup is doing, in detail, for prepareDomain.
As to why setup is requiring a GC in the root domain, as opposed to a simple
DC in the root domain, I don't know.
Setup requires a GC in the same site in order to avoid replication issues
(which can still happen if you are installing stretch clusters). This is
well documented.
Regards,
Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP
My blog: http://TheEssentialExchange.com/blogs/michael
Link with me at: http://www.linkedin.com/in/theessentialexchange
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 11:08 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Disjoint namespace and GC lookups
All,
We have what MS calls a disjointed namespace for our AD environment.
Empty Root Domain - AD-Root.V.E
Resources Domain - AD.V.E
Global catalogs are on all DC's in the child domain.
No GC's in the root.
We are installing Exchange which heavily utilizes Universal groups within
the forest for Exchange Admins to perform admin functions.
When performing the last step which is prepare domain for the local domain
that Exchange will be installed into, we receive the error "User not found."
I tried to run the application as different privileged users. I also tried
to run the app in the root domain and had the same error, "User not found."
We found an article that stated that a GC needed to be contacted in the root
domain, of we needed to prepare the entire forest for Exchange which is
undesirable. We only want to prepare the local domain where Exchange will be
installed.
So... I enable a GC in the root and, behold, it worked.
Now, for various reasons, our team is mixed in their desire to enable GC's
in the forest root. If we need to enable one, so be it but we are looking
for an explanation as to why one is needed in the root when we have them in
the child. If GC's are supposed to have a subset of everything object in the
forest and enable Universal group membership lookups, why would we need
additional GC's in the root?
Additionally, we have two sites. Each Domain crosses the two sites. So to
illustrate: AD-Root.v.e and AD.v.e both exist in both sites. If we enable
only only one GC in the opposite site from us, the application still fails
with the same error. However if we enable only one GC in our site, the
application works. So it seems that it does not span sites to find a GC
either.
We called our MS rep and he stated that we had a disjointed namespace in the
design and that we had to enable a GC in the root and that the GC's in the
child were not sufficient to look up the Universal Group Membership. BTW:
The Universal group exists in the root with members from the child domain.
So... if a GC, is a GC, is a GC.... Why do we need one in the root domain
with so many in the child? Why do we need a GC in the same site? Is there
something I am missing here?
I did find an blog post by Joe located below, explaining a disjointed
namespace and it does not seem that MS is telling us the same thing.
http://blog.joeware.net/2006/07/17/449/
HELP!!!
| | | |
| BrianB
Posts:95
| | 12/02/2008 4:19 PM |
| Joe,
Thanks for your reply. I am still not sure why a GC would need to be in
the root domain though.
How would I proof-test the "memberof" from the two perspectives of GC1
and GC2 that you speak about below?
Where in the config container does Exchange look for the GC? I have
found sites > Servers > NTDS > Properties > options=0x1 is_GC
What is Exchange looking for?
Brian
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Tuesday, December 02, 2008 10:21 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Your MS Rep is misinformed. Any GC can enumerate the universal groups of
the forest.
This is almost certainly related to the fact that Exchange doesn't like
to use the standard location services to find DCs/GCs, it reads the
config container directly and tries to figure it out on its own.
Otherwise any GC that is published in DNS for the site would be used
because that is the normal location services mechanism. This has nothing
to do with disjoint namespace and even if it did, MSFT needs to fix it
because they have stated that disjoint namespaces are fully supported.
That was something I had to get clarified with them all the way back in
2000.
Feel free to send my email to your MS Rep.
On the part of a GC is a GC is a GC.... not really. Due to
implementation details around linked attributes there are differences
between GCs that are DCs of different domains. For example if you have
Dom1 and Dom2 and you have GC1Dom1 and GC2Dom2 and you have Dom1\User1
who is in Dom1\LocalGroup1 and Dom2\LocalGroup2, enumeration of
Dom1\User1 memberof attribute WILL BE DIFFERENT on GC1Dom1 and GC2Dom2.
There are other subtleties there as well. None of which should affect
Universal group direct membership though.
--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm
<http://www.joeware.net/win/ad4e.htm>
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 11:08 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Disjoint namespace and GC lookups
All,
We have what MS calls a disjointed namespace for our AD environment.
Empty Root Domain - AD-Root.V.E
Resources Domain - AD.V.E
Global catalogs are on all DC's in the child domain.
No GC's in the root.
We are installing Exchange which heavily utilizes Universal groups
within the forest for Exchange Admins to perform admin functions.
When performing the last step which is prepare domain for the local
domain that Exchange will be installed into, we receive the error "User
not found." I tried to run the application as different privileged
users. I also tried to run the app in the root domain and had the same
error, "User not found."
We found an article that stated that a GC needed to be contacted in the
root domain, of we needed to prepare the entire forest for Exchange
which is undesirable. We only want to prepare the local domain where
Exchange will be installed.
So... I enable a GC in the root and, behold, it worked.
Now, for various reasons, our team is mixed in their desire to enable
GC's in the forest root. If we need to enable one, so be it but we are
looking for an explanation as to why one is needed in the root when we
have them in the child. If GC's are supposed to have a subset of
everything object in the forest and enable Universal group membership
lookups, why would we need additional GC's in the root?
Additionally, we have two sites. Each Domain crosses the two sites. So
to illustrate: AD-Root.v.e and AD.v.e both exist in both sites. If we
enable only only one GC in the opposite site from us, the application
still fails with the same error. However if we enable only one GC in our
site, the application works. So it seems that it does not span sites to
find a GC either.
We called our MS rep and he stated that we had a disjointed namespace in
the design and that we had to enable a GC in the root and that the GC's
in the child were not sufficient to look up the Universal Group
Membership. BTW: The Universal group exists in the root with members
from the child domain.
So... if a GC, is a GC, is a GC.... Why do we need one in the root
domain with so many in the child? Why do we need a GC in the same site?
Is there something I am missing here?
I did find an blog post by Joe located below, explaining a disjointed
namespace and it does not seem that MS is telling us the same thing.
http://blog.joeware.net/2006/07/17/449/
HELP!!!
| | | |
| listmail
Posts:763
| | 12/03/2008 1:11 AM |
| Doesn't matter what Exchange is looking for, you aren't going to be able to
change the functionality. But likely it determines the local machine's site
and then looks at the machines in that site and rates them by the options
and other attributes to find what it wants.
Proving that "all GCs are not created equal" for linked attributes is easy.
1. Start with a 2+ domain forest that has GCs in at least 2 of them.
2. Create a user in arbitrarily picked Dom1
3. Create a domain local group in Dom1
4. Add the user to the group created in step 3.
5. Create a domain local group in arbitrarily picked Dom2
6. Add the user to the group created in step 5.
7. Run the following command against a GC in both Dom1 and Dom2
adfind -h GC_NAME -gc -b USER_DN memberof
So like
adfind -h GC-DOM1 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
adfind -h GC-DOM2 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
The first query will show the DN from the DOM1 LG, the second query will
show the DN from the DOM2 LG.
joe
--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 4:15 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Joe,
Thanks for your reply. I am still not sure why a GC would need to be in the
root domain though.
How would I proof-test the "memberof" from the two perspectives of GC1 and
GC2 that you speak about below?
Where in the config container does Exchange look for the GC? I have found
sites > Servers > NTDS > Properties > options=0x1 is_GC
What is Exchange looking for?
Brian
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Tuesday, December 02, 2008 10:21 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Your MS Rep is misinformed. Any GC can enumerate the universal groups of the
forest.
This is almost certainly related to the fact that Exchange doesn't like to
use the standard location services to find DCs/GCs, it reads the config
container directly and tries to figure it out on its own. Otherwise any GC
that is published in DNS for the site would be used because that is the
normal location services mechanism. This has nothing to do with disjoint
namespace and even if it did, MSFT needs to fix it because they have stated
that disjoint namespaces are fully supported. That was something I had to
get clarified with them all the way back in 2000.
Feel free to send my email to your MS Rep.
On the part of a GC is a GC is a GC.... not really. Due to implementation
details around linked attributes there are differences between GCs that are
DCs of different domains. For example if you have Dom1 and Dom2 and you have
GC1Dom1 and GC2Dom2 and you have Dom1\User1 who is in Dom1\LocalGroup1 and
Dom2\LocalGroup2, enumeration of Dom1\User1 memberof attribute WILL BE
DIFFERENT on GC1Dom1 and GC2Dom2. There are other subtleties there as well.
None of which should affect Universal group direct membership though.
--
O'Reilly Active Directory Fourth Edition -
<http://www.joeware.net/win/ad4e.htm> http://www.joeware.net/win/ad4e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 11:08 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Disjoint namespace and GC lookups
All,
We have what MS calls a disjointed namespace for our AD environment.
Empty Root Domain - AD-Root.V.E
Resources Domain - AD.V.E
Global catalogs are on all DC's in the child domain.
No GC's in the root.
We are installing Exchange which heavily utilizes Universal groups within
the forest for Exchange Admins to perform admin functions.
When performing the last step which is prepare domain for the local domain
that Exchange will be installed into, we receive the error "User not found."
I tried to run the application as different privileged users. I also tried
to run the app in the root domain and had the same error, "User not found."
We found an article that stated that a GC needed to be contacted in the root
domain, of we needed to prepare the entire forest for Exchange which is
undesirable. We only want to prepare the local domain where Exchange will be
installed.
So... I enable a GC in the root and, behold, it worked.
Now, for various reasons, our team is mixed in their desire to enable GC's
in the forest root. If we need to enable one, so be it but we are looking
for an explanation as to why one is needed in the root when we have them in
the child. If GC's are supposed to have a subset of everything object in the
forest and enable Universal group membership lookups, why would we need
additional GC's in the root?
Additionally, we have two sites. Each Domain crosses the two sites. So to
illustrate: AD-Root.v.e and AD.v.e both exist in both sites. If we enable
only only one GC in the opposite site from us, the application still fails
with the same error. However if we enable only one GC in our site, the
application works. So it seems that it does not span sites to find a GC
either.
We called our MS rep and he stated that we had a disjointed namespace in the
design and that we had to enable a GC in the root and that the GC's in the
child were not sufficient to look up the Universal Group Membership. BTW:
The Universal group exists in the root with members from the child domain.
So... if a GC, is a GC, is a GC.... Why do we need one in the root domain
with so many in the child? Why do we need a GC in the same site? Is there
something I am missing here?
I did find an blog post by Joe located below, explaining a disjointed
namespace and it does not seem that MS is telling us the same thing.
http://blog.joeware.net/2006/07/17/449/
HELP!!!
| | | |
| BrianB
Posts:95
| | 12/05/2008 2:24 PM |
| Joe, or anyone else:
I have verified that the view of an object against the GC is the same
from all perspectives. We still do not have a GC in the domain that the
Schema FSMO resides. I can't figure out why Exchange 2007 setup
/preparedomain is requiring me to create a GC in both domains.
Is there some rule that requires a GC in each domain in the forest. I
have found where we are told to put a GC in each site that Exchange will
be installed in. I have not been able to determine why a GC needs to be
in both domains in that site.
Is there any clarification why setup cannot find what it wants form the
local domain GC and must look to the root domain GC to complete?
I am baffled. Based on my tests of the GC looking at member and memberof
I see the same thing from all perspectives.
Argh!!!
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Wednesday, December 03, 2008 12:07 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Doesn't matter what Exchange is looking for, you aren't going to be able
to change the functionality. But likely it determines the local
machine's site and then looks at the machines in that site and rates
them by the options and other attributes to find what it wants.
Proving that "all GCs are not created equal" for linked attributes is
easy.
1. Start with a 2+ domain forest that has GCs in at least 2 of them.
2. Create a user in arbitrarily picked Dom1
3. Create a domain local group in Dom1
4. Add the user to the group created in step 3.
5. Create a domain local group in arbitrarily picked Dom2
6. Add the user to the group created in step 5.
7. Run the following command against a GC in both Dom1 and Dom2
adfind -h GC_NAME -gc -b USER_DN memberof
So like
adfind -h GC-DOM1 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
adfind -h GC-DOM2 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
The first query will show the DN from the DOM1 LG, the second query will
show the DN from the DOM2 LG.
joe
--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 4:15 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Joe,
Thanks for your reply. I am still not sure why a GC would need to be in
the root domain though.
How would I proof-test the "memberof" from the two perspectives of GC1
and GC2 that you speak about below?
Where in the config container does Exchange look for the GC? I have
found sites > Servers > NTDS > Properties > options=0x1 is_GC
What is Exchange looking for?
Brian
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Tuesday, December 02, 2008 10:21 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Your MS Rep is misinformed. Any GC can enumerate the universal groups of
the forest.
This is almost certainly related to the fact that Exchange doesn't like
to use the standard location services to find DCs/GCs, it reads the
config container directly and tries to figure it out on its own.
Otherwise any GC that is published in DNS for the site would be used
because that is the normal location services mechanism. This has nothing
to do with disjoint namespace and even if it did, MSFT needs to fix it
because they have stated that disjoint namespaces are fully supported.
That was something I had to get clarified with them all the way back in
2000.
Feel free to send my email to your MS Rep.
On the part of a GC is a GC is a GC.... not really. Due to
implementation details around linked attributes there are differences
between GCs that are DCs of different domains. For example if you have
Dom1 and Dom2 and you have GC1Dom1 and GC2Dom2 and you have Dom1\User1
who is in Dom1\LocalGroup1 and Dom2\LocalGroup2, enumeration of
Dom1\User1 memberof attribute WILL BE DIFFERENT on GC1Dom1 and GC2Dom2.
There are other subtleties there as well. None of which should affect
Universal group direct membership though.
--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm
<http://www.joeware.net/win/ad4e.htm>
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 11:08 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Disjoint namespace and GC lookups
All,
We have what MS calls a disjointed namespace for our AD environment.
Empty Root Domain - AD-Root.V.E
Resources Domain - AD.V.E
Global catalogs are on all DC's in the child domain.
No GC's in the root.
We are installing Exchange which heavily utilizes Universal groups
within the forest for Exchange Admins to perform admin functions.
When performing the last step which is prepare domain for the local
domain that Exchange will be installed into, we receive the error "User
not found." I tried to run the application as different privileged
users. I also tried to run the app in the root domain and had the same
error, "User not found."
We found an article that stated that a GC needed to be contacted in the
root domain, of we needed to prepare the entire forest for Exchange
which is undesirable. We only want to prepare the local domain where
Exchange will be installed.
So... I enable a GC in the root and, behold, it worked.
Now, for various reasons, our team is mixed in their desire to enable
GC's in the forest root. If we need to enable one, so be it but we are
looking for an explanation as to why one is needed in the root when we
have them in the child. If GC's are supposed to have a subset of
everything object in the forest and enable Universal group membership
lookups, why would we need additional GC's in the root?
Additionally, we have two sites. Each Domain crosses the two sites. So
to illustrate: AD-Root.v.e and AD.v.e both exist in both sites. If we
enable only only one GC in the opposite site from us, the application
still fails with the same error. However if we enable only one GC in our
site, the application works. So it seems that it does not span sites to
find a GC either.
We called our MS rep and he stated that we had a disjointed namespace in
the design and that we had to enable a GC in the root and that the GC's
in the child were not sufficient to look up the Universal Group
Membership. BTW: The Universal group exists in the root with members
from the child domain.
So... if a GC, is a GC, is a GC.... Why do we need one in the root
domain with so many in the child? Why do we need a GC in the same site?
Is there something I am missing here?
I did find an blog post by Joe located below, explaining a disjointed
namespace and it does not seem that MS is telling us the same thing.
http://blog.joeware.net/2006/07/17/449/
HELP!!!
| | | |
| jamesawells
Posts:73
| | 12/05/2008 2:52 PM |
| It's an Exchange 2007 setup thing. I found out that someone had
misconfigured a development forest when I hit the same problem.
Should it be that way? IMHO, no. But that's what setup requires.
On 12/5/08, Britt, Brian <brian.britt@vanderbilt.edu> wrote:
> Joe, or anyone else:
>
>
>
> I have verified that the view of an object against the GC is the same
> from all perspectives. We still do not have a GC in the domain that the
> Schema FSMO resides. I can't figure out why Exchange 2007 setup
> /preparedomain is requiring me to create a GC in both domains.
>
>
>
> Is there some rule that requires a GC in each domain in the forest. I
> have found where we are told to put a GC in each site that Exchange will
> be installed in. I have not been able to determine why a GC needs to be
> in both domains in that site.
>
>
>
> Is there any clarification why setup cannot find what it wants form the
> local domain GC and must look to the root domain GC to complete?
>
>
>
> I am baffled. Based on my tests of the GC looking at member and memberof
> I see the same thing from all perspectives.
>
>
>
> Argh!!!
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
> Sent: Wednesday, December 03, 2008 12:07 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
>
>
>
> Doesn't matter what Exchange is looking for, you aren't going to be able
> to change the functionality. But likely it determines the local
> machine's site and then looks at the machines in that site and rates
> them by the options and other attributes to find what it wants.
>
>
>
> Proving that "all GCs are not created equal" for linked attributes is
> easy.
>
>
>
> 1. Start with a 2+ domain forest that has GCs in at least 2 of them.
>
> 2. Create a user in arbitrarily picked Dom1
>
> 3. Create a domain local group in Dom1
>
> 4. Add the user to the group created in step 3.
>
> 5. Create a domain local group in arbitrarily picked Dom2
>
> 6. Add the user to the group created in step 5.
>
> 7. Run the following command against a GC in both Dom1 and Dom2
>
>
>
> adfind -h GC_NAME -gc -b USER_DN memberof
>
>
>
> So like
>
>
>
> adfind -h GC-DOM1 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
>
> adfind -h GC-DOM2 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
>
>
>
> The first query will show the DN from the DOM1 LG, the second query will
> show the DN from the DOM2 LG.
>
>
>
> joe
>
>
>
>
>
>
>
> --
>
> O'Reilly Active Directory Fourth Edition -
> http://www.joeware.net/win/ad4e.htm
>
>
>
>
>
>
>
> ________________________________
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
> Sent: Tuesday, December 02, 2008 4:15 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
>
> Joe,
>
>
>
> Thanks for your reply. I am still not sure why a GC would need to be in
> the root domain though.
>
>
>
> How would I proof-test the "memberof" from the two perspectives of GC1
> and GC2 that you speak about below?
>
>
>
> Where in the config container does Exchange look for the GC? I have
> found sites > Servers > NTDS > Properties > options=0x1 is_GC
>
> What is Exchange looking for?
>
>
>
> Brian
>
>
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
> Sent: Tuesday, December 02, 2008 10:21 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
>
>
>
> Your MS Rep is misinformed. Any GC can enumerate the universal groups of
> the forest.
>
>
>
> This is almost certainly related to the fact that Exchange doesn't like
> to use the standard location services to find DCs/GCs, it reads the
> config container directly and tries to figure it out on its own.
> Otherwise any GC that is published in DNS for the site would be used
> because that is the normal location services mechanism. This has nothing
> to do with disjoint namespace and even if it did, MSFT needs to fix it
> because they have stated that disjoint namespaces are fully supported.
> That was something I had to get clarified with them all the way back in
> 2000.
>
>
>
> Feel free to send my email to your MS Rep.
>
>
>
> On the part of a GC is a GC is a GC.... not really. Due to
> implementation details around linked attributes there are differences
> between GCs that are DCs of different domains. For example if you have
> Dom1 and Dom2 and you have GC1Dom1 and GC2Dom2 and you have Dom1\User1
> who is in Dom1\LocalGroup1 and Dom2\LocalGroup2, enumeration of
> Dom1\User1 memberof attribute WILL BE DIFFERENT on GC1Dom1 and GC2Dom2.
> There are other subtleties there as well. None of which should affect
> Universal group direct membership though.
>
>
>
>
>
> --
>
> O'Reilly Active Directory Fourth Edition -
> http://www.joeware.net/win/ad4e.htm
> <http://www.joeware.net/win/ad4e.htm>
>
>
>
>
>
>
>
> ________________________________
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
> Sent: Tuesday, December 02, 2008 11:08 AM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] Disjoint namespace and GC lookups
>
> All,
>
>
>
> We have what MS calls a disjointed namespace for our AD environment.
>
> Empty Root Domain - AD-Root.V.E
>
> Resources Domain - AD.V.E
>
>
>
> Global catalogs are on all DC's in the child domain.
>
> No GC's in the root.
>
>
>
> We are installing Exchange which heavily utilizes Universal groups
> within the forest for Exchange Admins to perform admin functions.
>
>
>
> When performing the last step which is prepare domain for the local
> domain that Exchange will be installed into, we receive the error "User
> not found." I tried to run the application as different privileged
> users. I also tried to run the app in the root domain and had the same
> error, "User not found."
>
>
>
> We found an article that stated that a GC needed to be contacted in the
> root domain, of we needed to prepare the entire forest for Exchange
> which is undesirable. We only want to prepare the local domain where
> Exchange will be installed.
>
>
>
> So... I enable a GC in the root and, behold, it worked.
>
>
>
> Now, for various reasons, our team is mixed in their desire to enable
> GC's in the forest root. If we need to enable one, so be it but we are
> looking for an explanation as to why one is needed in the root when we
> have them in the child. If GC's are supposed to have a subset of
> everything object in the forest and enable Universal group membership
> lookups, why would we need additional GC's in the root?
>
>
>
> Additionally, we have two sites. Each Domain crosses the two sites. So
> to illustrate: AD-Root.v.e and AD.v.e both exist in both sites. If we
> enable only only one GC in the opposite site from us, the application
> still fails with the same error. However if we enable only one GC in our
> site, the application works. So it seems that it does not span sites to
> find a GC either.
>
>
>
> We called our MS rep and he stated that we had a disjointed namespace in
> the design and that we had to enable a GC in the root and that the GC's
> in the child were not sufficient to look up the Universal Group
> Membership. BTW: The Universal group exists in the root with members
> from the child domain.
>
>
>
> So... if a GC, is a GC, is a GC.... Why do we need one in the root
> domain with so many in the child? Why do we need a GC in the same site?
> Is there something I am missing here?
>
>
>
> I did find an blog post by Joe located below, explaining a disjointed
> namespace and it does not seem that MS is telling us the same thing.
>
>
>
> http://blog.joeware.net/2006/07/17/449/
>
>
>
> HELP!!!
>
>
>
>
>
>
--
Sent from my mobile device
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
| michael1
Posts:386
| | 12/05/2008 3:29 PM |
| I've asked TPTB. Perhaps they'll respond as to "why". I dunno.
Regards,
Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP
My blog: http://TheEssentialExchange.com/blogs/michael
I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of James Wells
Sent: Friday, December 05, 2008 2:30 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Disjoint namespace and GC lookups
It's an Exchange 2007 setup thing. I found out that someone had
misconfigured a development forest when I hit the same problem.
Should it be that way? IMHO, no. But that's what setup requires.
On 12/5/08, Britt, Brian <brian.britt@vanderbilt.edu> wrote:
> Joe, or anyone else:
>
>
>
> I have verified that the view of an object against the GC is the same
> from all perspectives. We still do not have a GC in the domain that the
> Schema FSMO resides. I can't figure out why Exchange 2007 setup
> /preparedomain is requiring me to create a GC in both domains.
>
>
>
> Is there some rule that requires a GC in each domain in the forest. I
> have found where we are told to put a GC in each site that Exchange will
> be installed in. I have not been able to determine why a GC needs to be
> in both domains in that site.
>
>
>
> Is there any clarification why setup cannot find what it wants form the
> local domain GC and must look to the root domain GC to complete?
>
>
>
> I am baffled. Based on my tests of the GC looking at member and memberof
> I see the same thing from all perspectives.
>
>
>
> Argh!!!
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
| hcoleman
Posts:104
| | 12/05/2008 3:39 PM |
| This is a guess, but part of /preparedomain needs to modify one of the universal groups in the root domain:
"Creates a new domain global group in the current domain called Exchange Install Domain Servers. The command places this group in the Microsoft Exchange System Objects container. It also adds the Exchange Install Domain Servers group to the Exchange Servers USG in the root domain."
(http://technet.microsoft.com/en-us/library/bb125224.aspx)
So it's going to need to contact a DC in the root domain to make the group membership change. There's no reason that it couldn't do that to a non-GC DC in the root domain, but apparently that's what it wants.
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Friday, December 05, 2008 12:19 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Joe, or anyone else:
I have verified that the view of an object against the GC is the same from all perspectives. We still do not have a GC in the domain that the Schema FSMO resides. I can't figure out why Exchange 2007 setup /preparedomain is requiring me to create a GC in both domains.
Is there some rule that requires a GC in each domain in the forest. I have found where we are told to put a GC in each site that Exchange will be installed in. I have not been able to determine why a GC needs to be in both domains in that site.
Is there any clarification why setup cannot find what it wants form the local domain GC and must look to the root domain GC to complete?
I am baffled. Based on my tests of the GC looking at member and memberof I see the same thing from all perspectives.
Argh!!!
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Wednesday, December 03, 2008 12:07 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Doesn't matter what Exchange is looking for, you aren't going to be able to change the functionality. But likely it determines the local machine's site and then looks at the machines in that site and rates them by the options and other attributes to find what it wants.
Proving that "all GCs are not created equal" for linked attributes is easy.
1. Start with a 2+ domain forest that has GCs in at least 2 of them.
2. Create a user in arbitrarily picked Dom1
3. Create a domain local group in Dom1
4. Add the user to the group created in step 3.
5. Create a domain local group in arbitrarily picked Dom2
6. Add the user to the group created in step 5.
7. Run the following command against a GC in both Dom1 and Dom2
adfind -h GC_NAME -gc -b USER_DN memberof
So like
adfind -h GC-DOM1 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
adfind -h GC-DOM2 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
The first query will show the DN from the DOM1 LG, the second query will show the DN from the DOM2 LG.
joe
--
O'Reilly Active Directory Fourth Edition - http://www.joeware.net/win/ad4e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 4:15 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Joe,
Thanks for your reply. I am still not sure why a GC would need to be in the root domain though.
How would I proof-test the "memberof" from the two perspectives of GC1 and GC2 that you speak about below?
Where in the config container does Exchange look for the GC? I have found sites > Servers > NTDS > Properties > options=0x1 is_GC
What is Exchange looking for?
Brian
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Tuesday, December 02, 2008 10:21 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Your MS Rep is misinformed. Any GC can enumerate the universal groups of the forest.
This is almost certainly related to the fact that Exchange doesn't like to use the standard location services to find DCs/GCs, it reads the config container directly and tries to figure it out on its own. Otherwise any GC that is published in DNS for the site would be used because that is the normal location services mechanism. This has nothing to do with disjoint namespace and even if it did, MSFT needs to fix it because they have stated that disjoint namespaces are fully supported. That was something I had to get clarified with them all the way back in 2000.
Feel free to send my email to your MS Rep.
On the part of a GC is a GC is a GC.... not really. Due to implementation details around linked attributes there are differences between GCs that are DCs of different domains. For example if you have Dom1 and Dom2 and you have GC1Dom1 and GC2Dom2 and you have Dom1\User1 who is in Dom1\LocalGroup1 and Dom2\LocalGroup2, enumeration of Dom1\User1 memberof attribute WILL BE DIFFERENT on GC1Dom1 and GC2Dom2. There are other subtleties there as well. None of which should affect Universal group direct membership though.
--
O'Reilly Active Directory Fourth Edition - http://www.joeware.net/win/ad4e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 11:08 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Disjoint namespace and GC lookups
All,
We have what MS calls a disjointed namespace for our AD environment.
Empty Root Domain - AD-Root.V.E
Resources Domain - AD.V.E
Global catalogs are on all DC's in the child domain.
No GC's in the root.
We are installing Exchange which heavily utilizes Universal groups within the forest for Exchange Admins to perform admin functions.
When performing the last step which is prepare domain for the local domain that Exchange will be installed into, we receive the error "User not found." I tried to run the application as different privileged users. I also tried to run the app in the root domain and had the same error, "User not found."
We found an article that stated that a GC needed to be contacted in the root domain, of we needed to prepare the entire forest for Exchange which is undesirable. We only want to prepare the local domain where Exchange will be installed.
So... I enable a GC in the root and, behold, it worked.
Now, for various reasons, our team is mixed in their desire to enable GC's in the forest root. If we need to enable one, so be it but we are looking for an explanation as to why one is needed in the root when we have them in the child. If GC's are supposed to have a subset of everything object in the forest and enable Universal group membership lookups, why would we need additional GC's in the root?
Additionally, we have two sites. Each Domain crosses the two sites. So to illustrate: AD-Root.v.e and AD.v.e both exist in both sites. If we enable only only one GC in the opposite site from us, the application still fails with the same error. However if we enable only one GC in our site, the application works. So it seems that it does not span sites to find a GC either.
We called our MS rep and he stated that we had a disjointed namespace in the design and that we had to enable a GC in the root and that the GC's in the child were not sufficient to look up the Universal Group Membership. BTW: The Universal group exists in the root with members from the child domain.
So... if a GC, is a GC, is a GC.... Why do we need one in the root domain with so many in the child? Why do we need a GC in the same site? Is there something I am missing here?
I did find an blog post by Joe located below, explaining a disjointed namespace and it does not seem that MS is telling us the same thing.
http://blog.joeware.net/2006/07/17/449/
HELP!!!
| | | |
| listmail
Posts:763
| | 12/05/2008 5:27 PM |
| First off, reread what I said... Doesn't matter what Exchange is looking
for, it wants the specific GC configuration it wants, without it, it won't
work. It isn't based on technical issues but on what the Exchange team did.
Does it make sense? No, but who ever said the Exchange team had to make
sense in the choices they make?
As for the view of an object is the same from all perspectives, it depends
on the object and the linkages to it. There is no guarantee that you will
get an identical view from every GC for every single object. And in fact,
you can be sure there are objects that will have different views depending
on the GC you look at.
joe
--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Friday, December 05, 2008 2:19 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Joe, or anyone else:
I have verified that the view of an object against the GC is the same from
all perspectives. We still do not have a GC in the domain that the Schema
FSMO resides. I can't figure out why Exchange 2007 setup /preparedomain is
requiring me to create a GC in both domains.
Is there some rule that requires a GC in each domain in the forest. I have
found where we are told to put a GC in each site that Exchange will be
installed in. I have not been able to determine why a GC needs to be in both
domains in that site.
Is there any clarification why setup cannot find what it wants form the
local domain GC and must look to the root domain GC to complete?
I am baffled. Based on my tests of the GC looking at member and memberof I
see the same thing from all perspectives.
Argh!!!
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Wednesday, December 03, 2008 12:07 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Doesn't matter what Exchange is looking for, you aren't going to be able to
change the functionality. But likely it determines the local machine's site
and then looks at the machines in that site and rates them by the options
and other attributes to find what it wants.
Proving that "all GCs are not created equal" for linked attributes is easy.
1. Start with a 2+ domain forest that has GCs in at least 2 of them.
2. Create a user in arbitrarily picked Dom1
3. Create a domain local group in Dom1
4. Add the user to the group created in step 3.
5. Create a domain local group in arbitrarily picked Dom2
6. Add the user to the group created in step 5.
7. Run the following command against a GC in both Dom1 and Dom2
adfind -h GC_NAME -gc -b USER_DN memberof
So like
adfind -h GC-DOM1 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
adfind -h GC-DOM2 -gc -b cn=someuser,cn=users,dc=dom1,dc=com memberof
The first query will show the DN from the DOM1 LG, the second query will
show the DN from the DOM2 LG.
joe
--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 4:15 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Joe,
Thanks for your reply. I am still not sure why a GC would need to be in the
root domain though.
How would I proof-test the "memberof" from the two perspectives of GC1 and
GC2 that you speak about below?
Where in the config container does Exchange look for the GC? I have found
sites > Servers > NTDS > Properties > options=0x1 is_GC
What is Exchange looking for?
Brian
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Tuesday, December 02, 2008 10:21 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Disjoint namespace and GC lookups
Your MS Rep is misinformed. Any GC can enumerate the universal groups of the
forest.
This is almost certainly related to the fact that Exchange doesn't like to
use the standard location services to find DCs/GCs, it reads the config
container directly and tries to figure it out on its own. Otherwise any GC
that is published in DNS for the site would be used because that is the
normal location services mechanism. This has nothing to do with disjoint
namespace and even if it did, MSFT needs to fix it because they have stated
that disjoint namespaces are fully supported. That was something I had to
get clarified with them all the way back in 2000.
Feel free to send my email to your MS Rep.
On the part of a GC is a GC is a GC.... not really. Due to implementation
details around linked attributes there are differences between GCs that are
DCs of different domains. For example if you have Dom1 and Dom2 and you have
GC1Dom1 and GC2Dom2 and you have Dom1\User1 who is in Dom1\LocalGroup1 and
Dom2\LocalGroup2, enumeration of Dom1\User1 memberof attribute WILL BE
DIFFERENT on GC1Dom1 and GC2Dom2. There are other subtleties there as well.
None of which should affect Universal group direct membership though.
--
O'Reilly Active Directory Fourth Edition -
<http://www.joeware.net/win/ad4e.htm> http://www.joeware.net/win/ad4e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Britt, Brian
Sent: Tuesday, December 02, 2008 11:08 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Disjoint namespace and GC lookups
All,
We have what MS calls a disjointed namespace for our AD environment.
Empty Root Domain - AD-Root.V.E
Resources Domain - AD.V.E
Global catalogs are on all DC's in the child domain.
No GC's in the root.
We are installing Exchange which heavily utilizes Universal groups within
the forest for Exchange Admins to perform admin functions.
When performing the last step which is prepare domain for the local domain
that Exchange will be installed into, we receive the error "User not found."
I tried to run the application as different privileged users. I also tried
to run the app in the root domain and had the same error, "User not found."
We found an article that stated that a GC needed to be contacted in the root
domain, of we needed to prepare the entire forest for Exchange which is
undesirable. We only want to prepare the local domain where Exchange will be
installed.
So... I enable a GC in the root and, behold, it worked.
Now, for various reasons, our team is mixed in their desire to enable GC's
in the forest root. If we need to enable one, so be it but we are looking
for an explanation as to why one is needed in the root when we have them in
the child. If GC's are supposed to have a subset of everything object in the
forest and enable Universal group membership lookups, why would we need
additional GC's in the root?
Additionally, we have two sites. Each Domain crosses the two sites. So to
illustrate: AD-Root.v.e and AD.v.e both exist in both sites. If we enable
only only one GC in the opposite site from us, the application still fails
with the same error. However if we enable only one GC in our site, the
application works. So it seems that it does not span sites to find a GC
either.
We called our MS rep and he stated that we had a disjointed namespace in the
design and that we had to enable a GC in the root and that the GC's in the
child were not sufficient to look up the Universal Group Membership. BTW:
The Universal group exists in the root with members from the child domain.
So... if a GC, is a GC, is a GC.... Why do we need one in the root domain
with so many in the child? Why do we need a GC in the same site? Is there
something I am missing here?
I did find an blog post by Joe located below, explaining a disjointed
namespace and it does not seem that MS is telling us the same thing.
http://blog.joeware.net/2006/07/17/449/
HELP!!!
| | | |
|
|