Benefits of Microsoft Office SharePoint Server 2007

Hello Guys,


      Below are the benefits of MOSS 2007

•  Provide a simple, familiar, and consistent user experience.
•  Boost employee productivity by simplifying everyday business activities.
•  Help meet regulatory requirements through comprehensive control over content.
•  Effectively manage and repurpose content to gain increased business value.
•  Simplify organization-wide access to both structured and unstructured information across disparate systems.
•  Connect people with information and expertise.
•  Accelerate shared business processes across organizational boundaries.
•  Share business data without divulging sensitive information.
•  Enable people to make better-informed decisions by presenting business-critical information in one central location.
•  Provide a single, integrated platform to manage intranet, extranet, and Internet applications across the enterprise. 

About Content Query

Hi Everyone,


             Content Query:

                                        We can use a Content Query control to link to pages or other items that are displayed based on a query that you design. For example, if you are presenting articles in an online news site, you could add a Content Query control to your site's Welcome Page layout so that new articles are highlighted on that page. You can build complex queries by using the Content Query field control. For example, you can specify which sites in your site collection to query, which lists to use, and what audience to target. You can also filter queries based on lists or libraries metadata.

We can add a Content Query control to a layout page in two ways:

·      We can add it directly to the layout page and configure it. When you do this, any page that uses the layout page will display the results of the query.

·       We can add it as a Web Part to a Web Part zone. When you do this, authors can modify the query or delete the Content Query control.

Convert MS Excel to SQL Server

Converting Excel database spreadsheets to a MS SQL Server database provides a far more structured, more repeatable approach for business critical processes. Excel spreadsheets provide infinite flexibility, but at the cost of bad data, and the cost of managing a distributed application that is intended for just one or a few users.  SQL Server database supports well-structured data, and repeatable, high quality data and workflow processes, with unlimited number of concurrent End Users. The good news is that PCA can migrate your Excel spreadsheets to MS SQL Server, and make your Excel Application more structured, while preserving the original functional integrity of the original MS Excel spreadsheet.

       Comparison of MS Excel to SQL Server:

		MS Excel	SQL Server
	Workflow	None (Email)	Process-flow defined
	Concurrent Updates	No (Single User)	Yes (Multiple, concurrent Users)
	Security	One password fits all	Role-based privileges
	Version Issues	High (file data stamp)	None
	Audit-ability	Low (date and email comparisons)	High (full audit trail)
	Data Integrity	Low (somewhat constrained)	Highly constrained
	Data Capacity	Limited	Unlimited
	Data Structures	Flat: 2-dimensions	Relational: 3-dimensions

Advantages of Data View Web Part(DVWP)

It has been posting interesting articles about Data View Web Part (DVWP).
I know a great deal about Data View Web Part and there are numerous solutions I posted here which were created with it (Blog archive SharePoint Lists and Libraries, Outlook Style KPIs).


We can use Data View Web Part to pull data from subsites


We can use Data View Web Part to aggregate data from more than one list


For more details check her post, or attend one of the online workshops about DVWP at End User SharePoint.


Advantage: This is very important for Windows SharePoint Services users since you do not have Content Query Web Part in WSS. By using DVWP you might be able to aggregate and present information in very interesting ways.


Problem: Although DVWP can aggregate data from subsites you would have to pre-configure all the sources. In case you add a new site you will need to ad it to your data sources. (I presume it might not perform very well when multiple sources are used).


Conclusion: No matter how hard you learn, when it comes to SharePoint, there is always something new to learn. Keep your eyes open!

Creating a SharePoint Site

    To create a SharePoint site, you must be a member of a site group that has the Create Subsites permission. This permission is included by default in the Full Control permission level. If you don't have the necessary permission, contact your server administrator.

1. On the File menu, point to New, and then click Web Site.
2. In the Specify the location of the new Web site box, type the location where you want to create the new site, including a name for the site.
   
   
   For example, you might type http://My_Server/My_Site as the URL of your new SharePoint site.  By default, Office SharePoint Designer 2007 suggests both a location and a name for the new site that are based on the site most recently opened. You may want to change either the location or the name, or both.
   
   
   
3. In the leftmost pane, click the category of template that you want to create.
   If you click SharePoint Templates, the list of available templates is retrieved from the server. At this point, you may be prompted to enter your user name and password to log on to the server.
   
     The list of SharePoint site templates is retrieved from the current server. When you connect to another server, you may see more, fewer, or other templates, depending on which ones the server administrator has made available.
   
4. In the center pane, click the template that you want to use to create your site.
5. If you want to add the new site to the current site — as folders in the current site, and not as a separate site — select the Add to current Web site check box. This check box is available only when you already have a site open.
     Because this option applies the selected template to the current site, you can use the option only if no other template is already applied. For example, you cannot add a new site that you create from the Team Site template to a site that was created from the Blank Site template. In such a case, the only way to apply a new template is to delete the site and then re-create it based on another template.
   
6. If you want to use encrypted connections, select the Use Encrypted Connection (SSL) check box.
7. Click OK.
   If you have chosen Import Web Site Wizard in the General category, the Import Web Site Wizard opens. Remember that the Import Web Site Wizard uses the Publishing feature, which cannot copy or move SharePoint content such as lists or libraries. Therefore, you cannot use the wizard to import a SharePoint site.
   
The new site is created on the server.

Building and Deploying Solution Packages

Hello Guys,

