ADAM full sync needed every 30 days??????

kage13

We are running ADAM on W2k3 R2 in a DMZ not joined to the domain. We have it
syncing with one domain controller. Since it was set in place the
incremental synchs (/sync) appear to be failing approx after 30 days from the
full sync.

The incremental sync is set as a scheduled task on the ADAM server. As I
mentioned, it works perfectly after the full sync and continues to work for
another 30 days. But then on day 31, the sync log does not show any new
data, on the same data from the last successful sync.

Its weird. Are we suppose to do a full sync every 30 days or should the
initial full sync be the only one and the incremental sync work there after?

Any ideas?

TIA.

Lee Flight

Hi

what sync mechanism are you using, ADAMSync? What command do you run for the
incremental? Does it sync if you run it outside of task scheduler?

Lee Flight

"kage13" <kage13@discussions.microsoft.com> wrote in message
news:4B3AC1C7-47EE-4785-A100-578B994E5A8C@microsoft.com...
> We are running ADAM on W2k3 R2 in a DMZ not joined to the domain. We have
> it
> syncing with one domain controller. Since it was set in place the
> incremental synchs (/sync) appear to be failing approx after 30 days from
> the
> full sync.
>
> The incremental sync is set as a scheduled task on the ADAM server. As I
> mentioned, it works perfectly after the full sync and continues to work
> for
> another 30 days. But then on day 31, the sync log does not show any new
> data, on the same data from the last successful sync.
>
> Its weird. Are we suppose to do a full sync every 30 days or should the
> initial full sync be the only one and the incremental sync work there
> after?
>
> Any ideas?
>
> TIA.

kage13

Thanks for the reply Lee. We are using ADAMsync to sync. The scheduled task
runs once an hour from 530am to 730pm M-F and is: adamsync /sync
localhost:389 "dc=domain,dc=com) /log sync_log.log

As I mentioned below, when the 31 first day is reached, the sync log does
not contain any new data, just keeps re-writing the data from the last
successful sync.

When I tried to do the manual sync this morning, I got "LDAP error
occurred." when I specified: adamsync /sync <adamserver>:389
"dc=domain,dc=com"

Next I tried using localhost and got some message about the active ADAM
instance is running on <adamserver>.

So I tried to bind using lap and could not bind, even though the account we
use to bind with is set to not expire or lock
(msds-user-account-control-computed:66048).

The weird thing is I was able to do a manual full sync without any issues.
Once that completed I changed a sync'd attribute on my account, waited for
the scheduled incremental sync to happen and it pulled it across fine.
Before the full sync, we had numerous new accounts that we created in AD and
did not sync'd until the full sync.

"Lee Flight" wrote:

> Hi
>
> what sync mechanism are you using, ADAMSync? What command do you run for the
> incremental? Does it sync if you run it outside of task scheduler?
>
> Lee Flight
>
> "kage13" <kage13@discussions.microsoft.com> wrote in message
> news:4B3AC1C7-47EE-4785-A100-578B994E5A8C@microsoft.com...
> > We are running ADAM on W2k3 R2 in a DMZ not joined to the domain. We have
> > it
> > syncing with one domain controller. Since it was set in place the
> > incremental synchs (/sync) appear to be failing approx after 30 days from
> > the
> > full sync.
> >
> > The incremental sync is set as a scheduled task on the ADAM server. As I
> > mentioned, it works perfectly after the full sync and continues to work
> > for
> > another 30 days. But then on day 31, the sync log does not show any new
> > data, on the same data from the last successful sync.
> >
> > Its weird. Are we suppose to do a full sync every 30 days or should the
> > initial full sync be the only one and the incremental sync work there
> > after?
> >
> > Any ideas?
> >
> > TIA.
>
>
>

Lee Flight

Hi

sorry for the delay, more inline below...

"kage13" <kage13@discussions.microsoft.com> wrote in message
news:13D7859F-CA8A-4C0B-8B0D-2DB350C29F49@microsoft.com...
> Thanks for the reply Lee. We are using ADAMsync to sync. The scheduled
> task
> runs once an hour from 530am to 730pm M-F and is: adamsync /sync
> localhost:389 "dc=domain,dc=com) /log sync_log.log
>
> As I mentioned below, when the 31 first day is reached, the sync log does
> not contain any new data, just keeps re-writing the data from the last
> successful sync.
>
> When I tried to do the manual sync this morning, I got "LDAP error
> occurred." when I specified: adamsync /sync <adamserver>:389
> "dc=domain,dc=com"

