Hi Martin, I just noticed you posted this question on my blog, but I'll answer here also.

If that query does not return any results, then it means there are not any users out of sync.  More specifically it means that all the users in the aspnet_Users table are also in the Users table. 

The script on my blog was only designed to handle that one case because DNN was often creating the user in the aspnet table but erroring out before it got created in the other table.

If the third party module caused this error, then it may be better to get the developer of that module to help you fix it.

Otherwise, you are going to need someone who has a good understanding of how the membership tables relate to each other to look at your specific issue.

Hello John,

thanks for the quick response! Yes, I had posted a comment on the blog as well. Shows my desperation I guess :-) I realize that your script was intended for a different problem and it seems to work well for most people. After investigating more today, I guess my problem comes down to wrong ApplicationIDs in the various tables. I have in the meantime managed (don't ask me how) to access the User Account module in 4 of the 5 sub-portals I have by re-assigning the ApplicationID GUID's (some were pointing to an Application ID which didn't correspond to the various portal IDs but to - I presume - that user module I had installed; and I changed them to point to PortalID 0 instead using the proper GUID from aspnet_Applications), but the main portal (0) still doesn't work.

Maybe the problem is as simply as that I missed some entries. Thanks anyway for the reponses.