Jie Li's GeekWorld : MOSS

Install MOSS 2007 & WSS 3.0 on Windows Server 2008 R2 – you will need SP2 slipstream

Jie Li — Thu, 07 May 2009 21:00:38 GMT

Windows Server 2008 R2 RC is avaliable several days ago. You may ask questions: What if I want to install WSS/MOSS on Windows Server 2008 R2? Is that supported?

The answer: WSS/MOSS RTM & SP1 is not supported on WS2008R2. But with SP2, it is supported. If you try to run the installer without SP2 slipstreamed, it would be blocked and you cannot continue. Meanwhile, if you want to use SQL Server 2008, you will also need to apply SQL Server 2008 SP1 on it after installation.

So slipstream build of WSS and MOSS SP2 is required. WSS SP2 slipstream build can be found here: x86 x64. There’s no slipstream build for MOSS so you need to create your own one. Here’s a quick guide:

Remove all stuff inside the Updates folder of your MOSS installation directory. Download both wss and moss SP2 packages, extract them in command line using /extract:drive\path option, and then put all into the Updates folder. Delete Wsssetup.dll, this is important. Otherwise only WSS SP2 will be installed.

More details can be found on TechNet.

With SP2 slipstreamed, you can run the installer without any problem now. After installation, site version will be 12.0.0.6421.

Windows Server 2008 SP2 is also supported by MOSS/WSS SP2.

Search Suggestions in IE8 with SharePoint/Search Server

Jie Li — Fri, 05 Sep 2008 03:23:13 GMT

IE8 Beta 2 has been there for a while. Although it is not supported to use together with SharePoint products yet (there’s no chance to support a beta product), you can still try it out. There’re couple of new features introduced like WebSlices, Accelerators and Search Suggestions.

Search Suggestions! Isn’t it cool to make your intranet SharePoint portal to be a Search Provider and have this lovely suggestion feature?

However, by default you can make SharePoint a Search Provider, but no way to add a suggestion feature.

So here it comes – an update to “Search As Your Type(SAYT)” codeplex project, with Search Suggestion working in IE8! And I also included a small green “S” logo icon file for that, all free:)

Since it needs time to update codeplex project, I’ll put something here.

1. Install SAYT on your SharePoint Server/Search Server as instructed. Do some test searches, to make sure it works.

2. Download new update from here:

http://cid-8007edf5c56fc334.skydrive.live.com/self.aspx/Public/SharePointSearchIE8.zip

3. Extract this zip file, copy all files to the directory you put GetInfo.aspx in first step, and overwrite it.

4. Modify ssprovider.xml as needed. Replace SharePointSearchCenter and SAYTUrl with your own ones.

5. Use IE8 to navigate to add.html, and add search provider.

6. Choose the green “S” provider and try it out!

You can add a sample provider on http://www.mssearch.cn:8099/add.aspx, and try type in “search server” to see the result.

Disclaimer: This code is not support by Microsoft, if you have problems, leave your comment here. SAYT Codeplex project will be updated later to include this feature.

What may happen when I crawl MILLIONS of files in MOSS/MSS? Part II - Why I need X64 instead of X86?

Jie Li — Sun, 13 Apr 2008 20:44:35 GMT

In last post of this series we talked about the crawl time and and CPU usage. This time we will talk about process memory usage and x86/x64 issue.

Many customers asked me questions about x86/x64 comparison. Most of them consider x64 would be a benefit, but they don't know what kind of benefit it really brings.

So now I tell you why it's needed.

As we know, SharePoint/search server has three layers. Each layer can only be single architecture.

Layer 1: Web Front Server (WFE)

WFE is needed to host the web site, process different user events. This layer, of course can be and should be x64, unless you have some pretty old webpart which still need x86. At this layer, the most memory consummation comes from IIS(w3wp.exe). For IIS in X86, it can only use at about 1.1-1.2G memory. If you hit this barrier, the process may just hang there. This situation happens when very big number of request lasted for a long time(several hours or days, it depends on how many users are accessing the site at the same time). You can have multiple WFE in one server farm.

It's quite important to have IIS recycle automatically, and sometimes you even need to manually recycle it.

Layer 2: Query Server.

Query Server hosts query engine. It continually receive index propaganda from index server. When users make a query, it will be sent to query engine. Query engine will check SQL Server for document properties, and check index for content chunk. So the disk performance is important for query server when query load is high. Other workload, like query time security trimming by custom security trimmer, is also done by Query Servers.