Do you get any (fuller) error if you run with /log. Also is there anything
in the ADAM instance event log when this error occurs?
You could also try running adamsync /ces <adamserver>:389 to see if there is
an error message recorded.

> Next I tried using localhost and got some message about the active ADAM
> instance is running on <adamserver>.

Would be good to see the exact message again with any corresponding event
log
messages

> So I tried to bind using lap and could not bind, even though the account
> we
> use to bind with is set to not expire or lock
> (msds-user-account-control-computed:66048).

Is that userAccountControl or msds-user-account-control-computed, they are
not quite the same IIRC I think you can have userAccountControl of 66048
but the account locked as shown by msds-user-account-control-computed (this
covers lockout and expiry)

http://support.microsoft.com/kb/305144

With account logon (success/failure) audit on the server and your DC (this
is a windows domain account?) checking the local and DC security event logs
when stuck in failure mode might give a clue.

> The weird thing is I was able to do a manual full sync without any issues.
> Once that completed I changed a sync'd attribute on my account, waited for
> the scheduled incremental sync to happen and it pulled it across fine.
> Before the full sync, we had numerous new accounts that we created in AD
> and
> did not sync'd until the full sync.

This is weird, did you re-enter the account password when performing the
full sync?
Basically full sync resets the DirSync cookie in the ADAMSync configuration
that is stored in the ADAM instance and then just runs the sync....Is there
anything in the security event logs (ADAM server and DC) to indicate the
success of the authentication associated with the full sync?

I think to debug this would require active review of the event logs for
Application, ADAM instance and Security on the ADAM server as well as review
of the security log on your DCs to check for account status events, kerberos
ticket expiry etc. as first pass. Depending on you available effort it
might be that you just choose to schedule a full sync for every 30 days and
live with the "issue".

Thanks
Lee Flight

kage13

Lee,

Here are the results of what you suggested and the exact error message
received when using the adamsync command:

C:\WINDOWS\ADAM>adamsync /sync localhost:389 "dc=domain,dc=com"
Warning: The current authoritative ADAM instance is <adamserver>:389.
Ldap error occured.
C:\WINDOWS\ADAM>adamsync /sync <adamserver>:389 "dc=domain,dc=com"
Ldap error occured.
C:\WINDOWS\ADAM>adamsync /ces <adamserver>:389
Listing configuration files:
---------------------------
Last Sync Attempt Time: 20080320125740.0Z
Last Sync Success Time: 20080320125753.0Z
Last Sync Error Time: 20080320125753.0Z
Last Sync Error String: Ldap error occured. Done.

As you can see not much to go on. Also, the event logs do not show anything
at all, nada. No errors, no warning, etc. In fact, the last entry in the
ADAM log was from last night listing the online defrag information entry.

When I mentioned the account status, it is the
msds-user-account-control-computed attribute. This is set to not expire or
lock since it is the 'bind' account used for the sync's. This account also
is not a member of the domain, nor is the adam server.

With regards to the full sync, I did not use passprompt, merely swapped
/sync with /fs and away it went successfully.

Any attempt to manually initiate an incremental (/sync) sync err's. THe
scheduled task keeps coming back with a Result of 0x0, indicating that it ran
successfully, whether it does or not.

I'm at a loss right now.

"Lee Flight" wrote:

