Ok, I guess I'm still not understanding the problem and why you can't do this with parameters.
First off, you don't need to look in USR02 to see what the date of last password change was. You can use the report RSUSR200 to do this (you can run it directly as a transaction, or from SA38, or you can call it from SUIM).
If I understand the requirement correctly, you want all of your users to change their password on or about the start of the new year, and you're giving a grace period of two weeks into January for them to get it done voluntarily, after which you want to force the change for those who haven't done it.
What is the current policy? No changes required at all? For the sake of argument, I'm going to assume this is where you are today, and what you're trying to change away from. Perhaps you're also trying to enforce more complexity in the passwords, i.e. require a mix of upper- and lower-case letters, numbers, minimum length, etc, than is currently required.
You might have a look in RSUSR200 to get an idea of how many users have already changed their password recently, and so therefore perhaps you don't actually want to force them to change again right away.
My suggestion is to decide on the standard length of time between mandatory password changes (for instance, every 90 days or 180 days, etc), plus your complexity rules, and call that good. Chances are that if you haven't been forcing changes previously, then most of your users will be forced to change as soon as you implement the policy via parameters. Only those who have already voluntarily changed more recently than the expiration period, or whose user accounts are new, will not be forced to change, and this is a good thing, not a bad thing. It's probably what you really want.
So, set the following parameters in your default or instance profile:
- login/password_expiration_time
- Length in days before password must be changed. If you set this to 90, for instance, then everyone whose password is older than 90 days will be forced to change at their next logon.
- login/password_compliance_to_current_policy
- If set to 1, will force users to change their password at the next logon, even if it hasn't expired yet, if the current password doesn't meet the complexity rules.
- login/password_max_idle_productive
- This is to catch those users who don't logon very often, but do once in a long while. If a person has changed their password, but then doesn't logon for another year (as an example), then this will cause their password to become inactive, thus requiring an administrative reset to let them logon again. Set this number fairly high, definitely much longer than login/password_expiration_time, perhaps about twice as long.
- login/password_max_idle_initial
- Similar to login/password_max_idle_productive, but this one catches people who have a new user account, or get their password administratively reset, but then don't login and change it even the first time. This is especially important if you tend to use the same (easily guessed) initial password for users, as you don't want user accounts sitting out there with an initial password that everyone knows. Set this number lower than login/password_expiration_time, perhaps about half the length.
- login/password_downwards_compatibility
- As long as all of your systems are on NetWeaver 7.00 or higher (I think), then you should consider changing this parameter to 0 (it defaults to 1). However, it's not really the focus of this discussion.
This is enough to force the change you're seeking. What level of complexity you then require, and how long the password history is maintained, etc, is up to you. If you set these parameters on New Year's Eve, then people will encounter the requirement to change on their next logon, unless they have already changed recently. If they don't logon for a long time, their accounts will become unusable until they seek an administrative reset. If they already haven't logged in for a long time (or ever), beyond the "max_idle" parameters, then their accounts will become unusable until they get an administrative reset.
Regards,
Matt