You can have multiple Query Server per farm. And Query Servers, should be x64 if you have the hardware.

Layer 3: Index Server.

Index Server is the spider. Because you can only have one Index Server currently in SharePoint 2007/Search Server 2008, you need to take great care of it. DO NOT put ANY other applications on it, DO NOT share the box with SQL. If you do, you will quickly be hit by the bad performance.

Yes, Index Server should be x64. The problem is, sometimes we cannot make it x64. For example, we have a 32bit ifilter which does not have any x64 implementation but is very important to customer business, or we only have 32bit protocol handler like Lotus Notes PH... In these situations, you can only have a 32bit Indexer.

You may suffer from the same limitation when using 32bit Indexer, especially in Lotus Notes. When you continues crawl too many Notes docs into SharePoint, index engine may hang there for several hours because of memory limit. I suggest, if you happen to come across such problem, make a simple application to monitor and automatically restart search service after one DB is finished. This can manually recycle the memory used by the engine.

In the future, nearly everything can be made x64. So stay tuned.

Database: SQL Server

No matter querying or indexing, the backend database is always a main contributor to the whole performance. So make it independent, make it faster, and even make it cluster. This will help with overall performance. x64 is the best choice for DB.

Index FTP content with SharePoint 2007/Search Server 2008

Jie Li — Thu, 10 Apr 2008 10:03:00 GMT

Question: Can SharePoint 2007/Search Server 2008 index and search ftp?

Answer: OOTB you cannot. But we have a FTP protocol handler in SharePoint 2001 ResKit, and that one can be used on SharePoint 2007 or Search Server 2008.

Important Notice: This approach is NOT supported by Microsoft. It is just for your test purpose only, and should not be used in an important production envoriment.

Some restrictions may apply: x86 and anonymous ftp only.

Here's the steps.

1. Get a copy of ftpph.dll. It is in SharePoint 2001 ResKit.

2. Copy it to c:\Program Files\Microsoft Office Servers\12.0\Bin

3. Register this dll. Open command prompt, navigate to c:\Program Files\Microsoft Office Servers\12.0\Bin, run "regsvr32 ftpph.dll".

4. Open Regedit, navigate to HKLM\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\Protocol Handlers

5. Insert a new string item: "ftp". The value is "FtpPH.SearchProtocol.1".

6. In command prompt, restart search service by "net stop osearch" and "net start osearch"

7. Download SharePoint Search Admin at http://www.codeplex.com/SearchAdmin , and then add a new custom content source for your ftp site.

8. Start full crawl, and you will see the crawl log. Job done!

Search Community Toolkit on Codeplex

Jie Li — Thu, 13 Mar 2008 04:21:58 GMT

http://www.codeplex.com/sct

Richard Riley (3x to your xbox racing wheel:)) announced the new Community Toolkit project on Codeplex, which gives you a list of opensource enhancement for Search Server 2008 and SharePoint 2007.

http://blogs.msdn.com/enterprisesearch/archive/2008/03/12/search-community-toolkit.aspx

Yes, Smart Search, Search as you type, Faceted Search, Search Admin... are all there. And there're two new additions: Search Asp.net Server Controls for your asp.net applications, and Search Center Branding Tool which can kick the boring sharepoint interface into hell by just a few modification:)

It's time to try for yourself!

Smart Search for SharePoint v1.2

Jie Li — Fri, 07 Mar 2008 21:00:06 GMT

Many many thanks to Shawn Feldman!

Quote from him:

"I was having a few issues getting smart search installed and granting it the right permissions to access the db (I’m running a multi account environment) so I put it in a feature, Gac’d it, and added SPSecurity.RunWithElevated for whenever it makes a database connection. Here’s the code if you’re interested."

It's my fault. I know this problem when I was working on a Internet(anonymous) facing SharePoint site. The problem of SmartSearch v1.1 is it will use the current user to access db, of course, cannot be successful when using IUSR_XXXX accounts. RunWithElevated is the definitely the solution but I don't have time to do as I'm alwasys travelling around.

So here you are:

Smart Search for SharePoint ver 1.2 - Mar 8 2008

I think this is the reason why we made these open source tools - everybody can contribute to it, and make our work better.

Build Custom Federated Search Connector in Microsoft Search Server (and SharePoint) - Solve Problems and Extend Your Ideas

Jie Li — Fri, 29 Feb 2008 14:17:23 GMT