> Hi
>
> sorry for the delay, more inline below...
>
> "kage13" <kage13@discussions.microsoft.com> wrote in message
> news:13D7859F-CA8A-4C0B-8B0D-2DB350C29F49@microsoft.com...
> > Thanks for the reply Lee. We are using ADAMsync to sync. The scheduled
> > task
> > runs once an hour from 530am to 730pm M-F and is: adamsync /sync
> > localhost:389 "dc=domain,dc=com) /log sync_log.log
> >
> > As I mentioned below, when the 31 first day is reached, the sync log does
> > not contain any new data, just keeps re-writing the data from the last
> > successful sync.
> >
> > When I tried to do the manual sync this morning, I got "LDAP error
> > occurred." when I specified: adamsync /sync <adamserver>:389
> > "dc=domain,dc=com"
>
> Do you get any (fuller) error if you run with /log. Also is there anything
> in the ADAM instance event log when this error occurs?
> You could also try running adamsync /ces <adamserver>:389 to see if there is
> an error message recorded.
>
> > Next I tried using localhost and got some message about the active ADAM
> > instance is running on <adamserver>.
>
> Would be good to see the exact message again with any corresponding event
> log
> messages
>
> > So I tried to bind using lap and could not bind, even though the account
> > we
> > use to bind with is set to not expire or lock
> > (msds-user-account-control-computed:66048).
>
> Is that userAccountControl or msds-user-account-control-computed, they are
> not quite the same IIRC I think you can have userAccountControl of 66048
> but the account locked as shown by msds-user-account-control-computed (this
> covers lockout and expiry)
>
> http://support.microsoft.com/kb/305144
>
> With account logon (success/failure) audit on the server and your DC (this
> is a windows domain account?) checking the local and DC security event logs
> when stuck in failure mode might give a clue.
>
> > The weird thing is I was able to do a manual full sync without any issues.
> > Once that completed I changed a sync'd attribute on my account, waited for
> > the scheduled incremental sync to happen and it pulled it across fine.
> > Before the full sync, we had numerous new accounts that we created in AD
> > and
> > did not sync'd until the full sync.
>
> This is weird, did you re-enter the account password when performing the
> full sync?
> Basically full sync resets the DirSync cookie in the ADAMSync configuration
> that is stored in the ADAM instance and then just runs the sync....Is there
> anything in the security event logs (ADAM server and DC) to indicate the
> success of the authentication associated with the full sync?
>
> I think to debug this would require active review of the event logs for
> Application, ADAM instance and Security on the ADAM server as well as review
> of the security log on your DCs to check for account status events, kerberos
> ticket expiry etc. as first pass. Depending on you available effort it
> might be that you just choose to schedule a full sync for every 30 days and
> live with the "issue".
>
> Thanks
> Lee Flight
>
>
>

Lee Flight

Hi

so the /sync works OK after you have performed a full sync?
More inline below...


"kage13" <kage13@discussions.microsoft.com> wrote in message
news:B8836919-1066-4424-ADAC-BBE2CAE05CC0@microsoft.com...

> C:\WINDOWS\ADAM>adamsync /sync localhost:389 "dc=domain,dc=com"
> Warning: The current authoritative ADAM instance is <adamserver>:389.

That warning is likely because your ADAM instance is a member of a
configuration (replica) set, the recommendation is always to sync to the
same ADAM instance.

> Ldap error occured.
> C:\WINDOWS\ADAM>adamsync /sync <adamserver>:389 "dc=domain,dc=com"
> Ldap error occured.
> C:\WINDOWS\ADAM>adamsync /ces <adamserver>:389
> Listing configuration files:
> ---------------------------
> Last Sync Attempt Time: 20080320125740.0Z
> Last Sync Success Time: 20080320125753.0Z
> Last Sync Error Time: 20080320125753.0Z
> Last Sync Error String: Ldap error occured. Done.

If you are in a position where the /sync fails perhaps you could try bumping
diagnostics on the ADAM instance...
Assuming that your ADAM instance has service name ADAM_instance1 then
under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\ADAM_instance1\Diagnos*tics

Edit the value
16 LDAP Interface Events
and set it to 5

and then run the /sync. Check ADAM instance event log for errors.
*Remember* to reset the registry value to 0 when done.

> When I mentioned the account status, it is the
> msds-user-account-control-computed attribute. This is set to not expire
> or
> lock since it is the 'bind' account used for the sync's. This account
> also
> is not a member of the domain, nor is the adam server.

So this is a standalone ADAM server? Presumably the sync has stored
credentials
for an account that has access to your AD? The account that you run the
scheduled task
with is a windows account local to the ADAM server that has Admin rights on
the ADAM instance?

> With regards to the full sync, I did not use passprompt, merely swapped
> /sync with /fs and away it went successfully.

Very odd maybe it's a bug with the cookie mechanism but it's hard for me to
join that with the 30 day window.

Lee Flight

kage13

Hi Lee,

Answers in order:

> so the /sync works OK after you have performed a full sync?
Only when it set as a scheduled task does it work. Manually, it err's out
as mentioned below.

