Archive

Archive for August, 2009

Denying Access

August 20, 2009 Leave a comment

A customer asked me if they could prevent a group of users from accessing the company SharePoint intranet site. My first reaction was to create a SharePoint Group in the site collection with no privileges. But since “NT Authority” users had read only access to the site, this did not work. SharePoint gives you rights based on the group to which your ID belongs that has the most privileges.

The way to deny access is to define a Policy for Web Application. These policies supersede all other SharePoint groups and rights.


One of the privileges you can assign a policy is “Deny All” – and any users defined in that policy who try to access the web application get the following window –

Advertisements
Categories: SharePoint 2007

Restricting Search on a Site

August 7, 2009 Leave a comment

A client recently had an interesting problem. They wanted to use their existing SharePoint farm (MOSS 2007) that hosted their intranet portal, team, and MySites to store machine generated EDI text files. Currently, these files were dumped into a shared drive directory. Users searched for files using the File Explorer search tool. By moving to SharePoint, they would be saving network bandwidth in addition to having a better, more efficient search solution.

The problem is that the files (and filenames) contained customer / vendor names. We created a site in the test farm and added a document library for the computer generated EDI documents. We moved a uploaded a large number of EDI files, and performed a full crawl.

Because of the data in the files, manyu search results became completely dominated by the EDI entries. This was unacceptable. The client wanted to be able to search just the EDI document library when needed, but not have it negatively impact normal searching.

  • We tried using “Authoritative Pages” hoping that by listing the EDI doc lib as less authoritative, the results would be pushed farther down the result list. What we found was that searching ignores the sites on Authoritative Pages if one of the search terms was part of the document filename (delimited by a recognized separator – which for SharePoint appears to be a space or a ‘+’).

  • Putting in a crawl rule excluding the EDI doc lib does not allow any searching.
  • Creating a seperate scope for the EDI doc lib did not work at first because the scope “All Sites” includes all scopes – including EDI.

To make the scope for EDI work, we had to change the All Sites scope definition to exclude the site /EDI.

Edit the “All Sites” scope and add an exclusion rule for the EDI site –

To make everything work with scopes, you have to add a Search Center, and modify all site collections to use the search center.

The Search settings is used to set identify the Search Center, and allow use of scopes

The Search Scopes setting is used to specify which scopes are available, their order, and the default scope.

Selecting the Display Group will allow adding the scopes –

Note – All existing site collections must be modified if they are to use the new scopes. You can use one Search Center or have a search center in one or more site collections.

Also, you must edit the search result pages (there are two) in each Search Center and edit the Search web parts to show scopes.

——————————————————————————————–
This is an alternate solution that can be used if there is a security reason to restrict search results (and not comingle indexes on one Shared Services database / index). However, it does complicate the toplogy and consume server resources.

  • Create a second Shared Service Provider (SSP)
  • Create a Web App to contain the special site with the document library
  • Associate the second SSP to the special site Web App (Central Administration > Application Management > Manage this Farm’s Shared Services – select Change Associations)
  • Remove the special site Web App from the default SSP (using Change Associations)
  • Exclude the special doc lib site using a crawl rule in the default SSP
  • Make sure the special Web App will be crawled by the second SSP by editing the Local Office Server SharePoint Sites content source (in the Start Addresses input box).
  • Set up incremental and full crawl schedules for the second SSP

Now the user can navigate the to special site Web App (for EDI) and searching will be within the EDI document library only, and any searching while in the other farm’s web apps will not be swamped by EDI results.
The downside is that you have an additional Web App (which is a drain on WFE resources), not to mention another SSP with associated crawling and indexing instances and databases.

Categories: SharePoint 2007