Re: Aging with AdamSync.exe

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


The only aging settings I see in the template XML config file are <frequency>
and <num-objects> but in an earlier post you said "if it is time to age that
object" which makes it sound like the XML file should have another setting like
<max-age-for-orphaned-objects> or something. I was assuming that an orphan was
deleted the very first time it was detected as an orphan, could you elaborate on
how adamsync decides "if it is time to age that object"?


"Eric Fleischman [MSFT]" <efleis@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:ulXstM8QGHA.5716@xxxxxxxxxxxxxxxxxxxxxxx
not sure I understand the question?
We age objects based upon the config settings in your XML file. So we age as
you tell us to.


--
Eric Fleischman [MSFT]
Microsoft Windows Server Division
This post is provided "AS IS" with no warranties, and confers no rights



"Steve Lynch" <user@xxxxxxxx> wrote in message
news:uthb2otQGHA.4536@xxxxxxxxxxxxxxxxxxxxxxx

One more question - you said "If you are using aging, and you can't see
objects anymore, and it is time to age that object, we would delete it". So
how does adamsync determine if its time to age the object. If the object is
missing from the source when aging runs, does it get deleted immediately, or
does adamsync wait for some period of time before deleting it?


"Eric Fleischman [MSFT]" <efleis@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23JzonbjQGHA.4384@xxxxxxxxxxxxxxxxxxxxxxx
I'm not aware of any docs, sorry.

I run adamsync every 5mins. Using this service account and no aging
configs, what are the drawbacks of my scenario?

The only drawback of not doing aging that comes to mind would be that if an
object moves out of scope and you never see it, like a deletion when you
don't have perms to see deleted objects, you will not delete the object in
the target. This problem is independent of the frequency at which you run
ADAMSync but rather only because you can't see some objects in the DS. This
is why we built aging. :) So, you can either use aging, or you can guarantee
visibility. You said you have visibility to the whole domain....so that's
fine, so long as we are including deleted objects, and we account for x-dom
moved objects, if that is relevant to you.

Does this mean if for some reason my AD permissions get changed where the
service account can not read the directory that ADAM Sync will delete all
the
objects it cannot see?

This depends. If you are using aging, and you can't see objects anymore, and
it is time to age that object, we would delete it. We don't have more perms,
so we don't know if this was an admin snafu or an actual object deletion or
move. We don't have a choice, we just don't know.
If you are not using aging, then it would never actually see this, and just
move on. HOWEVER, if you lose perms for a while and sync during that window,
you could miss some changes, as they would be out of your view.

Also, is there any performance problems with my scenario?

None that come to mind. DirSync is written to be run frequently with this
sort of incremental sync. A sync with few or no changes is very performant.

~Eric

--
Eric Fleischman [MSFT]
Microsoft Windows Server Division
This post is provided "AS IS" with no warranties, and confers no rights



"Jason Rupard" <JasonRupard@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:CF457B0E-35EB-4399-9F5D-80801537A445@xxxxxxxxxxxxxxxx
Eric, I am using a service account that has read only access to my AD
whole
domain to sync ADAM. You raise some interesting points and I was hoping
you
would elaborate more. Is there documention out there that talks about
these
different scenarios?

I run adamsync every 5mins. Using this service account and no aging
configs, what are the drawbacks of my scenario?

Does this mean if for some reason my AD permissions get changed where the
service account can not read the directory that ADAM Sync will delete all
the
objects it cannot see?

Also, is there any performance problems with my scenario?

Thanks

"Eric Fleischman [MSFT]" wrote:

Correct. If you have some snafu in the source AD....say you accidentally
get
denied perms to everything in the DS.....adamsync will take action in the
target accordingly if aging kicks off. It is not really possible for a
normal user to tell the difference between something that isn't there and
something they can't see. Security, what can you do.

Of course, one workaround is to guarantee visibility. That is, ensure you
have read perms to everything (including the deleted objects container)
and
not use aging at all. Then you only have the x-dom move case to contend
with, which may or may not be a core scenario for you.

~Eric

