SharePoint 2007 and WSS 3.0 Administration

The Business Data List Web Part requires an Application Definition File (.xml) to configure the BDC connection to SQL Server 2005. This file defines the connection, entities, and methods needed to expose external data through the Business Data Catalog. The other options describe unrelated SharePoint operations.

The Lists.asmx web service (accessed as list.asmx) provides SOAP-based operations for retrieving and manipulating SharePoint list items in MOSS 2007. This service supports methods like GetListItems to query list data. Option A is incorrect, Option C refers to a REST/OData service introduced in later versions, and web services do exist for this purpose.

SharePoint 2007 uses IFilter (Installable Filter) technology to index various file formats including PDF documents. The PDF IFilter must be installed on the index server to enable full-text search within PDF content. Options A, B, and C are not valid SharePoint filter components.

In the Business Data Catalog, FilterDescriptors define how users can query external data. Setting the Type to 'Comparison' enables equality-based filtering (like 'is equal to'), while 'Wildcard' enables pattern matching. The filter type must be configured in the Application Definition File under the FilterDescriptors node.

Generic lists in SharePoint use List Template ID 100. This ID allows event receivers to be scoped to all generic lists created in the site collection. Template ID 100 is the standard identifier for custom generic lists, while 101 is for document libraries and 99 for other list types.

STSADM solution commands include addsolution, deploysolution, retractsolution, and deletesolution - but NOT removesolution. Option D is incorrect because 'removesolution' is not a valid STSADM command in SharePoint 2007. The correct command to remove a solution from the store is 'deletesolution'. Options A, B, and C show valid STSADM syntax.

The CMS Assessment tool is the correct utility for identifying migration tasks when moving from MCMS 2002 to Microsoft Office SharePoint Server (MOSS) 2007. This tool scans the existing MCMS 2002 installation and provides a detailed report of all content and settings that need to be migrated, helping administrators plan the migration process. The prescan.exe utility mentioned in option A is related to SharePoint upgrades, not MCMS migrations, while stsadm commands with upgradesolution or createcmsprofile operators serve different purposes for SharePoint operations.

In SharePoint, a single content database can host multiple site collections, which is a common practice for efficient database management. However, a single site collection cannot span multiple content databases - it must reside entirely within one content database. This architecture is fundamental to SharePoint's content storage design. Option B incorrectly states that multiple site collections cannot point to a single content DB, while option C incorrectly suggests a site collection can span multiple databases.

To deploy a SharePoint feature, you must create a folder in the 12\TEMPLATE\FEATURES directory (option A), not in the bin directory. Within this folder, a Feature.xml manifest file (option C) is required to define the feature's properties and elements. The Central Administration interface is used to activate features after installation, not for the initial installation itself - that requires stsadm commands or PowerShell. The 12\bin\FEATURES path (option B) is incorrect as features are template definitions, not binary executables.

In SharePoint 2007's content type hierarchy, 'System' is the root parent content type from which all others derive. Content type IDs are hexadecimal strings that always start with '0x' - this is part of their internal identifier structure. 'Item' is a built-in content type but not the parent - it's a child of System. 'Document' is another built-in content type derived from Item, not the parent. The System content type serves as the ultimate base for the entire content type inheritance tree.

To prevent a document deletion, you must use the ItemDeleting event (option B), which fires before the deletion occurs and can be cancelled. The ItemDeleted event (option A) fires after deletion is complete, making it too late to prevent. Setting properties.Cancel = true (option C) within the ItemDeleting event handler cancels the deletion operation. Setting it to false (option D) would allow the deletion to proceed, which is the opposite of what we want.

Creating a custom field type in SharePoint requires three components: an XML definition file (option A) that defines the field type, a field class (option B) that represents instances of the field, and this class must inherit from SPField (option D) or one of its derived classes. SPCustomField (option C) is not a valid base class in the SharePoint object model - this is a common misconception. The correct base class is SPField, which provides the foundational functionality for all SharePoint field types.

SharePoint Designer can modify pages stored in the content database (option A), which includes site pages and web part pages. It can also modify master pages (option C), which are also stored in the content database. However, it cannot modify pages stored on file shares (option B) or application pages (option D), which are physical files in the SharePoint root directory and are not editable through SharePoint Designer. Application pages must be edited using tools that can access the server's file system directly.

The Content Query Web Part (CQWP) can query from a specific site collection (option B), from one specific site and all its subsites (option C), or from a specific list (option D). However, it cannot query across multiple site collections (option A) - this is a known limitation of the CQWP in SharePoint 2007. Each CQWP instance is scoped to a single site collection, making cross-site collection aggregation impossible with this web part alone.

Packaging a workflow feature in SharePoint 2007 requires four files: Manifest.xml (option A) defines the solution manifest, Feature.xml (option B) defines the feature itself, Workflow.xml (option C) contains the workflow definition, and Package.ddf (option D) is the makecab directive file for packaging the solution into a .wsp file. All four files are essential components of the workflow packaging process. The Manifest.xml lists the features in the solution, Feature.xml declares the workflow feature, Workflow.xml defines the workflow structure, and Package.ddf controls the cabinet file creation.

Business Data List Web Part displays business data in tabular format. Business Data Item Web Part shows details for a single item. Business Data Actions Web Part presents available actions on business data entities. Business Data Column is not a standard Web Part.

SharePoint 2007 Enterprise can index network file shares through file protocol sources. External websites are indexed using HTTP/HTTPS content sources. BDC exposes relational database data for indexing. Lotus Notes requires additional connectors not available out-of-box.

Content Deployment can copy web pages and their associated resources like images, style sheets, and layout pages between site collections. It does not copy assemblies, features, or web.config changes as these are deployment infrastructure elements specific to the source environment.

Solution packages in WSS/MOSS can deploy custom DLLs to GAC or Bin, apply web.config changes, install Features, and include resource files like images. These are the core deployment artifacts managed by the solution framework.