Use of Colligo Reader For SharePoint and Installation

Purpose of Colligo Reader for SharePoint:

Colligo enables you to easily download content from SharePoint sites to your laptop or machine so you can access the content offline such as document libraries offline, Get read-access to document and forms, view customs and standard lists, Access events, issues, links, contacts, tasks and agendas rather than having to copy files one by one through a browser. The reader is a client-only application – no server modifications are required. Colligo Reader works with all shipping versions of SharePoint, including Windows® SharePoint® Services (WSS 3.0 & 2.0), Microsoft® Office SharePoint® Server (MOSS 2007), and SharePoint®Portal Server (SPS 2003).


Download the Colligo Reader for SharePoint and install it.

Written By,


Sharepoint Outlook Sidebar from Harmony

Harmony Outlook sidebar provides full-featured access to documents within Sharepoint libraries. Using the Harmony sidebar documents in email attachments can be dragged to Sharepoint libraries and documents from Sharepoint libraries can be added as attachments or as links to emails. To cap it all Harmony Sidebar is Free!!!

Once the Harmony sidebar is installed and the Sharepoint connection is set up, Sharepoint documents will be available in the sidebar. Below screenshot shows contents of document library within the Harmony sidebar

Harmony Sidebar for Sharepoint can be downloaded from

Best Practice Analyzer for Windows SharePoint Service 3.0 and MOSS 2007

What Can Best Practice Analyzer for WSS/MOSS do?

The Microsoft Best Practices Analyzer for Microsoft Windows SharePoint Services 3.0 and the 2007 Microsoft Office System creates detailed reports to help administrators achieve greater performance, scalability, and uptime.

Install Best Practice Analyzer for WSS and MOSS 2007:

1. Download the best practice analyzer from the following URL.

2. Create the BPA folder on C drive.

3. Now run the downloaded file that Extracted to the C:\BPA folder.

Now we are going to execute the best practice analyzer on WSS/MOSS using the command.

4. Start -> RUN-> CMD and type the following command.