First let's be clear on exactly what a Solution package is. Note I'm using 'Solution' with a capital S  in this article to distinguish between what we are discussing here and the general idea of a technical solution built using SharePoint. A Solution is a package of SharePoint items for deployment - in physical terms it is a cabinet file (.cab) which is given the extension of .wsp to differentiate it from standard .cab files. Other articles on this blog cover the idea of using SharePoint Features to deploy functionality, so let's also be clear on the relationship between Features and Solutions. In general terms, some of the tasks which cannot be done with a Feature alone but can be done with a Solution include:

• Deployment of certain files to the filesystem, e.g. an assembly for workflow or web parts, custom files which will reside in the ‘12’ folder 
• Deployment of web part definition files (.webpart)
• Web.config modifications e.g. the ‘SafeControls’ entry required for a custom web part
• Code Access Security config modifications e.g. those required for custom web parts not running from the GAC

In addition to being able to do these things, Solutions can also contain Features. The way I think of it is that the Solution wraps the Feature. In actual fact, I always recommend that even if they don't need to be (e.g. we're not doing anything in the list above), Features are always deployed as part of a Solution.  The reason for this is that the Solution framework takes care of deploying all required files to all Web Front End (WFE) servers in a SharePoint farm. This alone is incredibly useful in working towards repeatable deployments, and ensures your WFEs stay synchronized.


How Solutions are specified
The key file used to specify what a Solution package consists of is the manifest.xml file. Going back to my earlier post on deploying web parts, the manifest.xml file for that scenario looks like this:

<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="122C0F04-78B7-4d42-9378-6F8B4F93ADD1">

  <FeatureManifests>

   

    <FeatureManifest Location="COB.Demo.WebPartDeployment.WriteToFileWebPart\feature.xml" />

  FeatureManifests>

  <Assemblies>

    <Assembly     Location="COB.Demo.WebPartDeployment.WriteToFileWebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.dll"

        DeploymentTarget="GlobalAssemblyCache">

      <SafeControls>

        <SafeControl Assembly="COB.Demo.WebPartDeployment.WriteToFileWebPart, COB.Demo.WebPartDeployment, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5"

                    Namespace="COB.Demo.WebPartDeployment"

                    Safe="True"

                    TypeName="*" />

        SafeControls>

    Assembly>

  Assemblies>

  <DwpFiles>

    <DwpFile

     Location="COB.Demo.WebPartDeployment.WriteToFileWebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart"

      FileName="COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart" />

  DwpFiles>

Solution>

This is assuming the web part is being deployed to the GAC - for this illustration this is a simpler scenario than deploying to the web application's bin directory, where Code Access Security (CAS) policy would also be required. Effectively, the manifest specifies that the Solution package consists of the following:

• a Feature with a header file named 'feature.xml'
• an assembly for deployment to the GAC named 'COB.Demo.WebPartDeployment.WriteToFileWebPart.dll'
• an entry in the SafeControls section of the application's web.config file, specifying all types in the specified assembly should be treated as safe
• a web part definition file named 'COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart' - this will be deployed to the web part gallery on the site

Importantly, all these details in the manifest.xml file are only used by SharePoint when the generated Solution package is deployed. They are effectively the instructions which say "go and get this item from the .wsp file and put it here". The actual process for generating the .wsp file is another task.

Building Solution packages
There are 2 options for building the actual package - build it manually using makecab.exe, or use an automated solution - there are several community-developed tools/techniques available. Since it's always good practise to understand what's actually happening in such processes, we'll cover how to do it manually here.
The first step is to write a .ddf (Diamond Directive File). This is a set of instructions for makecab.exe on how to build the folder hierarchy inside the .cab file. For my web part example, my file looks like:

.OPTION Explicit

.Set CabinetNameTemplate="COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp" 

.Set DiskDirectory1="Package"

;***

manifest.xml

;** this directory name is used for the folder name under 12\TEMPLATE\Features, so should

;** match up with what you want to call the feature!

.Set DestinationDir=COB.Demo.WebPartDeployment.WriteToFileWebPart

elements.xml

feature.xml

.Set DestinationDir=COB.Demo.WebPartDeployment.WriteToFileWebPart

WebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart

WebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.dll

;***

This file tells makecab.exe to do the following:

• create a .cab file named 'COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp'
• put the 'manfest.xml' file at the root of the hierarchy
• put the 'elements.xml' and 'feature.xml' files in a subfolder called 'COB.Demo.WebPartDeployment.WriteToFileWebPart'
• also put the 2 other files (with extensions .webpart and .dll) in this same subfolder, but that makecab.exe should look for these files in a subfolder on the main filesystem called 'WebPart'

This instructions file is then passed to makecab.exe with the following command-line command:

D:\SolutionDeployment\Development\COB.Demo.WebPartDeployment>"C:\Program Files\Microsoft Cabinet SDK\BIN\MAKECAB.EXE" /f COB.Demo.WebPartDeployment.ddf

Couple of things to note here. At the command prompt we have ensured the current directory is the directory where all our Solution files are kept. This ensures that our relative references in the .ddf file above can be resolved. We pass the /f parameter to indicate we are passing a directives file, and also pass the location of this file.
Assuming all the files/references are OK, this results in a .cab file with a .wsp extension which will be created in a subfolder under the current directory called 'Package' (the folder will be created for you if it doesn't exist). We now have a Solution package which can be deployed to another SharePoint server. But first let's take a peek inside - this can be done by temporarily renaming the extension to .cab. You should then see something like:

SharePoint Interview Questions

Hi Friends,

                Below is the link for SharePoint Interview Questions. Please go through it.

                http://it.toolbox.com/wiki/index.php/Sharepoint_Interview_questions


Thanks & Best Regards,
 Rakesh