> So this is a standalone ADAM server?
Yes, in the DMZ, not part of the domain.

>Presumably the sync has stored credentials for an account that has access to your AD? Yes, the 'eve' account has one way access to the DC in the domain to initialize a sync.

>The account that you run the scheduled task with is a windows account local to >the ADAM server that has Admin rights on the ADAM instance?
Yes, the local admin account is running the scheduled task.

I'll bump up the diag loggin level and see if anything pops up.

Thanks,

Ken



"Lee Flight" wrote:

> Hi
>
> so the /sync works OK after you have performed a full sync?
> More inline below...
>
>
> "kage13" <kage13@discussions.microsoft.com> wrote in message
> news:B8836919-1066-4424-ADAC-BBE2CAE05CC0@microsoft.com...
>
> > C:\WINDOWS\ADAM>adamsync /sync localhost:389 "dc=domain,dc=com"
> > Warning: The current authoritative ADAM instance is <adamserver>:389.
>
> That warning is likely because your ADAM instance is a member of a
> configuration (replica) set, the recommendation is always to sync to the
> same ADAM instance.
>
> > Ldap error occured.
> > C:\WINDOWS\ADAM>adamsync /sync <adamserver>:389 "dc=domain,dc=com"
> > Ldap error occured.
> > C:\WINDOWS\ADAM>adamsync /ces <adamserver>:389
> > Listing configuration files:
> > ---------------------------
> > Last Sync Attempt Time: 20080320125740.0Z
> > Last Sync Success Time: 20080320125753.0Z
> > Last Sync Error Time: 20080320125753.0Z
> > Last Sync Error String: Ldap error occured. Done.
>
> If you are in a position where the /sync fails perhaps you could try bumping
> diagnostics on the ADAM instance...
> Assuming that your ADAM instance has service name ADAM_instance1 then
> under:
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\ADAM_instance1\DiagnosÂ*tics
>
> Edit the value
> 16 LDAP Interface Events
> and set it to 5
>
> and then run the /sync. Check ADAM instance event log for errors.
> *Remember* to reset the registry value to 0 when done.
>
> > When I mentioned the account status, it is the
> > msds-user-account-control-computed attribute. This is set to not expire
> > or
> > lock since it is the 'bind' account used for the sync's. This account
> > also
> > is not a member of the domain, nor is the adam server.
>
> So this is a standalone ADAM server? Presumably the sync has stored
> credentials
> for an account that has access to your AD? The account that you run the
> scheduled task
> with is a windows account local to the ADAM server that has Admin rights on
> the ADAM instance?
>
> > With regards to the full sync, I did not use passprompt, merely swapped
> > /sync with /fs and away it went successfully.
>
> Very odd maybe it's a bug with the cookie mechanism but it's hard for me to
> join that with the 30 day window.
>
> Lee Flight
>
>
>

kage13

Lee,

After turning up the diag logging, all the events listed were wither 1138 or
1139, stating that an ldap_search was entered and ended.
However, I did find one different event that still came across as an
Informative entry:
Event Type: Information
Event Source: ADAM [name] LDAP
Event Category: LDAP Interface
Event ID: 1535
Date: 3/20/2008
Time: 11:27:22 AM
User: <adamserver>\Administrator
Computer: <adamserver>
Description:
Internal event: The LDAP server returned an error.

Additional Data
Error value:
00002089: UpdErr: DSID-031B0CBD, problem 5012 (DIR_ERROR), data 2

Other than this, I got nothing.


"Lee Flight" wrote:

