I'm posting this because it took me two hours to find - I've received an error that no Exchange 2007 server running the address list service could be found when trying to move a mailbox.
First of all the "Microsoft Exchange System Attendant" service stopped, I've set that to auto-restart.
Secondly, cause 2 (no inherited permissions on the address lists, use adsiedit to correct) solved the issue:
http://support.microsoft.com/kb/935636
Fix PDF in search of WSSS 3.0 and MOSS 2007
- Install Acrobat Reader 8 on the Sharepoint Webserver
- get a PDF icon in GIF format, e.g. pdf16.gif see this post: http://msmvps.com/blogs/cgross/archive/2004/10/26/16679.aspx
- save it into \program files\common files\microsoft shared\web server extensions\12\template\images
- make sure ACLs fit! Right click the file, Security, Advanced, "Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with the entries explicitely defined here."
- edit \program files\common files\microsoft shared\web server extensions\12\template\xml\docicon.xml and add the pdf extension
add the line just above the png mapping: <Mapping Key="pdf" Value="pdf16.gif"/>
- go into your shared services provider, search settings, file types, add file type,
add file extension PDF, the icon should appear!
for WSS 3.0 search:
- add Value named "38" as String value (assuming 1 to 37 are filled) to HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Applications\{ANYGUID}\Gather\Search\Extensions\Extensionlist and set "PDF" as the value.
-> see KB Article for reference: http://support.microsoft.com/kb/927675/en-us
then:
http://blogs.msdn.com/ifilter/archive/2007/03/29/indexing-pdf-documents-with-adobe-reader-v-8-and-moss-2007.aspx
for safety, I'll copy the settings mentioned in this article:
The version 8 of the adobe reader has some significant architectural changes (for the better of course) including an inbuilt IFilter to index PDF documents. Previously the adobe IFilter was available as a seperate download. This new change in architecture compromised the ability to search pdf documents from within MOSS 2007. However, the pdf filter works fine with WDS 3.0 . While many consultants recommend that if we're to index pdf documents through MOSS 2007, we use the the v.6 of adobe IFilter and if we want to index pdf documents through WDS 3.0 or higher, we use the v.8 of adobe reader. But what if we wanted to index pdf documents using both WDS and MOSS 2007?!!! Here's how you can use MOSS 2007 with adobe reader v.8, the version currently patronized by WDS:)
1. Download Adobe Reader v.8 .
2. Add the filter-extension to the File types crawled:
Start -> Program -> Microsoft Office Server -> SharePoint 3.0 Central Administration -> <Name of SharedService Provider> -> Search Settings -> File Types -> New File Type (Add extension pdf here)
3. Modify the following Registry keys by changing their "Default" value to the new CLSID of the Adobe IFilter: {E8978DA6-047F-4E3D-9C78-CDBE46041603}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office
server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf
Default --> {E8978DA6-047F-4E3D-9C78-CDBE46041603}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server
Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf
Default --> {E8978DA6-047F-4E3D-9C78-CDBE46041603}
4. Add the Installation directory of the Adobe Reader v.8 to the System Path. For example, if the Reader is installed on "D:\Program Files\Adobe", then add "D:\Program Files\Adobe\Reader 8.0\Reader" to the system path by:
--> Right Click on My Computer -> Properties -> Advanced -> Environment Variables -> Path (Under System Variables) -> Edit -> (Add "D:\Program Files\Adobe\Reader 8.0\Reader").
This effectively tells the adobe IFilter where to pick up the dependent DLLs.
5. Recycle the search service: > net stop osearch
> net start osearch
Sources:
Deb Haldar's Article on how to get AdobeReader8 Ifilter to work:
http://blogs.msdn.com/ifilter/archive/2007/03/29/indexing-pdf-documents-with-adobe-reader-v-8-and-moss-2007.aspx
Specify file types to crawl:
http://technet2.microsoft.com/Office/en-us/library/0f60c820-83c7-4d2b-99f2-8c49cff494481033.mspx?mfr=true
Limit or increase the quantity of content that is crawled:
http://technet2.microsoft.com/Office/en-us/library/51caa05d-b0bb-4598-bcc8-82d2723ba6101033.mspx?mfr=true
File types and IFilter reference:
http://technet2.microsoft.com/Office/en-us/library/09357d8e-37b9-4e96-b8fd-f17b990d010a1033.mspx?mfr=true
Now you've downladed all the Server Admin Templates from Microsoft from http://www.microsoft.com/downloads/details.aspx?FamilyID=5807b5ef-57a1-47cb-8666-78c1363f127d&DisplayLang=en and see that you'll have to individually import them using stsadm.exe.
Here is a little shortcut for you.
Start AllTemplates.exe and extract all files into a directory.
Create a .cmd file called deploy.cmd with the following content:
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o addsolution -filename %1
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o deploysolution -name %1 -allowgacdeployment -immediate
Create another .cmd file called startdeploy.cmd with the following content:
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o addsolution -filename ApplicationTemplateCore.wsp
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o deploysolution -name ApplicationTemplateCore.wsp -allowgacdeployment -immediate
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o copyappbincontent
call dodeploy AbsenceVacationSchedule.wsp
call dodeploy ApplicationTemplateCore.wsp
call dodeploy BudgetingTrackingMultipleProjects.wsp
call dodeploy BugDatabase.wsp
call dodeploy CallCenter.wsp
call dodeploy ChangeRequest.wsp
call dodeploy ComplianceProcessSupport.wsp
call dodeploy ContactsManagement.wsp
call dodeploy DocumentLibraryReview.wsp
call dodeploy EventPlanning.wsp
call dodeploy ExpenseReimbursementApproval.wsp
call dodeploy HelpDesk.wsp
call dodeploy InventoryTracking.wsp
call dodeploy ITTeamWorkspace.wsp
call dodeploy JobRequisition.wsp
call dodeploy KnowledgeBase.wsp
call dodeploy LendingLibrary.wsp
call dodeploy PhysicalAssetTracking.wsp
call dodeploy ProjectTrackingWorkspace.wsp
call dodeploy RoomEquipmentReservations.wsp
call dodeploy SalesLeadPipeline.wsp
Call startdeploy.cmd.
One of the long delayed tasks I've wanted to perform for quite a while was to upgrade our extensively used intranet based on Windows Sharepoint Services 2.0.
For this purpose I installed WSS 3.0 on the same box and decided on the side-by-side upgrade approach... and the nightmare began.
- WSS 3.0 installation itself - side-by-side - runs without any problems whatsoever on the same box. Sure, that must be something the MS developers did about a million times.
Trial upgrade - content issues:
- copy the database to a new database
- run "prescan.exe /all" in the 12 hive
- create a new web application
- assign the new database to it on the GUI fails, tells you to do it with stsadm.exe
- run "stsadm.exe -o addcontentdb -url xxx - databasename yyy", success on that
- Test the site.
- Front page works fine, any page underneath does not work with "master page not defined"!
- check the database, table "webs", for field "MasterUrl" - is empty!!
- change this to "_catalogs/masterpage/default.master"
- now error "master page not found"
- open the web with Sharepoint Designer 2007
- "_catalogs/masterpage/" is empty!
- create an empty new application and site with the team template, copy the whole "_catalogs" directory over using sharepoint designer
- Now I can browse the content and see our migrated data just fine
- Try to add a user using site admin, new error "list not found"
- Back to the database, check table "lists". ALL the system tables are missing.
Sharepoint crashing server issues:
-
At a certain point our Webserver refused work with any SQL connections to any SQL server. This sounds strange, doesn't it. We do have two SQL servers and a couple of ASP and ASP.NET sites using both of them. ALL sites stopped working!
-
Sharepoint refused working, stating "configuration database not found" - this is for WSS 2.0 and 3.0!
-
-
Some errors from the application event log:
-
Cannot connect to SQL Server. x64a not found. Additional error information from SQL Server is included below.
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
#50070: Eine Verbindung zur Datenbank STS_web3_1625862223 auf x64a kann nicht hergestellt werden. Bitte überprüfen Sie die Datenbankverbindungsinformationen und versichern Sie sich, dass der Datenbankserver läuft.
-
Unknown SQL Exception 10048 occured. Additional error information from SQL Server is included below.
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: TCP Provider, error: 0 - Only one usage of each socket address (protocol/network address/port) is normally permitted.)
- The Execute method of job definition Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition (ID 4f7f6523-ed76-43f7-903c-e01de21d69ea) threw an exception. More information is included below.
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: TCP Provider, error: 0 - Only one usage of each socket address (protocol/network address/port) is normally permitted.)
This last error gave me something more to search for on google and gave me the hint that something on the Office Sharepoint Search might be corrupted.
Indeed, this helped.´
In addition, I've had DCOM local activation errors in the log.
How to fix those: open regedit, search for the GUID that's in the event - this gets you to HKEY_CLASSES_ROOT\CSLID...
Note the name of the key plus the "AppID".
Open DCOMCNFG, open "Component Services, Computers, My Computer, DCOM Config", select "View - Detail", look for the Application ID noted from the Registry Key "AppID". Note it will have a similar name, but not necessarily the same name, to name of the key found in the Registry.
E.g. "Microsoft Office SharePoint Server Search Gathering Manager" with Key name HKEY_CLASSES_ROOT\CLSID\{3D42CCB1-4665-4620-92A3-478F47389230} is called "Osearch" with Application ID {58F1D482-A132-4297-9B8A-F8E4E600CDF6} in DCOM Config.
Right Click on the line, click "Properties", go to the "Security" tab, click on "Edit" under "Launch and Activation Permissions", and add the service account that was missing the permission to the ACL and grand "Local Launch/Local Activation".
I had permissions missing for above Office Search and for "IIS WAMREG admin service"