Backup of an individual database, Web application, or the entire farm Using Powershell command

Backup-SPFarm -BackupMethod <String> -Directory <String> [-AssignmentCollection <SPAssignmentCollection>] [-BackupThreads <Int32>] [-ConfigurationOnly <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-Item <String>] [-Percentage <Int32>] [-WhatIf [<SwitchParameter>]]

Or

Backup-SPFarm -ShowTree <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-ConfigurationOnly <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-Item <String>] [-WhatIf [<SwitchParameter>]]

BackupMethod - Specifies the type of backup file to be created.If a backup is performed with the

–ShowTree parameter, then the BackupMethod parameter is not used.

A full backup is a backup of all the selected data. A differential backup is a backup of all the selected data that has changed since the last full backup. If an item does not support differential backup, then a full backup is performed for that item instead.

The type must be either of the following:

- Full

- Differential

Directory  - Specifies the path where SharePoint 2010 Products stores the backup package it generates. If you have a computer on which Microsoft SQL Server 2008 and an instance of SharePoint 2010 Products are installed, you can use local drive paths. This includes a basic installation. However, if SQL Server 2008 and SharePoint 2010 Products are installed on multiple computers or if you have multiple servers running SharePoint 2010 Products, you must use Universal Naming Convention (UNC) share paths so that the SQL Server database and search components are written to the same location; for example, \\computer_name\volume\Backup).

Multiple backup packages can be stored in the same location. This is the same path that you pass to the Directory parameter of the Restore-SPFarm cmdlet.
The type must be either of the valid paths:
- C:\folder_name

Other parameters are optional .

In the Second command

ShowTree - Displays which objects in the farm will be backed up based on the other parameters passed to the Backup-SPFarm cmdelt, namely the Item parameter. Items that will be excluded from the backup based on the other parameters passed to the Backup-SPFarm cmdlet will be preceded with an asterisk character (*). Items that cannot be backed up will be enclosed in square brackets ([ ]). A backup will not be performed if the ShowTree parameter is present.

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

What is authentication? and Understanding Claims Based Authentication

Authentication is the process of determining whether someone or something is, in fact, who or what it is declared to be. In private and public computer networks (including the Internet), authentication is commonly done through the use of logon passwords. Knowledge of the password is assumed to guarantee that the user is authentic. Each user registers initially (or is registered by someone else), using an assigned or self-declared password. On each subsequent use, the user must know and use the previously declared password. The weakness in this system for transactions that are significant (such as the exchange of money) is that passwords can often be stolen, accidentally revealed, or forgotten.

 

For this reason, Internet business and many other transactions require a more stringent authentication process. The use of digital certificates issued and verified by a Certificate Authority (CA) as part of a public key infrastructure is considered likely to become the standard way to perform authentication on the Internet.

Logically, authentication precedes authorization (although they may often seem to be combined).

In the Microsoft world, authentication is usually performed by Active Directory.  I claim to be Sushant, and i prove this to Active Directory by providing my password. Other systems don’t trust me, they trust Active Directory. Active Directory gives systems a bit of data that says “yes, I personally know this guy. He is really Sushant.”

Now, if everyone used the same Active Directory installation in the same environment, then that’s all we would need. Claims based authentication is not needed in a simple environment like that.

But in the real world, things are different. We face three big challenges:

• Privacy regulations and other pieces of legislation are impacting what kind of information we are allowed to capture and store about users, so in some cases we can’t just demand that people give us all of their personal details.
• Businesses want to interoperate with other businesses, and government organisations want to provide more integrated services to citizens. However, different systems use different authentication systems (not everyone uses Active Directory, and even when they do, they have different instances.), and businesses want to integrate in a secure, legally compliant manner.

Claims based authentication is designed to address the two challenges mentioned above.

Claims based authentication addresses privacy and other compliance concerns by requesting less specific, less personal information about people, and by trusting other parties or systems to do the “proof of identity” check.

Powershell command to Upload and deploy a SharePoint solution package to the farm

Add-SPSolution [-LiteralPath] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Language <UInt32>] [-WhatIf [<SwitchParameter>]]

Detailed Description

