Home > Computers > Users not receiving email about an expiring password

Users not receiving email about an expiring password

WARNING – This post deals with making bulk changes to Active Directory. Proceed at your own risk.

I’ve been using the script (with a few tweaks) from http://rlmueller.net/PasswordExpires.htm to send users an email notification when they are within the configured Prompt user to change password before expiration policy. It works great but every once in a while a user would call because their password had expired & they did not receive the email. Over time occasionally that same user or a few other ones would call with the same issue.

Finally, one day another user called describing the same thing. Time to get to bottom of this one. I took a look at the user’s Active Directory account & sure enough the pwdLastSet attribute was over 90 days old. I took my script & modified it so I could just see the results without sending any emails. Your results with the original script may vary but at a minimum comment out the line that sends the email & instead pipe the output to the console.

# SendEmail $Mail $Notice

Write-Host $Name”,”$PwdExpiresDays

Sure enough when I ran it the user reporting the issue was not showing up in the results.

The script filters the results a little as noted below.

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `

   + “(pwdLastSet>=” + $($64Bit1) + “)” `

   + “(pwdLastSet<=” + $($64Bit2) + “)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=2)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=65536)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=32)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=48))”

So I modified the filter (see below) to just show all users & ran it again. This time the user having the issue showed up.

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user))”

So at least now I know the script is working but for some reason the user is being filtered out. I add each filter back one at a time to figure out which one is causing the user to be excluded. I skip over the two pwdLastSet filters because the account is already at 0 so that could cause it to not show up. So now my filter looks like this:

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=2))”


The user still shows up. On to the next one.

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=2)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=65536))”


Still there…next.

$Searcher.Filter = “(&(objectCategory=person)(objectClass=user)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=2)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=65536)” `

   + “(!userAccountControl:1.2.840.113556.1.4.803:=32))”


Bingo! The user isn’t showing up. So I do a little checking & find that !userAccountControl:1.2.840.113556.1.4.803:=32 will exclude users that aren’t required to have a password. Huh? Now why would any of my user accounts be configured to NOT require a password? So that begs the question, how many users are configured like this? I run the following Powershell command. The results will vary depending on your environment but suffice to say you do not want a lot. (Hint hint some may legitimately need to be configured like this.)

Get-ADuser -LDAPFilter “(userAccountControl:1.2.840.113556.1.4.803:=32)” | Select-Object name

You can even see this by looking at the userAccountControl attribute in AD & see that it is set to PASSWD_NOTREQD | NORMAL_ACCOUNT.

In all my years I’ve never seen this before so I did a little digging & ran across this TechNet post.


Long story short, a long time ago when “someone” migrated user accounts they may have done it wrong.

But enough pointing fingers, how to fix it. Use the Set-ADUser command to set the user’s PasswordNotRequired flag to $false.

Set-ADUser -Identity jsmith -PasswordNotRequired $false

I’ll leave it up to you how you want to modify all the affected users. Just be careful as there may be a legitimate account that needs this setting. Again, proceed at your own risk. I just filtered based on OU.

Get-ADuser -LDAPFilter “(userAccountControl:1.2.840.113556.1.4.803:=32)” -SearchScope Subtree -SearchBase “OU=Company,DC=contoso,DC=com” | Set-ADUser -PasswordNotRequired $false

  1. Rob
    April 18, 2016 at 9:37 am

    Hi Patrick. I got your link off SpiceWorks from a guy whom you helped with an Outlook error where he couldn’t create or link to a missing path for the .pst file. He said he followed your instructions about an inactive applet, but that on your suggestion he used Procmon and nailed it down to a missing “ForcePSTPath registry key”. I have the same problem on a friends PC that I have just upgraded with a SSD, but I am not really a PC expert, although maybe above average knowledge. Is there any way you can help me to find where I need to create the missing registry key, or how to search the mine of entries returned from Procmon? Thanks

  2. patrickhoban
    April 20, 2016 at 11:48 am

    Using Procmon is 50% science & 50% art. The “Sysinternal Administrator” book is a great resource. As far as the ForcePSTPath issue that does not ring a bell. If you just need to create it have a look at http://www.msoutlook.info/question/370.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: