in·for·ma·tion / [in-fer-mey-shuhn]

After installation of the Reporting Services Add-in you may find that the “Reporting Services” section is missing in the site administration Application Management page.

Reporting services logs information to a log file in the “%temp% directory” for the user who is installed the Reporting Services Add-in, the file name is RS_SP_<number>.log. 

Check for an error activating the ReportServer Feature in the Central Administration:

******* User does not have permission to add feature to site collection: http://machinename:8080

This is because you are accessing the site using an account which does not have high enough permission, even though it may already be in the Site Administrators & Site Collection Administrators lists. Try logging in with an enterprise administration account.
Once you have logged in with a suitable account you will see Site Administration & Site Collection Administration in the site settings page: 

1. Go to SharePoint 3.0 Central Administration.
2. Select Site Actions -> Site Settings
3. Under the Site Collection Administration section click Site Collection Features
4. Activate the Report Server Integration Feature in the list

You will then see a Reporting Services section appear in the Site Settings page as well as the Application Management page.

Although you can have many views in a library (don't know the exact limit yet but I have 82 so far), it seems that the library/list 'edit shared webpart' view selector dropdown only displays 47 custom views plus the 4 defaults.
I guess I'm going to have to try to find a way to change that limit….

Oh, and the list of views available in the dropdown aren't sorted alphabetically.

There's also an annoying bug that when editing the current view and clicking ok, you are thrown back to the published page and the settings for the toolbar have defaulted to 'full toolbar' even if you have previously specified summary or no toolbar.  <sigh>

I recently had problems when trying to access a webservice installed on a web site in IIS 6.0. When browsing to the web service at http://server/webservice.asmx I recieved:

"Server Application Unavailable. The web application you are attempting to access on this web server is currently unavailable. Please hit the "Refresh" button in your web browser to retry your request."

The application event log returned two errors:

Event Type: Error
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1088
Description: Failed to execute request because the App-Domain could not be created. Error: 0×80070005 Access is denied. 

Event Type: Error
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1334
Description: Failed to initialize the AppDomain:/LM/W3SVC/2079486950/Root 
Exception: System.IO.FileLoadException Message: Could not load file or assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Access is denied. 
StackTrace: at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark) at System.Activator.CreateInstance(String assemblyName, String typeName) at System.AppDomain.CreateInstance(String assemblyName, String typeName) at System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironment(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters) at System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironmentAndReportErrors(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters) 

I found various references related to "Failed to initialize the AppDomain:/LM/W3SVC/2079486950/Root"

One of which suggested that the error lay with .Net not having been registered with IIS.

To solve this, navigate to your .NET directory (something like C:WINDOWSMicrosoft.NETFrameworkv2.0.50727) in a command prompt and run the command aspnet_regiis.exe -i which will register ASP.NET with IIS

However – this returned an error: "The error indicates that IIS is in 64 bit mode, while this application is a 32 bit application and thus not compatible."

D.oH! wrong directory for the .Net Framework – we are on a 64bit server after all – try in cmd:

cd C:WINDOWSMicrosoft.NETFramework64v2.0.50727aspnet_regiis.exe -i 

and you should then see…

Start installing ASP.NET (2.0.50727).

…………………………

Finished installing ASP.NET (2.0.50727).

Then…still no joy. Tried an iisreset without success.

So…More googling for:

"Failed to execute request because the App-Domain could not be created. Error: 0×80070005 Access is denied."

… revealed (damn! you have to love google!) a post by dclaassen which suggested permissions at the website root…

So, as instructed I tried adding the Network Service account with read permissions to the website root folder and… voila!

[additional: later reconfigured the webservices to use integrated authentication and set the web application hosting the webservices to use the main MOSS portal application pool. This meant the webservices would use the logged in user correctly] 

When trying to access the Shared Services Provider Search Settings on a newly restored farm (http://server:54321/ssp/admin/_layouts/searchsspsettings.aspx) I'm getting the following error:

'Exception from HRESULT: 0×80040D23'

This initial error corresponds to an application event log:

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Timer
Event ID: 6398
Date:  2008-01-09
Time:  11:04:49
User:  N/A
Computer: <SERVERNAME>
Description:
Ett undantagsfel uppstod f”r k”rningsmetoden f”r jobbdefinitionen Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 6acb7104-0309-459f-aebb-55003e90a509). Mer information finns nedan.

Exception from HRESULT: 0×80040D23

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
—-

Uncommonly the Help & Support Center actually has a related article: Event ID 6398 Timer JobsURL: http://technet2.microsoft.com/windowsserver/WSS/en/library/76736512-efb5-406c-9ae9-ef619393f3ad1033.mspx 

However, this didn't offer any resolution – using the repair function did nothing.

Checking the services Start > Administrative Tools > Services and looking at the “Office SharePoint Server Search” service showed the service as stopped. Manually starting it gave the following pop up dialogue error:

Error 183: Cannot create a file when that file already exists.

The Application event log then showed an information event (ID: 1013) saying that the search service had terminated normally. Then shortly after the same Event ID: 6398 – Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 6acb7104-0309-459f-aebb-55003e90a509).

Additionally another error, also related to the 'Exception from HRESULT: 0×80040D23' :

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Delade tj„nster f”r Office Server
Event ID: 6482
Date:  2008-01-09
Time:  11:40:49
User:  N/A
Computer: AVENLNDSRV010
Description:
Programserveradministrationsjobbet misslyckades f”r tj„nstinstansen Microsoft.Office.Server.Search.Administration.SearchServiceInstance (4aa10976-553a-4176-a302-2c3337637d6d).

Orsak: Exception from HRESULT: 0×80040D23

Information om teknisk support:
System.Runtime.InteropServices.COMException (0×80040D23): Exception from HRESULT: 0×80040D23
   at Microsoft.Office.Server.Search.Administration.MSSITLB.IGatherManagerAdmin3.get_ConfigurationVersion()
   at Microsoft.Office.Server.Search.Administration.Gatherer.ProvisionGlobalProperties()
   at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
   at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
—

I checked the permissions on the databases and the account used for the search services was a db owner. It wasn't until I set the permissions for the services to be the system account (as opposed to a separate account for the search) that the SSP Search Settings became available again.
Worryingly, somewhere in the restore process the permissions have been messed up. Time for further testing & re-identifying the roles and permissions for the admin accounts. 

During a client installation I came accross a stumbling block when trying to map a UNC path to a WSS 3.0 document library.

The issue was that I need to batch copy files from one server share directly into a WSS 3.0 document library via the windows explorer view (UNC path).
However, while this works like a charm from Windows XP, doing this from a w2k3 server to another w2k3 server is problematic.
Having tried adding the UNC path mapping using command line: Net use X: \ServerSiteDocLib, and via windows explorer mapping to: \ServerSiteDocLib , both returned the error:

System error 67 has occurred. The network name cannot be found.

Since the other common way of accessing this, using the document library GUI and using the Actions > Open with Windows Explorer, failed to activate (as I thought due to the default IE lockdown on a w2k3 server), the following have also been set:

* The user account is a site owner in WWS 3.0 and is in the Power User group on the web server.
* Default IE security lockdown has been disabled on the w2k3 server
* All Active X controlls have been enabled
* The site is in a trusted zone

Still no joy.

After some head scratching & further investigation and eventually resorting to the 'phone a friend' option I was relieved to find that the answer was a reltively simple one:

Start the Web Client Service under services and set it to startmode automatic.

You've installed the PDF iFilter on the server and registered the dll…. you've added the icon to the images folder and the reference to the xml file… you've added the file type in the Shared Services provider Search Settings… you've run the full search indexing for the portal…

…the icon for pdf will display correctly in lists & libraries….but you *still* don't get pdf documents appearing search results??

You wouldn't happen to be running a 64bit server for SharePoint or SQL ??

If you are then there's some bad news for you. Adobe have not yet released a 64bit version of the iFilter for PDF. And while the 32bit version installs without error you will not get any results appearing in the SharePoint search.
As yet Adobe have not announced when (or even if) they will release this.

In the meantime there is an alternative…. Use this 64bit iFIlter from Foxit Software

Note: the installer does not register the application with MOSS 2007. After installing you will need to manually add a pdf extension in the registry settings:

  1. Open regedit and locate the following:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions12.0SearchApplications<SiteID>GatherSearchExtensionsExtensionList]
  2. Add a new String value with the latest number in the sequence and edit it to add pdf as the Value data.

Then, check that the pdf file type shows in the portal Shared Services Administration:
  1.  Under Search click Search Settings
  2.  Under Crawl Settings click File Types

If not then add it:
  1.  Click New File Type and add pdf

Incidentally, this will add the following reference for the pdf file type in the registry:
  1. Open regedit, locate [HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice Server12.0SearchSetupContentIndexCommonFiltersExtension.pdf] 
  2. Check the default value is {987f8d1a-26e6-4554-b007-6b20e2680632}

Check also that you have the .gif file that you want to use for the pfd icon in the following folder on the server: 
  Drive:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TemplateImages

