In working with a Microsoft Exchange 2007/2010 environment, most are familiar with the Client Access Server role. Microsoft has implemented the password change feature with the CAS role that allows the changing of passwords at the forms based login screen found in the CAS frontend web page.
However, if you notice that after implementing the password change feature in your Exchange 2007/2010 server your disk space starts to diminish rapidly, the problem could be roaming profiles. We as administrators who hate roaming profiles can add this issue to the very long list of issues that are caused by using roaming profiles in our environments. Once the password change policy is implemented on the CAS box, the password change feature uses a call that will create a profile on the server if the user has the “Allow logon locally rights to the box.”
This can create a huge problem for admins as you may still be stuck in an environment that uses roaming profiles and management for whatever reason will not depart from this methodology. You may have users who are flagged to change their profile who have a 10GB profile setting on a server that WILL get copied to the CAS box during a password change. Recently, in working with a client, we saw a CAS box that had some 50GB of space taken by profiles alone! This is NOT something like your Exchange logs that get purged with full backups.
Secondly, this causes huge performance issues to the end user as they may experience the tremendous amount of time that it takes to change their password for no apparent reason. In the backend, as part of the password change process, the system is having to copy possibly gigs worth of data to the server to “copy” the profile which is created during the process.
If you are seeing this issue with the password change functionality, most likely you have users who have the “Allow log on locally” right who do not need the ability to log on locally, and who by having this right, are creating profiles on your frontend server. This WILL NOT affect the password change functionality for those users who are removed from this policy setting. NOTE – It is VERY important that you are careful not to remove groups that would essentially lock you out of the server. It would be wise to leave the local Administrators group as well as Domain Admins in the policy setting.
Simply, remove the unwanted users/groups that have this right in the local policy of the server. Note, you may have policies that are being enforced at the domain level which may not allow you to add or remove users from particular policy settings. If that is the case, you will either need to change the policy at the domain level which may not be desirable, block policy inheritance, or explicitly deny the Computer account the “read” permission in the ACL listing for the particular Group Policy that is configuring this setting.