I am sorry to say that after doing extensive testing, that this module does not work reliably with the latest DNN and .NET with Active Social

Specifically:

I set the module up using the SSO option for multiple parent domains
I am using:

Windows Server 2008 and SQL Server 2008 (latest versions)
IIS 7 and ASP.NET (.net 4) and integrated pipeline
DNN 5.6.2 (latest versions)
The latest version of your module (DNNMasters.MPUS.Xtreme_PA_02.01.22.0)

The module is unreliable and has fatal problems, that makes it unusable for production
These are some of the problems:

INSTALLATION - breaks two of the combo boxes on the DNN User settings. These remain broken after uninstalling the module.

LOGOUT - it has erratic behavior, sometimes it does logout and other times it redirects to the wrong portal alias or even a portal alias that is not shared. Other times it errors out on log-out.

LOGIN - SSO does not work in any condition, you have to manually login to the different sites, even though the user is present in both. Also sometimes after login you are directed to the correct page, other times you are not.

SHARING - there is no way to share auto-assigned roles

ACTIVE SOCIAL - the module is incompatible with active social. Users shared from other sites don’t work, and there are several other errors.

UN-INSTALL - the module leaves behind several stored procedures that have to be manually removed.

This module shows promise, and almost works - but that won't do for our production use.

Installation: Nothing is broken on User Settings on our test portal and nobody else has reported such issue. Please provide access to the site where we can see this problem.

Logout: can't reproduce the issue, please provide access to the portal where we can see it.

Login: not true, SSO works perfectly well on parent portals, there are no known issues with the SSO at this time.

Sharing: the auto roles are are shared. However there is and issue (two days old and being fixed) where the user-in-role is not shared for the auto-assigned role on shared portals. This is the result of the design and functionality decisions that were made earlier based on customer requests.
We are now working on a changes that will allow direct management of sharing of auto-assigned roles except for the Registered Users and Subscribers which are default core roles.

Active Social: The issue that we know about is that the AS expects the portals to be duplicated for each shared portal while the MPUS keeps only one profile copy for all shared portals. We have fixes for the AS that allow it to see the shared profile correctly.

Un-install: will check and add to uninstall script if true.

There is erratic behavior on login/logout redirecting (which many people would not notice, as they don't redirect after login or logout) And as you know, the product does not support auto-roles and Active Social - these 4 issues makes the product unusable for us.

However, others who don't use Login/Logout redirects, and who don't use auto-roles/Active Social, could use the product with caution.

SSO we could not get to work reliably in our test cases with many portals and aliases. (The aliases were all valid). The module appears to loop through every portal alias in the DNN instance (shared or not) during Login and Logut and randomly will select the wrong one or return an invalid URL.

In the test case where there was a portal alias that was setup for future use [and currently did not resolve], the system would break every time.

The stored procedures left behind after uninstall are related to the navigator module for MPUS

I think from a standpoint of robustness,
the module would be better if it had an option to copy all the profile information between the shared portals. That would ensure that all other modules would function correctly, like Active Social and other modules that share/import/export users. On each login, you could check to sync changes made to a given user profile. More similar to how Plaxo syncs email contacts.

Why do you loop through all the portal alias' in the DNN instance and then do a redirect after Logout?

I can see three stored procedures left over and all three are from MPUS. The Navigator doesn't create any at all.
It'll be fixed a.s.a.p. 

The profiles:
Profile data is often bulky and slow to retrieve/write. Doing a full profile copy on initial share with thousands of users and big profiles would probably kill the process (timeout).
So using single shared profile copy and logical profiles on shared portals was a design decision made long time ago.

In the last few months we've had customers wanting to use MPUS with Active Social and we run into the shared profile issue. As a temporary work around we offer scripts that change the AS to use our shared profile.
We are aware that it's a workaround only and we are researching for the long term solution to add an option allowing alternatively fully independent portal profiles.

We do loop through all aliases on SSO login in order to allow full SSO. We have no way of knowing what alias will be used so we have to assume that each one is valid and might be used. Why would you add it otherwise ?

The SSO works reliably on parent portals. There is nothing special to it that might cause erratic behavior.
The module loops through each alias on every shared portal and logs the user in.
If the alias doesn't resolve it shouldn't be added to portal as there is no way to use it.

DNN 5.6.2 (latest versions)
The latest version of your module (DNNMasters.MPUS.Xtreme_PA_02.01.22.0)
AutoRole not shared !!!!
But if you create a new role on any site shared area, and do not mark it as shared, it is still shared by all the sites shared area !!!!
This makes it impossible to use the module!
Last ...
After removal of sites from the shared area, site removed all the roles, even the role of Administrators and Registered Users!!!!!
when will update !!!!????
P.S.
I wanted to buy DNNMasters Membership Management Suite Pro!!!!
but I'm afraid to buy it too will not work!

#1 Auto roles are shared automatically if you select to share all roles (*) (**)
#2 Unwanted sharing of new roles confirmed as bug and being fixed
#3 Tested by repeated sharing / un-sharing of portals and can't reproduce the issue of roles being deleted

* There are no users assigned to shared auto roles and this is entered as bug and being fixed.

** The auto-roles handling (except for Registered Users and Subscribers) is being changed so that they appear in sharing wizard as any other role.

Membership Management Suite Pro is now obsolete and not recommended for use on dnn 5.6+.
It was replaced by User Manager Suite 2.2 (dnn 5.6.+ only) and a trial is available on our site.

If one of the portals is not available because of an incorrect DNS entry or IP, I can not access the site, which records are correct.
After login to the correct site, is a module making any test portals, and instead the home page of the correct site, the browser shows an error, and link to the portal which is not available ...

Yes, if you are running the SSO configuration that's the case. The SSO process stops on the inaccessible alias and shows error.
However, the user is logged in to all portal aliases that were processed before the error.
It is responsibility of the admin to ensure that the portals are accessible for users or else there is no point in running SSO configuration.

Very bad when due to an error in the settings of a single site, logins do not work in 99 sites.
We must show the error to anyone who accesses only the site with incorrect settings! Admin can not watch every second of the settings of all 100 domains on the same host!

We'll add separate settings for the SSO to select the aliases that will be used by the logon/logoff process.

However, I really can't understand why you'd add an alias that doesn't work, especially when knowing what the results will be.

I guess all aliases/domains belonging to a company would be handled by the same DNS server with at least one secondary server. So what's the problem to maintain 100 domain aliases and adding an alias to DNS first, making sure it works and finally adding dnn alias ?
If you don't use the aliases don't add them to dnn.
Use IIS for redirecting multiple aliases to the domain that you want it to go - it's much better than stuffing dnn portals with multiple aliases.
Besides it's bad for SEO....

If the domain owner changed the settings in error or someone messed up his settings of malice - all sites in shared area affected.
illogical when due to an error of one - all suffer.

Multiple alias - for landing pages and micro-sites. Ifinity's url redirect now provides option to have specific pages use a different domain.

If you redirect specific pages to another domain users would expect the domain alias to work or there is no point in redirection.