My Sharepoint Musings

So up till now at my new job, i have been by far more concerned with making sure my sharepoint farm has 100% uptime, is stable, and well working. Now that things are actually configured correctly (for the most part) and are stable i am looking at how much the sever is being used, and how fast it is. What i have found actually shocked me a little, and i have found a few bumps along the road. I know you thinking, "hey doesn't sharepoint have built in usage logs?" Yes, it does. Does it provide alot of information? No. Does it always work the way it is suppose to? Nooooooo. My most recent experience has been with our new landing page push out. Avg hit was in the multiple 1,000 loads perday for the first week. When i noticed this pattern i started to look into "hey, can i cache the page more" and yes, you can. So i turned on page caching for the whole site collection and then the following week, looked at my usage logs and saw something disturbing. My avg hits for th...

Because of various factors, i was forced to make my sharepoint site use basic authentication instead of NTLM, Kerbrose, or any other auth system. This had to do with our novel environment, and a number of user problems, mostly people forgetting to use our domain/username format to log into sharepoint. After reconfiguring everything to use the basic authentication method, i ran into a problem with sharepoint search and it's Default content access account. Namely, you can not tell sharepoint search to not try to log in using the default access account with out the domain infront of it's name. The solution i found on the web was to create a crawl rule for your site, (ex: http://intranet/*) and specify a different content access account for it, and then uncheck "Do not allow Basic Authentication". Problem with this is that in order for sharepoint to search the sites at all, it forced me to check (set) "Crawl SharePoint content as Http pages." That is a problem b...

Here's the situation: I deployed a demo version of a sharepoint webpart as a solution to my webserver before i deployed the full version. So i deploy it, added it to a webpage and tried it out. Afterwards i removed it from the webpage, and deactivated the solution, then retracted the solution. Now is where the trouble came in at: I went to go deploy the full version of it and i got a "dll is in use error". All attempts to remove this dll i got errors, and crashed the server a few times during the proccess as well. Fun stuff. The solution: The solution is remarkably simple that most people will look right over it: Go to the webpart galery for the site(s) you used the webpart on, and remove it from the gallery. After doing this (and making sure it wasn't on any of the other pages on the site) deploying the package went through with out a problem. Wish this was documented better (and the solution providor knew about it more).

For various reasons i wont go into it is pretty clear to me that the people who originally set up the search server had never restarted it.. ever. I am having some trouble getting search to function correctly, or even start back up normally after i restarted the search server. What oringally forced me to restart the server was during my morning browsing of the error logs on my servers, i noticed that the search server (MOSS) had no hard drive space left on it's c:\ drive. So after clearing out some *.log files and freeing up alot of space, i tried restarting the server. The error messages i get are as follow: Under Shared Services Administration> Search> Search settings The search service is currently offline. Visit the services on Server page in SharePoint Central Administration to verify whether the service is enabled. This might also be because an indexer move is in progress. On the search server (Moss) event log: The database connection string is not available. Event Ty...

So i'v been battling looking for a solution to this problem all day, then it hit me. So i just made a new server for my moss install, replacing the old search server. And for the life of me after i installed sharepoint on the machine, i could not get through the configuration wizard, it just, would not, go, though! No matter what username and password i put in, it wouldn't work. Solution: I was signed in as the local administrator! You have to sign on a domain account that has access to the sql server for it to work correctly! DOH! go figure. Now if i can just fix this package solution problem with out having to resort to restarting my server.

So here's a new one sports fans, was adding a custom content query webpart for a link list i made, visited the site on a test box to see how it looked and got this when i visited the site using the fully qualified domain name (that is http://intranet.ourdomain.org instead of just http://intranet) Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator. Since my page was bound to a page layout, i tried to reproduce the error on another page, and got this error when publishing (using a FQDN): The operation failed because the following URL does not correspond to a SharePoint site collection: http://intranet.domain.org/_layouts/IniWrkflIP.aspx. Ah! Now we are getting somewhere! So lets look up this problem! Found out it has to do with the Access mappings on the server not being configured correct...

So i have been having fun with the stsadm -o export function allllllllll wweeeeeeekkkk llooonnggg. Reference my earlier post about how to fix search not indexing to find out why. Needless to say, trying to export the site has not been... easy, or anything close to that. stsadm -o export -url http://mysite's_sub_site -filename d:\somefile.cmp -versions 2 Error: FatalError: There is no row at position 0. Cause: An item, a list, some object in your site is referencing permissions of someone who simply not in your database anymore. How? Who knows, easy fix tho: Solution: First find the next site it was about to go to, i do it this way personally: 1. stsadm -o enumsubwebs http://mysiteiamexporting 2. find the last site that it was exporting before it errored out. Your problem site is the next site. 3. Go to the site, go to the administration page. 4. Go to Advanced Permissions, Actions -> Edit Permissions, click O.K. 5. Actions -> Inherit Permissions. Bam site is fixed now. Hap...