SQL databases used in Sharepoint There are quite a number of databases generated during a Sharepoint install and depending

on the "Farm" configuration there might be more or less. A lot of SQL DBA's get quite annoyed when all these databases suddenly appear in their system and they have no idea what each database does or why it is there. I have therefore decided to explain what databases get created during a MOSS install and what the purpose is behind each. A WSS install generates less databases and therefore I decided to focus on a MOSS install as this generates the most. Lets start by taking a look at a screen shots of the databases generated and then I will explain the purpose of each.

Below is a list of the databases generated by Sharepoint, the names may differ per deployment, but the purpose remains the same:

Config Database for the Farm - Sharepoint_Config - stores configuration information about the servers deployed in the farm , their individual configurations settings and some security information. Without this database there is no Sharepoint. Content database for the Admin Console - Sharepoint_AdminContent_GUID - sharepoint uses its own technology to render the web based admin console for Sharepoint. Therefore it needs it's own content database to stored the configuration settings for the web parts used. The actual data configured using this console is stored in the config database for the farm. The name for this database is system generated and cannot be controlled during the installation process and therefore it ends with a GUID. Config database for the SSP (Shared Service Providers) - BPS_SharedServices_DB - during the configuration process a SPP is defined to configure all the Shared Services used by Sharepoint. All the Configuration settings for these services are stored in this database. The name of the database can be controlled during the creation process and should be descriptive of the purpose. Content database for the SSP Console - BPS_SSP_Content - just like the admin console the SSP also needs a web site to allow you to configure the shared services and these also use web parts and lists. Therefore the SSP also needs its own content database to store these settings. SSP Search database - BPS_SharedServices_Search_DB - this database is used by the Enterprise search service to store metadata about the information crawled including typically security information. This is used for information stored external from Sharepoint. WSS search database - WSS_Search_sps-dc1 - this database is used by the WSS core components to store metadata about content stored inside the Sharepoint web application content databases. This is created during the installation process. Web Application Content - Office Content - this is the content database for the first user based web site in Sharepoint. Before the users can actually use Sharepoint a "Web Application", Site Collection and Site must be built. This database stores all the information generated within this web application. Additional content databases - Office_Content_2 - new content databases can be created to host additional "Site Collections" and "Web Applications" and there could be hundreds of these.

The other databases that are left over in the snapshot is used by other applications that do not have a direct influence on Sharepoint, but can be used in conjunction with the product. SQL Server system databases and sample databases

Project Server 2007 databases Live Communication Server 2005 databases. Reporting Services databases.

The databases in MOSS 2007 Since MOSS is more advanced than WSS, it also needs more types of databases to perform its tasks. Two of these types are the same as in a WSS environment, and the others are exclusive to MOSS installations. When installing MOSS using the Basic mode, each database name will have a suffix based on a Globally Unique Identifier (GUID) string, which is a 32-character-long string. If you install MOSS using the Advanced mode, you will be able to set these names manually: Configuration database: (Used by WSS and MOSS.) Contains SharePoint

configuration settings, such as front-end and back-end servers, mail servers, and portal site names. The name for this database is SharePoint_Config. Content database: (Used by WSS and MOSS.) Contains the actual data,

stored in the portal site and the team sites. Default name prefix: WSS_Content. Shared Services database: (Used by MOSS.) Used to store information

about the Shared Service provided; its default name is SharedServices1_DB. Shared Services Search database: (Used by MOSS.) Stores search index

and related content in the database SharedServices1Search_DB. Shared Services Content: (Used by MOSS.) Stores general information for

the Shared Services Provider instances in the database SharedServices_Content. Administrative Content: (Used by MOSS.) Stores content related to central

administration in the database file SharePoint_AdminContent. You may create a new content database when needed, but the other types must exist in one copy only. Besides these databases, you may create one more, when installing the Single Sign-On function in MOSS. That database will be named by the administrator (for example, SSO for single sign-on). Deploy using DBA-created databases (Office SharePoint Server) About deploying by using DBA-created databases In many IT environments, database administrators (DBAs) create and manage databases. Security policies and other policies in your organization might require that DBAs create the databases required by Microsoft Office SharePoint Server 2007.

