Some sources recommend that if you need to crawl anonymous SharePoint site, you should create a content source with type 'Web Site'. This is not really the best way because you will loose the intelligent incremental crawl. 'Web Site'-type can have incremental crawl scheduled but it will still crawl through the whole site creating unnecessary load. If you use 'Web Site'-type you also need to create crawl rules to include the content you want to be crawled.

What you should do is create content sources with type 'SharePoint Sites'. This way crawling will happen using SharePoint's web services and incremental crawl has a better understanding what has changed by investigating timestamp information from the content. Also you don't have to create any crawl rules to make the crawling work. You can create them if you need to for example to exclude something from being crawled. Authentication configurations are a bit different for 'SharePoint Sites'-typed content sources, and if these configurations are wrong, they can easily lead to the infamous 'Access denied'-errors in crawl logs. Here are the basic requirements for the authentication configurations when using 'SharePoint Sites'-typed content sources:

Enable Windows Authentication for SharePoint web application in anonymous zone

First of all anonymous SharePoint-site should have Windows Authentication enabled. Make sure that you enabled it for the web application in CA:

1. Open SharePoint 2010 Central Administration
2. Click Manage web applications under Application Management-section
3. Select your web application's row
4. Click Authentication Providers from ribbon
5. Click Internet-zone (or what ever is defined for your anonymous site)
6. Make sure that Enable Windows Authentication and Integrated Windows authentication are checked

7. Click OK

Enable Windows Authentication for anonymous IIS web site

Second thing you need to check is the configuration of you anonymous web site under IIS. You need to check that Windows Authentication is enabled for your IIS web site. You have to perform this task to all crawl servers.

For IIS 7:

1. Click Start -> Administrative Tools -> Internet Information Services (IIS) Manager
2. Click Sites
3. Select your anonymous site
4. Double-click Authentication under IIS-section in the Features View

5. Select Windows Authentication and click Enable from the Actions-pane on the right side of the window

Give full read access to default content access account

You should have a dedicated domain account that is used as a default content access account. This is important since this account is used by the crawler in any of the servers in your farm that has been assigned as crawl servers.

Default content access account needs to have Full Read-permissions to the SharePoint web application you are crawling.

1. Open SharePoint 2010 Central Administration
2. Click Manage web applications under Application Management-section
3. Select your web application's row
4. Click User Policy from the ribbon
5. Click Add Users
6. Click Next
7. Input your default content access account to Users-box
8. Select Full Read under Permissions
9. Click Finish

Set default content access account in Search Administration

You need to define a default content access account in the Search Administration.

1. Open SharePoint 2010 Central Administration
2. Click Manage service applications under Application Management-section
3. Click Search Service Application to open Search Administration
4. In System Status-panel you will see Default content access account. Click on the right side of that row to define an suitable account
5. Input your default content access account and password and click OK

That's it! Start a full crawl for your content source and you should see anonymous items crawled successfully.

First we'll see how data sources can be used. For load testing it is not that necessary to create complex test scripts. All we need to do is create load to the system. Easiest way to do this is to give a web test a data source with fixed URLs to most used pages in the tested SharePoint-environment. Front page and section front pages usually have a lot of web parts that lift content like news or latest documents to the front page for easy access, so these are good candidates. Bombard these URLs with your load test and you will get relatively realistic results.

Adding Data Source to Web Test

Using data sources with web tests comes pretty handy when you want to maintain requested URLs in seperate configuration files instead of making web test recordings. They are especially good when you need to do authenticated requests to web applications like intranets.

We have different options to use as a data source for web performance tests. These are Database, CSV- and XML-file. In this article I will only cover CSV- and XML-files.

CSV

We can add URLs for testing using CSV (Comma Seperated Values)-file. All we need to do is put each URL in a seperate line in a text file and save the file as .csv.

E.g. 

https://internet.contoso.com/

https://internet.contoso.com/AboutCompany

https://internet.contoso.com/Contact

If you need credentials to access the URLs defined in the CSV-file, you should add the credentials after the URL seperated by commas.

E.g.

https://intranet.contoso.com/,contoso\user1,password1

https://intranet.contoso.com/News,contoso\user1,password1

https://intranet.contoso.com/HR,contoso\user1,password1

XML

XML-file are a bit more complicated but very easy nevertheless. One of the benefits of using XML-file is that you can create seperate tables and group your requests. The term table can be a bit misleading when talking about XML-files, but basically a table means all the nodes under the root node that have the same name. 

Here is an example of XML-file data source that is grouped to anonymous and autheticated requests:

<?xml version="1.0" encoding="utf-8" ?>

<Pages>

<AnonymousPage>

<Url>https://internet.contoso.com/</Url>

</AnonymousPage>

<AnonymousPage>

<Url>https://internet.contoso.com/AboutCompany</Url>

</AnonymousPage>

<AnonymousPage>

<Url>https://internet.contoso.com/Contact</Url>

</AnonymousPage>

<PrivatePage>

<Url>https://intranet.contoso.com/PartnerMaterials</Url>

<Username>contoso\administrator</Username>

<Password>pass@word1</Password>

</PrivatePage>

</Pages>

As you can see there are two kinds of nodes under Pages-node; AnonymousPage and PrivatePage.  These nodes are considered as tables in web test configuration. AnonymousPage-table has three rows and PrivatePage-table has one row.

Node names are pretty self-explanatory. URLs point to either pages that have anonymous access enabled or pages using Windows Authentication. Now that you have two tables of URLs, you can create two data binded requests to the web performance test and assign each to use one of the tables. Each request will request URLs defined in the chosen table.

PrivatePage-node has also Username- and Password-nodes defined. These nodes are used to tell the web test what credentials it should use for the requests to the given URLs.

Step-By-Step: Adding URL Data Source To A Web Test

Here is an step-by-step example of adding data source of authenticated URLs to use with the web test. This example uses the XML-data from the above chapter. You can add similar data source for anonymous URLs following the same steps. Only difference is the table you choose in the step 4. Of course you might want to create a seperate web tests for anonymous and authenticated users and add the apporiate data sources to each of them for flexibility. More of the benefits of this later...

You are all done adding data source to the web test!

Step-By-Step: Adding Data Source Binded Request To Web Test

Let's continue making the use of the data source we added in the previous chapter. Now we will add a request to the web test and bind it's URL-property to our data source. This will make your web test do a request to each of the URLs in the data source. You can edit your data source-file and add or remove URLs as much as you want and the binded request in the web test will update automatically.

Step-By-Step: Binding User Credentials To Web Test

1.	Click Set Credentials-button on the tool bar in the web test designer.
2.	Click Bind...-button for Name- and Password-values and select columns containing credentials information for the requests.
3.	Click OK.
4.	If you take a look at the web test Properties-window, you can see the selected credentials bindings there.

Now your user credentials are binded to your data source and the request made from the web test will use credential information from the data source if they are defined.

Adding Proxy Binding for Web Test Requests

You can bind web test's Proxy-property to your data source as well. My example data source doesn't have any proxy information but you can easily add it there if needed. To bind the Proxy-property, just select your data source from the web test Properties-window.

Conclusion

Hope you enjoyed this article. In the future articles I'll talk about how to configure test mixes and performance counters in load tests.