(the icon can be found here (use the 17 x 17 one): http://www.adobe.com/misc/linking.html)
Then: 
  1. Edit the Docicon.xml file to include the .pdf extension. To do so: 
      Start Notepad, and then open the Docicon.xml file here: Drive:Program FilesCommon FilesMicrosoft SharedWeb server extensions12TemplateXml 
  2.  Add an entry for the .pdf extension. For example, where NameofIconFile is the name of the .gif file: <Mapping Key="pdf" Value="NameofIconFile.gif"/> 
  3.  On the File menu, click Save, and then quit Notepad. 

Next – REBOOT THE SERVER! (Before doing this there were a few minutes frustration. Simply stopping & starting the services, iisreset etc is not sufficient)

When rebooted go back to the portal Shared Services Administration and start a full crawl:
  1. Under Crawl Settings click Content sources and Crawl Schedules
  2. Click the arrow icon next to your Shared Service (Default name is: Local Office SharePoint Server Sites) and select Start Full Crawl

One more catch though… it's not free like the Adobe one would be. Though you can download and install it to "test" before coughing up the cash for the license.

We've recently been messing about with the CRM & MOSS integration features, and while the initial setup of the MOSS farm on Kerberos authentication wasn't the most straightforward we are now getting issues when trying to conect two CRM webparts for filtering. This doesn't happen if we connect a regular web part with a CRM list web part. It happens only between two CRM list web parts. 

The target webpart returns the following error:

"An error has occurred. This Web part could not be displayed. ERROR [42000] [Microsoft][ODBC SQL Server Driver][SQL Server]Conversion failed when converting from a character string to uniqueidentifier"

 As an additional part of this error, on refreshing the page or trying to redefine the filter, the target webpart for the filtering also returns the following:

When using the content editor web part, in some cases you can receive the following message when editing the content, or saving the content: "cannot retrieve properties at this time".

This exact error suddenly appeared on a client installation after https access was enabled via ISA server. Prior to that the content editor web parts worked normally over http. When browsing the site using the server name there is no problem. The issue therefore lies with the https translation.
The sites alternate access mappings are configured with the https url as an extranet. Changing this to any of the other options makes no difference.

Mart Muller refers to a MS KB article in his post here however I'm not sure this is correct. Neither of the two supposed causes are applicable in this case:

Further investigation ongoing…

I'm not one to complain, but…

[rant]

Yet again I find that one of the most intuitive, flexible site templates is hobbled for no good reason. Why on earth is the Multipage Meeting Workspace so restricted compared to the Team Site???

To begin with, lets take the function for 'save site as a template'….
- Team Site – 'save site as template' allows for inclusion of content. Great, nice one, useful feature that.
- Multipage Meeting Workspace – 'save site as template' DOES NOT allow for inclusion of content. WTF?? why on earth should I be restricted in this site?? maybe some people use this template for other things than meetings because we find the page tab layout extremely useful. This was a problem in 2003, why the hell hasn't it been fixed in 2007??

And then today I discovered another shortcoming that may not be quite so apparent. The new 2007 feature 'Send to location'…
- Team Site – document: Send to > Other location, add location (by typing instead of a browse function, hello? is this 2007??), send – file is copied. Ok. 
- Multipage Meeting Workspace – document: Send to > Other location, add location (grr), send – ERROR! "There were errors copying to this location. The destination is in a meeting workspace, which does not support this action."  DoH!!
I'm speechless. No, really.
Hello!!?? is there any light on in the MOSS development office??? WHY is this not possible in the Multipage Meeting Workspace site??? For what possible reason would I not want this feature available in this site template???

And do you know how I discovered this?? In testing the workflow features of SharePoint Designer in a Multipage Meeting Workspace site.

cue..

[subrant]

Somehow the development team for SharePoint Designer forgot to include the workflow function to allow MOVE document from one location to another. Instead you have to COPY the document to the destination location and then DELETE the original!!

Words begin to fail me at this point. Why on earth was this feature overlooked?? 9 times out of 10 a user will probably want to move a document rather than duplicate it. Surely this can't have been difficult for the development team to include??

Now I have to deal with a substandard method for getting a document from one location to another and finding that the DELETE step in the custom workflow causes the document in the target location as well as the origin location to be deleted!! Probably because this is a, you guessed it… Multipage Meeting Workspace site.

[/subrant]

And in case you're wondering, yes, the workflow function for copying a document from one location to another on a Multipage Meeting Workspace site works even though you can't do it via the drop menu 'Send to > Other location' options in the library!!!  o_0

[/rant]