This article discusses how DBAs can create these databases and farm administrators configure them. This article describes how to deploy Office SharePoint Server 2007 in an environment in which DBAs create and manage databases. The deployment includes all the required databases, one portal site, a Shared Services Administration Web site, My Sites, and one Shared Services Provider (SSP). This article only applies to farms that use Microsoft SQL Server 2000 with the most recent service pack or Microsoft SQL Server 2005 database software. Some procedures in this article use the Psconfig or Stsadm command-line tools. These tools are located in the following folder: Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN. Using these procedures, the DBA will create databases and the farm administrator will perform other configuration actions in the following order: The configuration database (only one per farm). The content database for Central Administration (only one per farm). Central Administration Web application (only one per farm, created by Setup). The Windows SharePoint Services search database (only one per farm). Start the Office SharePoint Search service.

For each portal site: Portal site Web application content database.

For each SSP: A content database for the My Sites Web application (if the SSP is using its own Web application). A content database for the Shared Services Administration Web application (if the SSP is using its own Web application). SSP Search database (one per SSP). SSP Web application (created by Setup if the SSP is using its own Web application).

Required database hardware and software Before you install and configure the databases, be sure that your database servers have the recommended hardware and software. For more information about these requirements, see Determine hardware and software requirements (Office SharePoint Server). There are also requirements specific to the database server, and, if you are using SQL Server 2005 database software, the DBA must configure surface area settings so that local and remote connections use TCP/IP only. All of the databases required by Office SharePoint Server 2007 use the Latin1_General_CI_AS_KS_WS collation. All of the databases require that the Setup user account be assigned to them as the database owner (dbo, or db_owner). For more information about the security requirements for these databases, see Plan for administrative and service accounts (Office SharePoint Server).

Required accounts The DBA needs to create SQL Server logins for the accounts that are used to access the databases for Office SharePoint Server 2007 and add them to roles For more information about the required accounts, including specific permissions and roles required for these accounts, see Plan for administrative and service accounts (Office SharePoint Server). The following table describes the accounts that are used to access the databases for Office SharePoint Server 2007. Account SQL Server Service Account Purpose Requirements

