Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've been slowly working on a script that will do everything I normally do for a new employee when they start. So far it all seems to be fine except one thing. Here's what I have:

Loads Quest snap-in.

Prompts for specific information for the user.

Gets information about a current similar employee for reference and pipes it into the new employee, minus the specific information I'm prompting for. Creates the AD account.

Gets group information of current employee and put the new user in the same groups.

Loads Exchange credentials and mail-enables the new user.

Goes to the File server and creates their home drive and gives specific rights as needed.

All works fine, except that when the new user is created, I can't login as them until I have went into ADUC and reset their password, unchecked "User must change password at next logon". It all looks fine, all the fields are populated, but when I go to OWA to test login, it says bad username and/or password. I've tried telling the script to manually uncheck the box, reset the password, disable, re-enable the account, etc. The commands execute just fine, no errors, but it seems like none of that works. But, if I right click on the user, select reset password, type in a password and uncheck the box, then I can immediately logon afterward.

So, it seems like there's another setting somewhere that I'm missing with the script that is happening when I do it manually. Here is the command I'm using to try and replicate what I'm doing manually:

Get-QADUser $username | Set-QADUser -UserPassword $accountpassword -userMustChangePassword $false

It seems to work, but not work... any suggestions would be greatly appreciated, this is the only thing holding me up from a pretty handy script! :) Thanks!

share|improve this question
    
Is the first character of the line really a #? The # is the comment character in PowerShell, meaning the line will not run. Remove the #. –  jscott Mar 30 '12 at 19:35
    
No, I have it commented out from just trying it before, just wanted to show the syntax I was using in case i'm missing something. It didn't seem to make a difference as far as fixing the problem. Sorry for the confusion, I'll edit and remove it. –  Don Mar 30 '12 at 19:39
    
have you tried the native MS AD powershell cmdlets? –  tony roth Mar 30 '12 at 19:56
    
Actually, I just figured out what it was. I was passing in -assecurestring but it wasn't actually returning the password I entered. Apparently I was barking up the wrong tree. :) Thanks for your time! –  Don Mar 30 '12 at 20:10
    
@don Be sure to post that as the answer and mark it as accepted. This will indicate this question is resolved. –  jscott Mar 30 '12 at 20:31

1 Answer 1

up vote 1 down vote accepted

Actually, I just figured out what it was. I was passing in -assecurestring but it wasn't actually returning the password I entered. Apparently I was barking up the wrong tree. :) Thanks for your time!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.