--
Eric Fleischman [MSFT]
Microsoft Windows Server Division
This post is provided "AS IS" with no warranties, and confers no rights



"Steve Lynch" <user@xxxxxxxx> wrote in message
news:ekEZdilPGHA.2828@xxxxxxxxxxxxxxxxxxxxxxx


Thanks for the explanation.

So that means <num-objects> is not really a "safety" net as much as a
"performance" net? Meaning if <num-objects> is set to 100, then only
100
will get aged on the first run, but the next 100 will get aged on the
next
run, and so on? So it won't really protect the target from unusually
large deletes in the event of a problem with access/permissions to
DirSync
at the source?


"Eric Fleischman [MSFT]" <efleis@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:u6WbIMVPGHA.3528@xxxxxxxxxxxxxxxxxxxxxxx
Thx for the poke Lee.
Answers:

1) This presumes you can see deletes...or more generally, all object
moves. ADAMSync can run in object security mode of DirSync. In fact,
this
is the default. This means, you may see some things but not others. If
you are a normal user, and you can't see deletes, you won't know an obj
was deleted and will not delete it in the target. As such, you need
something like aging. There are other scenarios too (say you are
syncing
OU=foo,dc=domain and only have perms to that OU, and an object is moved
to OU=bar,dc=domain....you can't see the move, but you wish you could,
because you want to delete the object in the target) but deletion is
the
most common one.
2) An object could fall out of scope of your sync (moved to another
container, deleted, etc.) and you will not delete it in the target.
3 & 4) Both of these are more of a perf safety net. The check here is,
we
go to the source and make sure the objects are still there for each
object in the target. It could be expensive, and take a while. So it's
really up to you. :)


--
Eric Fleischman [MSFT]
Microsoft Windows Server Division
This post is provided "AS IS" with no warranties, and confers no rights



"Lee Flight" <lef@xxxxxxxxxxxxxxx> wrote in message
news:uH1PEHVPGHA.1180@xxxxxxxxxxxxxxxxxxxxxxx
Hi

those are great questions, unfortunately I do not think
ADAMSync aging is documented anywhere public.

Hopefully Eric from Microsoft will spot this and answer.

Lee Flight

"Steve Lynch" <user@xxxxxxxx> wrote in message
news:%23GmpvJ$OGHA.964@xxxxxxxxxxxxxxxxxxxxxxx

Would someone explain the Aging feature of AdamSync.exe? Or maybe
just
point me
to some detailed info on the web somewhere? The ADAM documentation
doesn't
explain it at all. I'm not clear on some things, such as:

1. What are some situations when aging is needed? If DirSync is
working then
shouldn't all the deletes in the source get replicated to the target?

2. What can happen if aging never runs?

3. What is a good number for the <frequency> attribute? How would I
know how
many runs should happen before aging is required?

4. What is a good number for the <num-objects> attribute? Is this
just
a
"safety net", in case adamsync.exe tries to delete too many items?


Thanks!




















.

Relevant Pages

  • Re: Aging with AdamSync.exe
    ... domain to sync ADAM. ... Using this service account and no aging ... is there any performance problems with my scenario? ... So it won't really protect the target from unusually ...
    (microsoft.public.windows.server.active_directory)
  • Re: Aging with AdamSync.exe
    ... Those flags *are* the aging criteria. ... you tell us to age. ... Eric Fleischman [MSFT] ... target accordingly if aging kicks off. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Aging with AdamSync.exe
    ... We age objects based upon the config settings in your XML file. ... One more question - you said "If you are using aging, ... service account can not read the directory that ADAM Sync will delete ... target accordingly if aging kicks off. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Aging with AdamSync.exe
    ... One more question - you said "If you are using aging, ... HOWEVER, if you lose perms for a while and sync during that window, ... Eric Fleischman [MSFT] ... target accordingly if aging kicks off. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Aging with AdamSync.exe
    ... denied perms to everything in the DS.....adamsync will take action in the ... target accordingly if aging kicks off. ... Eric Fleischman [MSFT] ... So it won't really protect the target from unusually ...
    (microsoft.public.windows.server.active_directory)