Microsoft SMB Protocol and CIFS Protocol

Microsoft SMB Protocol and CIFS Protocol

The Server Message Block (SMB) Protocol is a network file sharing protocol, and as implemented in Microsoft Windows is known as Microsoft SMB Protocol. The set of message packets that defines a particular version of the protocol is called a dialect. The Common Internet File System (CIFS) Protocol is a dialect of SMB. Both SMB and CIFS are also available on VMS, several versions of Unix, and other operating systems.

The technical reference to CIFS is available from Microsoft Corporation at Common Internet File System (CIFS) File Access Protocol.

Although its main purpose is file sharing, additional Microsoft SMB Protocol functionality includes the following:

Dialect negotiation
Determining other Microsoft SMB Protocol servers on the network, or network browsing
Printing over a network
File, directory, and share access authentication
File and record locking
File and directory change notification
Extended file attribute handling
Unicode support
Opportunistic locks

In the OSI networking model, Microsoft SMB Protocol is most often used as an Application layer or a Presentation layer protocol, and it relies on lower-level protocols for transport. The transport layer protocol that Microsoft SMB Protocol is most often used with is NetBIOS over TCP/IP (NBT). However, Microsoft SMB Protocol can also be used without a separate transport protocol—the Microsoft SMB Protocol/NBT combination is generally used for backward compatibility.

The Microsoft SMB Protocol is a client-server implementation and consists of a set of data packets, each containing a request sent by the client or a response sent by the server. These packets can be broadly classified as follows:

Session control packets—Establishes and discontinues a connection to shared server resources.

File access packets—Accesses and manipulates files and directories on the remote server.

General message packets—Sends data to print queues, mailslots, and named pipes, and provides data about the status of print queues.

Ref: http://msdn.microsoft.com/en-us/library/aa365233(VS.85).aspx

SharePoint Escalation Team - MOSS 2007 Search Query Mechanism Part 1

Ref: http://blogs.msdn.com/spses/archive/2010/03/02/moss-2007-search-query-mechanism-part-1.aspx

Errors when crawling content sources in SharePoint Server 2007: "Event ID 2436" and "Access is denied"

Ref: http://support.microsoft.com/kb/971382

SQL Recovery Model Overview (Simple vs Full Recovery)

Simple Recovery Model

--------------------------------------------------------------------------------
The simple recovery model minimizes administrative overhead for the transaction log, because the transaction log is not backed up. The simple recovery model risks significant work-loss exposure if the database is damaged. Data is recoverable only to the most recent backup of the lost data. Therefore, under the simple recovery model, the backup intervals should be short enough to prevent the loss of significant amounts of data. However, the intervals should be long enough to keep the backup overhead from affecting production work. Including differential backups in the backup strategy can help reduce the overhead.

Generally, for a user database, the simple recovery model is useful for test and development databases or for databases containing mostly read-only data, such as a data warehouse. The simple recovery model is inappropriate for production systems where loss of recent changes is unacceptable. In such cases, we recommend using the full recovery model.

For more information, see Backup Under the Simple Recovery Model.
http://msdn.microsoft.com/en-us/library/ms191164.aspx

Full Recovery and Bulk-Logged Recovery Models

--------------------------------------------------------------------------------

The full recovery and bulk-logged recovery models provide greater protection for data than the simple recovery model. These recovery models rely on backing up the transaction log to provide full recoverability and to prevent work loss in the broadest range of failure scenarios.

•Full recovery model

Provides the normal database maintenance model for databases where durability of transactions is necessary.

Log backups are required. This model fully logs all transactions and retains the transaction log records until after they are backed up. The full recovery model allows a database to be recovered to the point of failure, assuming that the tail of the log can be backed up after the failure. The full recovery model also supports restoring individual data pages.

For more information, see Backup Under the Full Recovery Model.
http://msdn.microsoft.com/en-us/library/ms190217.aspx


•Bulk-logged recovery model