> Hi
>
> so the /sync works OK after you have performed a full sync?
> More inline below...
>
>
> "kage13" <kage13@discussions.microsoft.com> wrote in message
> news:B8836919-1066-4424-ADAC-BBE2CAE05CC0@microsoft.com...
>
> > C:\WINDOWS\ADAM>adamsync /sync localhost:389 "dc=domain,dc=com"
> > Warning: The current authoritative ADAM instance is <adamserver>:389.
>
> That warning is likely because your ADAM instance is a member of a
> configuration (replica) set, the recommendation is always to sync to the
> same ADAM instance.
>
> > Ldap error occured.
> > C:\WINDOWS\ADAM>adamsync /sync <adamserver>:389 "dc=domain,dc=com"
> > Ldap error occured.
> > C:\WINDOWS\ADAM>adamsync /ces <adamserver>:389
> > Listing configuration files:
> > ---------------------------
> > Last Sync Attempt Time: 20080320125740.0Z
> > Last Sync Success Time: 20080320125753.0Z
> > Last Sync Error Time: 20080320125753.0Z
> > Last Sync Error String: Ldap error occured. Done.
>
> If you are in a position where the /sync fails perhaps you could try bumping
> diagnostics on the ADAM instance...
> Assuming that your ADAM instance has service name ADAM_instance1 then
> under:
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\ADAM_instance1\DiagnosÂ*tics
>
> Edit the value
> 16 LDAP Interface Events
> and set it to 5
>
> and then run the /sync. Check ADAM instance event log for errors.
> *Remember* to reset the registry value to 0 when done.
>
> > When I mentioned the account status, it is the
> > msds-user-account-control-computed attribute. This is set to not expire
> > or
> > lock since it is the 'bind' account used for the sync's. This account
> > also
> > is not a member of the domain, nor is the adam server.
>
> So this is a standalone ADAM server? Presumably the sync has stored
> credentials
> for an account that has access to your AD? The account that you run the
> scheduled task
> with is a windows account local to the ADAM server that has Admin rights on
> the ADAM instance?
>
> > With regards to the full sync, I did not use passprompt, merely swapped
> > /sync with /fs and away it went successfully.
>
> Very odd maybe it's a bug with the cookie mechanism but it's hard for me to
> join that with the 30 day window.
>
> Lee Flight
>
>
>

Lee Flight

Hi

could you also add audit of logon failures to the local security policy on
the ADAM server if you do not have this on by default?

Thanks
Lee Flight

"kage13" <kage13@discussions.microsoft.com> wrote in message
news:F7C1D227-D7E5-4276-954F-663213D95309@microsoft.com...
> Hi Lee,
>
> Answers in order:
>
>> so the /sync works OK after you have performed a full sync?
> Only when it set as a scheduled task does it work. Manually, it err's out
> as mentioned below.
>
>> So this is a standalone ADAM server?
> Yes, in the DMZ, not part of the domain.
>
>>Presumably the sync has stored credentials for an account that has access
>>to your AD? Yes, the 'eve' account has one way access to the DC in the
>>domain to initialize a sync.
>
>>The account that you run the scheduled task with is a windows account
>>local to >the ADAM server that has Admin rights on the ADAM instance?
> Yes, the local admin account is running the scheduled task.
>
> I'll bump up the diag loggin level and see if anything pops up.
>
> Thanks,
>
> Ken
>
>
>
> "Lee Flight" wrote:
>
>> Hi
>>
>> so the /sync works OK after you have performed a full sync?
>> More inline below...
>>
>>
>> "kage13" <kage13@discussions.microsoft.com> wrote in message
>> news:B8836919-1066-4424-ADAC-BBE2CAE05CC0@microsoft.com...
>>
>> > C:\WINDOWS\ADAM>adamsync /sync localhost:389 "dc=domain,dc=com"
>> > Warning: The current authoritative ADAM instance is <adamserver>:389.
>>
>> That warning is likely because your ADAM instance is a member of a
>> configuration (replica) set, the recommendation is always to sync to the
>> same ADAM instance.
>>
>> > Ldap error occured.
>> > C:\WINDOWS\ADAM>adamsync /sync <adamserver>:389 "dc=domain,dc=com"
>> > Ldap error occured.
>> > C:\WINDOWS\ADAM>adamsync /ces <adamserver>:389
>> > Listing configuration files:
>> > ---------------------------
>> > Last Sync Attempt Time: 20080320125740.0Z
>> > Last Sync Success Time: 20080320125753.0Z
>> > Last Sync Error Time: 20080320125753.0Z
>> > Last Sync Error String: Ldap error occured. Done.
>>
>> If you are in a position where the /sync fails perhaps you could try
>> bumping
>> diagnostics on the ADAM instance...
>> Assuming that your ADAM instance has service name ADAM_instance1 then
>> under:
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\ADAM_instance1\Diagnos*tics
>>
>> Edit the value
>> 16 LDAP Interface Events
>> and set it to 5
>>
>> and then run the /sync. Check ADAM instance event log for errors.
>> *Remember* to reset the registry value to 0 when done.
>>
>> > When I mentioned the account status, it is the
>> > msds-user-account-control-computed attribute. This is set to not
>> > expire
>> > or
>> > lock since it is the 'bind' account used for the sync's. This account
>> > also
>> > is not a member of the domain, nor is the adam server.
>>
>> So this is a standalone ADAM server? Presumably the sync has stored
>> credentials
>> for an account that has access to your AD? The account that you run the
>> scheduled task
>> with is a windows account local to the ADAM server that has Admin rights
>> on
>> the ADAM instance?
>>
>> > With regards to the full sync, I did not use passprompt, merely swapped
>> > /sync with /fs and away it went successfully.
>>
>> Very odd maybe it's a bug with the cookie mechanism but it's hard for me
>> to
>> join that with the 30 day window.
>>
>> Lee Flight
>>
>>
>>

