Run Timed out-Content Deployment job

Central admin URL/Lists/Content%20Deployment%20Jobs/AllItems.aspx
Go to list settings.
Notice how four lines are set to Required:
RemoteJobDestinationServerUrl
RemoteJobDestinationSiteCollection
RemoteJobIncludeSecurity
RemoteJobIncludeUserInfoDateTime
Go into the settings of each one and change it to not required.
Go back to the list again, and edit the properties of the Toro Full job.
For the field “Last Status” it will have a 13 in it. Change that to a 1. Save the job.
Go back into the settings for the 4 fields and change them back to required.

You can now go back to this page:
Central admin URL/_admin/Deployment.aspx
And the job will say Completed. You can now run the job again.
The job is running right now.

Get super user/reader accounts detail at web applications

Get-SPWebApplication | %{Write-Host “Web Application: ” $_.url “`nSuper user: ” $_.properties["portalsuperuseraccount"] “`nSuper reader: ” $_.properties["portalsuperreaderaccount"] “`n”}

Managed Metadata Service in SharePoint 2010

Manage metadata:
Metadata is the data of data.
Manage metadata helps to provide with central location to store, manage metadata throughout aany site with in that SharePoint farm. This feature in SharePoint 2010 is one one step ahead of content type and site columns which we used in SharePoint 2007, but content type and site column were restricted to site collections.
Term Store: This is a location where we have all our metadata stored in.
Term: It is associated with an item in SharePoint 2010. A term has a unique ID and it can have many different text labels (synonyms).
Term set: It is a collection of related terms. There are two types of Terms available in SharePoint 20010 Managed Terms and Enterprise Terms.
Managed Terms: It is commonly referred to as “Taxonomy” are predefined words or phrases that can only be created by users with the appropriate permissions.  We can refer to this special group of users as “Metadata Content Managers”.
Enterprise Terms: It is commonly referred to as “Folksonomy” are words or phrases that have been added by the end user. Now that we have a better understanding on some of the key concepts.
The managed metadata service account should be the part of local admin group, farm admin and should have security admin at DB.
There will be only one DB associated with this service application.

Create Managed Metadata service application:
Central admin --> Application --> Application Management --> Manage service application --> Click New and then select Managed Metadata service --> Enter the Managed metadata service name, enter the existing SQL server name and the Managed metadata DB -->Select the authentication as Windows Authentication --> Enter the new application pool name --> Select configure and select the account name --> select Report syndication import errors from site collections using this service and Add this service application to the farm's default list.--> Create

 Now start the managed metadata service through central admin --> Start the Managed Metadata service application through "Start- SPServiceInstance " where GUID is the GUID of Managed metadata application

The Set-SPMetadataServiceApplication cmdlet first erases all accounts, then adds the accounts that you specified. If you only want to modify one value, and you want to use Windows PowerShell to do this, consider writing a script that uses Get-SPMetadataServiceApplication to get the values of the account parameters, assigns the values of all account parameters to temporary variables, modifies the variables you want to change, and then uses Set-SPMetadataServiceApplication to set all four account parameters.

MOSS MA not found in UPA

Issue:
Getting error as "MOSS MA not found." while creating sync connection in SharePoint 2010 user profile service.
Resolution:
start the following services through service console at that service/app server
Forefront Identity Manager Service
ForeFront Identity Manager Synchronization Service

Excel graph look and feel issue- PowerPivot

Issue: 
Graph available in excel not looks fine while opening through web browser. Some of the Vertical line missed. The same graph works fine if it is opened with excel instead of web browser.
Resolution:
After a long research I found that the feature needs to be activate one feature at site collection and site feature:
I enabled once again the feature at "site feature" and "Site collection feature":
SharePoint Server Enterprise Site features
Features such as Visio Services, Access Services, and Excel Services Application, included in the SharePoint Server Enterprise License.
Please note: The excel graph view in web browser will be a problem for existing files but working for new files with same content.

Migration from SharePoint 2007 to 2010

 

Migration from SharePoint 2007 to 2010:

1)    Need to have the SharePoint 2007 on 64 bit, because the SharePoint 2010 supports only 64 bit.

2)    Upgrade the SQL server to 2005 with SP3 or 2008-SP1

3)    Create a new SharePoint 2010 farm.

4)    Install the same solution in 2010.

5)    Take the backup of the entire content database at SharePoint 2007

6)    Take the solutions backup.

7)    Run Preupgradecheck in MOSS 2007 server.

     Analyze & Fix the issues.

8)    Configure web applications in SharePoint 2010.

9)    Configure service applications.

10) Configure general farm settings.

11) Reapply customizations.

12) Detach the DBs from SharePoint 2007 and attach it with SharePoint 2010.

13) Post Migration fixes

Authetication in SharePoint 2010

Classic:

In SharePoint the classic authentication, all is managed by AD. AD authenticates user in classic mode.

Active Directory authenticates a user, provides an NT Token. The token is used to authenticate to SharePoint. SharePoint consumes that token and it's converted into a SPUser object for authorization.

Kerberos Authentication:

Kerberos V5 authentication protocol provides a mechanism for authentication – and mutual authentication. – between a client and a server or between one server to another server.

Windows server 2003 implements the Kerberos V4 protocol as a security Support Provider(SSP), which can be accessed through the security support provider interface(SSPI). The Kerberos key distribution center(KDC) uses the domain’s AD directory service database as its security account database. AD is required for default NTLM and Kerberos implementations.

The Kerberos V5 protocol assumes that the initial transactions between client and server take place on an open network in which the packet is transmitted on a network which can be monitored and modified. This is very much like today’s Internet, where an attacker can easily pose either a client or a server, and can easily tamper the communication between client and server.

The Kerberos protocol is a more secure protocol that supports ticketing authentication. If user’s request contains valid user credentials and a valid Service Principal Name (SPN), then A Kerberos authentication server grants a ticket in response to a client computer authentication request. The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). The KDC distributes shared secret keys to enable encryption. The client and server computers must also be able to access Active Directory directory services. For Active Directory, the forest root domain is the center of Kerberos authentication referrals

Pros:

• Most secure Integrated Windows authentication protocol
• Allows delegation of client credentials
• Supports mutual authentication of clients and servers
• Produces less traffic to domain controllers
• Open protocol supported by many platforms and vendors

Cons:

• Requires additional configuration of infrastructure and environment to function correctly
• Requires clients have connectivity to the KDC (Active Directory domain controller in Windows environments) over TCP/UDP port 88 (Kerberos), and TCP/UDP port 464 (Kerberos Change Password – Windows)

Claims Based Authentication:

It is based on .net.

STS:

STS is built on Geneva framework which is now called Windows Identity Foundation. The STS (Security Token Service) core responsibility is issuing, managing, and validating security tokens. An STS resides on both an identity provider and SharePoint. STS is built on top of the shared services framework which is why it's listed as a service application within Central Administrator\Manage Service Applications page.

After a trust is established between SharePoint and an Identity provider, web applications can be set with Claims authentication type instead of classic. If a client attempts to authenticate to a claims aware web application, SharePoint redirects a client to the associated trusted identity provider. The identity provider authenticates clients and provides a security token. That token could be either of the following:

· NT Token

· SAML Token

This security token is then passed to SharePoint STS. In short, the STS will validate the token "Claims Based Identity" and generate a new security "SAML" token back to the client. This token is generated by SharePoint and for SharePoint. The client sends this SAML token to SharePoint to prove that he/she is officially authenticated. SharePoint validates and authenticates user and a SPUser object is created and is used for authorization.

1. Client hit SharePoint site via HTTP (Get)
2. SharePoint redirects client to Identity Provider in order to get a security token
3. Client attempts to authenticate to trusted Identity Provider
4. The identity provider's (Security Token Service) will validate the username and password and provide a security token to a client.

Note: A security token could be a Windows NT Token, SAML token, or FBA token

5. The client has a security token (authenticated) and submits it to SharePoint STS "Security Token Service"
6. SharePoint STS receives security token from client and determines if we trust the issuer of that token "Identity Provider"
7. STS then performs claims augmentation
8. STS issues client new SAML token
9. Client request resource "site" with new SAML token
10. SharePoint consumes SAML token, "validates authentication successful", and builds an SPUser object in order to authorize to the secured resource

FBA:

FBA users no longer uses an ASP.Net identity. FBA is now claims aware and the SharePoint STS facilitates the authentication process. Once user is authenticated, the SharePoint STS provides a SAML token to the client.

Note: When creating a web application designated for FBA, you must specify claims authentication type.

STS (federated equivalent of a domain controller) "issues tokens"

Basic FBA Sign-in process:

1. User signs in via FBA with credentials

2. SharePoint STS calls membership provider to authenticate

3. SharePoint STS calls role provider to get all the roles for the user

4. Post successful authentication, a SAML token is generated by the SharePoint STS and passed back to the user

5. The user then authenticates to SharePoint with SAML token and authentication is officially completed

It needs to make changes in the web.config files of that web application.

Supported authentication methods:

Method category	Authentication methods
Windows authentication	NTLM
	Kerberos
	Anonymous
	Basic
	Digest
Forms-based authentication	Lightweight Directory Access Protocol (LDAP)
	Microsoft SQL Server database or other database
	Custom or third-party membership and role providers
SAML token-based authentication (new with SharePoint Server 2010)	Active Directory Federation Services (AD FS) 2.0
	Third-party identity provider
	Lightweight Directory Access Protocol (LDAP)

To configure a Windows Authentication application to use Forms Based Authentication then you can convert from Classic Mode to Claims Based. But, there is no UI exist for doing this conversion. The only way around is through PowerShell.

IMPORTANT:  If an application is created using Claims Based Authentication and if you want to convert to Classic Mode then it is not possible either through the UI or through PowerShell.

How Claims works with Services

Accessing Internal Services

Within a Single Farm:

The classic example is a user performing a search. The WFE's (Server1) search web part talks to service application proxy. The associated search service application proxy calls the local STS to get a SAML token for the user. Once SAML token is collected, the search service application proxy then calls a server running the Query Processor via WCF call. I'll call this server, "Server 2". Server 2 receives the incoming request and validates the SAML token against its local STS. Once validated, Server 2 connects to various components to gather, merge, and security trims search results. Server 2 sends the trimmed search results back to Server 1 which is then presented to the user.

Accessing External Services

SharePoint 2010 STS can manipulate a SAML token in order to present it to an external web service. The way it presents the identity depends on the type of external web service. The goal is preventing the additional prompt for credentials so that a full Single Sign-On (SSO) experience is possible. The STS is comprised of the WIF "Windows Identity Framework" and also the C2WTS. Each component is used dependent upon the type of external service accessed.

Variation in SharePoint 2010

Variation:

Use of variation is to provision a publishing site into multi lingual sites and pages. A variation is a SharePoint feature that facilitates the management and maintenance of content that can be served to multiple languages, countries, or regions, but they can also represent different brands or devices.

How does Variations work?

For each channel you wish to serve content, you can specify a Variations label. Labels are instantiated as SharePoint publishing sites and the full set of labels in a site collection is referred to as the Variations Hierarchy. I refer to SharePoint publishing sites created and managed by the Variations feature as “variation sites.”

Using variations, target variation sites reflect one source variation site in terms of pages and site structure. When setting up variations, specify one variation site as the source; all other variation sites are targets. By default, pages published on the source variation site are copied to all target variation sites as draft versions and sites created on the source are created (not copied – this is an important distinction) on all target variation sites. You can only have one source variation site per Variation Hierarchy and you can only have one Variation Hierarchy per site collection.

What’s new in SharePoint 2010?

The concept and core architecture of Variations, in which pages and site structure are replicated across multiple variation sites in a site collection remains the same as in Microsoft Office SharePoint Server 2007; however, we have made significant improvements to better meet the needs of enterprise customers serving content across multiple channels.

These improvements can be divided into four categories:

• Server Citizenship
• Content Distribution
• Editing Experience
• Reliability

Server Citizenship

Variations operations now execute in the background via timer jobs. For the end user, this means that you no longer have to wait at a progress screen for operations to complete.  For the system administrator, this means that the cost of resource-intensive operations like Create Hierarchies can be better managed.

You can adjust the frequency with which Variations operations run in Central Administration. Next, I’ll explain the difference between the “Create” and “Propagate” timer jobs in the context of improvements we’ve made to the Variations content distribution models.

Site and Page Propagation

MOSS 2007 featured two models for distributing pages across your Variations Hierarchy:

1. Automatic Creation: If “Automatic Creation” is enabled on the Variation settings page (it is enabled by default), then publishing a page on the source variation site will cause that page to be copied to all target variation sites.

2. Manual Creation: If “Automatic Creation” is disabled, then the “Create Variations” Ribbon button is the only way to copy a new page to a specific, individual target variation site.

We’ve received feedback that there are often cases in which changes need to be published locally to the source variation site without being propagated to all targets. For instance, if the source variation site has a typo in English, the correction may not be relevant to a target site in German, so if the correction is published in the source page, it can be unnecessarily confusing to copy this changed English version to all target sites.

In SharePoint 2010, we introduce a third, “hybrid” content distribution model:

3. On-Demand Page Propagation

A setting has been added (configurable through the Object Model) to disable Automatic Page Propagation. When the setting is enabled, publishing or approving a page on the source variation site will not cause that page to be copied to any target variation sites. The "Automatic Creation" setting will be ignored for pages. "Update Variation" and "Create Variation” are the means by which a user can distribute content across the Variation hierarchy on-demand.

I’ll go into more detail on content distribution models in a future post. But so as not to keep you in suspense on how to configure on-demand page propagation, here are the PowerShell commands:

Enable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Add("DisableAutomaticPropagation", "True")
$folder.Update();

Disable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Remove("DisableAutomaticPropagation")
$folder.Update();

We’ve also made improvements for target variation site content owners to better understand what has changed on the source variation site when new draft versions appear on a target variation site.

Editing Experience

To make efficient use of their time and effort, target variation content editors need an easy and informative way to determine what content is new when pages are propagated from the source variation.

A new “View Changes” button compares the most recent source version propagated to the target with the most recent source version published on the target.  Changes are highlighted in a pop-up report to enable content processing directly in the rich-text editor.

Highlighted report

Corresponding location in the Rich Text Editor

This button is available on a target variation page after it has been published once and a new draft version has been copied from the source variation site via one of the Variations timer jobs. I will go into more detail on this new feature in an upcoming blog post dedicated to explaining View Changes with screenshots, a sample workflow, and an example scenario.

Reliability

One of our main goals for Variations in SharePoint 2010 is to make the feature more reliable so enterprise customers can entrust management and distribution of content across multiple channels to Variations.

Now that Create Hierarchies runs in the timer service, we support pausing and resuming this operation during timer service recycles to support long-running operations in large deployments. This also means that the process is not affected by Application Pool recycles. We’ve also made the relationships list, which tracks all target pages linked to a source page, more robust. We now track variations pages using GUIDs for better performance and scale.

Thanks for reading. Check back soon for upcoming blog posts on what’s new in Variations and other exciting developments in Enterprise Content Management.