Force password age to reach policy limits in Active Directory

For testing purposes, just set the test user to password expired.  OWA behaves the same way as if the password expiration date had passed.  Make sure to restart IIS on your exchange server or wait for the cached credentials to expire in IIS before attempting to test through OWA otherwise you will drive yourself nuts.

The problem is, their are about 5 password reset pages. I need to completely reproduce the potential issues my end uses may be having. With that said, I don't want to leave anything to chance and want to reproduce the environment as much as possible. I also don't want to have to modify group policy too much as well. I have about 500+ users operating in multiple regions, so I can't leave anything to chance.

There is only one main password change page (aexp.asp) that comes up with an expired password (regardles of how it has expired).  The other pages come up when the user initiates the password change or in response to invalid user input in the password change process.  

There is still the aexp2.asp, aexp2b.asp, aexp3.asp, aexp4.asp, and aexp4b.asp pages. By editing the pages, we were able to look at the source code on the browser and see the different pages come up.

I have never encountered those pages actually being used.  I've only seen aexp.asp acutally used in a password exiration notice.

Regardless, I would still like to reproduce the user experience. Plus I would really like a utility the allows me to target an account and modify the password age. It would be useful in many scenarios.

By checking the "user must change password at next logon" box, you ARE reproducing a password expiration expirence.  There is no actual "date" a password expires on, there are only a count of the number of days since it was last change controlled by the applicable GPO.  When that count exceeds the number of days, AD sets the same flag that you are setting when you check the above mentioned box in their profile.  I know of no utility that would allow you to mess with that counter.

I was eventually able to reproduce the environment to find out which pages came up. In a lab environment, I determined that different aexp pages come up in different scenarios. If your password is about to expire, you are redirected to anot.asp which ask you if you want to change your password because it will expire. If you say yes, you are redirected to an aexp page. Off of memory, I believe it's aexp2b.asp. If you manually change your password, you are redirected to an aexp2.asp . Last, if your password has expired or if you need to change your password, you are then redirected to a third different aexp asp page. These pages are important if you are, like myself trying to brand your password change IIS/OWA environment. Regardless, all of the aexp pages redirect the user variables to the achg.asp page as the achg page is the main mechanism for this entire password process.