Just another WordPress.com weblog
SharePoint Lessons Learned
This month I’d like to discuss a few things we’ve learned over the past year while trying to deploy MOSS 2007.
Our SharePoint deployment is more of an ASP model; each business unit that utilizes our SharePoint deployment wants their own unique URL. One of the things that we’ve discovered is when you create a Web App, (and create a new application pool for the web app) MOSS doesn’t give the application pool the appropriate permissions on the SharePoint Servers, which leads to a series of DCOM errors in the event log (Event ID 10016), to resolve this issue we’ve done the following.
- Add the application pool account to the local WSS_WPG group on each SharePoint server.
- Also, you need to Add the WSS_WPG group to the ‘IIS WAMREG admin Service’ in ‘Component Services’ browse to ‘Computers/My Computer/DCOM Config’ right click, go to properties, and click edit under ‘Launch and Activation Permissions’ add the account, and give ‘Allow’ to ‘Local Launch’, ‘Remote Launch’, ‘Local Activation’, and ‘Remote Activation’.
- You can either follow this route, or explicitly add each individual application pool account to the IIS WAMREG admin Service.
- Also, in our installation, we’ve removed anonymous access from the ‘Access this computer from the network’ in the local security policy, if you do the same, then you will either need to allow the WSS_WPG group, or the individual application pool accounts to this as well.
Setting up Host Header for SSL, this is another one that took a bit of research. Ultimately what we found was that there is a vb script in the Inetpub/AdminScripts directory called adsutil.vbs which allows you to define the host header for the site. You simply run the following command:
- adsutil.vbs set /w3svc/[identifier]/SecureBindings “IP:443:[host header name]”
So for example you’d run:
Adsutil.vbs set /w3svc/123456789/SecureBindings “192.168.1.10:443:mysharepointsite.com”
The [identifier] is the unique IIS Id of the virtual server.
We’ve also run into some crawling issues. Our WFE’s sit behind a hardware based load balancer (Cisco CSM). Currently our load balancer will not allow traffic to pass from behind it and then back in again. So basically when SharePoint tries to do a crawl, it does a DNS query for all of the SharePoint sites it needs to crawl. It then updates the HOSTS file with that information. So then when it attempts to do a crawl it tries to crawl via the Load Balanced IP address instead of the local address, which in turn our Load Balancer won’t allow. In order to work around the issue, we had to edit the HOSTS file on all of our SharePoint servers and add all of our URL’s with the actual local IP address instead, and then set it to read only otherwise every time SharePoint attempted to do a crawl it would overwrite our manual changes. Of course now we get hundreds of errors a day in the event log because SharePoint can’t edit the HOSTS file, go figure.
On a positive note, we’ve managed to resolve our SP1 issues, though not by actually fixing the problem. After 5 failed attempts based on Microsoft supports recommendations, we decided to completely rebuild the farm, and restore all the content manually. At the same time we migrated to 64bit hardware. We circumvented the SP1 issues by slipstreaming SP1 into our WSS/MOSS and Project 2007 installs.