Lee Flight

Hi

do you get one of those errors per manual sync attempt?

Thanks
Lee Flight

"kage13" <kage13@discussions.microsoft.com> wrote in message
news:288DFA17-F0D6-4417-92F1-A1C573BC6759@microsoft.com...
> Lee,
>
> After turning up the diag logging, all the events listed were wither 1138
> or
> 1139, stating that an ldap_search was entered and ended.
> However, I did find one different event that still came across as an
> Informative entry:
> Event Type: Information
> Event Source: ADAM [name] LDAP
> Event Category: LDAP Interface
> Event ID: 1535
> Date: 3/20/2008
> Time: 11:27:22 AM
> User: <adamserver>\Administrator
> Computer: <adamserver>
> Description:
> Internal event: The LDAP server returned an error.
>
> Additional Data
> Error value:
> 00002089: UpdErr: DSID-031B0CBD, problem 5012 (DIR_ERROR), data 2
>
> Other than this, I got nothing.
>
>
> "Lee Flight" wrote:
>
>> Hi
>>
>> so the /sync works OK after you have performed a full sync?
>> More inline below...
>>
>>
>> "kage13" <kage13@discussions.microsoft.com> wrote in message
>> news:B8836919-1066-4424-ADAC-BBE2CAE05CC0@microsoft.com...
>>
>> > C:\WINDOWS\ADAM>adamsync /sync localhost:389 "dc=domain,dc=com"
>> > Warning: The current authoritative ADAM instance is <adamserver>:389.
>>
>> That warning is likely because your ADAM instance is a member of a
>> configuration (replica) set, the recommendation is always to sync to the
>> same ADAM instance.
>>
>> > Ldap error occured.
>> > C:\WINDOWS\ADAM>adamsync /sync <adamserver>:389 "dc=domain,dc=com"
>> > Ldap error occured.
>> > C:\WINDOWS\ADAM>adamsync /ces <adamserver>:389
>> > Listing configuration files:
>> > ---------------------------
>> > Last Sync Attempt Time: 20080320125740.0Z
>> > Last Sync Success Time: 20080320125753.0Z
>> > Last Sync Error Time: 20080320125753.0Z
>> > Last Sync Error String: Ldap error occured. Done.
>>
>> If you are in a position where the /sync fails perhaps you could try
>> bumping
>> diagnostics on the ADAM instance...
>> Assuming that your ADAM instance has service name ADAM_instance1 then
>> under:
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\ADAM_instance1\Diagnos*tics
>>
>> Edit the value
>> 16 LDAP Interface Events
>> and set it to 5
>>
>> and then run the /sync. Check ADAM instance event log for errors.
>> *Remember* to reset the registry value to 0 when done.
>>
>> > When I mentioned the account status, it is the
>> > msds-user-account-control-computed attribute. This is set to not
>> > expire
>> > or
>> > lock since it is the 'bind' account used for the sync's. This account
>> > also
>> > is not a member of the domain, nor is the adam server.
>>
>> So this is a standalone ADAM server? Presumably the sync has stored
>> credentials
>> for an account that has access to your AD? The account that you run the
>> scheduled task
>> with is a windows account local to the ADAM server that has Admin rights
>> on
>> the ADAM instance?
>>
>> > With regards to the full sync, I did not use passprompt, merely swapped
>> > /sync with /fs and away it went successfully.
>>
>> Very odd maybe it's a bug with the cookie mechanism but it's hard for me
>> to
>> join that with the 30 day window.
>>
>> Lee Flight
>>
>>
>>