Hi there! Mike Kullish, here. I'm a PFE based out of Minneapolis, MN with a focus on AD, Hyper-V and DFS but I try to help customers with anything on the Windows Desktop and/or Server platforms. I have been with Microsoft for nearly three years and this is my first blog post.
Have you ever had a need to configure notifications for user's password expirations but found that existing solutions didn't quite fit the bill? We all know you can use built-in solutions with Windows and Active Directory/Group Policy but this requires users to interactively log-on to a network-based computer. What about those BYOD or mobile users or users of web apps/email? More often than not, these users will have to call the helpdesk because they had no idea their domain passwords were going to expire. Statistics show that some of the most common calls to the helpdesk are password-related and implementing a process like the one covered here could really make a dent in your helpdesk call volume and costs.
Recently, a customer asked for some help implementing a solution for this issue based on a script they'd found on the Microsoft TechNet Script Center. The script queries the pwdLastSet attribute of user accounts in AD and the MaxPwdAge property within the domain, then does some time computations and sends an email to those users who are near a password expiration 'event.'
I thought it would make a helpful blog post to cover some of the details and considerations when implementing a solution like this. The particular script my customer found was the work of Microsoft MVP Robert Pearman and he deserves the Kudos for initially putting it together, as well as several refinements to it (including support for Fine Grained Password Policies).
- PFEs don't normally provide code beyond sample or "proof of concept" code
- The code we discuss here is an additional layer beyond code from a PFE; it is code from a Microsoft MVP resource
- As with ANY code, you should always test/validate its behavior in an isolated lab
- Note the script author has validated the code via his own testing on Windows Server 2008 R2. Did I mention you should test/validate the code?
- If/when you're ready to deploy it to production, you should employ a solid change control process and a controlled release. This code can possibly generate emails to 100,000s of users.
You can download the script from the following link. (https://gallery.technet.microsoft.com/Password-Expiry-Email-177c3e27)
Click on the blue box and save the file to a workstation or member server. Obviously, a DC would work but likely isn't the best choice. The workstation or member server needs the RSAT tools for Active Directory installed. If you already have an "admin server" system where you have existing scripts, tools, Scheduled Tasks, etc., that would be a logical place for this.
Once you have downloaded the script:
- Place the file in a directory on your admin server. (For this example, I will use C:\scripts)
Edit the following portions of the script as applicable using Notepad or PowerShell ISE
- This will be the name of your SMTP server. The admin server machine will need to be able to send using SMTP – you will likely need to work with your email team to get that process working
$expireindays = 21
- This is the number of days prior to password expiration that you want to notify users. The actual number of days remaining before expiration will be displayed in the email notification.
$from = "Company Administrator <email@example.com>"
- This field can be modified to be sent from a valid email account within your environment. Consideration should be given to this address in order to prevent the perception of a phishing email as well as how replies will be handled.
$logging = "Enabled" # Set to Disabled to Disable Logging
- Logging is recommended to ensure that you can trace any errors that might occur
$logFile = "C:\scripts\PasswordExpiration\pwdexp.csv"
- This field should be changed to a desired location on the local system or network share as desired.
$testing = "Enabled"
Set to Disabled to email users (configuring this to Enabled, runs a check against all accounts and sends emails ONLY the account specified in the $testRecipient field below.)
- Configuring this to disabled actually sends emails to the users that will have their passwords expire in the configured amount of time.
- Understand this - you risk sending out a mass-email to 10s, 100s or 10,000s of users.
- This is automation – with great power, comes great responsibility
$testRecipient = "firstname.lastname@example.org"
- Specifies the test user account that will receive the test email. CAUTION: This account will receive 1 email for every user the script identifies.
- Save the script once you are done editing it.
Now you can test the script by running it in a lab.
- You may need to modify the execution policy for PowerShell scripts on your admin server machine.
You should get an email that looks something like this:
From: email@example.com [mailto:firstname.lastname@example.org]
Sent: Thursday, March 23, 2015 12:52 PM
Subject: Your Windows password will expire in 4 days.
Your corporate network password will expire in 4 days.
To change your password on a PC press CTRL-ALT-Delete and chose "Change Password."
It is important to ensure that you change the section of the script under $body. The message should be modified to ensure that user's don't accidentally delete the email because they suspect it is spam or a phishing email. Good inter-team collaboration and communication about this "password expiration notification process" cannot be emphasized enough.
- Work with your helpdesk and security teams to ensure everyone signs off on this effort and approves the specific text and additional information for the email, including how to manage a 'reply' to that email address
When it all is working as desired/expected, you can disable testing:
$testing = "Disabled"
Now, at some pre-determined time, you or one of your staff can execute the script to generate the 'password expiry notification email' to the affected users.
For those who don't want to manually run the script, it's a simple process to create a Scheduled Task to run the script automatically.
There are numerous other ways to address this need; I have talked to many people who have developed their own processes, scripts and/or code for this. This particular process was pretty easy to implement and I was able to work with my customer to get the whole thing working in a short amount of time.
Thanks to Hilde and all the other PFE bloggers here for helping me "dip a toe" in the blog-pond (or pool?) and a special thanks to Microsoft MVP Robert Pearman who provided some insight and details around his script.
See you all next time!
Mike "CANNONBALL!" Kullish