The only things I can think of being the problem is that you use both the integration provider and the integration httpModule, or that you role provider has a very very large amount of roles. Are you using forms authentication?
Hi Magnus, Thanks for the quick reply. When you say using both could be the problem? Are they exclusive i.e. I should only have to use the provider not the module or the module not the provider?
Do I really have to use them at all? I'd assumed, perhaps naively, that I could just run SqlMembershipProvider and add the two roles (in the current setup they are the only roles in addition to the episerver defaults).
It appears that EPiServer Mail only works if the users/roles are stored in the tblEPiServerCommonUser and tblEPiServerCommonGroup tables. Is this indeed the case? (as opposed to the aspnet_Users, aspnet_Roles where they appear if I just use SqlMembershipProvider)
This install is indeed using forms authentication (timeout=20, slidingExpiration=true - sessionState InProc timeout=20).
Exactly, Mail uses the tblEPiServerCommon* tables which are exposed in the Common* role/membership providers. The integrating provider copies users/roles from your backing membership/role providers, so by adding the MailAdmins role to your SqlRoleProvider and adding it to your sql user the same setup should be copied by the integrators if set up correctly.
I don't know if the module and membership provider can conflict, but if you are using forms auth you don't need the integration module. In this case the synchronization will be done when the user logs in through the login form. The module is used when using for example Windows authentication to pick up the current user from the context (because the user doesn't log in using a form which can trigger the membership provider sync).
It appears to be working using the provider (and not the module) + ensuring that MultipleActiveResultSets=True on the connection string (I was receiving 'There is already an open DataReader associated with this Command which must be closed first').
I have never seen those types of problems. Having to enable MultipleActiveResultsSets is probably a sign of something else, but I have no idea what I'm afraid.
About scripting and changing the admin mode I have experience with quite extensive modifications and I can only say that I wouldn't recommend doing anything that is not explicitly supported in the API - it will cause tears when upgrading if not before :)
I'm trying to get EPiServer Mail 5.0 working with a CMS6.0.530.0 install. The installation instructions (http://world.episerver.com/Documentation/Items/Installation-Instructions/EPiServer-Mail/Installation-Instructions---EPiServer-Mail-50/) appear to suggest adding a 'MailAdmins' and 'MailEditors' role to allow access. However when I do this the users still do not have access (only the initial user created on install does - the rest receive 'access is denied' prompts when clicking 'manage recipients').
Is this not possible (sticking to SqlMembershipProvider only and adding the groups)?
I tried using the EPiServerCommonIntegrationMembershipProvider (with SqlMembershipProvider and * in the config) and the EPiServerCommonUserIntegration module and although that appeared to work (I saw my user sync'd into the common tables and I could log in as them an use EPiServerMail) it appeared to raise other issues whereby certain aspects of the CMS site failed to load or took extremely long or even Connection Reset errors (all of which is removed as soon as I change back to SqlMembershipProvider instead of CommonIntegration.