As far as I can remember this has always occured. I used dnn 3.x at another site. I was dissappointed to see this is still happening here. (Though if you arent looking for it you dont know it happens) And unless you logout to log in as an admin, you wouldn't that I can think of

Thanks.  In the mean time, I've gone down the route of checking last action date and removing users who haven't touched the system in 6 months.  Unfortunately, there doesn't seem to be any code in the strict Network/AD loggin path that updates the last logged in time / last action date fields in the membership tables.  So I've added that functionality to the AddLog stored proc (figuring no matter what login path they take, they will get logged).  So now I am back to waiting for it to run its course so I can see who hasn't actually logged in....

If you do figure out how to get AD to work through the scheduled tasks, I am still interrested.  There seemed to be too much reliance on portal information being loaded in cache for it to work simply.

mikeh or 1-0-1, have you had a chance to look into the scheduled task further? It is something I'm going to have to dig into. I was thinking that maybe I could write a job that bypasses DNN altogether, just write a vb program that deals directly with the DNN tables, instead of going through the API's. Granted, I haven't done hardly any coding in DNN, or any coding with AD, so I'm flying blind. But it seems that the only table that would have to be updated is the UserRole table.  Hmmmm, well actually, that would be only synchronizing the roles, but that is the part that is the most important for me, at least for the time being.

Any thoughts on whether that would work?