Forum Discussion
Unexpected behavior with Set-ADUser
What exactly is not working? The only way the above cmdlets will fail is if you have not set any of the variables you use. And the parameters you are changing have nothing to do with limiting logon.
I agree. That is why is so confusing to me. I did find that there was a scenario where POBox was null, which was causing the script to fail, but I can't figure out how the log on to settings got set = to city.
Hello, Margalit.
One possible culprit is the way the attributes are named. For instance, if you run Get-ADUser XYZ -Properties l (that lower-case letter L), you get the corresponding value of the city you populated for the user XYZ. However, if you run Set-AdUser XYZ -l Paris (that's the same lower-case L), you will discover that the city was not updated to Paris but the logonServeer attribute was set to Paris. Which means the user XYZ will only be able to logon to a domain computer named Paris.
It has been quite an annoying discovery, but after changing the command to Set-ADUser XYZ -City Paris, the user's city was updated (and the attribute LogonWorkstations is empty).
If you did this for a number of users already, simply run the command Set-ADUSer XYZ -LogonWorkstations $null (or whatever computers you wanted to restrict XYZ's logons to).
Regarding the POBox, I've had this issue with other fields (like email, phone etc) and I'd imagine the issue is similar. If the csv you import from has no value, the import will fail.
For example:
Set-ADUser XYZ -OfficePhone "" (empty phone number) will fail. However,
Set-ADUser XYZ -OfficePhone $null will work.
What I've done to work around this was to check for null values in the csv (or whatever you import your list of users from) and replace empty values with $null
If ($i.OfficePhone -eq "") {$i.OfficePhone = $null}.
Probably there are more elegant solutions, but this was quite easy and worked for me.
Cheers.
halap