Hi,

On our website we allow users to donate without registering on the site ... but behind the scenes an account is created for them in the DNN user tables to store their information until it can be exported into our internal accounting systems.  The account is really just a dummy account so that we can get their information to process their payment.

We'd like to create a process that will essentially cleanup these dummy accounts once they've been dormant for a set time.  We'd schedule this to run regularly so that our database doesn't get filled with these accounts.

We know that we'll need to delete from the users table and likely the membership tables as well as the profile property tables?  Are there others that we need to be aware of?

This is the list of tables we've compiled that we'll need to delete from (as far as we know):

Profile
UserPortals
UserProfile
UserRoles
Users
aspnet_Membership
aspnet_Profile
aspnet_Users
aspnet_UsersInRoles

Can anyone think of any others?

We know we'll also have to delete from some custom and third-party module tables ...

sybru-
Are you removing the accounts only due to the duplicate email issue?
 
While there is no single "right way" to approach your issue, I can say from my own experience that I often find it worthwhile to "disable" rather than "delete".  Most of the time it doesn't matter one way or the other but in the rare case that it does matter the benefit of keeping historical data handy can be huge.  Unless the old data is dangerous (sensitive data like credit card info) or is an actual hinderance (DB performance impacted) my approach would be to just do the minimum to resolve the duplicate email issue while preserving the data.  You never know how that data might be useful in the future.
 
 
Regarding duplicate email addresses: 
Since the email addresses are only for "one-time-use" accounts, have your user account auto-creation routine prepend the email addresses with a fixed-length integer timedate value representing the moment the account was created.  This insures unique email addresses even if the same email address is repeatedly used.  Because you know the string length of the timedate va, it's also easy for you to extract the actual email address if you need to use it.  Of course, you would ONLY do this for those "one-time-use" accounts.  Regular users' accounts would need to keep the original email addresses intact (for password reminders and such).

Example: 
John Doe creates an account at 10:37:12am on May 7, 2009, with email address "johndoe@msn.com".  Your account-creation solution would create the email address as "20090507103712johndoe@msn.com".  
 
 
If auto-generated accounts make it difficult to manage REAL accounts: 
Too many defunct accounts in the mix can make it hard to use the DNN user admin tools.  You can mark such accounts as "deactivated" but they still show up in the lists of users.  A trick I've used in the past was to provide a custom account management solution that "flipped" defunct user's portalid values.  For instance, if you want to deactivate a user's account on portal 3 (portal assignments stored in the USERPORTALS table), the solution flipped the user's entry from a value of "3" to "-3".  As easy as that, the user no longer appeared for portal 3 but we maintained all user data as well as an indicator of each portal a user was "deleted" from.  Flipping the value from "-3" back to "3" restored a "deleted" user.  
 
Note that this is a total "hack" of how the system is meant to work.  It just happens to be one method I've used in the past when portal membership ran into the thousands and the site admins asked for an easy way to "remove" old accounts from portals without actually deleting data.
 
 
It may be more work for you to alter your current solution than to simply delete data, but you'll continue to have to deal with duplicate email addresses.  It's also possible the boss will walk in one day asking which people have donated more than once in the past three years -- with historical data intact in the DB it would take only a single query to give a complete list of who, how many times and when.
 
 
Hope this has helped in some way.  Good luck!
-mamlin