Isolating ADAM from AD

Hi,

I'm trying to use ADAM as a development/testing environment. I exported the
AD schema, then objects, using ADSchemaAnalyzer followed by ldifde. Now when
I run my application against the ADAM instance (on my local computer, Windows
XP Pro) and change a property, the real AD is updated with the same change.
Is there a way I can disconnect these? Thanks,

Robert

Lee
Tue May 06 11:22:35 PDT 2008

Hi

ADAM and AD are disjoint, they do not inter-replicate.
One possible explanation is that your application is actually
targetting AD rather than ADAM this can happen in test dev
if you are logged into the client machine with domain credentials
sufficient to modify AD and you get the LDAP target wrong.

Add some debug code to your application to confirm what you
are connecting to, read dnsHostName from rootDSE of the
ADAM instance or check that supportedCapabilities on rootDSE
contains ACTIVE_DIRECTORY_ADAM oid. A network sniff
should reveal what going on.

Lee Flight

"Robert S" <Robert S@discussions.microsoft.com> wrote in message
news:1A9B2F9D-6CBA-477C-B28D-138E1D0528EF@microsoft.com...
> Hi,
>
> I'm trying to use ADAM as a development/testing environment. I exported
> the
> AD schema, then objects, using ADSchemaAnalyzer followed by ldifde. Now
> when
> I run my application against the ADAM instance (on my local computer,
> Windows
> XP Pro) and change a property, the real AD is updated with the same
> change.
> Is there a way I can disconnect these? Thanks,
>
> Robert
>

RobertS
Tue May 06 17:36:02 PDT 2008

