My Sharepoint Musings

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

So there was a mix up to day on the Sharepoint site, apparently a test version of a MAJOR website was being worked on and went "poof". No biggy right? thats what backups are for. Unless the person who set up the backup used his username in the auth part of it and has since left the company. Thats right, since he left we haven't been backing up the sharepoint sites, any of them. Scarry stuff. Lession learned: Look not just at your web-front and your moss server, but your sql back up server's event logs. And DO NOT, repeat, DO NOT use your personal account when setting up mission-critical processes!

So a user of mine tried to edit a page in our massive collection of sites that document software applications and their use. When they went to (in editing mode) Page -> Page setting they got the following in their face: Error returned: User Not Found Source of problem: My predecessor had a search problem after he migrated users over to the MOSS 2007 server. A few users had the same GUID as each other, even tho they are suppose to be unique. So his solution was to delete the offending user out of the database manually... And that is how i got my problem. Parts of the sharepoint sites pull from the tp_ID feild and reference that. Others reference tp_GUID. This page uses tp_ID to pull the information it needs to generate the settings page. My hack-solution: This is unsupported by microsoft, note that i only did this as a temporay measure. I created, manually, a fake user in the database that used the same tp_ID as the one he deleted a while ago.. yes i had to do some annoying sql to ge

So my problem was i wanted to enable the Site Directory on the old WSS 2.0 page i migrated over, and no matter how many features i enabled on the page, it just would not allow me to create a SiteDriectory template page, even if i forced the issue with sharepoint designer. Silly me, solution is right in the Central Administration: Central Admin -> Operations -> Upgrade and Migration -> Enable features on existing sites. Yes even tho i told it to use the enterprise feature set, it could not do so unless i performed this step first..

Well there is a slight delay on some of my documentation about converting from 2.0 to 3.0. I am still in the process of documenting the process for the company, once that is finished i will do a quick conversion and put what i have up here for all to see. What i'd like to comment on is the domain\username to newdomain\username migration process which, in my case, needs to happen every time i convert another website from 2.0 to 3.0. During our migration process of moving WSS 2.0 to WSS 3.0 websites, i ran into a problem with the old server not being configured correctly. More to the point the server's user lists were not connected to our Active Directory. It was all done localy (yes, each user added to the local machine, and then added to the WSS 2.0 site). This was one of the driving factors behind why the company is converting over to MOSS servers. However, this brought up a problem for me as i converted the websites. How do i maintain username permissions but make everyone us

So i just started my new job as my company's "sharepoint guru" which so far involves administration, supporting, designing, redesigning of all of their sharepoint sites and infopath forms... which happens to span 3 different versions of sharepoint right now. You heard me right, from STS to MOSS, they have sites running on them all, and the plan is to have me negotate, migrate, and set up all of the old systems to play nice on MOSS. This is about when i should mention that i dont have previous sharepoint experince, or infopath. I do have a decade+ of webdevelopment experince as a part-time thing, but i have always stayed an arms length from microsoft products. And i am really starting to understand why as i start this long journey. As i fumble and trip my way through sharepoint administration and yes, migration, i will update this blog in hopes that people who run into the same head-against-wall moments i have had allready, can side step them, and keep moving forward. My