The SharePoint Swiss Army Knife

And I’m not talking about the rock and roll type of headbanging either. I’m talking about the type of headbanging where you slam your forehead onto your desk every hour or so and pray to the SharePoint gods for moral support.

I was actually part of a small group of non-Microsoft beta testers while the ECTS Solution Accelerator was still Beta and was able to work with it pretty easily in a dev 2003 environment so I thought what the heck, can’t be much different for a Windows Server 2008 environment right? Yeah…right… So I’ve spent the last couple of days trying to install this Extranet Collaboration Toolkit (Technet documentation here) onto a Windows Server 2008 production box hosting Windows SharePoint Services version 3.0 and luckily for me none of the documentation had been written for Windows Server 2008 yet. On the flip side, I get to try to write everything I remember down and to share my experience with all of you guys! 🙂

Architecture (My Setup)

1 – Windows Server 2008 Standard 64-bit hosting latest WSS v3.0 bits + AD LDS + the ECTS.
1 -SQL Server 2005 with a new instance just for the new WSS farm.
1- Windows Server 2003 Domain Controller (Also the Enterprise Root Certificate Authority).

Steps

1. Installed 64-bit Windows Server 2008 Standard. This was basic, no biggies.
   
2. Installed 64-bit WSS v3.0 with SP1
   – Download bits here
   – Download post SP1 infrastructure updates
   – Read deployment documentation here
   – Comments: The documentation is pretty good here, was able to install with all recommended service accounts.
   
3. Download Extranet Collaboration Toolkit
   – Download bits here
   – Follow along with this prep and deployment guide
   – Comments: I’ll outline some of the gotchas I came across below

Gotchas

This section will pretty much follow the steps detailed in the deployment guide but I’ll intervene with comments where I met some difficulty.

Preparing the environment

1. Record all the Required Data on a piece of paper or something. Will make your life easier later on. These include of:

– Internal URL
– External URL
– ADAM host name
– SQL Server name
– etc, they’re all listed and detailed at the beginning of the guide.

2. Make sure you have an Enterprise Root Certification Authority deployed on your domain controller. If not, see this article. Comment: this step was pretty easy and self-explanatory.

3. Setup DNS alias using CNAME records for your internal and externally facing collaboration site URLs. Example internal: http://collab.mycompany.com; external: https://partners.mycompany.com

4. Install Certificate and Update Key File Permissions – now this part was a major pain the butt. I spent a solid day figuring this out. From the extranet server the guide tells us to use Internet Explorer to access our Enterprise Certification services, usually found at http://domainController/certsrv.

First road block was that with new features (security?) in Windows Server 2008 and Vista, you’ll need to download a hotfix for your Certification Authority (CA). I don’t have the link to the hotfix but you’ll see it when you try to access the webpage. The other gotcha in this step is the fact that it must be an encrypted site, so you’ll have to install a self-signed certificate and bind it to the IIS website. This part wasn’t too hard.

So after I got the CA prepped and was able to access the page, I resumed with the guide:

– Request a certificate
– Click advanced certificate request
– Click Create and submit a request to this CA
– Use the Web Server Certificate Template, type the FQDN of the extranet server. Ex: wssextranet.mycompany.com
– Under Key Options, create a new key set with Microsoft RSA SChannel Cryptographic Provider.
Click Automatic key container name and then select “the Store certificate in the local computer certificate store check box.”

This is where I got tripped up. I didn’t have that check box! I’m not sure why but I surely found out that it didn’t work after trying to complete this step for the 5th time unsuccessfully. Everytime that I was installing the certificate, it was being installed to the account’s profile and not the ‘All users’ profile. So with much digging I found 4 links that helped enable me to request a Certificate via command line.

– How to enable LDAP over SSL with a thir-party certification authority (KB 321051)

– Configuring LDAP over SSL Requirements for AD LDS (Windows Server 2008 )

– MSDN SharePoint Forum post by Dan Barua 7/24/2008

– Advanced Certificate Enrollment and Management

So after creating the request.inf file, and replacing the “Subject=” with the extranet server instead of the DC (another gotcha), I created a request file using:

certreq -new c:\request.inf c:\request.req

Then you have to submit it to your Enterprise CA using:

certreq -submit -attrib “CertificateTemplate:webserver” c:\request.req c:\certnew.cer

Then install using:

certreq -accept c:\certnew.cer

So now the certificate should be installed to the right place, except I was having a hard time finding where it was installed to so I found another way to change the permissions on the Certificate that I didn’t see mentioned in any of the documentation:

