When you are developping pages for SharePoint using Visual Studio, you always have to copy it somewhere in the SharePoint 12 directory in order to test it. It would be great if, while working on your project file, your code would be automaticaly copied to the operationnel file in the SharePoint 12 of your development machine when you type a Ctrl + S. So I did it.
Here is the VB .Net code for a Macro you can add to Visual Studio.
Prerequisites:
As in a WSPBuilder project, create a 12 directory in your Visual Studio project, and respect the directories you will have in your post deployment environments.
This Macro will test if the file you are going to save is somewhere under the 12 directory, and if so, will save it in your project context of course, but will also copy it to the corresponding directory under the SharePoint 12 of your development machine.
How to install it?
Create a Macro in visual studio then replace the module code by the following code, then attach the Ctrl + S Keyboard shorcut to it.
Imports System Imports EnvDTE Imports EnvDTE80 Imports System.Diagnostics
Public Module Module1 Sub SaveTo12() Dim myFile As String = DTE.ActiveDocument.Path MsgBox(myFile) DTE.ActiveDocument.Save() Dim maTable() As String maTable = myFile.Split("\") 'MsgBox("matebleLength : " & maTable.Length) Dim copyPath As String Dim is12Found As Boolean = False For i As Integer = 0 To maTable.Length - 2 If maTable(i) = "12" Then is12Found = True End If If is12Found Then copyPath &= maTable(i) & "\" End If Next i Dim _12Path As String = "C:\Program Files\Common Files\Microsoft Shared\web server extensions\" copyPath = _12Path & copyPath 'MsgBox(copyPath) If is12Found Then 'MsgBox(copyPath) If Not System.IO.Directory.Exists(copyPath) Then System.IO.Directory.CreateDirectory(copyPath) End If
System.IO.File.Copy(myFile & "\" & DTE.ActiveDocument.Name, copyPath & DTE.ActiveDocument.Name, True) End If End Sub
Listenning most of customers I work for, one of the bad point of SharePoint is the time that developments require to customize sites or extend SharePoint in order to give it more complete functionalities.
Customers often forget that if they had to do a SharePoint site from scratch using Asp .Net they would have had to rewrite some of the most appreciated SharePoint functionnalities like document libraries, security manager that can connect to company Active Directory, and so on. Anyway, it is right that sometimes, for a single functionality, it takes much more time to add it to a SharePoint site than to an Asp .Net site.
Why ?
I start writing this post looking for the reasons that makes sometimes a SharePoint project take so long time to be delivered, and in the same time looking for solutions that can improve development speed.
I will write later a chapter about deployment of SharePoint sites and explain that deployment tasks can sometimes take 30 % of the project full time even if you prepare your deployment, and that may take much more time if you don't do, with enormous risks to postpone the planned delivery date.
I also will write about graphical customosation, html + css and javaScript, that is also a big cost of time especially if you don't start well.
However, I prefer for the moment to focus on developement and try to look for practices to improve development speed in SharePoint.
First of all, why development are sometimes taking so much time in SharePoint project comparing to Asp .Net ones?
There is two main reasons:
Most of the server code you will have to write will have to be built before having to be tested.
You will have to deploy the code you've just written on your development machine before testing it.
These numerous operations of building and deployment set a lot of time especially if they come along with IIS reset. If you compare with a Asp .Net project, the developer in the case of a pure Asp .Net, write his client and server code, and test it by just pressing F5 !
So I will try to think about way of developping SharePoint code in order to be as close as possible to the Asp .Net developper experience.
So to avoid the two noticed previous points, there is obvious things to do :
using scripts
working directly on pages that are below the 12 directory.
- Using Scripts
You can program against WSS Object Model writting in line code in all the pages:
Master Pages
Layout Pages
Applicative Pages
Of course, for the two first type of Pages, it is a temporary solution, because it is not a best practice to use in line code in these pages since this code won't be able to execute if the page is customized.
Anyway, starting writiing your functionality using in line code will make you save a lot of time since you won't have to build your code before testing it. You won't have neither to deploy your dll an have to wait for IIS Reset or Pool Recycling.
To avoid deployment you have to develop code on files that are in the 12 directory. Files inside features for master pages and layout pages, file inside Layouts directory for applicative pages.
It would be great if, while working on your project file in Visual Studio, your code would be automaticaly pasted to the operationnel file in the SharePoint 12 of your development machine when you type a Ctrl + S.
I hope this post will be very usefull for anybody who have to use it because I was so happy myself when I discovered this SharePoint trick completely by chance, and it made me save so much time since this day.
You have sometimes this error while developping a SharePoint application :
Server Error in '/' Application.
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Even if you have activated the possibility to see errors and trace in SharePoint (Web application web.config --> callstack="true", customerror="off", debug="true") you won't have a precise indication of what ressource is missing.
So just right click your page and choose "view source".
do you want to hide the sign-in link on your SharePoint sites for your internet users that access it in anonymous authentication mode?
Well, there is one simple and very quick way to do this with 2 scripts in your master page using C# + JavaScript. The effect will be that the link will not be present for anonymous user, but authenticated users will see Welcome and Action menus.
In the head section of your master page place this code :
Don't forget to replace the in line code in the master page later, by an User Control or a Custom control, as the in line code will fail if the master page is customized...
There is no question about using or not using a solution (.wsp file) to deploy or upgrade a SharePoint solution. You must use a .wsp.
Anyway, using a .wsp to deploy a solution, there is some points you need to pay attention to :
The way to deploy when upgrading a solution.
There is only one way to deploy the fisrt time, with the stsadm instruction:
stsadm -o deploysolution ...
But when you want to upgrade a solution there is two ways to do :
With the stsadm instruction stsadm -o upgradesolution
By retracting the solution, removing it, and redeploying it again.
What's the difference ?
Renaming your solution in order to make a .wsp versionning
The second way for instance allow you to rename your solution in the solution store in order to be able to make a versioning of your .wsp.
With the first way, you will have to keep always the same name for your solution in the solution store.
.wsp deployment and feature installation
Deploying a .wsp make all the features inside to be installed in the farm. Upgrading, not necessary so...
Asume you deploy a solution. Then you uninstall a feature that was deployed, thus installed with this deployment.
If you uninstall this feature, it will be NOT reinstalled when upgrading the solution with "upgradesolution" stsadm command.
However, it will be reinstalled when retracting the solution, removing it, and redeploying it.
Solution files that are shared between several solutions
There is no difference between the two ways of upgrading a solution regarding solution files management. When you upgrade a solution using " upgradesolution" stsadm command, all the files prevously deployed with the solution will be removed, and will be copied again in the required directories if they always are present inside the .wsp. So, what's happenig if two solutions share the same file ?
Asume you have a solution that have deployed a site definition. If you make an other solution to make changes to this site definition and deploy it, the site definitions files will belong to the new soltuion. If you retract and remove this solution, all the site definition files will be removed from your farm !
So you will have to redeploy the first solution to recover your farm originale state.
While working with SharePoint Customization using WSS object model, we sometimes need to read XML files. A good way to do it is to use XPath. It is more much usable if you simplify its use by writing a C# Class like the following one :
This class allows you to retrieve a single node value or multiple nodes values :
public class XMLExplorateur { protected XPathDocument docNav; protected XPathNavigator nav; protected XPathNodeIterator xit; protected bool initpath = true; public XMLExplorateur() { }
public XMLExplorateur(String path) { try { docNav = new XPathDocument(path); nav = docNav.CreateNavigator(); } catch { docNav = null; nav = null; } } public bool Init(String path) { try { docNav = new XPathDocument(path); nav = docNav.CreateNavigator(); } catch { docNav = null; nav = null; return false; } return true; }
And here is the way to use it : I asume the xml file is inside a feature directory and I want to get informations from this file in my feature FeatureActivated method :
<Customer> <FirstName>John</FirstName> <LastName>Doe</LastName> <LatestPurchasseDate>05/10/2008 13:37</LatestPurchasseDate> <SalesComment id="1">To be called back next week</SalesComment> <SalesComment id="2">was very interested by Mr. Smith porposal</SalesComment> </Customer>
You will find MSDN link to study XPath syntax : here.
Updated on 2009 may 29 thanks to Michael Hanes (see this post comments)
Updated on 2009 may 20 from Configure search service account for a moss 2007 farm
Summary
Prerequisites
1 - Farm topology
2 - Installation
3 - Domain user accounts
3.1 Excerpt of Office SharePoint Server Security Account Requirements
3.2 MOSS Search Required Domain User Accounts
Required Tasks Overview
1 - Recommended required tasks sequence
2 - Reference documentations
Starting and Configuring Office SharePoint Server Search
1 - Starting the Search
2 - Creating the SSP Web Application and the MySite Web Application
2.1 create the SSP Web Application
2.1 create the MySite Web Application
3 - Creating the SSP
4 - Configuring the basic Search within the Share Services Administration Site
4.1 Specify the default content access account
4.2 Create content sources
4 - Test the MOSS Search
Introduction
This post includes the key steps for starting and configuring:
Office SharePoint Server Search
for a small server farm.
A small server farm is defined as
Components scaled to two tiers (at least two servers) with either a dedicated WFE or dedicated database.
I have chosen for this post the topology with the dedicated database.
In this post, we are going to describe the required steps to start and configure the MOSS search for the single WFE of the small farm in order to be compliant with the Least Privilege Administration policy using Domain User Accounts.
Least-privilege administration requirements when using domain user accounts
Least privilege administration is a recommended security practice in which each service or user is provided with only the minimum privileges needed to accomplish the tasks they are authorized to perform. This means that each service is granted access to only the resources that are necessary to its purpose. The minimum requirements to achieve this design goal include the following:
- Separate accounts are used for different services and processes.
- No executing service or process account is running with local administrator permissions.
By using separate service accounts for each service and limiting the permissions assigned to each account, you reduce the opportunity for a malicious user or process to compromise your environment.
Least privilege administration with domain user accounts is the recommended configuration for most environments.
[...]
Prerequisites
1 - Farm topology
The configuration for this post is described in the following tables and illustration.
The following illustration shows the topology for the roles and servers described in the preceding table
2 - Installation
You have already installed MOSS 2007 on the Web Front End server, and are just ready to start and configure MOSS search.
3 - Domain user accounts
3.1 Excerpt of Office SharePoint Server Security Account Requirements
Here is the HTML version of the part of onclick="javascript:Track('ctl00_mainContentContainer_ctl00|ctl00_mainContentContainer_ctl01',this);" href="http://go.microsoft.com/fwlink/?LinkID=92883&clcid=0x409"> Office SharePoint Server security account requirements dedicated to SSP and therefore to the MOSS search.
Least privilege administration using domain user accounts
Least privilege administration using SQL authentication
Least privilege administration with domain user accounts when connecting to pre-created databases
valign="top" width="103">
SSP application pool account
Application pool identity for the shared services administration Web application.
No manual configuration is necessary.
No manual configuration is necessary.
The following are automatically configured:
- Membership in the db_owner role for the SSP content database.
- Access to read from and write to the SSP content database.
- Access to read from and write to content databases for Web applications that are associated with the SSP.
- Access to read from the configuration database.
- Access to read from the Central Administration content database.
- Additional permissions to front-end Web servers and application servers are automatically granted.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- For security isolation, use a separate service account for each SSP.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- NOT a member of the local Administrators group on any server in the farm, including the computer running SQL Server.
- NOT a SQL Server login.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- For security isolation, use a separate service account for each SSP.
valign="top" width="103">
SSP service account
Used by the following:
- SSP Web services for inter-server communication
- SSP Timer service to run specific types of jobs
- Application pool identity of application pool associated with the virtual directory associated with a given SSP
- No manual configuration is necessary.
- This account should not be a member of the Administrators group on any computer in the server farm.
- Use a domain user account.
- No manual configuration is necessary. The same permissions as the SSP application pool account are automatically granted.
- This account should not be a member of the Administrators group on any computer in the server farm.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- NOT a member of the Administrators group on any server in the farm, including the computer running SQL Server.
- NOT a SQL Server login.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
After the configuration database and the Central Administration content databases are created, add this account to the following for these databases:
- Users group
- WSS_Content_Application_Pools lang="EN-US" style="font-size: 8pt; font-family: 'Verdana','sans-serif'"> database role
After the content database for the Shared Services Administration site, the SSP database, and the SSP search database are created, add this account to the following for each of these databases:
- Users group
- db_owner role
After My Sites are created, add this account to the following for the My Sites Web application content database:
- Users group
- db_owner role
After each content database is created, add this account to the following:
- Users group
- db_owner role
valign="top" width="103">
Office SharePoint Server Search service account
Used as the service account for the Office SharePoint Server Search service. There is only one instance of this service and it is used by all SSPs.
By default, this account runs as the Local System account.
If you want to crawl remote content by changing the default content access account or by using crawl rules, change this to a domain user account. If you do not change this account to a domain user account, you cannot change the default content access account to a domain user account or add crawl rules to crawl this content. This restriction is designed to prevent elevation of privilege for any other process running as the Local System account.
- Must be a domain user account.
- Although it is written in the Microsoft .doc documentation "Must be a member of the Farm Administrators group on the server" if you refer to the HTML documentation, it is written "Must not be a member of the Farm Administrators group". I flagged this mismatch as a bug to Technet and think that this account must not be a member of the Farm Administrators group. (see this post comments)
The following are automatically configured:
- Access to read from the configuration database.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- NOT a member of the Administrators group on any server in the farm, including the computer running SQL Server.
- NOT a SQL Server login.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
After the configuration database and the Central Administration content databases are created, add this account to the following for these databases:
- Users group
- WSS_Content_Application_Pools lang="EN-US" style="font-size: 8pt; font-family: 'Verdana','sans-serif'"> role
After the SSP database and the SSP search database are created, add this account to the following for each of these databases:
- Users group
- db_owner role
valign="top" width="103">
Default content access account
The default account used within a specific SSP to crawl content, unless a different authentication method is specified by a crawl rule for a URL or URL pattern.
No manual configuration is necessary if this account is only crawling local farm content. If you want to crawl remote content by using crawl rules, change this to a domain user account, and apply the requirements listed for a server farm.
- Must be a domain user account.
- Must not be a member of the Farm Administrators group.
- Read access to external or secure content sources that you want to crawl by using this account.
- For sites that are not a part of the server farm, this account must explicitly be granted Full Read permissions on the Web applications that host the sites.
The following are automatically configured:
- Full Read permissions are automatically granted to content databases hosted by the server farm.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- By default, in a server farm environment, the Office SharePoint Server Search service account is used until a different account is specified. After completing Setup and running the configuration wizard, change this account to a domain user account.
- Do not grant the default content access account access to the directory service.
For added security, use a different default content access account for each SSP.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- NOT a member of the Administrators group on any server in the farm, including the computer running SQL Server.
- NOT a SQL Server login on the SQL Server Host.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- By default, in a server farm environment, the Office SharePoint Server Search service account is used until a different account is specified. After completing Setup and running the configuration wizard, change this account to a domain user account.
- Do not give the default content access account access to the directory service.
For added security, use a separate default content access account for each SSP.
After the configuration database and the Central Administration content databases are created, add this account to the following for these databases:
- Users group
- WSS_Content_Application_Pools lang="EN-US" style="font-size: 8pt; font-family: 'Verdana','sans-serif'"> database role
valign="top" width="103">
Content access account
A specific account that is configured to access a content source. This account is optional and is specified when you create a new crawl rule. For example, content sources that are external to Office SharePoint Server (such as a file share) might require a different content access account.
Same as the SSP default content access account listed previously.
- Read access to external or secure content sources that this account is configured to access.
- For Web sites that are not a part of the server farm, this account must explicitly be granted Full Read permissions on the Web applications that host the sites.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- NOT a member of the Administrators group on any server in the farm, including the computer running SQL Server.
- NOT a SQL Server login.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
valign="top" width="103">
Profile import default access account
Used to:
- Connect to a directory service, such as the Active Directory directory service, a Lightweight Directory Access Protocol (LDAP) directory, a Business Data Catalog application, or other directory source.
- Import profile data from a directory service.
If no account is specified, the default content access account is used. If the default content access account does not have read access to the directory or directories that you want to import data from, use a different account. You can plan up to one account per directory connection.
Same requirements as server farm.
- Read access to the directory service.
- If Enable Server Side Incremental is selected for an Active Directory connection and the environment is Windows 2000 Server, the account must have the Replicate Changes permission in Active Directory. This permission is not required for Windows Server 2003 Active Directory environments.
- Manage User Profiles personalization services permission.
- View permissions on entities used in Business Data Catalog import connections.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- This account can be the same account as the default content access account, or you can use a separate account.
- Read access to the directory service.
- Manage User Profiles personalization services permission.
- This account should not be a member of the Administrators group on any computer in the server farm.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- NOT a member of the Administrators group on any server in the farm, including the computer running SQL Server.
- NOT a SQL Server login.
Server farm standard requirements with the following additions or exceptions:
- Use a separate domain user account.
- This account can be the same account as the default content access account or you can use a separate account.
- Use an account that has read access to the directory service and the Manage User Profiles personalization services permission.
This account should not be a member of the Administrators group on any computer in the server farm.
valign="top" width="103">
Excel Services unattended service account
The account that Excel Calculation Services uses to connect to external data sources that require a non-Windows user name and password string for authentication. If this account is not configured, Excel Services will not attempt to connect to these types of data sources. Although the account credentials are used to connect to non-Windows data sources, the account must be a member of the domain in order for Excel Calculation Services to use it.
Must be a domain user account.
Must be a domain user account.
Must be a domain user account.
Must be a domain user account.
Must be a domain user account.
3.2 MOSS Search Required Domain User Accounts
If we follow the previous table recommendations, we need the following Domain User Accounts to start and configure the MOSS Search (I have used orange color for the least privilege administration requirements and red color for manual operation)
Account Name
SPS_WebAppSSP1
Account Description:
SSP application pool account
Application pool identity for the shared services administration Web application.
Account Least privilege administration using domain user accounts
No manual configuration is necessary.
The following are automatically configured:
- Membership in the db_owner role for the SSP content database.
- Access to read from and write to the SSP content database.
- Access to read from and write to content databases for Web applications that are associated with the SSP.
- Access to read from the configuration database.
- Access to read from the Central Administration content database.
- Additional permissions to front-end Web servers and application servers are automatically granted.
- Use a separate domain user account.
- For security isolation, use a separate service account for each SSP.
Account Name
SPS_SSP1_Service
Account Description:
SSP service account
Used by the following:
- SSP Web services for inter-server communication
- SSP Timer service to run specific types of jobs
- Application pool identity of application pool associated with the virtual directory associated with a given SSP
Account Least privilege administration using domain user accounts
- Use a domain user account.
- No manual configuration is necessary. The same permissions as the SSP application pool account are automatically granted.
- This account should not be a member of the Administrators group on any computer in the server farm.
- Use a separate domain user account.
Account Name
SPS_MossSearch
Account Description:
style="">
Office SharePoint Server Search service account
Used as the service account for the Office SharePoint Server Search service. There is only one instance of this service and it is used by all SSPs.
Account Least privilege administration using domain user accounts
- Although it is written in the Microsoft .doc documentation "Must be a member of the Farm Administrators group on the server" if you refer to the HTML documentation, it is written "Must not be a member of the Farm Administrators group". I flagged this mismatch as a bug to Technet and think that this account must not be a member of the Farm Administrators group. (see this post comments)
The following are automatically configured:
- Access to read from the configuration database.
- Use a separate domain user account.
Account Name
SPS_DefaultContent (cannot write "access" because logon name number of characters is limited to 20)
Account Description:
style="">
Default content access account
The default account used within a specific SSP to crawl content, unless a different authentication method is specified by a crawl rule for a URL or URL pattern.
Account Least privilege administration using domain user accounts
- Must be a domain user account.
- Must not be a member of the Farm Administrators group.
- Read access to external or secure content sources that you want to crawl by using this account.
- For sites that are not a part of the server farm, this account must explicitly be granted Full Read permissions on the Web applications that host the sites.
color="#ff8040">The following are automatically configured:
- Full Read permissions are automatically granted to content databases hosted by the server farm.
- By default, in a server farm environment, the Office SharePoint Server Search service account is used until a different account is specified. After completing Setup and running the configuration wizard, change this account to a domain user account.
- Do not grant the default content access account access to the directory service.
color="#ff8040">For added security, use a different default content access account for each SSP.
Required Tasks Overview
1 - Recommended required tasks sequence
First we will start the Office SharePoint Server Search.
It can seem paradoxical, but we need to start SharePoint Server Search first before having created a SSP because when performing this task, we define an Index Server in the "Query and Indexing" section and we need to have an Index Server defined when creating a SSP.
By the way because we are in a small server farm topology we will use our single Web Front End server for both search queries and indexing.
Starting the Office SharePoint Server Search will also initialize its Service Account
You will notice that no specific permissions is required regarding the SSP's databases or the databases of Web Applications associated with the SSP's for this service account so as we can start the Office SharePoint Server Search before having created any SSP.
Then we will create 2 Web Applications one for the SSP and another for the MySite feature, because it is recommended to use 2 different Web Applications for them.
Finally we will configure the Office SharePoint Server Search within the new created SSP.
Starting and Configuring Office SharePoint Server Search
1 - Starting the Search
In Central Administration, on the Operations tab, in the Topology and Services section, click Services on server.
On the Services on Server page:
If the server name that appears is not the server that you want to configure, click the arrow next to the server name, click Change Server, and then click the server for which you want to enable or disable the index server role or query server role.
In the Start services in the table below section, in the Status column for Office SharePoint Server Search, if the status is Stopped, in the Action column click Start.
On the Configure Office SharePoint Server Search Service Settings page, in the Query and Indexing section, enable server roles for the server as appropriate for your configuration:
select Use this server for indexing content.
select Use this server for serving search queries.
On the Configure Office SharePoint Server Search Service Settings page, in the Farm Search Service Account section, type the Office Server search Account credentials:
(Do not forget to specify the Domain name.)
Although it is written in the Microsoft .doc documentation "Must be a member of the Farm Administrators group on the server" if you refer to the HTML documentation, it is written "Must not be a member of the Farm Administrators group". I flagged this mismatch as a bug to Technet and think that this account must not be a member of the Farm Administrators group. (see this post comments)
Notice that the Index Server Default File is now defined.
Web Front End and Crawling
This section is to be taken into account, because unexpected issues can occur if you checked "Use a dedicated web front end computer for crawling". So read it carefully and choose a dedicated web front end only if necessary.
For example problem may occur with the " href="file:///C:/WINDOWS/system32/drivers/etc/hosts">C:\WINDOWS\system32\drivers\etc\hosts" file as desscribed in this post:
Perform the same operations as above for the MySite Web Application. I did not specify a specific service account for this web application, but in order to respect least privilege administration you should have created a service account for this web application that is not a member of the server local administrators group
3 - Creating the SSP
In Central Administration, on the Quick Launch Menu, click Shared Services Administration
In Manage this Farm's Shared Services page click New SSP
In the New Shared Services Provider Page
In the SSP Name section use the drop down list to retrieve the previously created SSP Web Application
In the My Site Location section use the drop down list to retrieve the previously created MySite Web Application
In the SSP Service Credentials section type the SPS_SSP1_Service service account credentials
Notice that in the Index Server section the index server name and the Path for index file location have been retrieved
Let the default values for the other fields and click OK
Wait while SharePoint is provisioning htyour SSP...
SharePoint then display the Success! page
4 - Configuring the basic Search within the Share Services Administration Site
In the previous Success! page click the shared services administration site link
The shared services administration site home page is opening.
On the Shared Services Administration page, in the Search section, click Search settings.
On the Configure Search Settings page, in the Crawl settings section, click Default content access account.
On the Default Content Access Account page, in the Account box, type the domain and user name for the account (in the form domain\username).
SPS_DefaultContent
In the Password and Confirm Password boxes, type the password for the account.
Be sure that this account has read access to external or secure content sources that you want to crawl by using this account.
For sites that are not a part of the server farm, this account must explicitly be granted Full Read permissions on the Web applications that host the sites.
Click OK.
You are taken to the Configure Search Settings page and can check the new value for the Default Content Access Account
Create content sources
(On the Shared Services Administration page, in the Search section, click Search settings.)
On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.
On the Manage Content Sources page, click New Content Source.
On the Add Content Source page, in the Name section, in the Name box, type a name for the content source.
Note:
Each content source name must be unique within the SSP in which it is created.
In the Content Source Type section, select the type of content you want to crawl by using this content source.
In the Start Addresses section, in the Type start addresses below (one per line) box, type the URLs from which the search system should start crawling.
Note:
For performance reasons, you cannot add the same start addresses to multiple content sources.
In the Crawl Settings section, select the behavior for the type of content you selected.
In the Crawl Schedules section, you can specify when to start full and incremental crawls.
You can create a full crawl schedule by clicking the Create Schedule link below the Full Crawl list.
You can create an incremental crawl schedule by clicking the Create Schedule link below the Incremental Crawl list.
Click OK.
4 - Test the MOSS Search
By default the Search setting comes with a default Content Source: Local Office SharePoint Server sites
Using this default Content Source contextual menu, start a full crawl
The full crawl starts...
You can check the crawling progression by going back to the Configure Search Settings page, and if you refresh the page, you will notice that the Items in index: field value is changing while SharePoint is crawling your Farm Content.
When the crawling is done the value of the indexing status come back to Idle within the Configure Search Settings page.
You can then go to one of your SharePoint site and perform a search operation in order to check your content was properly indexed and the MOSS search is working well.
border="0" alt="" id="BLOGGER_PHOTO_ID_5337823900659323490" />
border="0" alt="" id="BLOGGER_PHOTO_ID_5337823900740671634" />
border="0" alt="" id="BLOGGER_PHOTO_ID_5337823903319681858" />
border="0" alt="" id="BLOGGER_PHOTO_ID_5337823908735801170" />
border="0" alt="" id="BLOGGER_PHOTO_ID_5337823910087605570" />