This recovery model bulk logs most bulk operations. It is intended solely as an adjunct to the full recovery model. For certain large-scale bulk operations such as bulk import or index creation, switching temporarily to the bulk-logged recovery model increases performance and reduces log space consumption. Log backups are still required. Like the full recovery model, the bulk-logged recovery model retains transaction log records until after they are backed up. The tradeoffs are bigger log backups and increased work-loss exposure because the bulk-logged recovery model does not support point-in-time recovery. For more information, see Backup Under the Bulk-Logged Recovery Model http://msdn.microsoft.com/en-us/library/ms190692.aspx and Considerations for Switching from the Full or Bulk-Logged Recovery Model. http://msdn.microsoft.com/en-us/library/ms190203.aspx

For more details & comparison table please refer link below:


Ref: http://msdn.microsoft.com/en-us/library/ms189275.aspx  

How to stop the transaction log of a SQL Server database from growing unexpectedly

http://support.microsoft.com/kb/873235

A transaction log grows unexpectedly or becomes full on a computer that is running SQL Server

http://support.microsoft.com/kb/317375

SQL Server 2008 Transaction Log Truncation

http://technet.microsoft.com/en-us/library/ms189085.aspx

Collaborative Application Markup Language [CAML]

Introduction to Collaborative Application Markup Language (CAML)

Collaborative Application Markup Language (CAML) is an XML-based language that is used in Windows SharePoint Services to define the fields and views used sites and lists. CAML is also used to define tables in the Windows SharePoint Services database during site provisioning.

Note: CAML is case-sensitive.

Site Customization with CAML

CAML can be used in various ways to customize a SharePoint site, including the following:

•In script or code that implements members of the Windows SharePoint Services object model, where CAML strings are passed through method parameters, assigned to properties, or returned by methods and properties

•In SOAP messaging that passes CAML strings to a Windows SharePoint Services Web service to interact remotely with a deployment

•In front-end site definitions used to instantiate SharePoint sites

•In Windows SharePoint Services Features to add specific functionality within a particular scope

Rendering with CAML

CAML is used for two types of rendering in Windows SharePoint Services: to define the type of data that is contained within a field, and to construct HTML that is displayed in the browser. For information on the two major uses of CAML, see Data-Defining Elements and HTML-Rendering Elements.

Programming with CAML

The following programming tasks and overview topics illustrate various ways in which CAML is used to customize site and list definitions:

Ref: http://msdn.microsoft.com/en-us/library/ms426449.aspx

-----------------------------------------

Data-Defining Elements


Collaborative Application Markup Language (CAML) has two major types of elements—those for page rendering and those for field rendering and schema definition. The CAML field rendering elements are designed for use when rendering individual field values. These can appear in field definitions, or more commonly, in FLDTYPES.XML at Local_Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\50\Templates\1033\xml.

A field is a column or an attribute of information that a user can add to a list. Each list on a Web site based on Microsoft Windows SharePoint Services has metadata stored in the List of Lists table in the database. The format of the schema is an XML structure, such as the following:

Each of the display modes (Display, Edit, New, etc.) contains a definition for how to render each of the field data types that are supported by Windows SharePoint Services.


For each display mode there is a display pattern, or CAML-rendering expression. Some CAML elements are used specifically in display patterns. Others can be used in either context, for page rendering or for field rendering, but are used primarily in rendering fields. The following intrinsic CAML-rendering elements are used to build templates that can include both static HTML and data, as well as metadata of the field being rendered

Ref: http://msdn.microsoft.com/en-us/library/dd586682(v=office.11).aspx
-----------------------------------------
Programming with the Microsoft.SharePoint and Microsoft.SharePoint.Administration Namespaces

Major top-level classes
The Microsoft.SharePoint and Microsoft.SharePoint.Administration namespaces provide types and members for working with lists and sites, as well as for managing a server or collection of servers running Microsoft® Windows® SharePoint™ Services. These namespaces have four major top-level classes:

•SPGlobalAdmin
•SPVirtualServer
•SPSite
•SPWeb

From these classes you can gain access to all the other classes to work with lists and Web sites, or to manage one or more servers. Starting with one of these classes, you can work through the object model to the class that you need to use. The following table briefly describes these four classes.

Ref: http://msdn.microsoft.com/en-us/library/dd586716(v=office.11).aspx