– Go to Run > MMC > Add in Certificates snap-in for Local Computer account
– Expand to Certificates (Local Computer) > Personal > Certificates
– Right-click on your certificate > All Tasks > Manage Private Keys… > Add Network Service permissions.

Unfortunately, we won’t really be able to test this out until we install the ADAM/AD LDS instance so you may have to loop back to this step and review if you can’t connect to it later on.

5. Set up the Web App, Site Collection, Extend it to port 443, and Set up Forms-based Authentication – This was easy, basic SharePoint admin stuff. Just make sure you bind an SSL cert to the extranet site in IIS or else you won’t be able to browse to it.

Install ECTS

This was tricky as your mileage may vary depending on your environment. The setup wizard didn’t work for me so I had to install all the components manually one by one.

1. Run the ADAM Setup Script – As pointed out by a post in this thread, you’ll have to manually update the ects_setup_adam.vbs file to reflect the new location of ldifde.exe.

strLDIFDE =  objFSO.BuildPath(colProcessEnvVars(“windir”), “\system32\ldifde.exe”)

Then run cscript ects_setup_adam.vbs CN=ExternalUsers,DC=domain,DC=com

After this step you’ll be able to test to see whether or not your certificate from earlier works properly with your LDAP connection. To test this:

– Run > ldp.exe > Connect > your AD LDS server’s FQDN, port 636 (default), check SSL > OK
– You should get a response and no pop-up error.

2. Run the Database Setup Script – For some weird security issues, I was unable to run this script from my extranet server so I copied all the files over to my SQL Server and ran the script there with no problems.

cscript ects_setup_sql.vbs sql\instance

3. Run the ECTS Setup Script – This step really gave me some new gray hairs. For some reason I was getting the following error:

Adding the WSPs to SharePoint…
ERROR: Could not add the ECTSBase.wsp to SharePoint.  Script aborting…

So after awhile, I thought I would try on a Windows 2003 server to see what would happen. I noticed that this time the script went further than on the 2008 Server so I ran it once more but this time interrupted the script right after it generated the WSPs and before it tried to deploy. I copied the WSPs over to the Extranet server and then tried to manually add them to the solution store. Then I noticed that my service account didn’t have access to run STSADM even though it was a member of the Local Administrators’ group. I still don’t know why this is, but after running STSADM as the Local Administrator account I was able to do the following commands to add the solution to the solution store:

stsadm -o addsolution -filename c:\ECTSBase.wsp

stsadm -o addsolution -filename c:\ECTSSolution.wsp

Now they show up in Central Admin > Operations > Solution Management. Woohoo! From here you can deploy the 2 solutions to your web app. Next step is to activate the features at the Site Collection level. I compared the available number of visible features to the script file and noticed a discrepancy. There were some hidden features – 6 visible and 2 hidden.

So I carefully activated each feature one at a time according to their order in the setup script:

stsadm -o activatefeature -name ExternalCollaboration -url http://collab

stsadm -o activatefeature -name ConfigurationUtility -url http://collab

stsadm -o activatefeature -name SiteCollectionApproval -url http://collab

stsadm -o activatefeature -name SiteCollectionManager -url http://collab

stsadm -o activatefeature -name UserManager -url http://collab

stsadm -o activatefeature -name CreateSiteCollection -url http://collab

stsadm -o activatefeature -name ExternalUserApproval -url http://collab

stsadm -o activatefeature -name ECTSBase -url http://collab

Working with the ECTS Web Parts

Configuration Utility Web Part – At first I was unable to update any of the configurations but after scanning my event viewer, it mentioned that a service account had insufficient permissions to the SharePoint_AdminContent_GUID database. Fixed this by giving the account sys_admin permissions to that DB.

[Update – 7/30/2008 5:30pm]

Site Collection Manager Web Part – I was getting an access denied page when trying to approve the submitted site creation request. Event ID error 6141. Fixed it by making the Application Pool account run as a domain account instead of Network Service. – TechNet

Adding External Users Error/External Login Error: “An invalid dn syntax has been specified. (C:\inetpub\…\web.config line 133)”. Solved this by manually updating the web.config file’s ADAMConnectionString. The LDAP string was incompletely configured. Should be:

<add name=”ADAMConnectionString” connectionString=”LDAP://ADLDSserver.mycompany.com:636/CN=Users,CN=ExternalUsers,DC=mycompany,DC=com” />

To be continued… I’ll update this post with more information as I continue to work with the ECTS.