I assume the read of this article understand what is federated search. So we already know that in order to use Federated Search webpart in Search Server, you need to provide a RSS feed to it, which can also be called "OpenSearch" stuff.

But, not every application you search will return this kind of RSS/ATOM feed. For example, Google, Baidu and many other web sites. So how can you federate search results from this kind of web sites?

http://msdn2.microsoft.com/en-us/library/bb931083.aspx

Scenario 2: Connecting to an External Search Site That Returns Results in HTML Format

Scenario background: The site is configured to use Anonymous access.

Possible solution: Use a Web application outside of the context of a SharePoint site, which contains a lightweight ASPX page that does the following:

Submits a search request to the site by using the search terms passed in the initial request URL.

Converts the results in the HTML response received from the external search site to RSS format.

Returns the RSS XML in the response to the search server.

In this scenario, the federated connector’s Web application could be located on a remote server; however, a simpler solution is to create the Web application within the _layouts folder for the SharePoint site. For more information about creating this type of Web application, see How to: Modify Configuration Settings for an Application to Coexist with Windows SharePoint Services.

In a variation for this federated connector solution, you can add support for multiple external search sites by modifying the ASPX page to include details for more than one site within a case statement. The query template specified for these locations could then include a custom parameter that specifies which site in the case statement receives the federated query. Another variation is to combine the results for multiple external search providers, incorporating logic to order the results based on relevance.

Well, there're already some people who did a nice job, for example Andrew Woodward:

http://www.21apps.com/2008/01/search-server-2008-federated-sites-that.html