The Add-SPSolution cmdlet adds a SharePoint solution package to the farm. This cmdlet does not deploy the uploaded SharePoint solution. Use the Install-SPSolution cmdlet to deploy the SharePoint solution in the farm

LiteralPath - Specifies the path to the solution package.The type must be a valid path in either of the following forms:

- C:\folder_name
- \\server_name\folder_name

Other parameters Are optional

Please find the details at : http://technet.microsoft.com/en-us/library/ff607552.aspx


Deploys an installed SharePoint solution in the farm

Install-SPSolution [-Identity] <SPSolutionPipeBind> [-AllWebApplications <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-CASPolicies <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-GACDeployment <SwitchParameter>] [-Language <UInt32>] [-Local <SwitchParameter>] [-Time <String>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]
Or

Install-SPSolution [[-Identity] <SPSolutionPipeBind>] -Synchronize <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Language <UInt32>] [-WhatIf [<SwitchParameter>]]

Identity -

Specifies the SharePoint solution to deploy.
The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint solution (for example, SPSolution1); or an instance of a valid SPSolution object

All other Fields are Optional

Please find the details at : http://technet.microsoft.com/en-us/library/ff607534.aspx

SharePoint 2010 Products administration by using Windows PowerShell

This article describes how to use Windows PowerShell with Microsoft SharePoint 2010 Products and provides an overview of basic Windows PowerShell cmdlets and concepts necessary to get the most benefit from this powerful functionality.

Overview

Windows PowerShell is a command-line scripting tool that provides an administrator full access to applicable application programming interfaces (APIs), along with the ability to unlock the capability to interact directly with SharePoint 2010 Products to manipulate Web applications, site collections, sites, lists and much more. In addition, the administrator has the ability to script cmdlets (pronounced "command-lets"), which makes for an improved experience from past product versions.

Windows PowerShell 2.0 is a pre-requisite for installing SharePoint 2010 Products. It will be installed, if necessary, when you run the Microsoft SharePoint Products Preparation Tool. By default, Windows PowerShell is located at the following path: <%SystemRoot%>\System32\WindowsPowerShell\v1.0\PowerShell.exe.

Note:

Windows PowerShell 2.0 is backward compatible with Windows PowerShell 1.0 and subsequently installs to the v1.0 folder.

We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

Accessing Windows PowerShell for SharePoint 2010 Products

After installing SharePoint 2010 Products, the applicable Windows PowerShell cmdlets are available by using the SharePoint 2010 Management Shell, or by using the Windows PowerShell console. With the management shell, you can manage every aspect of SharePoint 2010 Products. You can create new site collections, Web applications, user accounts, service applications, proxies, and more. The commands from the management shell output SharePoint objects based on the Microsoft .NET Platform. These objects can be applied as input to subsequent commands or stored in local variables for later use.

With the management shell, you do not have to register the snap-in that contains the cmdlets. Registration of the Microsoft.SharePoint.PowerShell.dll module for SharePoint 2010 cmdlets is automatic, as a result of the line Add-PSSnapin Microsoft.SharePoint.PowerShell in the SharePoint.ps1 file located in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\Config\PowerShell\Registration. If you choose to use the Windows PowerShell console, you must register this snap-in manually.

Whether you are using the management shell or the Windows PowerShell console, you can also load additional snap-ins.

To access the SharePoint 2010 Management Shell

1. On the Start menu, click All Programs.
2. Click Microsoft SharePoint 2010 Products.
3. Click SharePoint 2010 Management Shell.

Note:

The SharePoint 2010 Management Shell and the Windows PowerShell console also differ in the use of the ReuseThread option, which defines how the threading model is used. The management shell's use is defined by this line, {Host.Runspace.ThreadOptions = "ReuseThread"}, which is in the SharePoint.ps1 file

Permissions

Before you can use the management shell and the Windows PowerShell cmdlets, verify that you meet the following minimum requirements: See Add-SPShellAdmin.

If you do not have membership in the SharePoint_Shell_Access role or WSS_Admin_WPG local group, use the Add-SPShellAdmin cmdlet. When the Add-SPShellAdmin cmdlet is used, the user is added to the WSS_Admin_WPG group in all front-end Web servers and is added to the SharePoint_Shell_Access role. If the target database does not have a SharePoint_Shell_Access role, the role is automatically created. Once the Add-SPShellAdmin cmdlet has been run, the user can run SharePoint 2010 Windows PowerShell cmdlets in a multiple-server farm environment.