Where C:\BPA is the location that contains the Microsoft Best Practices Analyzer for Microsoft Windows SharePoint Services 3.0 and the 2007 Microsoft Office System. (If the Microsoft Best Practices Analyzer for Microsoft Windows SharePoint Services 3.0 and the 2007 Microsoft Office System is in a different location, replace C:\BPA with that location.

5. Type the following command, and then press ENTER:
sharepointbpa.exe -cmd analyze -substitutions SERVER_NAME CentralAdministrationServer

where “CentralAdministrationServer” is the server name for your SharePoint Central Administration.
It is important that SERVER_NAME is included in the parameters capitalized and that CentralAdministratorServer is replaced with the server name that is running SharePoint Central Administration.

6. After the analysis is complete, open in a web browser. will be in the same location that the Microsoft Best Practices Analyzer for Microsoft Windows SharePoint Services 3.0 and the 2007 Microsoft Office System was installed.

7. Exit the command. Now on the report HTML page, you will get available Error on your server and warning message with a solution.

8. Find the Problem and resolve it one by one.

Written by


Manage Content Types on New Button

SharePoint Lists are enabled with multiple content types, because of that we can add items with a different type of properties and documents. In advanced, the New Menu displays those Content type available in List as its sub-menu.

New Button

So how the SharePoint displays those Content types under New menu and how we can enable and disable those content types under that new Menu.

So here is the simple snippet to list out the content types enabled in New Menu.

SPList list = web.Lists[“ListName”];

IList ctoFolder = list.RootFolder.UniqueContentTypeOrder;

foreach (SPContentType ctype in ctoFolder) 


UniqueContentTypeOrder of SPFolder member lists out the Content Types visible on New Menu. Now we’ll see the code for removing the ContentType on New menu.

SPList list = web.Lists[“ListName”];

IList ctoFolder = list.RootFolder.UniqueContentTypeOrder;

//Code for removing the Content Type sub-menu in New Menu.

//Removing the “Test Content Type” menu under New Menu

for (int i = ctoFolder.Count – 1; i >= 0; i–) 

    if (ctoFolder[i].Name == “Test Content Type”) 

list.RootFolder.UniqueContentTypeOrder = ctoFolder; 

//Code for adding the Content type sub-menu under New Menu

//Adding the “Test Content type” menu under New Menu

SPContentType ctype = list.ContentTypes[“Test Content Type”];                                        

The above helps us to enable and disable the Content type on New Button in SharePoint List.

The SSP Timer Job Distribution List Import Job was Not Run.Event Id 6641

If  the user profiles are not updated after you changed users property on the SSP and you get the following error

log in your SharePoint server 2007

Then follow the following solutions steps

1. One of Microsoft’s best practices is to make sure that the application pool account for your SSP and your service account for the SSP are the same account.

2. Make sure to add this account to the backup operator’s local group on all your MOSS servers.

3. If you are using Kerberos authentication for your web applications make sure you set your service name principle account for you ssp on you MOSS application server. In order to complete this operation you must install Window support tools from your Windows server installation files under support>>tools>>supporttools.msi. Once you have installed the support tools go to start>>All programs>> Windows support tools>> command prompt. 
setspn.exe –A HTTP/name_of_ssp_address domain\appication 
Assume your site address is ssp, your domain is SharePoint, and your application pool account is svc_ssp. Run these commands 
setspn.exe –A HTTP/ssp SharePoint\svc_ssp (Run this Command) 
setspn.exe –A HTTP/ SharePoint\svc_ssp (Run this command) 

If you are using Kerberos authentication on any of your web applications you must run these commands for the web applications to function properly including your central administration site.

4. Check your system event logs on your MOSS server for any DCOM errors.  You will notice your DCOM errors are associated with your application pool accounts.  Add these accounts to the IIS WAMREG admin service.  Make sure the accounts have the local launch, remote launch, local activation, and remote activation.

5. Next stop your Office SharePoint Server Search through central administation>> operations>> Services on Server.

6. Then go to central administration>> operations>> service accounts.  Click on web application pool.  Then under web service choose Windows SharePoint Service Web application.  Next under application pool, choose your Shared Service Provider application pool account.  Under configurable you will notice that it populated your application pool account.  Now re-enter your password and click ok.

7. Login into all your MOSS servers and run iisreset /noforce.

8. Go back to central administation>> operations>> Services on Server and restart your Office Server Search.

9. Then go to central administation>>Application Management>> Manage this Farm’s Shared Services.  click the drop down on the default SSP and click edit properties.  In the SSP service credentials enter username and password.  In the index, server category select your index server and then click ok. Make sure you wait about 5 minutes.

I hope this should work.

User Profile Synchronization is Not Working in SharePoint Server 2007, Event id 5555

If the user profile is not synchronizing after you changed the property of the user property on SSP and if you found the following error message in your event log

then follow the following solution steps.

Solution Steps:

open the command prompt and run the following command.

stsadm -o sync -DeleteOldDatabases 0

then it removing the old data.

Now it should work properly.

10 Requirements Traps to Avoid

10 Requirements Trap to Avoid
The path to quality software begins with excellent requirements. Slighting the processes of requirements development and management is a common cause of software project frustration and failure. This article describes ten common traps that software projects can encounter if team members and customers don’t take requirements seriously. I describe several symptoms that might indicate when you’re falling victim to each trap, and I offer several solutions to control the problem.
Trap #1: Confusion over “Requirements”
Symptoms: The simple word “requirements” means different things to different people. An executive thinks that “requirements” might be a high-level product/project concept or business vision, while a developer’s “requirements” might look suspiciously like detailed user interface designs. One symptom of potential problems is that project stakeholders refer to “the requirements” with no qualifying adjectives. The project participants, therefore, will likely have different expectations of how much detail to expect in the requirements.
Solutions: The first step is to recognize that there are several types of requirements, all legitimate and all necessary. A second step is to educate all project participants about key requirements engineering concepts, terminology, and practices.
Trap #2: Inadequate Customer Involvement
Symptoms: Despite considerable evidence that it doesn’t work, many projects seem to rely on telepathy as the mechanism for communicating requirements from users to developers. Users sometimes believe that the developers should already know what users need, or that technical stuff like requirements development doesn’t apply to users. Often, users claim to be too busy to spend the time it takes to iteratively gather and refine the requirements. (Isn’t it funny how we never have time to do things right, but somehow we always find the time to do them over?)
One indication of inadequate customer involvement is that user surrogates (such as user managers, marketing staff, or software developers) supply all of the input to requirements. Another clue is that developers have to make many requirements decisions without adequate information and perspective. If you’ve overlooked or neglected to gather input from some of the product’s likely user classes, someone will be unhappy with the delivered product. On one project I heard about, the customers rejected as unacceptable the first time they saw it, which was at its initial rollout. This is a strong—but late and painful—indication of inadequate customer involvement in requirements development.
Solutions: Begin by identifying your various user classes. User classes are groups of users who differ in their frequency of using the product, the features they use, their access privilege level, or in other ways. (See “User-Driven Design” by Donald Gause and Brian Lawrence in STQE, January/February 1999, for an excellent discussion of user classes.)
An effective technique is to identify individual “product champions” to represent specific user classes. Product champions collect input from other members of their user class, supply the user requirements, and provide input on quality attributes and requirement priorities.
This approach is particularly valuable when developing systems for internal corporate use; for commercial product development, it might be easier to convene focus groups of representative users. Focus group participants can provide a broad range of input on desired product features and characteristics. The individuals you select as user representatives can also evaluate any prototypes you create, and review the SRS for completeness and accuracy. Strive to build a collaborative relationship between your customer representatives and the development team.
Trap #3: Vague and Ambiguous Requirements
Symptoms: Ambiguity is the great concern of software requirements. You would have encountered ambiguity if a requirement statement can have several different meanings and you’re not sure which is correct. This ambiguity results may be more harmful when multiple readers interpret a requirement in different ways. Each reader conclusion may be correct, and then ambiguity remains undetected until later—when it’s more expensive to resolve.
Another hint that your requirements are vague or incomplete is that the SRS is missing information the developers need. A Tester can’t think of test cases to verify whether each requirement was properly implemented, your requirements are not sufficiently well defined. Developers might assume that whatever they’ve been given in the form of requirements is a definitive and complete product description, but this is a risky assumption.
The ultimate symptom of vague requirements is that developers have to ask the analyst or customers many questions, or they have to guess about what is really intended. The extent of this guessing game might not be recognized until the project is far along and implementation has diverged from what is really required. At this point, expensive rework may be needed to bring things back into alignment.
Solutions: Avoid using intrinsically subjective and ambiguous words when you write requirements. Terms like minimize, maximize, optimize, rapid, user-friendly, easy, simple, often, normal, usual, large, intuitive, robust, state-of-the-art, improved, efficient, and flexible are particularly dangerous. Avoid “and/or” and “etc.” like the plague. Requirements that include the word “support” are not verifiable; define just what the software must do to “support” something. It’s fine to include “TBD” (to be determined) markers in your SRS to indicate current uncertainties, but make sure you resolve them before proceeding with design and construction.
To ferret out ambiguity, have a team that represents diverse perspectives formally inspect the requirements documents. Suitable inspectors include:
  • the analyst who wrote the requirements
  • the customer or marketing representative who supplied them (particularly for use case reviews)
  • a developer who must implement them
  • a tester who must verify them
Another powerful technique is to begin writing test cases early in requirements development. Writing conceptual test cases against the use cases and functional requirements crystallize your vision of how the software should behave under certain conditions. This practice helps reveal ambiguities and missing information, and it also leads to a requirements document that supports comprehensive test case generation.
Consider developing prototypes; they make the requirements more tangible than does a lifeless textual SRS. Create a partial, preliminary, or possible implementation of a poorly understood portion of the requirements to clarify gaps in your knowledge. Analysis models such as data flow diagrams, entity-relationship diagrams, class and collaboration diagrams, state-transition diagrams, and dialog maps provide alternative and complementary views of requirements that also reveal knowledge gaps.
Trap #4: Unprioritized Requirements
Symptoms: “We don’t need to prioritize requirements,” said the user representative. “They’re all important, or I wouldn’t have given them to you.” Declaring all requirements to be equally critical deprives the project manager of a way to respond to new requirements and to changes in project realities (staff, schedule, quality goals). If it’s not clear which features you could defer during the all-too-common “rapid descoping phase” late in a project, you’re at risk from unprioritized requirements.
Another symptom of this trap is that more than 90% of your requirements are classified as high priority. Various stakeholders might interpret “high” priority differently, leading to mismatched expectations about what functionality will be included in the next release. Sometimes developers balk at prioritizing requirements because they don’t want to admit they can’t do it all in the time available. Often users are also reluctant to prioritize because they fear the developers will automatically restrict the project to the highest priority items and the others will never be implemented. They might be right about that, but the alternatives can include software that is never delivered and having ill-informed people make the priority trade-off decisions.
Solutions: The relative implementation priority is an important attribute of each use case, feature, or individual functional requirement. Align use cases with business requirements, so you know which functionality most strongly supports your key business objectives. Your high-priority use cases might be based on:
  • The anticipated frequency or volume of usage
  • Satisfying your most favored user classes
  • Implementing core business processes
  • Functionality demanded regulatory compliance
If you derived functional requirements from the use case descriptions, this alignment helps you implement the truly essential functionality first. Allocate each requirement or feature to a specific build or release.
Many organizations use a three-level prioritization scale. If you do, define the priority categories clearly to promote consistent classification and common expectations. A more robust solution is to analytically prioritize discretionary requirements, based on their projected customer value and the estimated cost and technical risk associated with construction. (A spreadsheet to assist with this approach is available online; see this article’s Web Infolink for more information.)
Trap #5: Building Functionality No One Uses
Symptoms: I’ve experienced the frustration of implementing features that users swore they needed, then not seeing anyone use them. I could have spent that development time much more constructively. Beware of customers who don’t distinguish glitzy user interface “chrome” from the essential “steel” that must be present for the software to be useful. Also beware of developer gold plating, which adds unnecessary functionality that “the users are just going to love.” In short, watch out for proposed functionality that isn’t clearly related to known user tasks or to achieving your business goals.
Solutions: Make sure you can trace every functional requirement back to its origins, such as a specific use case, higher-level system requirement, business rule, industry standard, or government regulation. If you don’t know where a requirement came from, question whether you really need it. Identify the user classes that will benefit from each feature or use case.
Deriving the functional requirements from use cases is an excellent way to avoid orphan functionality that just seems like a cool idea. Analytically prioritizing the requirements, use cases, or features also helps you avoid this trap. Have customers rate the value of each proposed feature, based on the relative customer benefit provided if it is present—and the relative penalty if it is not. Then have developers estimate the relative cost and risk for each feature. Use the spreadsheet mentioned under Trap #4 to calculate a range of priorities, and avoid those requirements that incur a high cost but provide relatively low value.
Trap #6: Analysis Paralysis
Symptoms: If requirements development seems to go on forever, you might be a victim of analysis paralysis. Though less common than skimping on the requirements process, analysis paralysis results when the view prevails that construction cannot begin until the SRS is complete and perfect. New versions of the SRS are released so frequently that version numbers resemble IP addresses, and a requirements baseline is never established. All requirements are modeled six ways from Sunday, the entire system is prototyped, and development is held up until all requirement changes cease.
Solutions: Your goal is not to create a perfect SRS, but to develop a set of clearly expressed requirements that permit development to proceed at
acceptable risk. If some requirements are uncertain, select an appropriate development lifecycle that will let you implement portions of the requirements as they become well understood. (Some lifecycle choices include the spiral model, staged release, evolutionary prototyping, and time-boxing.) Flag any knowledge gaps in your SRS with “TBD” markers, to indicate that proceeding with construction of those parts of the system is a high-risk activity.
Identify your key decision-makers early in the project, so you know who can resolve issues to let you break out of the paralysis and move ahead with development. Those who must use the requirements for subsequent work (design, coding, testing, writing user documentation) should review them to judge when it’s appropriate to proceed with implementation. Model and prototype just the complex or poorly understood parts of the system, not the whole thing. Don’t make prototypes more elaborate than necessary to resolve the uncertainties and clarify user needs.
Trap #7: Scope Creep
Symptoms: Most projects face the threat of scope creep, in which new requirements are continually added during development. The Marketing department demands new features that your competitors just released in their products. Users keep thinking of more functions to include, additional business processes to support, and critical information they overlooked initially. Typically, project deadlines don’t change, no more resources are provided, and nothing is deleted to accommodate the new functionality.
Scope creep is most likely when the product scope was never clearly defined in the first place. If new requirements are proposed, rejected, and resurface later—with ongoing debates about whether they belong in the system—your scope definition is probably inadequate.
Requirement changes that sneak in through the back door, rather than through an established and enforced change control process, lead to the schedule overruns characteristic of scope creep. If Management’s sign-off on the requirements documents is just a game or a meaningless ritual, you can expect a continuous wave of changes to batter your project.
Solutions: All projects should expect some requirements growth, and your plans should include buffers to accommodate such natural evolution. The first question you should ask when a new feature, use case, or functional requirement is proposed is: “Is this in scope?” To help you answer this question, document the product’s vision and scope and use it as the reference for deciding which proposed functionality to include.
Apparent scope creeps often indicates that requirements were missed during elicitation, or that some user classes were overlooked. Using effective requirements gathering methods early on will help you control scope creep. Also, establish a meaningful process for baselining your requirements specifications. All participants must agree on what they are saying when they approve the requirements, and they must understand the costs of making changes in the future. Follow your change control process for all changes, recognizing that you might have to renegotiate commitments when you accept new requirements.
Trap #8: Inadequate Change Process.
Symptoms: The most glaring symptom of this trap is that your project doesn’t have a defined process for dealing with requirements changes. Consequently, new functionality might become evident only during system or beta testing. Even if you have a change process in place, some people might bypass it by talking to their buddies on the development team to get changes incorporated. Developers might implement changes that were already rejected or work on proposed changes before they’re approved. Other clues that your change process is deficient are that it’s not clear who makes decisions about proposed changes, change decisions aren’t communicated to all those affected, and the status of each change request isn’t known at all times.
Solutions: Define a practical change control process for your project. You can supplement the process with a problem- or issue-tracking tool to collect, track, and communicate changes. However, remember that a tool is not a substitute for a process. Set up a change control board (CCB) to consider proposed changes at regular intervals and make binding decisions to accept or reject them. (See “How to Control Software Changes” by Ronald Starbuck inSTQE, November/December 1999, for more about the CCB.)The CCB shouldn’t be any larger or more formal than necessary to ensure that changes are processed effectively and efficiently. Establish and enforce realistic change control policies. Compare the priority of each proposed requirement change against the body of requirements remaining to be implemented.
Trap #9: Insufficient Change Impact Analysis
Symptoms: Sometimes developers or project managers agree to make suggested changes without carefully thinking through the implications. The change might turn out to be more complex than anticipated, take longer than promised, be technically or economically infeasible, or conflict with other requirements. Such hasty decisions reflect an insufficient analysis of the impact of accepting a proposed change. Another indication of inadequate impact analysis is that developers keep finding more affected system components as they implement the change.
Solutions: Before saying “sure, no problem,” systematically analyze the impact of each proposed change. Understand the implications of accepting the change, identify all associated tasks, and estimate the effort and schedule impact. Every change will consume resources, even if it’s not on the project’s critical path. Use requirements traceability information to help you identify all affected system components. Provide estimates of the costs and benefits of each change proposal to the CCB before they make commitments. (A checklist and planning worksheet to assist with requirements change impact analysis is available online; see this article’s Web Infolink for more information.)
Trap #10: Inadequate Version Control
Symptoms: If accepted changes aren’t incorporated into the SRS periodically, project participants won’t be sure what all is in the requirements baseline at any time. If team members can’t distinguish different versions of the requirements documents with confidence, your version control practices are falling short. A developer might implement a canceled feature because she didn’t receive an updated SRS. I know of a project that experienced a spate of spurious defect reports because the system testers were testing against an obsolete version of the SRS.
Using the document’s date to distinguish versions is risky. The dates might be the same but the documents may be different (if you made changes more than once in a day), and identity documents can have different “date printed” labels. If you don’t have a reliable change history for your SRS, and earlier document versions are gone forever, you’re caught in this trap.
Solutions: Periodically merge approved changes into the SRS and communicate the revised SRS to all who are affected. Adopt a versioning scheme for documents that clearly distinguishes drafts from baselined versions. A more robust solution is to store the requirements documents in a version control tool. Restrict read/write access to a few authorized individuals, but make the current versions available in the read-only format to all project stakeholders. Even better, store your requirements in the database of a commercial requirements management tool. In addition to many other capabilities, such tools record the complete history of every change made in every requirement.
Keys to Excellent Software Requirements
While these ten traps aren’t the only ones lurking in the requirements minefield, they are among the most common and most severe. To avoid or control them, assemble a robust toolkit of practices for eliciting, analyzing, specifying, verifying, and managing a product’s requirements:
  • Educating developers, managers, and customers about requirements engineering practices and the application domain
  • Establishing a collaborative customer-developer partnership for requirements development and management
  • Understanding the different kinds of requirements and classifying customer input into the appropriate categories
  • Taking an iterative and incremental approach to requirements development
  • Using standard templates for your vision and scope, use case, and SRS documents
  • Holding formal and informal reviews of requirements documents
  • Writing test cases against requirements
  • Prioritizing requirements in some analytical fashion
  • Instilling the team and customer discipline to handle requirements changes consistently and effectively

These approaches will help your next product’s requirements provide a solid foundation for efficient construction and a successful rollout.

Courtesy – ProcessImpact


Javed Nehal

Top 10 Estimation Best Practices in Agile

1. Use more than one person – By engaging the team in the estimation process we gain the benefits of additional insights and consensus building. Additional people bring different perspectives to estimating and spot things individuals may miss. Also, the involvement in the process generates better consensus and commitment for the estimates being produced.

2. Use more than one approach – Just as one person is likely to miss perspectives of estimating so too are single approaches. Use multiple estimation approaches (comparison to similar projects, bottom up, user story points, etc) and look for convergence between multiple approaches to reinforce likely estimate ranges.

3. Agree on what “It” and “Done” means – make sure everyone is estimating in the same units (e.g. ideal days), have the same assumptions, and are based on standard developer ability/effort. When asking for estimates spell out what you are asking them to estimate. What does “Done” include? Coded, unit tested? How about integrated and system tested? What about refactoring contingencies? User meeting time?

4. Know when to stop – estimating an inherently unpredictable process (custom software development with evolving requirements) will never be an exact science. Balance enough effort against the diminishing returns and false accuracies of over-analysis. Look for broad consensus between team members at a coarse-grained level and then move on. It is better to save estimation time for periodic updates than over analyze.

5. Present estimates as a range – We call them “estimates” not “predictions” because they have a measure of uncertainty associated with them. Manage the expectation of project stakeholders and present them as a range of values. E.G. Between $90,000 and $120,000

6. Defend/explain estimate range probabilities – If stakeholders automatically latch onto the low end of an estimated range explain the low probability of achieving this and steer them to a more likely value. If your organization persistently fails to understand, present a range of likely values (e.g. around the 50% to 97% probability range)

7. Don’t reserve estimating for when you know least about the project – Estimation should not be reserved for the beginning of projects. Instead done throughout as we learn more about the emerging true requirements and the ability of the team to build and evaluate software.

8. Be aware of common estimation omissions – Consult lists of common estimating omissions (such as Capers Jones’) and ensure these items are taken into account. Look back at retrospective notes for things that did not go so well, and tasks that were missed or ran late – make sure we include enough time for these.

9. Embrace reality early – As the project progresses, it is tempting to think development will get faster and faster now all the technical problems have been overcome. However, don’t underestimate the load of maintaining and refactoring a growing code based. Especially if the system is now live; support, maintenance, test harness updates, and refactoring can quickly erode the velocity improvements anticipated, so use the real velocity numbers.

10. Review, Revisit, Remove head from the sand, Repeat – Our first estimates will likely be our worst. Don’t leave it there; review the project velocities to see how fast we are really going. Revisit the estimates armed with the real velocities to determine likely end dates. Embrace the reality you see, “The map is not the territory”, reprioritize and repeat the estimation process often to adapt and iterate to the most accurate estimates.


Javed Nehal

Configure Twitter Search with Sharepoint and Search Server

This blog explains the steps in configuring Twitter Search with Sharepoint and Search Server 2008

Prerequisite: Search Server Express or Search Server 2008 installed and configured

1. Navigate to the Search Administration Page (under Shared Services Administration) from SharePoint Central Administration Page,

2. Navigate to the  Search Administration Page as shown below

3. Then Click on “Federated Locations” Link under “Queries and Results” for configuring the search on Twitter.

Federated Locations is used to configure search on third-party websites like Google, Bing, etc…

4. Now we are in “Manage Federated Locations”. Using this page we can add or import a new third party search to SharePoint.

Click on “New Location” link to add a new search to the SharePoint Page. This will show the “Add Federated Location” page.

5. The Add Federated Location page has 4 categories as General information, Location Information, Display Information, Restrictions, and Credentials Information.

On General Information enter the

Location Name as “Twitter Search”,

Display Name as “Twitter Search”,

Description as “Search tweets on Twitter”

Author as “Copmany Name”

Version as “1”

Leave the Trigger part as “Always: Query should always match”

6. Federated Search was mainly configured on Location information. There only we have to add the configuration address for search.

Select the Location type as ‘OpenSearch 1.0/1.1”, then only we can search on other servers,

Add the search address as{searchTerms}

on Query Template and “More Results” link Template.

6. Then on Display information check the “Use Default Formatting” to view the default view for the Twitter Search.

If you want to apply your own style, uncheck the “Use Default Formatting” and edit the style sheet in XSL textbox and the parameters needed for XSLT under properties textbox.

7. After finishing this, Click OK to save this new New location.

8. After that, we have to add the Federated web part to Search results page to get the result on Search Query.

Add the Federated Result Web part, and then edit the properties to select the location type for the web part.

9. On editing the properties for webpart, choose the location type “Twitter Search”

10. Click OK to save the properties to Federated Results webpart.

11. We can also change the view of the Twitter search to look more attractive by changing the XSL stylesheet on XSL Editor property under display properties on when editing the web part.

Move SharePoint Site from One Domain to Another Domain

I am having two separate domains in Mumbai and Chennai called Mumbai as and Chennai as Both domains are running SharePoint server 2007 with a different domain.
I am planning to move Mumbai SharePoint server 2007 site to Chennai SharePoint server 2007.
For this scenario, you can do the following steps to move the SharePoint site from domain to another.
NOTE: SharePoint version should be same, mean if you installed the service pack on source machine (Mumbai SharePoint server) at the same, you should install the service pack on the destination server (Chennai SharePoint server)
You can check the version of SharePoint, open SharePoint central administration->site setting, you can view the version.
Steps to be the following:
Source SharePoint server (Mumbai SharePoint server):
    1. Take back of the SharePoint site which you required to move using stsadm.exe command utility.
Stsadm.exe –o backup –url -filename c:\mumbai.bak
    2. Move the backed up file to destination SharePoint server.

Destination SharePoint server (Chennai SharePoint server):

1. Create new SharePoint web application on the SharePoint server

     2. Create SharePoint site collection for the new web application.
Note: site collection template should be same as source SharePoint server. For example, if you created team template on source SharePoint server, then you should create same team template in destination SharePoint server.
     3. Then you need to overwrite the database using stsadm command utility
Stsadm.exe –o restore –url -filename c:\mumbai.bak –overwrite
     4. If you access the site immediately after restore, you will get the access denied error.
     5. Add a user via command line because the restored site will deny all of your login attempts (unless your server is on the same domain as the original source server – *** this post describes the steps for restoring to a different domain***)
Using the central administration console, you will note that the site collection still references the original administrators which are now invalid on this new domain (Chennai domain SharePoint).
NOTE: you can view using following steps >> Central Administration >> Application Management >> Site Collection Administrators (on Chennai SharePoint central administration domain).
     6. Now you need to change ownership of the site collection using the following command.
stsadm -o siteowner -url http://chennai/ -ownerlogin chennai\administrator
      7. Now if you refresh central admin console you will see the new administrator as an owner, you can change the secondary administrator at this point as well using same utility.
stsadm -o adduser -url http://localhost -userlogin administrator -useremail [email protected] -role administrator -username administrator
      8. Now reset the IIS and you can log in the main site collection as an administrator.
      9. Then you can optionally run this to clean up the old lingering logins explicitly

                stsadm -o migrateuser -oldlogin olddomain\MossAdmin -newlogin newdomain\MossAdmin

Article was written by