Need to decide…
- Where to host ADAM – We want it replicated for additional fault tolerance:
- The best option may be to run it on each SharePoint server in your farm… ADAM supports clustering via network load balancing. If you have setup up NLB for SharePoint, it then should not be too difficult to set it up for ADAM as well. This also eases configuration on Internet-facing servers… you don’t need to allow additional firewall rules from the SharePoint web server to an ADAM server in your trusted network.
- Place the DB external to the SharePoint server for scale out … you don’t want to install an essential component on a web farm server that you want to be able to take down to apply maintenance.
- I should be something short, and fairly memorable. It also should sounds distinct from the Internal URL… I am trying “PartnerPoint.uvm.edu” to start out with .
- ADAM Setup:
- ECTS requires SSL for ADAM… check the Event Viewer “ADAM” events for SSL errors. Documentation suggests giving the ADAM service account rights to the required certificate in the “All Users” profile… this worked for me in TEST once my certificate has a Fully Qualified Domain Name in its subject line. My auto-enrollment generated certs only have the FQDN in the SAN (subject alternative name) field, thus I needed to generate a new cert for SSL to work. Once doing the PROD deployment, this fix did not work, and I had to copy the PROD SSL cert from the “Computer Account” Personal certificate store to the “Service Account” Personal certificate store (the store labeled “ECTS Instance”)
- In our production environment I had trouble running the setup script… this was because I was trying to use ports that ADAM considered “invalid”. Keep an eye on %windir%debugadamsetup.log if scripts fail… as indicated here:
- It seems that host headers may be required by the setup scripts… if initial config fails, try adding host headers to internal and external web sites, then running setup again.
- Connection Strings are for ADAM and the ECTS database are stored in the web.config files of each SP web site instance… you can inspect these to validate your config. Also, you can change the ECTS database using these connect strings. By doing to I was able to rename the database to “ECTSTest” so that I will be able to install the PROD database on the same server.
- In more complex environments where you are adding ECTS to an existing SharePoint server, the ects_setup_sharepoint.vbs script may not update all of the web.config files on your server. This was not a problem on my test server, but it was a real pain in production. To fix the issue, I copied the following sections from my Extranet site web.config to by internal (“Default” zone) web site web.config:
<add name=”ADAMConnectionString” connectionString=LDAP://myserver:636/CN=Users,OU=ECTS,dc=mycontext />
<add name=”DBConnectionString” connectionString=”Data Source=MYDB; Database=ECTS; Integrated Security=SSPI” />
<allow users=”*” />
<network host=”smtp.myzone.net” port=”25″ defaultCredentials=”true” />
“SharePoint – Collaboration” forum on MSDN:
ECTS online documentation on TechNet:
Here is one that really helped me:
(actually, the same information is available on many web sites, but this is really concise. Getting “real” debug output helps to identify the source of config problem. I found these stack traces a lot more useful than looking at SharePoint diagnostic logs)