When you run the Add-SPShellAdmin cmdlet to add a user to the SharePoint_Shell_Access role, you must have the following security permissions:

• Securityadmin server role access on the SQL instance and the db_owner role in a database.
• Administrative permission on the local computer.

Note:

Typically, the person that will use the Add-SPShellAdmin cmdlet must be associated with the user account that was used for Setup.

You must run the Add-SPShellAdmin cmdlet for all databases to which you want to grant access. If no database is specified, the farm configuration database is used. If you do specify a database, the farm content database will be included in addition to the farm configuration database you specify.

To see a list of all of the *SPShellAdmin cmdlets, from a Windows PowerShell command prompt, type Get-Command -Noun SPShellAdmin.

Scripts and execution policies

Although you can use Windows PowerShell to perform a single administrative task, the real benefit of using Windows PowerShell cmdlets is the ability to use a script to automate a series of tasks. A script is a plain text file that contains one or more Windows PowerShell commands. Windows PowerShell scripts have a .ps1 file name extension.

When using a script, be aware that the minimum required execution policy for SharePoint 2010 Products is RemoteSigned, while the default policy for Windows PowerShell is Restricted. If the policy is left as Restricted, the SharePoint 2010 Management Shell will change the policy for Windows PowerShell to RemoteSigned. This means the SharePoint 2010 Management Shell must be launched with elevated administrative permission by selecting Run as administrator. This change will apply to all Windows PowerShell sessions.

Source : http://technet.microsoft.com/en-us/library/ee806878(office.14).aspx#section2

How to create a Document Library in Sharepoint 2010

Be on the site on which we want to create a Document Library .

On the Top left hand side Under Site actions You would see New Document Library

Fill In the details , Like name of the Library, Description, you can also select if you want it to be displayed in the Quick launch or not

 If you want to turn on Versioning you can enable it from here too.

The Document Library is created . you can also get into the document Library settings from here to make changes in the settings of the document library like

1. Permissions
2. versioning
3. Incoming Email settings
4. create columns , view , worflows etc

Can i Install SharePoint on Windows Vista/Windows 7

The majority of developers prefer to and, with the exception of SharePoint, usually do develop on a client operating system. This has not been possible on previous versions. Developers would have had even more of a problem in SharePoint Foundation 2010, as it will only ship in a 64-bit version. No 32-bit version will ship, not even for testing or evaluation purposes. Microsoft currently has no virtualization platform for the client operating system that supports 64-bit guests. This forces SharePoint developers to use alternate virtualization platforms (that is, VMWare that supports 64-bit guests). Or they have the option to use a server operating system such as Windows Server 2008 as a client operating system, which most are reluctant to do.

To promote development and adoption of SharePoint Foundation 2010/ SharePoint Server  2010, Microsoft has unblocked SharePoint 2010 installations on certain editions of Windows Vista and Windows 7. Only single computer installations will be allowed (one-click or single server farm). Initially this will not be an officially supported setup

What is a Farm Passphrase ?

The farm passphrase is a new security feature in SharePoint Foundation 2010. Similar to a password, it is created as part of the initial creation of a SharePoint farm (or as a part of upgrade). The passphrase is created during PSConfig portion of SharePoint installation. It is then only required for adding additional servers to the farm.

In addition to a somewhat added layer of security, the farm passphrases main function is that it is used to encrypt the credentials for the farm administrator and other “managed accounts.” Using the new managed accounts feature is optional and the details surround its use will be covered in detail in another module. Just Keep in mind that managed accounts are similar to traditional service accounts except they are managed by SharePoint. Because the credentials for these managed accounts can be encrypted by SharePoint, SharePoint also now has the capability to access account credentials and use them. For example when creating a new Web application, an administrator can select and associate a managed account to the Web application without having to know the password for that managed account. Using the encryption key created using the farm passphrase, SharePoint will be able to decrypt the credentials for any managed account. Administrators will thus potentially not have to know the passwords for any accounts managed by SharePoint, which can be a big plus in a least privileged security environment.