After two days of troubleshooting some vexing problems with ECTS, I have arrived at a new recommendation concerning this product:
Okay, that may be a bit damning… here is a qualifier. If you have no SLA with your customers, don’t mind lots of downtime, love C# programming, and otherwise find SharePoint troubleshooting highly amusing, then ECTS is the solution for you. Otherwise, try something less painful.
The main discovery that pushes me to make this recommendation is that the ECTS solution is not supported by Microsoft. The head of the MS Solutions Accelerator group once told me that all Solutinos Accelerators for currently supported MS products are supported by Microsoft. This is not actually the case. Always read the fine print for your Solutions Accelerators. In the case of ECTS, we find the following in the ECTS FAQ, available in the “Informational Materials” download. From http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=d9af2c25-989c-45c4-8008-1f15722190ed:
Answer: Although every effort was made to ensure that the External Collaboration Toolkit for SharePoint provides trouble-free installation and reliable operation, it is not officially supported by Microsoft. We will provide best effort support on the SharePoint – Collaboration forum, but cannot guarantee timely resolution of any issues.
Other pertinent bits of info from the Information Materials:
- There is a suggestion that the product has been tested and is “supported” (whatever that means) only with Server 2003 (not Server 2008).
- There is a reference to the commercial product called the “External Collaboration Manager“, which I expect was developed by the same consultants that created ECTS in the first place (although I have no proof of that).
I am going to pursue aggressively a Forms-based authentication solution using ADFS as a replacement for this service.
FWIW, here is a quick breakdown on the current set of problems, and what I did to fix them:
- When attempting to load the \sites\[sitename]\_layouts\ExternalCollaboration\aeu.aspx page (add new external user form), one user reported “Access Denied” error messages, even though he was in the site administrators list.
- This happens because the aeu.aspx page checks to see is the currently logged in user is in the “Site Owners” group. Of course, being a site administrator should be sufficient, but the page does not check for effective rights, but instead performs a simple ACL check.
- Users would intermittently experience page load errors when attempting to load the same “aeu.aspx” page. Experientation with our load balancer indicated that the problem occured on only one of the two web front ends in our farm. Attempts to troubleshoot by using verbose Diagnostic logging, SysInternals ProcMon, and various browser debuggers (ieHTTPHeaders, Fiddler) turned up nothing.
- Finally, I discovered that there was a single “ExternalCollaboration.RESX” file missing in the inetpub\wwwroot\wss\VirtualServers\[IIS-site]\App_GlobalResources\ directory. After copying the RESX file to all three production IIS sites on both web front ends, and performing an IIS Reset, the page load error went away. I don’t believe that these files ever got replicated to the second web front end after installation, so add this step to your farm build procedure.
- Our Account Services team reported that the “PartnerAdmin” page (or ECTS Administration web part) was reporting a “service unavailable” error.
- This problem happened because all of the web.config files on our server reverted their “ADAMConnectionString” values to point to the pre-production host name for our ECTS LDAP service. The event that triggered this service reversion is still unknown. After I updated the string to point to “sharepoint.uvm.edu”, the problem was resolved. Once again, I really need to re-install the whole solution using the correct LDAP connection string… the incorrect value is still cached somewhere in the SharePoint infrastructure that I cannot locate (most likely in configuration DB), waiting to bite me again.