I would go a little further on this. Here I take Baidu as an example. Baidu is the biggest Internet search engine in China. (Google China? God knows where them are. Baidu introduced many interesting applications that Chinese users love to use. But Google China, is only famous for stealing the input method dictionary of another major Internet company SOHU, and then made its own Pinyin input method. After this was exposed to the public, they did a not so honest "apologize" and said that were two interns who did it. Perfect, later this became a popular phase in China, if anyone did evil things but was discovered by the public, he would say it's intern's or temporary employees' fault. Well, what a shame on this "not to be evil" company. - little off topic) .

Baidu.com does not return any RSS feed. What's more, it is using GB2312 encoding method to show the results. So if you directly use regex to capture something in Baidu, you will get some squares which do not make sense.

And there're some limitations in asp.net Request.QueryString method. It cannot correctly process Gb2312 encoding. So the Page Load Method must be changed to the following code:

protected void Page_Load(object sender, EventArgs e)
    {
        if (Request.QueryString["q"]!= null)
        {
            query = Request.Url.Query.ToString();
            query = query.Remove(0,3);
        }
    }

In this way, a query string will be kept so you can process it with Encode and Decode. If you use QueryString, you will get a stupid behavior that it incorrectly use Decode method in a wrong encoding charset...The result is a disater. Stupid, stupid, stupid. I want to slap the guy who wrote this method. Does he know there're not only English in this world?

For example, my nickname opal, in Chinese is 猫眼石. If queried from IE, it will be encoded using UTF-8. But Baidu can only consume GB-2312.

In UTF-8, 猫眼石 is %E7%8C%AB%E7%9C%BC%E7%9F%B3.

In GB2312, 猫眼石 is %C3%A8%D1%DB%CA%AF.

It's quite different. If you want do a search for %E7%8C%AB%E7%9C%BC%E7%9F%B3, and it is treaten as a GB2312 string, it will become 4.5 Chinese charactors. and none of them will make sense.

Okay, compain less, do more. So then we need to decode query string.

 private string getRssItemXml(string query)
    {
        //first you must decode it as UTF8. Because when IE access a utf-8 based website, it will pass the corresponding encoded strings.
        //Of course, you can modify web.config to make this application using Gb2312, but that doesn't make sense.
        query = HttpUtility.UrlDecode(query, Encoding.UTF8);
        //Then we need do encode it to gb2312. Baidu can only consume that.
        query = HttpUtility.UrlEncode(query, Encoding.GetEncoding("gb2312"));
        string url = string.Format("http://www.baidu.com/s?wd={0}", query);

        WebClient client = new WebClient();
        byte[] byteData = client.DownloadData(url);
        //Returned results are also in GB2312, so you have to rebuild it.
        string strData = Encoding.GetEncoding("gb2312").GetString(byteData);
        Regex searchPattern = new Regex("\\)\" href=\"(?<link>.*?)\" target=\"_blank\"><font size=\"3\">(?<title>.*?)</font></a><br>(?<desc>.*?)<br>");
        StringBuilder sb = new StringBuilder();

        foreach (Match m in searchPattern.Matches(strData))
        {
            sb.AppendFormat("<item><title><![CDATA[{0}]]></title><link><![CDATA[{1}]]></link><description><![CDATA[{2}]]></description></item>",m.Groups["title"].Value,m.Groups["link"].Value, m.Groups["desc"].Value);
        }

        return sb.ToString();
    }

So then put this aspx file to a website, have your federated search webpart point to it, like http://www.abc.com/Baidu.aspx?q={searchTerms}, and then you can get Baidu federated search in Microsoft Search Server 2008.

I put part of my work here:

http://cid-8007edf5c56fc334.skydrive.live.com/self.aspx/Microsoft%20Search%20Server/CaptureWeb.rar

It contains:

Baidu Federated Search Web Service
Baidu News Federated Search Web Service
iCiba (English-Chinese Dictionary) Federated Search Web Service
Dictionary.com Federated Search Web Service

Yes! You can put dictionaries on your federated search web page so if anybody want to search a word, he will get the meaning immediately! You can also have some triggers to make this happen only with numbers or charactors, etc.

Real World Lotus Notes Index Result in SharePoint 2007

Jie Li — Wed, 20 Feb 2008 17:47:51 GMT

Crawled Notes data: 1240 Gbytes

Crawled Notes Items: 2.7 Million

SharePoint Index: 70 Gbytes

SharePoint Search DB: 120 Gbytes

Data vs Index = 124:7 = 18:1, which is a ratio of 6%.

Index vs Search DB = 7: 12. Search DB is 160% of Index.

In total, (Search DB+Index)/Data=16%

Remember, this ratio varies in different environment, depends on how you use Notes Applications, how many attachments are there, and many other factors. I put it here only as a reference. Maybe update later.

Next steps of SharePoint Search Enhancement, and...

Jie Li — Sun, 17 Feb 2008 10:53:00 GMT

I was collecting feedbacks from many people these days about the enhancement we did for SharePoint Search in China. Good feedback, bad feedback, that's okay. I just put the whole list here:

Search As You Type, SAYT: The live search feel for your SharePoint search box.

TODO: Check if there's any chance we can make use of AJAX.NET.

http://www.codeplex.com/SearchAsYouType

Predefined Search: Some kind of Saved Search. Just by a single click, and your query will be remembered and can be share to the public.

TODO: Currently none. If you have ideas, contribute to the open source project!

http://www.codeplex.com/MOSSPredefinedSearch

Smart Search: 1. Display top ten hot search keyword. 2. Display relevant search keywords.

TODO: Bugfix, and a pure English version.

http://www.codeplex.com/smartsearch

SharePoint Search Admin: A GUI based tool which can do SharePoint search administration, much better and easy to use than SharePoint Search settings page itself.

TODO: Bugfix, add more tricks so that can help service people to deliver things on time.

http://www.codeplex.com/searchadmin

Chinese "did you mean" webpart: Deliver a did you mean feature for Simplified Chinese.

TODO: None

http://www.codeplex.com/cndidyoumean

Some people have a concern that these codeplex tools are not supported by Microsoft. That's true. But I must emphasize here, that codeplex thing is OPEN SOURCE. Yes, we are talking about Open Source in Microsoft. Personally I am some kind of open source lover, I think if you really want to do some thing like SOA or SaaS, open source development model would be a pretty good alternative to a complex API set. The pain of API set is the blackbox development. Product team people may not understand the business needs as deeply as we field people do. So, it is quite possible that they do something unreasonable with the product. The gain of API set is also the blackbox model. It simplified the process of development, lowered the entry barrier of newbie developers. Of course, open source may lead to bad documentation and unreadable code, also complexity of the code you write to extend it. So, a balance between opensource and api would be better for service development. So far, Firefox has been proven to be a good example.

A little off topic. But things really are different when you talk to IT pro. It depends on what is the model: a product only solution or a product+service solution? For platforms like SharePoint, a product+service solution is definitely the wiser choice. Because in a more successful implementation, nearly everything needed to be customized for the organization. In this way, the codeplex thing would be a great help.

It may be hard to change people's thought immediately, but time would prove this.

Dealing with custom content source in SharePoint Search

Jie Li — Sat, 09 Feb 2008 20:04:25 GMT

By default, SharePoint 2007 family (MOSS/MSS) supports the following content sources: Web sites, SharePoint Sites (WSS/SharePoint Server), Exchange Public Folders(through OWA), File Shares, Lotus Notes databases on Domino Server. Through BDC and user profiles/My sites, Microsoft Office SharePoint Server 2007 has two more content sources: databases and people profiles.

Yes, we can use Protocol Handlers(It is also called "connectors", don't be confused, protocol handler is not a friendly name to most of the people so we changed it) to index other contents. A protocol handler can be implemented in C++, and also C# if you don't care about the performance. So, you can give the database ability to Search Server 2008, you can connect some other things like FileNet and Documentum... By creating a protocol handler, you can also have the ability to control security trimming, a much better and wiser way than custom security trimmer.

But how can I add/remove/edit a custom content source after the new protocol handler is registered?

The answer is: using object model. You can find CustomContentSource under Microsoft.Office.Server.Search.Administration namespace. I have a open source administration tool at http://www.codeplex.com/searchadmin (SharePoint Search Admin).

There's an interesting member in CustomContentSource: Tag. By modifying this property, you can set an URL of the page to modify the settings for a custom content source. Don't forget to append CustomContentSource.Id after the page, otherwise how can the page know which content source should it open?

For example, you can specify http://moss:90/Edit.aspx as a edit page. If the Id property of current content source is 45, the actrual link would be something like http://moss:90/Edit.aspx?cid=45.

Last but not the least important, custom content source is not limited to only new protocol handlers. You can also add something like file://, http:// or even notes:// to it.

So why not make a content source edit page for Lotus Notes? Yes! You can replace the original lame one and use your own! Check out SharePoint Search Admin, you will find the option is already there for you:)

(Still jet-lagging...See you in Seattle!)

SharePoint Search Admin v.06: Support 250K Lotus Notes Databases Now

Jie Li — Sat, 02 Feb 2008 19:57:40 GMT

http://www.codeplex.com/searchadmin

We all know that SharePoint 2007 and Microsoft Search Server 2008 support Lotus Notes content source. So we can index the databases on Domino Servers.

Y-E-S. But there ARE some issue you may face in the real world.

The original idea of SharePoint Search Admin (or MOSS Search Admin, MSA) comes from a customer request in Australia. They wanted to deal with Domino Document Manager, and they had thousands of Notes DBs to index. But in SharePoint Search Settings page, you need to manually add all these Notes dbs one by one. So I wrote MSA to batch add all these DBs.

But later, I found MSA can solve many problems when you work on enterprise search solutions built on SharePoint, for example some troubleshooting work, provide some workaround to bugs... It's more and more useful, especially in large Notes envoriment.

We will talk about the problems later, now we will only discuss this update.

Yesterday a issue happened in my customer envoriment. After they created 500 content sources for 500 Notes DBs, they cannot create any new content sources any more.

Okay, there's a 500 limit in content source per SSP. This is okay for file share and websites, because we can have 500 start address per content source. But things are very tough in Notes content source, you can only have ONE Notes DB per content source if you are using default content source creation page!

This made me crazy. We always have thousands of DBs to index, but now we can only index 500 of them. Customer don't want to have multiple SSPs.

Thanks to our great Mitch Prince, he immediately shed the light on me: Using OM.

In fact, SharePoint Lotus Notes content source can support multiple DB/Directory in single content source. The only reason we cannot do it OOB is: that Content source creation page are really poorly made. This can be workaround by using object model, exactly how MSA did.

Damn, how can I forget my own tool?

So I added this in MSA. It's quite simple, just a single line of code.

LotusNotesCS.StartAddresses.Add(startAddress);

So now you can add up to 250,000 Lotus Notes DBs in one SSP! Well, if you are sure you won't hit our performance barrier.

What about the future? In next major release of SharePoint Search Admin, I'll complete reorganize the UI, and add more useful functions to make it a powerful alternative to SharePoint Search Setting UI. Hope I can did better than System Center!

Faceted Search 2.0 for SharePoint/Search Server

Jie Li — Wed, 23 Jan 2008 09:27:12 GMT

Leonid Lyublinski released his second major version of Faceted Search today, this is a great tool that can instantly improve your SharePoint Server/Search Server user experience!

It provide the following benefits:

Grouping search results by facet

Displaying a total number of hits per facet value

Refining search results by facet value

Update of the facet menu based on refined search criteria

Displaying of the search criteria in a Bread Crumbs

Ability to exclude the chosen facet from the search criteria

Flexibility of the Faceted search configuration and its consistency with MOSS administration

and in version 2, he enhanced:

Multi- thread processing. 1st thread runs for up to 500 facets synchronously, while the 2nd thread is running asynchronously against up to ~30,000 facets

Client side refresh (not AJAX based) that updates only Facets web part w/o page refresh

Web part connection to pass Facet Settings to the Bread Crumbs

Extended facet schema now supports:

Facet icons. Default icon per Facet name complimented by an icon per Facet value
Friendly names for facet values
Built-in wild-card match, e.g. FileExtension=”ASPX?ID%” will match all “ASPX?ID=” records (useful for exclusions)
Exclusions. Allow exclude facet when values match pattern
Improved search syntax, added supports for sentences and quoted phrases

I would suggest that everyone who use SharePoint and Search Server to install this open source and free tools, it's really great.

http://www.codeplex.com/FacetedSearch

Live demo(lower right corner)

http://www.wssdemo.com/Search/Pages/results.aspx?k=search

No more MOSS or SPS, only SharePoint Server

Jie Li — Fri, 18 Jan 2008 18:45:47 GMT

THE BOSS said: MOSS should not be called MOSS, it should only be refered as Microsoft Office SharePoint Server, or SharePoint Server for short.

It's really strange and hard to change my habit for typing MOSS and SPS. I think this change may be good for newbies to sharepoint -- they don't know what's MOSS and what's SPS. And even a Microsoft employee may not understand the difference. One of the marketing managers in my team always use the term "SPS" in her customer invitation letter, I had to explain to her everytime that "SPS" stands for "SharePoint Portal Server 2003" and "MOSS" for "Microsoft Office Sharepoint Server 2007", but she couldn't remember at all, or I guess she just didn't want to remember. So, this change may help with such situations.

But what about Microsoft Search Server? Better they remain to be MSS and MSSE I think.

And...my codeplex project will change its name to SharePoint Search Admin!

http://www.codeplex.com/searchadmin

How foolish I am...

What may happen when I crawl MILLIONS of files in MOSS/MSS? Part I

Jie Li — Thu, 17 Jan 2008 15:11:45 GMT

1. On MOSS box, CPU usage seems very high for several hours. Target system may also suffer from low performance.

This will happen in several situation, especially after you changed crawl impact rules. By default, MOSS/MSS will request for 8 files at one time for a single server, you can change it to 64 at the most. But remember, although sometimes this can help with crawl speed, it will hurt performance of both MOSS and target systems. So, if there's no special needs, do not set this value to too high. For low performance servers, you may want to increase the interval between two file requests.

Meanwhile, crawl schedules should be adjusted to prevent target system from being impacted in business hours.

2. Crawl time takes too long. Only ~30,000 files can be crawled per hour.

Check the bottleneck first. You can use some program to monitor the bandwidth, cpu usage, sql box performance... But don't forget to check your NIC. Let's say you have a 100Mbits connection to the intranet. So on average, you can get 8~10Mbytes per second, which means 480~600Mbytes per minutes, 29~36Gbytes per hour. Considering other factors, it is about less than 30Gbytes.

Then take a look at the content you are crawling. If the average size of your files is about 1Mbytes, which is very common if that is a mixed set of PPT/DOC/XLS files, you can of course only crawl about 30,000 files per hour.

So, increase your network bandwidth is a key to crawl speed.

Sometimes, nothing wrong about the MOSS box, nothing wrong about your network bandwidth, it's just because your target system is too slow, for example an old Domino server. In this case please refer to point 1.

To be continued...

SharePoint Batch Query Test Tool

Jie Li — Thu, 06 Dec 2007 12:13:52 GMT

http://www.codeplex.com/batchquery

When I was testing the new wordbreaker provided by Hylanda, they gave me a keyword library which had 100,000+ keywords. Each of them needed to be queried, and the results needed to be saved.

After some sorting/removing garbage work, there were still 18,000+ keywords. It would really be a pain to query them by hand.

There is also a request from http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2512852&SiteID=1.

So I wrote a small tool to do this job automatically. It reads keyword list from a pure text file (each keyword in one line), and then queries them on MSS/MOSS, saves the results in XML files to the disk.

The source code is very simple. Most part of it is from MOSS SDK. So feel free to use it.