This account is used as the service SQL Server prompts for this account during SQL account for the following SQL have two options: Server services: Assign one of the built-in system account MSSQLSERVER Network Service, or Local Service) to the logo configurable SQL Server services. For more in SQLSERVERAGENT these accounts and security considerations, r If you are not using the default Up Windows Service Accounts topic instance, these services will be (http://go.microsoft.com/fwlink/?LinkId=121 shown as: in the SQL Server documentation. MSSQL$InstanceName Assign a domain user account to the logo SQLAgent$InstanceName However, if you use this option you must tak steps required to configure Service Principal N Active Directory in order to support Kerberos which SQL Server uses.

Setup user account

The Setup user account is used to Domain user account run the following: Member of the Administrators group on e Setup on each server which Setup is run The SharePoint Products SQL Server login on the computer runnin and Technologies Member of the following SQL Server secu Configuration Wizard securityadmin fixed server role The PSConfig command dbcreator fixed server role line tool If you run Stsadm command-line tool command The Stsadm commandwrite to a database, this account must be a mem line tool the db_owner fixed database role for the datab The Server farm account is used to: Act as the application pool identity for the SharePoint Central Administration application pool. Run the Windows SharePoint Services Timer service.

Server farm account/Databas e access account

Domain user account. If the server farm is a child farm with We consume shared services from a larger farm, be a member of thedb_owner fixed database configuration database of the larger farm. Additional permissions are automatically granted Web servers and application servers that are joi This account is automatically added as a SQL Se computer running SQL Server and added to the security roles: dbcreator fixed server role securityadmin fixed server role db_owner fixed database role for all dat server farm

Create and configure the databases Use the procedures in this section to create the required databases and give the accounts membership in the database Users security group and database roles. The procedures require action by the DBA and the Setup user account. Each step is labeled [DBA] or [Setup] to indicate which role performs the action. The following procedure will only have to be performed once for the farm, on the server you want to run the Central Administration Web site. The farm only has one configuration database and one content database for Central Administration. Create and configure the configuration database, the Central Administration content database, and the Central Administration Web application 1. [DBA] Create the configuration database and the Central Administration content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [Setup] Run Setup on each server computer in the farm. You must run Setup
Note:

on at least one of these computers by using the Complete installation option.

The rest of the farm servers will be configured after the procedures in the article are finished and the farm is established. You will run the SharePoint Products and Technologies Configuration Wizard on these servers by selecting the Yes, I want to connect to an existing server farm option, instead of by using the commands used in this procedure.

3. [Setup] On the server on which you used the Complete installation option,
do not run the SharePoint Products and Technologies Configuration Wizard after Setup. Instead open the command line, and then run the following command to configure the databases:

Psconfig cmd configdb create server <SqlServerName> database <SqlDatabaseName> user <DomainName\UserName> password <password> admincontentdatabase <SqlAdminContentDatabaseName> Note: <SqlDatabaseName> is the configuration database. -user is the server farm account.<SqlAdminContentDatabaseName> is the Central Administration content database. 4. [Setup] After the command has completed, run the SharePoint Products and Technologies Configuration Wizard and complete the remainder of the configuration for the server. This creates the Central Administration Web application and performs other setup and configuration tasks. 5. [DBA] After the SharePoint Products and Technologies Configuration Wizard has completed, perform the following actions for both the configuration database and the Central Administration content database: Add the Office SharePoint Server Search account, default content access account, and the SSP service account to the Users group.

Add the Office SharePoint Server Search account, default content access account, and the SSP service account to the WSS_Content_Application_Pools role.

6. [Setup] To confirm that the databases were created and correctly configured, verify that the home page of the Central Administration Web site can be accessed. However, do not configure anything by using Central Administration at this time. If the Central Administration page does not render, verify the accounts used in this procedure and ensure that they are properly assigned. The following procedure will only have to be performed once for the farm. The farm has only one Windows SharePoint Services search database. Create and configure the Windows SharePoint Services Search database and start the Windows SharePoint Services Search service 1. [DBA] Create the Windows SharePoint Services Search database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account. 2. [Setup] Open the command line, and then run the following command to configure the database and start the Windows SharePoint Services Search service: stsadm -o spsearch -action start -farmserviceaccount <DomainName\UserName> -farmservicepassword <password> -farmcontentaccessaccount <DomainName\UserName> -farmcontentaccesspassword <password> -databaseserver <server\instance> -databasename <DatabaseName> Note: -farmserviceaccount is the server farm account. -farmcontentaccessaccount is the Office SharePoint Services Search service account. For -databaseserver, if you are using the default instance of SQL Server, you only have to specify the name of the computer running SQL Server. The following procedure must be performed once for each server running indexing or search queries in the farm. Start the Office SharePoint Server Search service on each server that will run search queries or indexing [Setup] Open the command line, and then run the following command: stsadm -o osearch -action start -role <OsearchRole>-farmcontactemail <FarmContactEmail> -farmserviceaccount <DomainName\UserName> -farmservicepassword <password> For additional information, see Osearch: Stsadm operation (Office SharePoint Server). Note: farmserviceaccount is the server farm account. role specifies what type of server role the server plays. The values for OsearchRole can be "Index", "Query", or "IndexQuery". For more information about these options, see Add query servers to expand a farm (Search Server 2008).

The following procedure will only have to be performed once for the farm. The farm only has one My Sites database. The My Sites Web application typically is hosted by its own SSP. Create and configure the content database and Web application for My Sites 1. [DBA] Create the My Sites content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [DBA] Add the SSP service account to the db_owner role for the My Sites
Web application content database. 3. [Setup] Open the command line, and then run the following command to configure the My Sites content database: stsadm.exe -o extendvs -url <url> -donotcreatesite -exclusivelyusentlm -databaseserver <DatabaseServerName> -databasename <DatabaseName> -apidtype configurableid -description <IISWebSiteName> -apidname <AppPoolName> -apidlogin <DomainName\UserName> -apidpwd <password> For additional information, see Extendvs: Stsadm operation (Office SharePoint Server). Note: url is the URL (in the form http://hostname:port) of the My Sites Web application. databasename is the content database for the My Sites Web application. description is the text name you give to the Web site in IIS. apidname is the text name that you give to the Web application pool in IIS. apidlogin is the identity for the application pool in IIS. This is the application pool process account. If you are using Kerberos v5 authentication rather than NTLM authentication, use the negotiate parameter rather than the exclusivelyusentlm parameter Important: This command must be run on the same computer that is indicated in the url parameter. This is the same computer that is running the My Sites Web application. The host name and port combination must not describe a Web application that already exists or an error will result without creating the Web application.

4. [Setup] Open the command line, and then run the following command to
restart IIS: iisreset /noforce. You must create a Shared Services Administration site Web application for every SSP in the farm. Create the content database and the Web application for the Shared Services Administration site 1. [DBA] Create the Shared Services Administration site content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [DBA] Using SQL Server Management Studio, add the SSP service account to
the Users group and then to thedb_owner role for the Shared Services Administration site content database.

3. [Setup] Open the command line, and then run the following command to create the Shared Services Administration site Web application and configure the content database: stsadm.exe -o extendvs -url <url> -donotcreatesite -exclusivelyusentlm -databaseserver <DatabaseServerName> -databasename <DatabaseName> -apidtype configurableid -description <IISWebSiteName> -apidname <AppPoolName> -apidlogin <DomainName\UserName> -apidpwd <password> For additional information, see Extendvs: Stsadm operation (Office SharePoint Server). Note: url is the URL (in the form http://hostname:port) of the Shared Services Administration site Web application. databasename is the content database for the Shared Services Administration site Web application. description is the text name you give to the Web site in IIS. apidname is the text name that you give to the application pool in IIS. apidlogin is the identity for the application pool in IIS. This is the application pool process account. If you are using Kerberos v5 authentication rather than NTLM authentication, use the negotiate parameter rather than the exclusivelyusentlm parameter Important: This command must be run on the same computer that is indicated in the url parameter. This is the same computer that is running the Shared Services Administration Web application. The host name and port combination must not describe a Web application that already exists or an error results and the Web application is not created.

4. [Setup] Open the command line, and then run the following command to
restart IIS: iisreset /noforce. The following procedure will have to be performed once for each portal site in the farm. Create and configure the portal site Web application content database 1. [DBA] Create the portal site Web application content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [DBA] Using Microsoft SQL Server Management Studio, add the SSP Service
account to the Users group and then to the db_owner role for the portal site Web application content database. 3. [Setup] Open the command line, and then run the following command to configure the portal site Web application content database: stsadm.exe -o extendvs -url <url> -donotcreatesite -exclusivelyusentlm -databaseserver <DatabaseServerName> -databasename <DatabaseName> -apidtype configurableid -description <IISWebSiteName> -apidname <AppPoolName> -apidlogin <DomainName\UserName> -apidpwd <password>

For additional information, see Extendvs: Stsadm operation (Office SharePoint Server). Note: url is the URL (in the form http://hostname:port) of the portal site Web application. databasename is the content database for the portal site Web application. description is the text name you give to the Web site in IIS. apidname is the text name that you give to the Web application pool in IIS. apidloginis the identity for the application pool in IIS. This is the application pool process account. If you are using Kerberos v5 authentication rather than NTLM authentication, use the negotiate parameter rather than the exclusivelyusentlm parameter. Important: This command must be run on the same computer that is indicated in the url parameter. This is the same computer that is running the Web application. The host name and port combination must not describe a Web application that already exists or an error results and the Web application is not created.

4. [Setup] Open the command line, and then run the following command to
restart IIS: iisreset /noforce. The following procedure must be performed once for each SSP in the farm. Create and configure the SSP content database and SSP Search database, and then create and configure the SSP 1. [DBA] Create the SSP content database and the SSP Search database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [DBA] Using Microsoft SQL Server Management Studio, add the following
accounts to the Users group and then to the db_owner role in both databases: Server farm account SSP Service account Windows SharePoint Services Search service account Office SharePoint Server Search service account Application pool process account. This is the Web application pool identity for each Web application associated with the SSP. In this article, these are the Shared Services Administration Web application and the My Sites site Web application.

3. [Setup] Open the command line, and then run the following command to create the SSP (the SSP will use the DBA-created SSP content database and the SSP Search database): stsadm -o createssp -title <SSPName> -url <url> -mysiteurl <url>ssplogin <UserName> -ssppassword <password> -indexserver <IndexServerName>-indexlocation <IndexFilePath>sspdatabaseserver <SSPDatabaseServerName> -sspdatabasename <SSPDatabaseName> -searchdatabaseserver

<SearchDatabaseServer> -searchdatabasename <SearchDatabaseName> For additional information, see Createssp: Stsadm operation (Office SharePoint Server). Note: url is the URL (in the format http://hostname:port/ssp/admin) of the Shared Services Administration site. mysiteurl is the URL (in the format http://hostname:port) of the My Sites Web site. ssplogin is the SSP service account in the format domain\username. indexserver is the name of the server that the index is hosted on. indexlocation is the directory on the index server where the farm administrator specified the index to be stored. By default this is SystemDrive:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications. Important: This command must be run on the same computer that is indicated in the url parameter. This is the same computer that is running the Web applications. In this article, this is the server where the Shared Services Administration site Web application and the My Sites Web application are running. Note: For more information about properly sizing these databases, see Estimate performance and capacity requirements (Office SharePoint Server) and Estimate performance and capacity requirements for portal collaboration environments.

How to find SharePoint 2007 Databases

manishs7 Posted on 08/05/09 at 3:57 PM 0 of 0 members found this article helpful There are quite a number of databases created during a SharePoint 2007 installation and configuration (Shared Services Provider, Windows Search etc.). Number of databases gets increased over time with creation of new web applications and site collections' content databases. If you are not careful about changing the SharePoint provided default database names to some meaningful ones during installation and configuration, very soon your database server will be crowded with strangely named databases. It becomes worse if you have a database server hosting multiple SharePoint installation. Below is a list of the databases generated by SharePoint with the default name and purpose: * Config Database for the Farm - Sharepoint_Config - stores configuration

information about the servers deployed in the farm , their individual configurations settings and some security information. Without this database there is no Sharepoint. * Content database for the Admin Console - Sharepoint_AdminContent_GUID sharepoint uses its own technology to render the web based admin console for Sharepoint. Therefore it needs it's own content database to stored the configuration settings for the web parts used. The actual data configured using this console is stored in the config database for the farm. The name for this database is system generated and cannot be controlled during the installation process and therefore it ends with a GUID. * Config database for the SSP (Shared Service Providers) BPS_SharedServices_DB - during the configuration process a SPP is defined to configure all the Shared Services used by SharePoint. All the Configuration settings for these services are stored in this database. The name of the database can be controlled during the creation process and should be descriptive of the purpose. * Content database for the SSP Console - BPS_SSP_Content - just like the admin console the SSP also needs a web site to allow you to configure the shared services and these also use web parts and lists. Therefore the SSP also needs its own content database to store these settings. * SSP Search database - BPS_SharedServices_Search_DB - this database is used by the Enterprise search service to store metadata about the information crawled including security information. This is typically used for information stored external from Sharepoint. * WSS search database - WSS_Search_sps-dc1 - this database is used by the WSS core components to store metadata about content stored inside the Sharepoint web application content databases. This is created during the installation process. * Web Application Content - Office_Content - this is the content database for the first user based web site in Sharepoint. Before the users can actually use Sharepoint a "Web Application", Site Collection and Site must be built. This database stores all the information generated within this web application. * Additional content databases - Office_Content_2 - new content databases can be created to host additional "Site Collections" and "Web Applications" and there could be hundreds of these. So, coming back to the meat of this article, how to find all the SharePoint 2007 databases in one place. It's easy, go to Central Admin --> Operations--> Under Backup and Restore click "Perform a backup". There you will see all the databases for the SharePoint farm. See Screen shot below (taken from SharePoint VHD) SharePoint2007Databases.JPG (163 KB) (File Type Details) SharePoint 2007 Databases

Detaching Databases in MOSS 2007 Environments. While performing database maintenance there are few things to consider and execute to keep your environment healthy. First being preparetomove, if you are detaching databases from a production environment this is a must. The following line is extremely important so I thought I would make it bold :) Any database that is attached to a MOSS 2007 farm and consuming from an SSP has to have stsadm -o preparetomove executed prior to the actual detach from the farm. This is due to several reasons, the main being IT WILL break the relationship between your shared service provider and your database. This relationship can be repaired but it essentially means losing the part of your search index that relates to that database. The full command is below. stsadm -o preparetomove {-ContentDB <DatabaseServer:DatabaseName> | -Site <URL>} [-OldContentDB <uniqueidentifier>] [-undo] For detaching databases cleanly from the farm we really only care about the first 2 switches. So your command might look like this. stsadm -o preparetomove -contentdb SQLSERVER:DBNAME -site http://www.sharepointskills.com Followed by the following command to actually remove your database from your farm.

stsadm -o deletecontentdb -url http://www.sharepointskills.com databaseserver SQLSERVER -databasename DBNAME When you want to reattach your database to the farm its only 1 step rather than the 2 step process. stsadm -o addcontentdb -url http://www.sharepointskills.com databasename DBNAME -databaseserver SQLSERVER Essentially what this does is it tells the SSP that you are relocating this database and to prepare to get a new database GUID. It tells the system that the current GUID for databaseA is stale and that when this database name is picked up the next time in the crawl to replace its GUID. With doing that is shifts all of the Site information and index's for that database to the new database GUID. If you fail to use this command prior to the move it will create a stale entry in your SSP and all sites going forward in the database will not be crawled. Additionally it will create a pretty ugly error in your web front end application log that looks similar to the following. Failure trying to synch web application 09a21da5-4485-4b00-8268-772aea7fea12, ContentDB 65301403-c277-4b4c-ad5a-e822572d10ea: A duplicate site ID 3b3a4372-aa91-4e0c-ba57-2567958d81bb(http://portal/sites/test1) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. This is wonderful it gives you a resolution! However there is much more to this resolution than what meets the eye. First we need to find out which databases are currently not in sync, this can be done from a simple stsadm command on your SSP web front end. stsadm -o sync -listolddatabases 5 This command will list all databases that have not synced up correctly with the SSP in greater than 5 days. Based on your schedule to index your age value may change. You may want to change this value to 10 or 15. The result set returned is a list of database GUID's and the date/time they were last synchronized. Now that we have determined the list we need to clean them up and get those guys synced. To do this we execute an stsadm command that sets all of those GUID's as old, then during your next index it will pick up the new GUID's for your production databases not currently being synced. stsadm -o preparetomove -contentdb sqlserver:dbname -oldcontentdb <GUID>

where sqlserver is where your content is housed, dbname is any database in your child farm, and GUID is a guild from the list of non-syncing databases we generated with the command above. Based on your crawl schedule wait until the next full crawl. Once it completes go back into your SSP and run the stsadm -o sync -listolddatabases 5 command again. Anything left can likely be removed at this point. You can remove what is left by running the following command. stsadm -o sync -deleteolddatabases 5 this will delete all GUID entries in the SSP for anything that is out of sync for more than 5 days. You have now successfully cleaned all inconsistencies with syncing in your SSP. All out of sync alerts should now subside.

Microsoft Office SharePoint Server (MOSS), Windows SharePoint Services (WSS). MOSS builds on WSS by adding both core features as well as end user web parts. Its main strengths are that it enables an organizations information to be organized and aggregated in one central, web-based application and it provides a taxonomy for corporate data. MOSS integrates closely with applications in the Microsoft Office suite and adds various features such as hierarchical organization of content areas, enhanced navigation, Single Sign On, personalization features,indexed search, the Business Data Catalog, in-browser rendering and, in certain cases, editing of Microsoft Office documents. It can also be used to create specialized documentspecific libraries, such as Microsoft PowerPoint slide libraries, which can be used to share not only specific slides from a presentation but also their design as well.[1] The latest version, MOSS 2007, improves over its predecessor, SPS 2003, in integrating with Microsoft Office applications, enterprise content management (with the integration of Microsoft Content Management Server into MOSS), Enterprise Search, web content management, more specialized document management, records management, Web 2.0 collaborationfunctionality like blogs and wikis, delivery of information stored in SharePoint via RSS, and the ability to take content and lists offline withOutlook 2007 and Microsoft Access. A MOSS application can abstract multiple WSS sites under the covers. [edit]Architecture The architecture is composed of Web Server front ends running the WSS application with MOSS plugging-in functionality where required, generally a search service which crawls the data store creating an index, a number of other services, and the database back-end, a standardenterprise architecture. As such it can be built out by

load balancing more web servers on the front end and building larger clusters of SQL Server on the back-end. SharePoint allows administrators to create Web Applications each on its own port. A separate web application on a separate port can contain site collections, each having its own database in SQL Server. Site collections can have sites which can contain subsites. A web server can contain hundreds of site collections. MOSS 2007 also allows content types and document libraries to have information management policies, which allows the triggering of workflowor deletion of information after a certain fixed event or time period, helping to reduce many of the size-growth problems of earlier versions.... [edit]Features [edit]Office 2007 integration MOSS integrates closely with Microsoft Office applications. It can render Microsoft Office documents in web pages. In addition, with the proper server side infrastructure, it can allow the documents to be edited from within the browser as well. For other document types in a document library, Microsoft Office applications can directly edit the document in the document library. This feature is available for Microsoft Excel andMicrosoft InfoPath. Using Excel Services, MOSS can allow Excel 2007 workbooks to be loaded, edited, and displayed in a SharePoint page. All calculations happen on the MOSS server. MOSS can also host and render Microsoft InfoPath forms using the Infopath Forms Services to have it viewed and filled out using a browser. Microsoft Office Outlook can also be used for accessing and synchronizing SharePoint document libraries.[2] On connecting a document library with Outlook, the library will be listed in the navigation pane, and the files in it will be listed along with certain metadata such as author. Compatible Microsoft Office documents will be previewed in the preview pane and Microsoft Office Outlook search bars can be used to search the libraries as well. The search entered using the Outlook bar will be federated to the SharePoint server, and the results will be displayed in Outlook itself. By synchronizing a document library, Outlook can make the files available offline, which can be opened and edited using otherMicrosoft Office 2007 applications; the changes will be synchronized back to the SharePoint library by Outlook.

While it is not necessary to use Microsoft Office 2007 to take advantage of the integration with the Microsoft Office suite, it offers the most integration with MOSS 2007. A few examples of the improved integration with Office 2007 include: 2-way synchronization of Outlook Calendar and SharePoint Calendar. Overlaying a SharePoint Calendar on top of user's Outlook 2007 Calendar. SharePoint Task-Assignment Synchronization into user's Outlook Task List. Offline Synchronization of SharePoint Documents. Viewing SharePoint RSS feeds through Microsoft Office Outlook Display of Meta-data values for a given document type in the Office Ribbon as

a user is editing a document from a document library. [edit]Enterprise search MOSS 2007 can be used for enterprise search, to search across the document libraries and user groups.[3] MOSS 2007 fully indexes all the documents stored in its library, in addition, it also indexes data stored in external databases which are exposed via ADO.NET or Web Serviceswith a well-defined WSDL schema. Any search from the portal interface or client applications can use the MOSS search capabilities to search over this index. SharePoint servers, Web sites, file shares, Exchange Public Folders, and databases can be set as data sources which it will then index. The indexing system is a tuned version of the one used in Windows Desktop Search. The indexing engine uses specified crawling rules to decide what is to be indexed. The index engine uses continuous propagation, which allows even a partial index to be queried against. It also exposes a UI for visual administration of the search capabilities. MOSS 2007 also includes suggestion capability, which suggests search terms in case of typographical errors. Microsoft Office SharePoint Server 2007 Standard, and Microsoft Office SharePoint Server 2007 Enterprise also includes a people searchfunctionality, which can search for people, based on their affiliation and expertise, provided the enterprise infrastructure makes the information available. It can search from SharePoint user groups, as well as Active Directory and other LDAP directories provided the information has been imported into MOSS. [edit]Business Data Catalog The Business Data Catalog (BDC),[4] introduced in MOSS 2007, enables presenting business data from back-end server applications such asSAP or Siebel 2007 or

databases to be viewed by the web-based interface of SharePoint without writing any code. It comprises a metadata repository and an object model. It provides a unified and simple way to invoke operations. It presents a consistent, objectoriented interface to the business logic that is embedded in typical business applications. The Business Data Catalog provides homogeneous access to the underlying data sources by using a declarative metadata model that simplifies the client object model. The Business Data Catalog Definition Editor is now included in the MOSS SDK.[5] The BDC Editor can connect to a database or a web service provided by a LOB system and then generate the Application Definition File for it. The task of maintaining the catalog is divided among four roles: business analyst who identifies the data to be presented, metadata author who creates the tags to identify the data to SharePoint, administrator, and developer. [edit]MySite MySite is an important feature in MOSS 2007 that enables users to obtain access to a personalized view of the information that's relevant to them. MySite has a Public view and a Private view. Users are able to determine the permissions on various pieces of information that are in a MySite and select whether their colleagues, manager, or everyone in the organization can see each piece of information. The Private view of a user's MySite enables them to see the following types of information: Workspace - Users can see and access the workspaces to which they have

access, saving wasted navigation time. My Links - A list of personal links that are important to the user. As users are

browsing the SharePoint site, they can quickly add a link for a given page to the My Links list by selecting Add Link from a menu in the upper right corner of the page. Personalization Sites - Special SharePoint sites that personalize content based

on a user's role in the organization can be pinned to the appropriate user's My Site based on their organization role (HR, Facilities, Finance, etc.). Microsoft has released several role-based personalization templates to help people get started with this feature. Colleague Tracker - Enables users to track the changes that they have

permission to see in their colleague's MySites.

Outlook e-mail - Web Parts are available for users' MySites that display their

e-mail and calendar information from Exchange. Distribution Groups - In the public version of MySite, you can see the

distribution groups that you're a member of and, when looking at other users' MySites, can see the distribution groups that you have in common with them. Standard WSS Site Features - Since a MySite is a WSS site at its core, users'

MySites have all of the typical functionality that comes with Windows SharePoint Services (Document Libraries and Lists, Recycle Bin, Version Control, Workflow, etc) If the system has the appropriate multi-language packs and templates installed, users can be given the option of creating their MySite in one of the languages available on the system instead of being forced to use the language that governs the more public areas of the SharePoint system. This might be useful in a scenario where a global enterprise is enabling their users in China and Spain to create their MySite in Chinese or Spanish.