I found sometimes what will happen (in RC0) is I execute a password reset, the process completes correct (or at least appears to) and I'm getting an glitch.It "Resets" the password to a random password and doesn't unlock the account.But on the plus side I do have the ability to register as long as the Client software is installed on the system in question. It will restart and run the registration wizard properly and ask questions.Still have the firewall disabled on the server. Working on that one still. Yes. Exceptions for WMI, 526 TCP and 527 TCP inbound are both set in the firewall:)SeanComputers are cool. I just can't hold myself back.

>>It "Resets" the password to a random password and doesn't unlock the account. define unlock? >> It will restart and run the registration wizard properly and ask questions. it will restart?? if u don't have the password to logon, how can you register? and for firewall issue, would appreciate if you can put it in a separate thread. there are some tools to troubleshot such networking issues and others might be able to help you better. Also, are the server and client machines in the same subnet? the firewall rule default to allow connections from same subnet. :)

Yeah the Self Service Password Reset (SSPR) only resets passwords, it doesn't perform account unlocks. Choices to mitigate this are as follows. Educate the users to reset their passwords instead of slinging loads of incorrect passwords at the DC when they evidently cannot remember their password. Implement a timed unlock, e.g. lock out for 30 minutes. Increase the lockout threshold (I believe we recommend 50 these days). Write a custom activity that unlocks accounts. Add this to the password reset workflow so that it runs after the password reset. The activity can check the account in question and unlock if it's locked. To unlock a user you modify lockoutTime attribute to zero. You can verify the status using userAccountControl. It's the fifth bit (0x10). Can't remember if you can unlock by XOR'ing 0x10. IIRC there's some funnies with ADS_UF_LOCKOUT using ADSI which is why people prefer lockoutTime but it's been a while and I can't remember so I could be talking rubbish...

i believe it does unlock the a/c in AD. Do you see otherwise?

I found it DID do the unlock.What I'm noticing is occasionally it "goes through the motions" of the unlock process (prompts, accepts, resets P/W) but at the end it is NOT the password I reset it to. And if the account WAS locked out it still is.This isn't typical but say 2 times out of 7?So you'll have this scenarioUser is NOT locked out and successfully resets password anyhow and gets inUser IS locked out and successfully resets password, unlocks self and gets inand sometimesUser is/ is not locked, successfully resets password but cannot login with new password at any workstation.If I go back much later and try the reset process again, it does go through with the new password.Maybe it's an RC0 thing :)Computers are cool. I just can't hold myself back.

if you have multiple AD, it takes a while for replication to happen. So what you have seen is just delay?

Nope. Single AD, Single ILM. Or do you mean sometimes, if you do Multiple Password resets (*say like when you're testing*) it get's "lost in the fray" ? ;)Computers are cool. I just can't hold myself back.

well... If you only have single DC, i don't have a good explanation. (i would blame on your AD being slow, hehe, just kidding) but i tried resetting as fast as i can manually but never have such problem btw, the easily way to test reset is to "Lock the machine" instead of logging out.

Yep. That's been what I've been doing. Seems to work so far. I have to get my MA's scheduled to get the sync to ILM automated. I haven't had the nerve to try "THE OTHER WAY" way and try sending things back into A/D.That, I have to be Ohhhhh soooooo sooooo careful about THAT!If I kill the Metaverse, Meh.If I kill A/D, well errrrrr..... I'll get "called out" and be applying to the "Burger King"SeanComputers are cool. I just can't hold myself back.

Doh!No, I'd based my answer on some untested misconceptions. There's been a couple of posts and e-mails (various sources) whereby people have asked for the ability to unlock and the general answer has been write a custom activity.I just tested a reset against a locked account and the account was unlocked by the same process.Thanks for pointing that out.Note also that the ADS_UF_LOCKOUT bit didn't change when I was locked out and unlocked. Only lockoutTime (and the other attributes associated with a pwd mod) so my advice above was a little off too. Best bet to ascertain lockout is to check lockoutTime for a value > 0 and then reset to 0.Sorry everyone!

well... first, there is unlocking the user from AD. That's done during SSPR. However, SSPR doesn't unlock the user from ILM's lockout activity. This might be the first confusion second, there is a "Disable" account in AD. SSPR doesn't "un-disable/enable" the a/c this might be the cause of confusion

In RC0 the SSPR operation DID happen in two passes, which would explain the behavior you are seeing. This will be different in RC1.AhmadAW

In RC0 the SSPR operation DID happen in two passes, which would explain the behavior you are seeing. This will be different in RC1. AhmadAW Building on what Ahmad said, in RC0, when the process only makes it through the first password reset (to the random value), it usually means that the password supplied by the user did not meet the password policy restrictions set in the target domain, so the second pass failed. In the second pass, we are actually doing a Password Change operation, so all password policies are in effect.

That does sound like what's happening in RC0. I just had a user who had a locked out account try to reset his password. The process went ok but the password "failed" to reset. What it appears may have happened was MAYBEUser reset password to one not in compliance (IE: Old reused, not complex)Second run successfully resets passwordNew Password didn't work.Checked A/D. Account was successfully unlocked with "User must key in new password at next login" checked off.So is this a case where the ILM "random password" the user never sees, ends up being the one that works?Hurry up RC1! :)I've had this happen to me and the only fix is "ADUC" select User, Reset password to whatever. Done.Computers are cool. I just can't hold myself back.