I tested what you recommended, and it all looked okay, and then I noticed
that even through the ADSI Edit tool, I had the same issue. I was only
connected to my local instance, but updates were occurring on the domain
controller. It was like the objects were accessible through my ADAM instance,
but really pointing to the AD I exported them from. (Maybe this is from
referrals? I'm not sure how that works.)

Anyway, I created a new ADAM instance, NOT with the same name
(DC=adam,DC=com instead of DC=company,DC=com - I read online somewhere that's
keeping the same name is a good idea, but I'm not sure about that now). I
re-imported the schema diff, and re-exported and re-imported the objects
using the ldifde "-c" switch to change the FromDN/ToDN. The local data
directory for the new instance is about 4x larger than the original instance,
and updates now stay local. I'm sure now I just did something wrong in the
original import. (In fact, I recall that ldifde reported "0 entries modified"
the first time, even though ADSI Edit showed new objects...this time I saw
non-zero numbers here). Weird. Thanks for the pointers,

Robert

"Lee Flight" wrote:

> Hi
>
> ADAM and AD are disjoint, they do not inter-replicate.
> One possible explanation is that your application is actually
> targetting AD rather than ADAM this can happen in test dev
> if you are logged into the client machine with domain credentials
> sufficient to modify AD and you get the LDAP target wrong.
>
> Add some debug code to your application to confirm what you
> are connecting to, read dnsHostName from rootDSE of the
> ADAM instance or check that supportedCapabilities on rootDSE
> contains ACTIVE_DIRECTORY_ADAM oid. A network sniff
> should reveal what going on.
>
> Lee Flight
>

Lee
Wed May 07 01:13:02 PDT 2008

Hi

ADSIEdit does chase referrals, often a source of confusion with
configuration
sets that are not fully synchronized; it's possible that your empty ADAM may
have genereated a referral that resolved back to the domainDNS partition of
your AD. Take care when using accounts that have write permission on your
AD...

Lee Flight

"Robert S" <RobertS@discussions.microsoft.com> wrote in message
news:27269B04-512B-4F47-BD1F-145BADE52001@microsoft.com...
>I tested what you recommended, and it all looked okay, and then I noticed
> that even through the ADSI Edit tool, I had the same issue. I was only
> connected to my local instance, but updates were occurring on the domain
> controller. It was like the objects were accessible through my ADAM
> instance,
> but really pointing to the AD I exported them from. (Maybe this is from
> referrals? I'm not sure how that works.)
>
> Anyway, I created a new ADAM instance, NOT with the same name
> (DC=adam,DC=com instead of DC=company,DC=com - I read online somewhere
> that's
> keeping the same name is a good idea, but I'm not sure about that now). I
> re-imported the schema diff, and re-exported and re-imported the objects
> using the ldifde "-c" switch to change the FromDN/ToDN. The local data
> directory for the new instance is about 4x larger than the original
> instance,
> and updates now stay local. I'm sure now I just did something wrong in the
> original import. (In fact, I recall that ldifde reported "0 entries
> modified"
> the first time, even though ADSI Edit showed new objects...this time I saw
> non-zero numbers here). Weird. Thanks for the pointers,
>
> Robert
>
> "Lee Flight" wrote:
>
>> Hi
>>
>> ADAM and AD are disjoint, they do not inter-replicate.
>> One possible explanation is that your application is actually
>> targetting AD rather than ADAM this can happen in test dev
>> if you are logged into the client machine with domain credentials
>> sufficient to modify AD and you get the LDAP target wrong.
>>
>> Add some debug code to your application to confirm what you
>> are connecting to, read dnsHostName from rootDSE of the
>> ADAM instance or check that supportedCapabilities on rootDSE
>> contains ACTIVE_DIRECTORY_ADAM oid. A network sniff
>> should reveal what going on.
>>
>> Lee Flight
>>
>

Dmitri
Wed May 07 06:51:07 PDT 2008

FWIW, referral chasing is disabled in w2k8 version of ADSIEdit.

--
Dmitri Gavrilov
SDE, Exchange

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Lee Flight" <lef@le.ac.uk-nospam> wrote in message
news:%23l2mtoBsIHA.2492@TK2MSFTNGP06.phx.gbl...
> Hi
>
> ADSIEdit does chase referrals, often a source of confusion with
> configuration
> sets that are not fully synchronized; it's possible that your empty ADAM
> may
> have genereated a referral that resolved back to the domainDNS partition
> of
> your AD. Take care when using accounts that have write permission on your
> AD...
>
> Lee Flight
>
> "Robert S" <RobertS@discussions.microsoft.com> wrote in message
> news:27269B04-512B-4F47-BD1F-145BADE52001@microsoft.com...
>>I tested what you recommended, and it all looked okay, and then I noticed
>> that even through the ADSI Edit tool, I had the same issue. I was only
>> connected to my local instance, but updates were occurring on the domain
>> controller. It was like the objects were accessible through my ADAM
>> instance,
>> but really pointing to the AD I exported them from. (Maybe this is from
>> referrals? I'm not sure how that works.)
>>
>> Anyway, I created a new ADAM instance, NOT with the same name
>> (DC=adam,DC=com instead of DC=company,DC=com - I read online somewhere
>> that's
>> keeping the same name is a good idea, but I'm not sure about that now). I
>> re-imported the schema diff, and re-exported and re-imported the objects
>> using the ldifde "-c" switch to change the FromDN/ToDN. The local data
>> directory for the new instance is about 4x larger than the original
>> instance,
>> and updates now stay local. I'm sure now I just did something wrong in
>> the
>> original import. (In fact, I recall that ldifde reported "0 entries
>> modified"
>> the first time, even though ADSI Edit showed new objects...this time I
>> saw
>> non-zero numbers here). Weird. Thanks for the pointers,
>>
>> Robert
>>
>> "Lee Flight" wrote:
>>
>>> Hi
>>>
>>> ADAM and AD are disjoint, they do not inter-replicate.
>>> One possible explanation is that your application is actually
>>> targetting AD rather than ADAM this can happen in test dev
>>> if you are logged into the client machine with domain credentials
>>> sufficient to modify AD and you get the LDAP target wrong.
>>>
>>> Add some debug code to your application to confirm what you
>>> are connecting to, read dnsHostName from rootDSE of the
>>> ADAM instance or check that supportedCapabilities on rootDSE
>>> contains ACTIVE_DIRECTORY_ADAM oid. A network sniff
>>> should reveal what going on.
>>>
>>> Lee Flight
>>>
>>
>
>