Centralized Membership and Independent Roles

You can share membership across separate installs of Community Server.

To do this, you create a main site and any number of satellite sites. Membership and profiles will be centralized, but each site will be responsible for its own roles.

To begin, create at least two separate instances of Community Server. Let's call them Main, Satellite1, Satellite2, SatelliteN. While you can use either the Web Installer or the MSI, you will only be able to install the MSI version once per machine. So, if you are want to host all your communities on the same box, it would probably be best to use the web installer.

As part of the installation, you should leave the default options set (Script ASP.NET MemberRoles, Script Community Server, Create Community). We also recommend using the same credentials/email for the administrator [1] and not create sample data.[2]

Before merging membership, you need to verify the ApplicationName setting in the cs_SiteSettings table. The ApplicationName is one piece of information that ties Community Server to the ASP.NET Membership system. If you used one of the installers for initial setup, you will have a single entry in the cs_SiteSettings table for each site, representing the installed instance of Community Server with an ApplicationName of dev. If you performed a manual install, you may have a different ApplicationName in each of your installs. While the name isn't important, it is critical that all sites share the same application name.

You can now begin to tweak each of the satellite sites so they point to the main site for membership. Since you will be telling Community Server to use one database for content and another for membership, you must add a second connection string. Open SatelliteX\Web\connectionStrings.config and add a new connection string called Membership that points to the main database. In a local setup, connectionStrings.config may look like this:

<?xml version="1.0" encoding="utf-8"?>
<connectionStrings>
    <add name="SiteSqlServer" connectionString="server=(local);uid=;pwd=;Trusted_Connection=yes;database=satellite1" />
<add name="Membership" connectionString="server=(local);uid=;pwd=;Trusted_Connection=yes;database=main" />
</connectionStrings>

Now you must tell ASP.NET to use this new connection string for both Membership and Profile access. Open SatelliteX\Web\web.config and change the connectionStringName attribute for both the default <membership> and <profile> providers.[3] Your file should look something like this:

<add name="CommunityServerSqlProvider"
    ...
    connectionStringName="Membership"
    applicationName="dev"
    ...
/>

Because you are using independent roles, you will not be touching the <roleManager> configuration in any way.

At this point, you should be able to test each of the primary areas affected:

• Centralized Profile - Login to any of the sites, change some profile information, and then log in to one of the other sites as the same user and see the updated profile.
• Centralized Membership - Create a new account on any site and then log in with this new user's credentials to any other site without registering.
• Independent Roles - Change the roles for one user on a site and then log in to any other site and see that the roles have not been updated for other sites.

You can also see what is happening in the database:

• Main Database - Open the aspnet_Membership table and you will find a record for each user that exists on any site (union of all sites).
• Satellite Database - Open the aspnet_Membership table and you will only find records for the users created during installation.
• All Databases - Open the cs_Users table and you will find only records for users who have logged into the specific site.[4]

As you can see configuring shared membership is not too difficult, but the choice to leverage the capability should be well planned. If multiple sites use a single site (and database) for all membership/profile requests, that site/box must be able to support the additional load imposed by this configuration.

[1] When the membership stores are centralized, it will be nice to have a single user already configured with access to all sites.

[2] If you select to Create Sample Data, content will be created pointing to the default admin account. Since you will have multiple admins, one for each community, you will have to clean up the data once you centralize membership and remove the duplicate administrators.

[3] During this step many people tend to worry about synching the applicationName setting on the providers. Since Community Server supports virtualization (multiple sites from one database), the applicationName is pulled from the value in the cs_SiteSettings.ApplicationName column of the database for each site and not from the attribute in Web.config. This is the primary reason Community Server is configured to use custom providers (CSMembershipProvider, CSProfileProvider, CSRoleProvider).

[4] One feature of Shared Membership is that a CSUser is not created until a user actually logs in. During login, if the membership record is found a user record is created (if it does not exist) to wrap the member.