Pages

Showing posts with label Sharepoint. Show all posts
Showing posts with label Sharepoint. Show all posts

Get Manager approval in SharePoint Designer 2010 - Step by Step

A fundamental condition that you always encountered when gathering workflow requirement is to get the user's manager approval, a tedious amount of coding to connect to active directory retrieve user profile information, get his manager login name, pass it as a parameter to the workflow, create a custom task for the manager with a notification. 
SharePoint 2010 Designer to the rescue, you can do all the above in 15 clicks, with ZERO code involved. Just by doing the following:

  1. Open SharePoint Designer 2010 and connect to your SharePoint site.
  1. Click Workflows and select the workflow type you need, for this presentation I'll use reusable workflow with All content types as my scope. But this doesn't affect the following logic, the same steps applies for the List and Site workflows.
  1. From the Workflow ribbon select Actions > Collect Data from User, you can also select assign a to-do task but collect action from user allows you to create a custom task for the manager
  1. This will show you the Action in the workflow editor.
  1. The action is constructed from three parts:
    1. The data, which is the custom task that will be collected
    2. This user, which in our case the manager
    3. Output to variable: collect. Collect is  the task ID which you can change it, use it to refer to the task when you need to pass a variable through this task.
  1. Clicking on data will allow you to create the custom task by starting the task wizard, open the wizard and click Next.
  2. You will need to specify a Task name, and you can also specify a description. For now lets call the task "Review Task". And click Next
  1. Now you can Specify the Task custom field by clicking Add and select the field type, I will specify two field:
    1. Approved as a choice with Yes/No.
    1. Comment as a text area.

More Here

Courtesy:http://blogs.technet.com/b/meacoex/archive/2010/11/01/get-manager-approval-in-sharepoint-designer-2010-step-by-step.aspx

Configuring ADFS Trusts For Multiple Identity Providers with SharePoint 2010

To begin with, start on the ADFS server to which your SharePoint site has the trust (we'll call it RP).
  1. Open the federationmetadata.xml file from the ADFS server that users will be authenticating against (we'll call it IP) in the browser.  By default the location will be https://myIpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml.  If you get an untrusted certificate error in the browser you'll need to add the root authority certificate for the IP ADFS server's SSL to your trusted root authorities store.  NOTE:  This assumes that you have the same root authority certificate for both the SSL access to the IP ADFS web server and the IP ADFS token signing certificate.  If they are not the same then you need to add the root certificate authority for BOTH to the local RP ADFS server's certificate store.  To do that:
    1. Click through to view the web site, which should show the Xml file.
    2. Click on the View Certificates icon so you can see the SSL certificate that was used.
    3. Click on the Certificate Path tab.
    4. Double-click on the top certificate in the chain - this is the root authority certificate.
    5. Click on the Details tab.
    6. Click on the Copy to File... button and save the certificate in CER format to the local disk.  You can now close out all of the certificate dialogs and browser.
    7. Open up the Certificates MMC; if you don't have a shortcut for this then just start the MMC from the Run menu, Add snap-ins, and add the Certificates snap-in for the Computer (local).
    8. Expand the Trusted Root Certification Authorities node, right-click on the Certificates node, and choose the Import menu.  Follow the wizard to import the root authority .CER file you exported above.
    9.  
  2. Open up the AD FS 2.0 Management application.
  3. Expand the Trust Relationships node, then right-click on the Claim Provider Trusts node and select Add Claims Provider Trust...
  4. Click the Start button to begin the wizard.
  5. Leave the default option selected to Import data about the claims provider published online or on a local network, and in the edit box put in the address to the FederationMetadata.xml file (https://myIpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml by default) then click the Next button.  If your root authority certificate is correctly installed and the name can be resolved, then the wizard will continue to the next step.  If not, you have troubleshooting to do.
  6. Provide a Display Name and optionally Notes, then click the Next button.


More Here

Courtesy:http://blogs.technet.com/b/speschka/archive/2010/11/24/configuring-adfs-trusts-for-multiple-identity-providers-with-sharepoint-2010.aspx

Configuring SharePoint to use a Specific Identity Provider in ADFS

One example where this may be necessary is if you have one ADFS server that is a sort of hub for other ADFS servers being used. If we follow this scenario out, suppose you have multiple web applications in SharePoint, and for each one your users should authenticate against a different Active Directory forest via ADFS. Well, using the procedures I described in the previous posting, you can create the trusts in ADFS to make that scenario work. However, the first time your users navigate to the SharePoint site that uses that hub ADFS server, or if they use the In Private features of IE to navigate to the site, they will get an intermediary page from ADFS before they log on. That intermediary page will list ALL of the claims identity providers and ask the user to select the one against which they wish to authenticate. Then they are redirected over to the login page for that identity provider (IP).



In a perfect world though, we don't want users to see that intermediary page - we'd rather redirect them immediately to the correct IP for authentication. Fortunately ADFS provides support for this through a "whr" query string parameter. If you add this query string parameter when navigating to ADFS then it will do a look up of the whr parameter to find a matching IP. If it finds one, then it automatically redirects you to that IP. In ADFS 1.x that parameter was a URN, like urn:foo:monkey. In ADFS 2.0 it takes the format of a Uri. To find the value you should use for the whr query string parameter, open up the AD FS 2.0 Management application. Expand the Trust Relationships...Claims Provider Trusts node, then double-click on the IP that you want used. Click on the Identifiers tab and you will see a grayed out edit box called Claims provider identifier:. The value in there is what should be in your whr query string parameter. For example, in my environment the IP identifier is http://tgen1.terri.local/adfs/services/trust. In order to get users of a web application to redirect immediately over to that IP I need to append the following to the normal login query string that SharePoint uses: &whr=http://tgen1.terri.local/adfs/services/trust When I do that I no longer see the IP selection page in ADFS, I just go directly to logging in.


More Here


Courtesy:http://blogs.technet.com/b/speschka/archive/2010/11/24/configuring-sharepoint-to-use-a-specific-identity-provider-in-adfs.aspx

Delegation of control with SCVMM 2008 R2 self service portal


This topic is about delegation of controle of virtual machines with Virtual Machine Manager self service portal.
you can make a profile with in VMM, and the user of that profile can only controle the virtual machines you want as an administrator.

First you login for example via SharePoint Portal to the Vitual Machine environment :




You login with the right user credentials to get in the VMM self service portal.
Then you get in the serverrole environment of Microsoft System Center Virtual Machine Manager.
The administrator gives you the rights to the right environment in SCVMM with the right Virtual Machine to manage with
delegation of controle.

You can connect all your own virtual machine with the right delegation of controle :
 


More Here

Courtesy:http://mountainss.wordpress.com/2011/04/20/delegation-of-control-with-scvmm-2008-r2-self-service-portal/

Using SiteMinder authentication in Sharepoint

Introduction
Many enterprise IT environments use Netegrity SiteMinder (hereafter called SiteMinder) to secure Web applications and servers. When customers decide to move to MS SharePoint 2007 (MOSS), they want to continue to use SiteMinder for their existing Web environment, and also as the authentication mechanism for their portal.
This article is an example of the implementation of the solution that allows using the SiteMinder authentication with WSS 3.0.

The key technical points of the solution:
1. SiteMinder authentication.
2. FBA (Form Based Authentications) for SharePoint applications.
3. Custom login form.
4. Custom membership and role providers.

SiteMinder authentication

The SiteMinder authentication is used for single sign on (SSO) functionality. Once SiteMinder authenticates a user it adds a special HTTP header with the user name to each HTTP request. SiteMinder can also create an authentication cookie that can be used if you want client software integration, for example, if you want to modify a document from a document library, using MS Word.
Since the SiteMinder authenticates users, the SharePoint authentication can be, and should be bypassed, we trust that the user is already authenticated and her name is contained in the HTTP header. The custom login form pulls the UserID from the HTTP header, creates the authentication token and redirects the request to the destination page. The trick is to make the SharePoint framework to authorize (or deny) the authenticated user correctly. To resolve users and role names the SharePoint framework has to use custom membership and role providers.
FBA (Form Based Authentications) and custom login form.
Since we are going to use the custom authentication mechanism (not Windows authentication) we have to use the Form Based Authentication. Our form shouldn’t have any UI, and user shouldn’t even be aware that the form is called.
The FBA has to be set up on the SharePoint Central Administration website. After opening the site go to: Application management->application security->authentication providers
At this point make sure that you are changing the right SharePoint application, the application URL is displayed at the upper-right corner of the page.
When you see the authentication type for your application (it’s windows by default) click “Default” and you will be navigated to the “Edit authentication” page.
On this page you can set up the Form Based authentication and the membership and role providers.
If you want to be able to edit documents from document libraries using MS Office software, don’t forget to click the “client software integration” radio-button
After you set up the FBA authentication for a SharePoint application, the central administration web site changes the web.config file of the SharePoint application. It sets up the authentication to “Forms” and loginURL to _layouts\logon.aspx. In the modified web.config file of the SharePoint application you will see something like this:


More Here

Courtesy:http://mosssiteminderauthentication.blogspot.com/

Anonymous access SharePoint Web Application

Demonstrate how can we enable anonymous access for a sharepoint web applicaqtion, I already have enabled forms authentication and whenever I try to open the web application, following screen comes up that shows I must login to the site to create document libraries and lists.

Follow the steps to enable anonymous access for the web application.
  • Move to central administration
  • Choose correct web application where u want to enable anonymous access, by default central administration web application will be selected, you can change the selected application and then select the membership provider.

click on the provider and edit the settings, you will see the following screen and check “Anonymous Access” check box.



open your web application and login using your site collection administrator account and move to Advance permissions in people and group section, go to settings menu and click “Anonymous access” as per following screen

after clicking you will see following screen and select “Entire Site” and press ok

once it is done you have enabled anonymous access, now open your web application, you will see following screen

Highlighted red section on top right corner shows that you are not logged in to the site and you can access the main site page.

More Here


Courtesy:http://shafaqat309.wordpress.com/2011/01/16/anonymous-access-sharepoint-web-application/

Sites vs Site Collections Sharepoint

When building a collaboration system, you will soon face a choice between using sites or site collections. In general I tend to favor multiple site collections. i.e. each project or department has their own site collection.

Storage Quotas

Most organizations don’t have an unlimited amount of storage. Keeping the data growth under control is important. In SharePoint it’s possible to impose a quota at the site collection level, but not at the site level. If you chose one big site collection, everybody would be dipping into the same pool. When a site collection is approaching it’s quota, the site collection owners will receive email notifications.

Security

In SharePoint, security groups are defined at the site collection level. i.e. visitors, members and owners. Using seperate site collections, it’s easy to keep track of all the groups and you know they are all related to the content stored in this site collection.

By using multiple sites in the same site collection, you would have to start breaking security inheritance at various levels and adding additional groups. i.e. Project 1 members, Project 2 members, etc. If you have a couple of hundred projects, you end up with several hundred SharePoint groups as well; keeping tabs on what people can do at various levels becomes tricky. When a site is deleted, the groups supporting it should also be removed; custom code is required.


If information sharing is important for your organization, some additonal steps need to be done if you use multiple site collections. One option is to give everyone read permission through a web application policy. The downside is if a site collection wants to hide its information; i.e. they are working on market sensitive information such as a corporate merger. A different approach is to have a system that synchronizes all of the visitor groups groups; e.g. using a timer job. Each site collection should then have a mechanism that allows them to opt out of this synchronization.

Content databases

A SharePoint web application can have multiple content databases; each content database equals one SQL database. This allows the amount of data to scale and at the same time keep the SQL databases at a size manageble for disaster recovery. Using administration tools, it’s possible to move a site collection between content databases; something that is not possible for a single site. This functionality can be important in balancing your load across several databases.

Navigation

One area where multiple site collections become a challenge is navigation. For sites within a site collection, sub sites can automatically appear in the navigation controls. These entries are only shown if the current user has access to them; security trimming.

Since site collections don’t have a hierachy and they don’t know about each other, there is not automatic support for cross site collection navigation. You will have to come up with your own system. i.e. using the object model to add entries to the navigation system, or read the navigation configuration from some other location.

Site queries

One web part that can be very handy is the Content Query Web Part. This allows you to perform a query that rolls up content from your site. Keeping the number of sites within a site collection low, these types of queries have an easier time.

Provisioning challenges

If you go for the multiple site collection approach, additional questions need answering.

* Who should be able to create new site collections?
* Should new site collections require approval? If so, by whom?
* A site collection will have a lifespan. How does one determine the end and what does one do then?
* Should the requestor become a site collection administrator? This allows them to do anything, including screwing up the whole site collection. This level of access may only be acceptable for certain individuals?

More Here


Courtesy:http://sharepointmystery.wordpress.com/2011/01/16/sites-vs-site-collections/

Restore Sharepoint Site Use Sharepoint Powershell

  • Run Sharepoint 2010 Products -> Sharepoint 2010 Central Administrator -> Application management -> Manage Web Application click NewCreate New Site
  • And then fill name of website, port, register account for website click OK.
  • Run Sharepoint 2010 Products -> Sharepoint 2010 Management Shell, write script :
Stsadm –o restore –url -filename <”(location and name of file).bak”>
Script restore
  •  
  • Check Collection administrator
Run Sharepoint 2010 Products -> Sharepoint 2010 Central Administrator -> Application Management -> Change site collection administrators -> use username is administrator

More Here


Courtesy:http://tedyseptiady.wordpress.com/2011/01/07/restore-sharepoint-site-use-sharepoint-powershell/

Connecting to SharePoint with Claims Authentication

In a nutshell, the process of connecting to SharePoint happens like this; Make a request, re-direct to an STS for login, post token from login to SharePoint’s STS (‘_trust’ site), post token from SharePoint’s STS to SharePoint, and then capture and store the ‘FedAuth’ cookie generated by the site. Then and only then, can you start accessing the data from the site by providing the ‘FedAuth’ cookie. The diagram below outlines the process in a slightly more detail…




The new SharePoint Client objects accessing SharePoint and most of its information much easier than before. Unfortunately; they are new, and new things have very little support. Fortunately, this fact didn’t keep us from long hours with Microsoft Tech Support (naturally calling me back right as I was about to walk out the door).


Now on to the good stuff…


The primary component of using the SharePoint Client objects is the ClientContext class. This class manages all of the interaction with your application and the SharePoint site. You tell the ClientContext what you want it to do and then tell it to execute. All-in-all, it makes the code much cleaner when pulling information from SharePoint.



Instead of muddying up my code, I decided to extend the ClientContext class and make it able to connect to a Claims-based site on its own. The key to extending the class, was in utilizing the ‘ExecutingWebRequest’ event. Here is where I was able to do all of my work and setup the connection with SharePoint.


But; before I continue, one warning. This is beta code and should be used at your own risk. I currently only having it working by retrieving authentication by impersonating the local context. So, it will not pass on any Claims Based credentials if used from a website (Windows Identity Foundation).


If anyone reading this can figure out a clean way to pass on the user’s token, please let me know. Thanks!
view source
print?
001 using System;
002 using System.Linq;
003 using System.Net;
004 using System.Net.Security;
005 using System.Security.Principal;
006 using System.ServiceModel;
007 using System.ServiceModel.Channels;
008 using System.Text;
009 using System.Web;
010 using System.Xml;
011 using Microsoft.IdentityModel.Protocols.WSTrust;
012 using Microsoft.SharePoint.Client;
013
014 namespace SharePointLibraries
015 {
016 public class ClaimsClientContext : ClientContext
017 {
018 // store this info at the class level for access by the ExecutingWebRequest event
019 private string SharePointRootUrl
020 {
021 get
022 {
023 // return (new Uri(_sharePointSiteUrl)).GetComponents(UriComponents.Scheme | UriComponents.Host, UriFormat.SafeUnescaped).ToString();
024 var siteUri = (new Uri(_sharePointSiteUrl));
025 return string.Format("{0}://{1}/", siteUri.Scheme, siteUri.Host);
026 }
027 }
028 private string _sharePointSiteUrl;
029 private string SharePointSiteUrl
030 {
031 get { return _sharePointSiteUrl.EndsWith("/") ? _sharePointSiteUrl : _sharePointSiteUrl + "/"; }
032 set { _sharePointSiteUrl = value; }
033 }
034 public string SharePointSiteRealm { get; set; }
035 private string _loginStsUrl;
036 private string LoginStsUrl
037 {
038 get { return _loginStsUrl.EndsWith("/") ? _loginStsUrl : _loginStsUrl + "/"; }
039 set { _loginStsUrl = value; }
040 }
041
042 // store the Saml token so that it can be used by successive requests
043 private static string IssuedSamlToken { get; set; }
044 private static DateTime IssuedSamlTokenExpireDate { get; set; }
045
046 ///
047 /// Public constructor for all three being strings
048 ///

049 ///
050 ///
051 ///
052 public ClaimsClientContext(string sharePointSiteUrl, string sharePointSiteRealm, string loginStsUrl)
053 : base(sharePointSiteUrl)
054 {
055 if (sharePointSiteUrl == null) throw new ArgumentNullException("sharePointSiteUrl");
056 if (sharePointSiteRealm == null) throw new ArgumentNullException("sharePointSiteRealm");
057 if (loginStsUrl == null) throw new ArgumentNullException("loginStsUrl");
058
059 // save the settings
060 SharePointSiteUrl = sharePointSiteUrl;
061 SharePointSiteRealm = sharePointSiteRealm;
062 LoginStsUrl = loginStsUrl;
063
064 // specify the default credentials to use
065 Credentials = CredentialCache.DefaultCredentials;
066
067 // add a handler for the ExecutingWebReques event to provide the SAML token
068 // this.ExecutingWebRequest += new EventHandler(ClientContext_ExecutingWebRequest);
069 ExecutingWebRequest += ClientContext_ExecutingWebRequest;
070 }
071
072 ///
073 /// Public constructor for Site Url being a Uri
074 ///

075 ///
076 ///
077 ///
078 public ClaimsClientContext(Uri sharePointSiteUrl, string sharePointSiteRealm, string loginStsUrl)
079 : base(sharePointSiteUrl)
080 {
081 if (sharePointSiteUrl == null) throw new ArgumentNullException("sharePointSiteUrl");
082 if (sharePointSiteRealm == null) throw new ArgumentNullException("sharePointSiteRealm");
083 if (loginStsUrl == null) throw new ArgumentNullException("loginStsUrl");
084
085 // save the settings
086 SharePointSiteUrl = sharePointSiteUrl.ToString();
087 SharePointSiteRealm = sharePointSiteRealm;
088 LoginStsUrl = loginStsUrl;
089
090 // specify the default credentials to use
091 Credentials = CredentialCache.DefaultCredentials;
092
093 // add a handler for the ExecutingWebReques event to provide the SAML token
094 ExecutingWebRequest += ClientContext_ExecutingWebRequest;
095 }

More Here


Courtesy:http://fredericloud.com/2011/01/11/connecting-to-sharepoint-with-claims-authentication/

Sharepoint 2007 : Configure and start the Microsoft Single Sign-On service

To use single sign-on, the Microsoft Single Sign-On service (SSOSrv) must be installed on all Microsoft Windows front-end Web servers in the farm. SSOSrv must also be installed on all servers running Excel Services. If the Business Data Catalog search is used, SSOSrv must also be installed on the index server.
SSOSrv is configured by using the Services console. When configuring the service, a logon account is required. The logon account must meet all of the following criteria:
  • Must be a domain user account. It cannot be a group account.
  • Must be an Office SharePoint Server farm account.
  • Must be a member of the local Administrators group on the encryption-key server. (The encryption-key server is the first server on which you start SSOSrv.)
  • Must be a member of the Security Administrators role and db_creator role on the computer running Microsoft SQL Server.
  • Must be either the same as the single sign-on administrator account, or a member of the group account that is the single sign-on administrator account.

Configure and start the Microsoft Single Sign-On service

  1. On the server, click Start, Control Panel, Administrative Tools, and then click Computer Management.
  2. In the Computer Management console, expand Services and Applications, and then click Services.
  3. Right-click Microsoft Single Sign-On Service, and then choose Properties.
  4. On the General tab, change the Startup type to Automatic.
  5. On the General tab, under Service Status, click Start.
  6. Click OK to save your changes and close the Properties window.
  7. Repeat steps 1 through 6 for each applicable server in the farm.Source : http://technet.microsoft.com/en-us/library/cc262932.aspx#Section1


More Here


Courtesy:http://panca.wordpress.com/2009/04/07/sharepoint-2007-configure-and-start-the-microsoft-single-sign-on-service/

Configure Sharepoint (MOSS) Single Sign-On

.
  1. http://www.thorprojects.com/blog/archive/2008/08/02/moss-single-sign-on-setup-step-by-step.aspx
  2. http://www.sharepointblogs.com/michael/archive/2007/07.aspx
  3. http://www.sharepointblogs.com/llowevad/archive/2007/06/25/sharepoint-2007-single-sign-on-setup.aspx
First step is to create 2 domain security groups (SSOADMINS and SSOMANAGERS), set the Group Scope as Global and Group Type as Security.
Create a domain user account (SSOADMIN) and make it a member of the SSOADMINS group, and also make SSOADMIN a member of the Administrators group on the encryption key server (SSO service server – see below). Also make any other user accounts who will manage Sharepoint SSO service settings members of the SSOADMINS group.
Add user accounts as members of the SSOMANAGERS group, for those accounts who will manage Single Sign-On Enterprise Application Definition settings.
Ensure that the SSOADMIN user is a member of the local Administrators group on each WFE server.

Create a login for the SSOADMIN user on the Sharepoint SQL Server machine and assign them to the dbcreator and securityadmin roles.
After making changes to domain accounts / groups, it might be a good idea if your re-logon/restart your MOSS server. Also it may be worthwhile logging into your MOSS server as the SSOADMIN user while configuring SSO Server settings.  Last time I configured SSO I kept getting the “You do not have sufficient rights to perform this operation” error message, which I solved by logging in as the SSOADMIN user to make those changes.
Configure the Microsoft Single Sign-On Service (services snap-in) to start automatically using the SSOADMIN user account for it’s logon details. This must be done on each WFE server and also on the Indexing server.
* Note: Do not start the SSO service on any server yet, the first server on which the SSO service is started becomes the encryption key server.
On the machine you’ve decided will be the encryption key server, start the SSO service. On this machine, log into Sharepoint Central Admin.
Add the SSOADMIN user to the farm administrators group.
In Site Settings -> Permissions, add the SSOADMINS and SSOMANAGERS groups and give them Read permissions.
In Operations -> Service Accounts, select the Single Sign-On service and set the credentials to the SSOADMIN user account.
In Operations -> Manage Settings for Single Sign-On, select Manage Server Settings; 

Set the Single Sign-On Administrator Account to the SSOADMINS group.
Set the Enterprise Application Definition Administrator Account to the SSOMANAGERS group.
Leave the remaining options as default and click OK.
If you see an error message displayed to the effect that you don’t have enough permissions, rights, access denied etc, check that you’ve configured the logins on SQL Server, made the SSOADMIN a local Administrator, finally you might login as SSOADMIN while you make these changes.
In Operations -> Manage Settings for Single Sign-On, select Manage Encryption Key;
Click Create Encryption Key, once this is finished you’ll probably want to back it up.
At this point you’re ready to start creating Enterprise Application Definitions and setting credentials for those EAD’s.

More Here


Courtesy:http://platinumdogs.wordpress.com/2008/10/30/configure-sharepoint-moss-single-sign-on/

Leverage and Extend Claims based identity in SharePoint 2010

Windows Identity Foundation (WIF) is the platform on which SharePoint 2010 claims authentication is based. WIF, which is fully supported in SharePoint 2010, ADFS 2.0, ASP.NET, Windows Communication Foundation (WCF), and any other .NET application you care to develop, provides the infrastructure necessary to generate, transmit, and process claims-based identity in a simple and straightforward manner. It removes the roadblocks imposed by legacy authentication schemes like NTLM and Kerberos and puts control directly into the hands of developers, users, and IT security professionals. long story short, it’s a framework written to help solve identity issues common in the of cloud computing and service-oriented architecture.


The idea of claims based identity is one that many people are willing to try. Getting accurate information out there to the public though does take time.

The important point is this is based on industry standards. Many different entities are on board along with Microsoft in this matter. The digital world continues to give us new opportunities and those involved believe that this will help all of us to get the most out of it. There is a strong foundation in place to continue building upon. The use of AD FS v2, CardSpace, and Windows Identity Foundation are all important pieces of this puzzle.


As a demonstration of these capabilities, I’ll show how SharePoint 2010, WCF,and WIF can be put together to solve the identity delegation problem. In this demo session part 1 I start establishing the trust relationship between ADFS 2.0 and SharePoint with PowerShell and demonstrate how the claims get into SharePoint.Then we build and deploy a claims viewer Webpart with WIF programming model. In part 2 We start with a web service that is front-ending line-of-business information stored in a SQL database. Then, we’ll configure it to use WIF to request the calling user’s claims from SharePoint and process the token so that authorization decisions can be made. we’ll surface this information in SharePoint 2010 as an External Content Type using Business Connectivity Services (BCS).


More Here


Courtesy:http://sptechpoint.wordpress.com/2010/11/23/whats-new-in-sharepoint-2010-security/

What is Single Sign On in SharePoint? (Non Technical)

Single Sign On in SharePoint is a Service. It is really just something that holds credentials (login’s/passwords) for different applications. These other applications can be CRM systems, ERP systems, whatever. It does not automatically integrate or pass through credentials to these systems. This may sound obvious to some people, but it’s important to point out because this is what I always hear people think it does.





What it really does is allows developers and administrators to connect other systems in webpart code and as an example an administrator could use it in the BDC application definition xml’s authentication for connecting to say a SQL database. It is wonderful in that it gives a great starting point and service for configuration and development to pull data from other systems into SharePoint (typically).

More Here


Courtesy:http://sharepointkb.wordpress.com/2008/11/25/what-is-single-sign-on-in-sharepoint-non-technical/

Accessing Users and Roles ClientObjectModel Sharepoint

Working with users, groups, and roles, and dealing with their permissions for SharePoint elements, can be quite complex. In former SharePoint versions, the only way to affect the security was to use the provided security web services. With SharePoint 2010, the client object model dramatically simplifies working with security settings. For third-party applications, no matter if they are written as Windows or Silverlight applications, it’s very easy to access the SharePoint security model and to build extended functionality on it. This section contains examples of how the client object model can deal with security.
• How to add users to a SharePoint group
• How to retrieve members of a SharePoint group
• How to create a role
• How to add a user to a role
• How to create a new SharePoint group and assign the group to a role
• How to break the security inheritance
How to Add Users to a SharePoint Group
Adding a user to a SharePoint group is a common task, particularly in conjunction with creating a web site. The following example shows two ways to add a user to a group. The first one uses the Group.Users.AddUser method, which expects a User instance of an existing user. The second method adds a new user to a group by using the UserCreationInformation class. The new user is identified by its LoginName. If the user already exists in the site collection, the user is added to the group anyway. The examples in Listings  require a valid group within the property Web.AssociatedMemberGroup to exist; thus, the default group at the time of the web site creation has not been removed.
public void Example19()
{
ClientContext ctx = new ClientContext(“http://clserver%22%29;/
Group membersGroup = ctx.Web.AssociatedMemberGroup;
// Add existing user to membersGroup
User currentUser = membersGroup.Users.AddUser(ctx.Web.CurrentUser);
// Add new user to membersGroup
UserCreationInformation userCreationInfo = new UserCreationInformation();
userCreationInfo.Email = aa@bb.com;
userCreationInfo.LoginName = @”ws10582\john”;
userCreationInfo.Title = “John”;
User newUser = membersGroup.Users.Add(userCreationInfo);
ctx.Load(currentUser);
ctx.Load(newUser);
ctx.Load(membersGroup);
ctx.ExecuteQuery();
Console.WriteLine(“The users ” + currentUser.LoginName
+ ” and ” + newUser.LoginName
+ ” have been added to group ‘” + membersGroup.Title
+ “‘.”);
}
function example19() {
var ctx = new SP.ClientContext.get_current();
this.membersGroup = ctx.get_web().get_associatedMemberGroup();
// Add existing user to membersGroup
this.currentUser = this.membersGroup.get_users().
addUser(ctx.get_web().get_currentUser());
// Add new user to membersGroup
this.userCreationInfo = new SP.UserCreationInformation();
this.userCreationInfo.set_email(“aa@bb.com“);
this.userCreationInfo.set_loginName(“ws10582\john”);
this.userCreationInfo.set_title(“john”);
this.newUser = this.membersGroup.get_users().add(this.userCreationInfo);
ctx.load(this.currentUser);
ctx.load(this.newUser);
ctx.load(this.membersGroup);
ctx.executeQueryAsync(
Function.createDelegate(this, this.onSucceededCallback),
Function.createDelegate(this, this.onFailedCallback));
}
function onSucceededCallback(sender, args) {
alert(“The users ” + this.currentUser.get_loginName()
+ ” and ” + this.newUser.get_loginName()
+ ” have been added to group ‘” + this.membersGroup.get_title()
+ “‘.”);
}
How to Retrieve Members of a SharePoint Group
To get a list of all users that are members of a specified group, you can use the Group.Users collection

public void Example20()
{
ClientContext ctx = new ClientContext(“http://clserver%22%29;/
Group membersGroup = ctx.Web.AssociatedMemberGroup;
UserCollection allUsersOfGroup = membersGroup.Users;
ctx.Load(allUsersOfGroup);
ctx.ExecuteQuery();
foreach (User user in allUsersOfGroup)
{
Console.WriteLine(“ID: ” + user.Id + “, LoginName=” + user.LoginName);
}
}
function example20() {
var ctx = new SP.ClientContext.get_current();
var membersGroup = ctx.get_web().get_associatedMemberGroup();
this.allUsersOfGroup = membersGroup.get_users();
ctx.load(allUsersOfGroup);
ctx.executeQueryAsync(
Function.createDelegate(this, this.onSucceededCallback),
Function.createDelegate(this, this.onFailedCallback));
}
function onSucceededCallback(sender, args) {
var enumerator = this.allUsersOfGroup.getEnumerator();
while (enumerator.moveNext()) {
var user = enumerator.get_current();
alert(“ID: ” + user.get_id() + “, LoginName: ” + user.get_loginName());
}
}
How to Create a Role
Defining your own roles, also known as permission levels, is a common task when dealing with complex security requirements. With the client object model, you can easily define your own roles and assign them to SharePoint users or groups.
public void Example21()
{
ClientContext ctx = new ClientContext(“http://clserver%22%29;/
Web oWeb = ctx.Web;
BasePermissions basePerms = new BasePermissions();
basePerms.Set(PermissionKind.ViewListItems);
basePerms.Set(PermissionKind.ViewPages);
RoleDefinitionCreationInformation roleCreationInfo =
new RoleDefinitionCreationInformation();
roleCreationInfo.BasePermissions = basePerms;
roleCreationInfo.Description = “Role for viewing pages and list items”;
roleCreationInfo.Name = “Restricted read-only access”;
RoleDefinition roleDef = oWeb.RoleDefinitions.Add(roleCreationInfo);
Ctx.Load(roleDef);
ctx.ExecuteQuery();
Console.WriteLine(“New role ‘” + roleDef.Name +
“‘ has been successfully created.”);
}
function example21() {
var ctx = new SP.ClientContext.get_current();
this.oWeb = ctx.get_web();
var basePerms = new SP.BasePermissions();
basePerms.set(SP.PermissionKind.viewListItems);
basePerms.set(SP.PermissionKind.viewPages);
var roleCreationInfo = new SP.RoleDefinitionCreationInformation();
roleCreationInfo.set_basePermissions(basePerms);
roleCreationInfo.set_description(“Role for viewing pages and list items”);
roleCreationInfo.set_name(“Restricted read-only access”);
roleCreationInfo.set_order(1);
this.roleDef = this.oWeb.get_roleDefinitions().add(roleCreationInfo);
ctx.load(this.roleDef);
ctx.executeQueryAsync(
Function.createDelegate(this, this.onSucceededCallback),
Function.createDelegate(this, this.onFailedCallback));
}
function onSucceededCallback(sender, args) {
alert(“New role ‘” + this.roleDef.get_name() +
“‘ has been successfully created.”);
}
image
How to Add Users or Groups to Roles
Assigning SharePoint users or groups to roles is shown in Listings
public void Example22()
{
ClientContext ctx = new ClientContext(“http://clserver%22%29;/
Web oWeb = ctx.Web;
Principal oUser = oWeb.CurrentUser;
RoleDefinition oRoleDef =
oWeb.RoleDefinitions.GetByName(“Restricted read-only access”);
RoleDefinitionBindingCollection roleDefinitionBindingColl =
new RoleDefinitionBindingCollection(ctx);
roleDefinitionBindingColl.Add(oRoleDef);
RoleAssignment oRoleAssignment =
oWeb.RoleAssignments.Add(oUser, roleDefinitionBindingColl);
ctx.Load(oUser, user => user.Title);
ctx.Load(oRoleDef, role => role.Name);
ctx.ExecuteQuery();
Console.WriteLine(“User ‘” + oUser.Title +
“‘ assigned to role ‘” + oRoleDef.Name + “‘.”);
}
function example22() {
var ctx = new SP.ClientContext.get_current();
this.oWeb = ctx.get_web();
this.oUser = oWeb.get_currentUser();
this.oRoleDef =
this.oWeb.get_roleDefinitions().getByName(“Restricted read-only access”);
var roleDefinitionBindingColl =
SP.RoleDefinitionBindingCollection.newObject(ctx);
roleDefinitionBindingColl.add(this.oRoleDef);
var oRoleAssignment = this.oWeb.get_roleAssignments().add(
this.oUser, roleDefinitionBindingColl);
ctx.load(this.oUser, “Title”);
ctx.load(this.oRoleDef, “Name”);
ctx.executeQueryAsync(
Function.createDelegate(this, this.onSucceededCallback),
Function.createDelegate(this, this.onFailedCallback));
}
function onSucceededCallback(sender, args) {
alert(“User ‘” + this.oUser.get_title() + “‘ assigned to role ‘” +
this.oRoleDef.get_name() + “‘.”);
}
As you can see, the RoleAssignments.Add (in JavaScript, RoleAssignments.add) method takes a Principal object as a parameter. The Principal class serves as the base class for both users (User) and groups (Group). So, you can assign either a user or a group to a role.
■ Caution When using JavaScript, the instantiation for the class SP.RoleDefinitionBindingCollection is done through the static function SP.RoleDefinitionBindingCollection.newObject(ClientContext), which takes the current client context as a parameter.
How to Create a New SharePoint Group and Assign the Group to a Role
The examples in this section demonstrate the creation of a new SharePoint group, using the
GroupCreationInformation class. The Contributors role is then assigned to this new group
public void Example23()
{
ClientContext ctx = new ClientContext(“http://clserver%22%29;/
Web oWeb = ctx.Web;
GroupCreationInformation groupCreationInfo = new GroupCreationInformation();
groupCreationInfo.Title = “My Custom Contributor Group”;
groupCreationInfo.Description = “This group has contributor rights.”;
Group oGroup = oWeb.SiteGroups.Add(groupCreationInfo);
RoleDefinitionBindingCollection roleDefinitionBindingColl =
new RoleDefinitionBindingCollection(ctx);
RoleDefinition oRoleDefinition =
oWeb.RoleDefinitions.GetByType(RoleType.Contributor);
roleDefinitionBindingColl.Add(oRoleDefinition);
oWeb.RoleAssignments.Add(oGroup, roleDefinitionBindingColl);
ctx.Load(oGroup, group => group.Title);
ctx.Load(oRoleDefinition, role => role.Name);
ctx.ExecuteQuery();
Console.WriteLine(“Group ” + oGroup.Title + ” created and assigned to role “
+ oRoleDefinition.Name);
}
function example23() {
var ctx = new SP.ClientContext.get_current();
this.oWeb = ctx.get_web();
var groupCreationInfo = new SP.GroupCreationInformation();
groupCreationInfo.set_title(“My Custom Contributor Group”);
groupCreationInfo.set_description(“This group has contributor rights.”);
this.oGroup = oWeb.get_siteGroups().add(groupCreationInfo);
var roleDefinitionBindingColl =
SP.RoleDefinitionBindingCollection.newObject(ctx);
this.oRoleDefinition =
oWeb.get_roleDefinitions().getByType(SP.RoleType.contributor);
roleDefinitionBindingColl.add(this.oRoleDefinition);
this.oWeb.get_roleAssignments().add(this.oGroup, roleDefinitionBindingColl);
ctx.load(this.oGroup, “Title”);
ctx.load(this.oRoleDefinition, “Name”);
ctx.executeQueryAsync(
Function.createDelegate(this, this.onSucceededCallback),
Function.createDelegate(this, this.onFailedCallback));
}
function onSucceededCallback(sender, args) {
alert(“Group ‘” + this.oGroup.get_title() + “‘ created and assigned to role ‘”
+ this.oRoleDefinition.get_name() + “‘.”);
}
image
How to Break the Role Inheritance
In SharePoint, by default all elements (such as Web, List, and ListItem) rely on role inheritance. That means that permissions are inherited from top to bottom. A user has the same permissions on a list item as on a list, because the list item inherits its permissions from the list. There are scenarios, though, in which this default role inheritance is not desirable and has to be broken—for example, if you want a list item to be accessed only by special users or groups. The example in this section shows how to break the role inheritance of a list item and assign special permissions to it. Figures show the list item permissions before and after breaking the role inheritance.

More Here


Courtesy:http://kolliparachandra.wordpress.com/2010/11/01/accessing-users-and-roles-clientobjectmodel/

Planning SharePoint Claim Based Authentication

SharePoint Server 2010 introduces claims-based authentication, which is built on Windows Identity Foundation (WIF).

If you select classic-mode, you can implement Windows authentication and the user accounts are treated by
SharePoint Server 2010 as Active Directory Domain Services (AD DS) accounts.

If you select claims-based authentication, SharePoint Server 2010 automatically changes all user accounts to claims
identities, resulting in a claims token for each user. The claims token contains the claims pertaining to the user.
Windows accounts are converted into Windows claims. Forms-based membership users are transformed into
forms-based authentication claims.

Claims authentication is built on WIF. WIF is a set of .NET Framework classes that are used to implement claims-based identity.
Claims authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML.
For more information about claims authentication.
Click here see detail
Architecture for SAML token-based providers


SharePoint security token service This service creates the SAML tokens that are used by the farm.
The service is automatically created and started on all servers in a server farm.
The service is used for inter-farm communication because all inter-farm communication uses claims authentication.
This service is also used for authentication methods that are implemented for Web applications that use claims authentication,
including Windows authentication, forms-based authentication, and SAML token-based authentication.
You must configure the security token service during the deployment process.
Click here for more information Configure the security token service (SharePoint Server 2010).

Token-signing certificate (ImportTrustCertificate) This is the certificate that is exported from an IP-STS. The certificate is copied to one server in the farm.
Identity claim The identity claim is the claim from a SAML token that is the unique identifier of the user.
Only the owner of the IP-STS knows which value in the token will always be unique for each user.
Realm In the SharePoint claims architecture, the URI or URL that is associated with a SharePoint Web application
that is configured to use a SAML token-based provider represents a realm.
SPTrustedIdentityTokenIssuer This is the object that is created on the SharePoint farm that includes the values
necessary to communicate with and receive tokens from the IP-STS.

Relying party security token service (RP-STS) In SharePoint Server 2010, each Web application that is configured
to use a SAML provider is added to the IP-STS server as an RP-STS entry.
A SharePoint Server farm can include multiple RP-STS entries.

Identity provider security token service (IP-STS) This is the secure token service in the claims environment
that issues SAML tokens on behalf of users who are included in the associated user directory.

More Here


Courtesy:http://kmukesh.wordpress.com/2010/11/26/planning-sharepoint-claim-based-authentication/

The SharePoint Security Object Model

image
This is a class diagram of some standard SharePoint objects available inside the SharePoint object model. As you can see from this object model, there are two internal classes, namely SPMember and SPPrincipal. SPPrincipal inherits from SPMember. In short, anything that can be given a security right within SharePoint in one way or the other inherits from the SPMember base class. Therefore, there are SPGroup, SPUser, and SPRole. These three objects are what can be given permissions inside of SharePoint. As you will see shortly, SPRole has been deprecated since SharePoint 2007.
image
At the heart of this class diagram is an internal abstract base class called SPSecurableObject.
Anything inside of SharePoint that be given a permission is an SPSecurableObject. Any
SPSecurableObject implements the ISecurableObject interface. Examples of such object are SPWeb, SPSite, SPList, and SPListItem. Let’s take the example of SPWeb. SPWeb inherits from
SPSecurableObject. Therefore, it is an object that permissions can be given to. The next question is how exactly do you give permissions to this object? The SPWeb object has different properties on it. These properties represent the roles (SPRole), the group’s (SPGroup), and the user’s (SPUser) that have access to this particular SPWeb.
There are three properties representing the users that have access to this particular SPWeb. They are SiteUsers, Allusers, and Users.
• Users: Users explicitly added to the SPWeb.
• AllUsers: All users that have anything to do with the SPWeb. Users plus users
SharePoint saw through Groups.
• SiteUsers: Aggregation of AllUsers at the SiteCollection level.


The SiteUsers is a superset of AllUsers is a super set of Users. And all three of these are a collection of the SPUser object. This can be seen in Figure
image
Obviously, it is the SiteCollection which is the eventual security boundary. All SPWeb inherit the users from SiteCollection, unless of course such inheritance has been broken. Similarly, there are two properties representing groups, which are Groups and SiteGroups. You can probably guess what these are: the groups are also inherited from parent to SPWeb. As before, both Groups and SiteGroups represent collections of the SPGroup object.
Finally, there is also a property called Roles. This is a collection of type SPRole. However, as
mentioned earlier, that SPRole has been deprecated since SharePoint 2007. To replace these, two new objects have been introduced, namely SPRoleDefinition and SPRoleAssignment, which can be seen in the class diagram in Figure
image
In order to understand these two objects, visit your site collection. In your site collection, go to site settings, and then under users and permissions click site permissions. You should see the various groups and users added to this SiteCollection, along with their associated permission levels. This can be seen in Figure
image
In the ribbon, you will also find a button called permission levels, so click that button. Clicking this button will show you the defined permission levels inside a SiteCollection, as shown in Figure
image
Click the full control link and it should show you the various permissions you can configure in any SharePoint permission level. Some of these permissions can be seen in Figure
image
Specifically, in the object model, the permissions you see as check boxes are represented by an Enumerator called SPBasePermissions. SPRoleDefinition represents the levels such as “Full Control”, “Contribute”, while a Role Assignment contains a collection of Role Definitions.
Any object that inherits from SPPrincipal can be assigned a SPRoleAssignment. This becomes
clearer when you observe all the objects in one single class diagram, as shown in Figure

More Here


Courtesy:http://kolliparachandra.wordpress.com/2010/12/06/the-sharepoint-security-object-model/

Securing and Managing Site Content Sharepoint

Permission levels – are made up of sets of permissions. SP ships with a list of permissions; can’t be added, edited or deleted.

Securable objects – are levels within SP 2010 that can be locked down, or secured, by setting specific user access. Sites, lists, ibraries and items are all securable objects.

Server farm level acceess:

(1) Local administrator: Also members of server farm administrator; can do all duties of a farm admin, plus other non-Sharepoint tasks, such as installing patches, service packs, IIS, start/stop service, SQL server maintenance etc. By default do not have access to SP sites.

(2) Farm administrator: Can perform any tasks in Central Admin. By default do not have access to SP sites.

To manage server farm administrators, from Central Admin website, Site Actions à Site Settings à People and Groups. It’s not a functions in one of the 8 major central admin categories!!!

Service Application Administrators, two groups:

(1) Service administrators: Delegated by Farm Admin, can manage settings for a specific service application. Central Admin à Manage service Application.

(2) Feature administrators: Delegated by Farm Admin, are associated with a specific feature within a service application.

Site Collection Administrators –

Have full permission/access to all sites under the site collection.




Site Administration –

Site Owners group – users have full control to content on this site. Can be customized on a child site or lower level. When you create a site, a [site name] Owners group is created. Group members will have full access to the new site.

Administration beneath the site level –

doesn’t always require group membership.

à Document library or list – no specific group that manages content at this level, but permissions can be configured. Useful when you only want a portion of your content to have restricted access.
à Individual items – similar to above.

Understanding permissions –

Permission levels –

Tips –

(1) Not a good idea to modify default permission levels. Make a copy and edit it instead.
(2) Not good idea to delete default permission level.

6 default levels -

(1) Full control – will have access to everything on the site and can perform site admin tasks. Not to be confused with site collection administrators.
(2) Design – view/add/update/delete/approve/customize. Can approve contents too. Can do anything on the securable objects except for admin tasks.
(3) Contribute – view/add/update/delete list items and documents. Th standard permission level to grant user access to contents and containers.
(4) Read – Vew pages and list items and download documents. Standard permission for user who need read, but not add.edit item.
(5) Limited Access – Can view specific items, lists, documents, folders. The permission cannot be assigned. Instead, it’s a customized permissions.
(6) View Only – Can view pages, list items, documents. Users can’t download documents with server-side handlers.

Others:

(1) Restricted Read – For publishing sites only. Similar to read, but not to create alerts, browse user info or use client integration.
(2) View Only
(3) Approve – Edit/approve pages, list items, documents. For publishing sites only.
(4) Manage hierarchy – create sites; edit pages/list items/documents. Fir Publishing sites only.

Creating a New Permission Level Based on Existing Permission Level

Sharepoint Security Groups: Created within the browser and can be used with given site collections. By default, SP creates security groups (site groups) when a new site collection is created. The groups created vary according to the templarte that is used.

(1) Site Collection Administrators: has Full Control permission and can do anything to the site collection. Can’t be overridden.

Owners/Members/Visitors – By default these groups are created for all new site collections.

Configuring Permission during site creation –

When you create a new [site], default value is to use the same permission as the parent site collection. If choose to use a unique permission, you will be prompted to configure three new access groups: [new site name] owners/members/visitors.

When you add a new SP security Group (site collection level), it applies to current securable objects and all child securable objects.

Active Directory Groups -

You can also use AD Groups. For security, you must use AD email-enabled security groups. Distribution list cannot be used. The group must have a SID (security ID) in AD.

More Here


Courtesy:http://sharepointstudy.wordpress.com/2010/12/13/chapter-8-%E2%80%93-securing-and-managing-site-content/

SharePoint – Must Knows

What is SharePoint?
- Microsoft SharePoint is a browser-based collaboration and document management platform from Microsoft. A Content Management System which allows groups to set up a centralized, password protected space for document sharing. Documents can be stored, downloaded and edited, then uploaded for continued sharing.


Differences between SharePoint Portal Server and WSS?
- Windows SharePoint Services 2.0 is a collection of services for Microsoft Windows Server 2003 that you can use to share information, collaborate with other users on documents, and create lists and Web Part pages. You can also use Windows SharePoint Services 2.0 as a development platform to create collaboration applications and information-sharing applications.


SharePoint Portal Server 2003 is a scalable, enterprise portal server that is built on Windows SharePoint Services 2.0.


In addition to the features of Windows SharePoint Services 2.0, SharePoint Portal Server 2003 includes the following features:


* News and topics
* My Site, with personal views and with public views
* Information that can be targeted to specific audiences
* Index functionality and search functionality across file shares, across Web servers, across Microsoft Exchange Public Folders, across Lotus Notes, and across Windows SharePoint Services 2.0 sites
* Alerts that notify you when changes are made to relevant information, documents, or programs
* Single sign-on functionality for enterprise application integration
* Integration with Microsoft BizTalk Server

What is a Document Library?
- Document Libraries are collections of files that you can share with team members on a Web based on Microsoft Windows SharePoint Services. For example, you can create a library of common documents for a project, and team members can use their Web browsers to find the files, read them, and make comments. Users with Microsoft Office 2003 can check out and edit the files as if they resided on a local or network drive.


By default, your team Web site comes with a built-in document library named Shared Documents, which is listed on the Quick Launch bar as well as on the Documents and Lists page.


What is a Meeting Workspace?
- A Meeting Workspace is a Web site for gathering all the information and materials for one or more meetings. If your meeting materials — such as agendas, related documents, objectives, and tasks — are often scattered, a Meeting Workspace site can help you keep them all in one place.


It provides a place where your meeting attendees can go for the most up-to-date information about the meeting, whether you are managing a year-long project with recurring meetings or planning a small event.


What is a Document Workspace?
- A Document Workspace site is a Microsoft Windows SharePoint Services site that is centered around one or more documents. Colleagues can easily work together on a document — either by working directly on the Document Workspace copy or by working on their own copy, which they can update periodically with changes that have been saved to the Document Workspace copy.


What is a Site Hierarchy?
- When you configure a report server to run in SharePoint integrated mode, the SharePoint Web hierarchy is used to address items that are processed and managed on a report server.


The following elements of the Web hierarchy can be used to access and secure report server content. Other objects such as lists and pages are not used to access report server content and therefore are not described below.


* SharePoint Web Application: A SharePoint Web application can be installed as a stand-alone server or under a farm that contains a collection of virtual servers. A Web application has a URL (for example, http://servername) and can contain multiple sites.
* Site: A site is either a parent site for a Web application or a sub-site.
* SharePoint Library: A library contains documents or folders. A library or folder in a library is the only site object that can store reports, report models, shared data sources, and external images.
* Item: Report server items that you can reference in a URL include a report definition for a report or sub report, a report model, a shared data source, or an external image.


What is a Web Part?
- Web Parts are the building blocks of Web Part Pages in SharePoint sites. They can be added to Web Part Pages in SharePoint sites to offer users increased functionality. The Web Parts that are loaded within a site’s Web Part zones usually determine how popular a site truly will become.


List view Web Parts


* Announcements
* Calendar
* Links
* Shared Documents
* Tasks
* Team Discussions


Apart from these, there are also some miscellaneous Web Parts, namely Content Editor Web Part, Form Web Part, Image Web Part, Page Viewer Web Part, Relevant Documents Web Part, Site Users Web Part, User Tasks Web Part and XML Web Part.


Difference between Document Library and Form Library?
- Document libraries in SharePoint consist of your main/core documents. For example a word document, excel, PowerPoint, Visio, pdf, csv, notepad etc.


- A Form Library provides a simple way for you to share and track XML-based forms that are used to gather information. For example, you can create a form library for your team’s expense report forms. In a form library, you can use the versioning and approval features to manage your forms, just as you manage files in other types of libraries. You can keep track of versions, so that you can view a version history and restore previous versions if necessary. You can also specify that forms remain in a pending state until they are approved or rejected by someone who has permission to do so.


What is a Web Part Zone?
- Web Part Zones are containers of Web Parts that are used to group and organize Web Parts on a Web Part Page. Web Part zones also have a set of properties that serve a dual-purpose. You can use one subset of properties to organize the layout and format of Web Parts on the Web Part Page. You can use another subset of properties to provide an additional level of modification protection (or “lock down”) of the Web Parts within the zone.


The Web Part zone properties each have default settings or behaviors. As you add Web Parts to the Web Part page, you automatically set some of these property values. Although these property values are not designed to be edited in the browser, you can modify them by using an HTML editor compatible with Microsoft WSS , such as Microsoft Office FrontPage 2003.


How is Security managed in SharePoint?
- Security can be handled at the Machine, Domain, or SharePoint level.


Authentication:
SharePoint can run under various IIS modes to authenticate its users. The modes include: Anonymous, Basic, Integrated Windows or Certificates Authentication (over SSL).


Authorization:
SharePoint security facilitates the regulation of access privileges of users and groups as well.


Impersonation:
.NET Impersonation which is utilized by SharePoint allows an application to run under the context of the client accessing an application.


Deployment and Code Access Security:
.NET Code Access Security (CAS) provides a security model. It can restrict the operations that can be performed as well as the resources that can be accessed by managed code.


How are Web Parts Developed?
- Web parts are developed in Visual Studio.Net. It offers many web parts and page templates, and can also be downloaded from the Microsoft site.


What is a SharePoint Farm?
- In the context of SharePoint, the term ‘Farm’ is used to describe a collection of one or more SharePoint Servers and one or more SQL Servers that come together to provide a set of basic SharePoint Services bound together by a single Configuration Database in SQL.


Differences between WSS and MOSS 2007?
- Windows SharePoint Service (WSS) is included with Windows Server, and Microsoft Office SharePoint Server 2007 (MOSS) is a separately purchased product that offers richer features for business.


- If your company has Windows Server, you can use the extensive features of WSS. If it isn’t set up for your company, you’ll have to ask your IT manager to set it up, turn it on, or whatever verbiage will get WSS in your hands.


WSS 3.0 offers all the standard site templates to build team sites, document workspaces, blank sites, blogs, wikis, and meeting workspaces.


- You can also use WSS 3.0 to create people and group lists. You can integrate WSS 3.0 sites with Access 2007, Excel 2007, Outlook 2007, Word 2007 and PowerPoint 2007. You can create RSS feeds and set up alerts to notify you when content changes on a site. Version control, task notification and alerts all come with WSS 3.0


- MOSS 2007 offers all of the features included in WSS 3.0. In addition, MOSS 2007 offers business intelligence features that allow you to track key performance indicators and build BI dashboards into your team site. The dashboards can assemble and display business info using Excel spreadsheets, SQL, or integrate with line of business applications. Excel Services in MOSS go beyond simply displaying Excel spreadsheets, you can actually stream parts of a spreadsheet, showing or hiding various parts. Workflow can also be integrated into MOSS 2007 and WSS 3.0. And don’t get me started on slide libraries – a much needed and unique way to share and reuse slides that is available in MOSS 2007.


- MOSS 2007 also offers My Sites, which are individual mini-sites that can be set up to show who in your company you’re connected to, what your tasks and skills are, your contact information, and more. When I worked at a consulting firm, we used our My Sites to let co-workers know what we did so that they knew whom to call on for a new project. We used the My Sites to ‘advertise’ ourselves.


- One of our team members was given the task of putting together a team site for my group that summarized our My Sites and provided other links and resources. He had about one month to build the site, but a big project prevented him from doing it. He asked me to take his place at a presentation of the site to a larger group in the company, giving me two hours notice. Now, while I don’t recommend doing a site in two hours, I was able to do this in less than two hours – more of a tribute to how easy SharePoint is to use than to my skills.


- The features that are included in WSS 3.0 are easy for anyone to use and set up. You can create your own team site, set up a blog in minutes, create wikis, use Word to post your blog entries, create slide libraries so that all your employees can find and reuse different slides from different presentations and lots more. But first you have to plan your site and decide how to organize it to help your team be more productive.


Definition of Site in SharePoint?
- A site definition is a group of files that reside on the Web server and that define a unique type of SharePoint site. Each SharePoint template that appears on the Web Site tab of the new dialog box is based on a site definition. For example, one site definition defines the Team Site, Blank Site, and Document Workspace templates, and another site definition defines the Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and Multipage Meeting Workspace templates.


What is a Template in SharePoint?
- A template is a pre-defined set of functions or settings that can be used over time. There are many templates within SharePoint. Site Templates, Document Templates, Document Library and List Templates.


Custom templates are a way of packaging up a set of changes to an existing site definition and making those available for new sites and lists. Every custom template is based on a site definition. Custom templates are stored in the database and made available through the central or site collection template galleries.


How do we install Web Parts?
- Web Parts are the building blocks of Web Part Pages in SharePoint sites. They can be added to Web Part Pages in SharePoint sites to offer users increased functionality. The Internet Platform and Operations group chose to install Microsoft Office Web Parts and Components, but you could install any Web Parts compatible with Windows SharePoint Services.


Web Parts can be installed only after Windows SharePoint Services is installed and configured on the server.


To Install Office Web Parts and Components:


1. On the first front-end Web server, open the folder that contains the Office Web Parts and Components files.
2. Double-click Setup.exe.
3. Repeat steps 1 and 2 for each front-end Web server.


Difference between Web and Site?
- SharePoint Web Application could be defined as an IIS Web Site specifically configured to run WSS sites. A Web application is the logical & physical partition/container within IIS to create portals.
IIS Web Site could be defined as an entry point in the IIS Web Server infrastructure. The Site-Collection and Sites are the logical & physical in the context of SharePoint’s content database. Ultimately sites and site-collection live in content database.
A single web application could have multiple site collection within it and each site collection has a top level site and could have multiple sub sites in it. A WSS site collection acts as a container of WSS Sites.


Differences between WebPart Page Gallery, Site Gallery, Virtual Server Gallery, Online Gallery?
- Users can include Web Parts from any of the following sources by default:
• Online Gallery: A set of Web Parts that is available over a Web service that permits many servers to share access to a common, centrally maintained gallery of Web Parts. The URL for this Web service is specified in the Online Library element of the web.config file for a site. This gallery provides a way for the IT administrator to deploy Web Parts.
• Site Web Part Gallery: Contains Web Parts that is available to a particular site. By default, when you run Stsadm.exe to install a Web Part, Stsadm.exe adds the Web Part to the Virtual Server Gallery. This gallery provides a way for the SharePoint Administrator to deploy Web Parts.
• Virtual Server Gallery: Lists Web Parts that is available to all sites on the server. This gallery provides a way for a server administrator to deploy Web Parts
• Web Part Page Gallery: Contains Web Parts that are already added to the current page. This gallery, unlike the other galleries, is generated dynamically. It contains Web Parts that are added to the page but are closed. The Web Part is still associated with the page by an entry in the SharePoint database, which also stores any shared or personalized property settings for the Web Part. To bring back a closed Web Part, select it from the Web Part Page Gallery.


What is GAC?
- The Global Assembly Cache (GAC) enables you to share assemblies across numerous applications. The Global Assembly Cache is automatically installed with the common language runtime. Components are typically stored in C:\WINNT\Assembly. It is one of the two locations where we can deploy a Web part assembly within a SharePoint Site, the other being a Bin Directory.


What is DWP?
- Dashboard Web Part (.dwp) is a Web Part description file. The .dwp file can be stored on and referenced from any computer, and contains XML metadata that describes an instance of the Web Part.
To create and export a simple Web Part, you can open any Windows SharePoint Services or SharePoint Portal Server page that you have permission to modify, configure any Web Part on that page, and then export the .dwp file. Because the .dwp file is a description of a Web Part instance, you can edit the file in any text editor on another computer and then import the .dwp file again to show a modified Web Part.


What is CAML?
- Collaborative Application Markup Language (CAML) is the XML-based language that is used to build and customize Web sites based on SharePoint.


CAML can be used to do the following:


* Provide schema definition to the Web site provisioning system about how the site looks and acts.
* Define views and forms for data and page rendering or execution.
* Act as a rendering language that performs functions in the DLL like pulling a value from a particular field.
* Provide batch functionality for posting multiple commands to the server using protocol.


Define Themes.
- Themes represent a collection of graphics and cascading style sheets that can modify how a Website looks, to spice up the look and feel of a Website. It allows users to easily customize the look of their personal sites from the Site Settings page for each site. Themes are applied automatically to the entire personal site, except for the public view. Applying the theme to the public view requires additional steps by the portal site administrator.


Define Presence.
- A Presence indicator is appended to every person in your contact list in the Launch bar and in the member list in each workspace. A person’s presence is determined by a collection of attributes that describe the person’s status, activity, location, willingness to communicate, and contact information. Presence information helps you to contact others and helps others to reach you.


Presence indicators in SharePoint Workspace correspond to those you see for contacts in Microsoft Office Communicator. If a contact is not running Communicator, you see a subset of these presence indicators.


Can Web Parts be connected? If so, how?
- Yes. You can connect Web Parts together by passing data, such as a row or filter, from one Web Part to change the display of the other Web Part’s data. By connecting Web Parts, you can synchronize their behavior and manage data in dynamic and interesting ways. Traditionally, the chore of connecting sets of data from different data sources has not been easy and has often required programming skills. But with Web Parts, making data connections is as simple as using menu commands. By connecting Web Parts, you can, for example, present data from two Web Parts in alternate views, perform related calculations between two Web Parts, and filter a Web Part using values from another Web Part – all on one Web Part Page.


What is Personal View and Shared View?
- When a Web Part page is in Shared View, all users see the same page and any changes you make in shared view are intended for all users to see. When a Web Part page is in Personal View, you see any personal changes you have made and any changes you make in this view are intended just for you to see.


When a Web Part page is in Personal page view, you:


* Can usually view and modify the Layout and Appearance common Web Part properties, but not the advanced ones. In some cases, the developer of a Web Part may decide not to display some or all common properties or you may not have permission to see them.
* Can view and modify custom Web Part properties. In some cases, the developer of a Web Part may decide not to display some or all custom properties or you may not have permission to see them.
* Can view and modify, but not delete, shared Web Parts with appropriate permission. Once you modify a shared Web Part, however, it becomes a personalized Web Part.
* Can view and modify, but not delete, personalized Web Parts. The modified property values of these Web Parts apply only to you.
* Can view, modify, and delete private Web Parts. These Web Parts only apply to you, no other users can see them, even in shared view.


When a Web Part page is in shared view, you:


* Can view and modify common as well as custom Web Part properties. Changes you make apply to all users.
* Can view, modify, and delete shared Web Parts. Changes you make apply to all users.
* Cannot view, modify or delete private Web Parts. You can only view, modify, and delete private Web Parts in personal view.
* Cannot view or modify personalized Web Parts, either your own, or for another user.


What is a STP File and FWP File?


- Site templates are stored into the site collections site template gallery as STP (.stp) files, whereas SharePoint sites which have been backed up are stored as FWP (.fwp) files.


How does SharePoint support Microsoft Outlook integration?
- The Document Library has syncing capability that allows us to easily access, preview, search and edit our SharePoint Document Libraries in Outlook. In order to do that, we just need to navigate to a SharePoint Document Library in our web browser, click on the ‘actions’ dropdown menu and select ‘connect to Outlook’.


We can even access our SharePoint documents in Outlook. We can preview a Document, or search it using Outlook’s Instant Search, and even better, we also can access and edit it Offline.


Explain Document Versioning in SharePoint Document Libraries.
- Document Versioning allows us to keep multiple versions of a document. If a change needs to be reversed, we can restore the previous version and continue working. When versioning is turned on, a Version History command is added to the drop-down list that users see when they click the arrow next to a document name (and the toolbar) in the Edit Properties page for the document.


When versioning is enabled, versions are automatically created whenever a user updates a document in a document library. Versions are created in the following situations:


* When a user checks out a file, makes changes, and checks the file back in.
* When a user opens a file, makes changes, and then saves the file for the first time.


If the user saves the file again, without closing the file, a new version is not created. If the user closes the application he or she is using to edit the file, and then opens it and saves the file again, another version is created.


* When a user restores an old version of a file (and does not check it out).
* When a user uploads a file that already exists, in which case the current file becomes an old version.


Also note that,


* When a file is deleted from a library, all previous versions are deleted as well.
* Versions can be created for all file types except HTML files that contain images or embedded objects. If you want to create versions as HTML, you must use the MHTML format (often saved as .mht) when saving to this Web site. This also applies to those files on the Web site that you check out and modify.


Where are Web Part Resources contained?
- Web Part Resources are contained in the SharePoint File System, SQL, and the Global Assembly Cache (GAC) folder. They are also referenced in the web.config folder.


Different Installation methods for deploying Web Parts and its PROS/CONS.
- Microsoft SharePoint Foundation requires that a Web Part be deployed in the Web Part gallery before it can be added to a Web page.


There are multiple locations within a SharePoint site where you can deploy a Web Part assembly.


* Solution Gallery – The Solution Gallery is the recommend placed to deploy a Web Part by using a sandboxed solution. It provides monitoring and security for your Web Parts by default.
* Bin Directory — The bin directory is a folder stored in your Web application root directory. The location of this folder is determined when the Web site is created in Internet Information Services (IIS). In SharePoint Foundation, this can happen either through the Central Administration site, or by manually creating a new Web site in IIS manager. (If a bin directory does not exist you must add one manually. Do not store Web Parts in the local _app_bin directory, which is reserved for use by Microsoft.)
* Global Assembly Cache — A global location where signed assemblies can be deployed. The global assembly cache enables you to share assemblies across numerous applications. The global assembly cache is automatically installed with the .NET runtime. Components are typically stored in C:\WINNT\Assembly folder.


Deployment Locations Advantages Disadvantages




Solution Gallery


Code deployed to the Solution Gallery is run in partial trust, by default. Codes in the Solution Gallery also have resource usage monitoring to ensure the health of the farm. The Solution Gallery is specific to a site collection. All of the object model in SharePoint Foundation is not available in the Solution Gallery.




Bin Directory


Assemblies run with partial trust, by default. Code that runs from this directory has a low level of code access security (CAS) permissions. Because administrators must explicitly raise permissions that have been granted to a Web Part so it can function properly, they often prefer that assemblies run in the bin directory with a known set of required CAS permissions.


A bin directory is specific to a Web application. This makes it possible to isolate code to a particular Web application.
In order for the Web Part to run in multiple Web applications, you must deploy it to the global assembly cache.




Global Assembly Cache


Assemblies run with full trust by default. They are globally installed, so they will work in any Web application. The global assembly cache can contain multiple versions of the same assembly.




Generally there are no CAS restrictions on code installed to the global assembly cache.


Also, an assembly deployed to the GAC is cached, so if the assembly is rebuilt, it is not automatically updated on the SharePoint site. You must force SharePoint Foundation to reload the assembly by resetting Internet Information Services (IIS).






What are Ghosted and Unghosted Pages in SharePoint?
- Ghosted Page: Ghosted means that the Site Definition pages have Not been Customized (Ghosted means Un-Customized) and the pages in your Site Definitions run directly from the file system (cached of course). You can check this out by going to a page like the default.aspx page in the STS Site Definition and typing “Hello” in the body somewhere. Run IIISRESET to clear the cache, and you’ll see that “Hello” shows up immediately on all sites that were created using that Site Definition.


Unghosted Page: Unghosted means that the site has been Customized (Unghosted means Customized). When you customize a v2 site in FrontPage or a v3 site in SharePoint Designer, or you add custom fields to a Doc Library, or you customize a site in the UI and then save it as a Template – upload it into a Template Gallery – and then create sites using that template; then the changes that you made are stored in the database as a diff and that is referred to as Unghosted (Note that all Unghosted sites are based on a Site Definition).
A request for a Customized (Un-Ghosted) page returns a response which is a combination of data from both the file system and the database. In v2 this was a performance hit, and you wanted to avoid having a large number of sites that were Un-Ghosted. In v3 – caching etc. has been improved, and you are encouraged to use SharePoint Designer to do as much customization as you want.


How are Site Data stored in SharePoint?
- SharePoint sites are Data, not Application Codes, but Data.


A SharePoint site, at its core, is a set of lists. Document libraries, users, event calendars, surveys, tasks, discussions, Web Part galleries, template galleries — they’re all lists. Even the instancing of Web Parts on specific pages in a site (zones, properties, etc.) is effectively a list. For every list, we store data and Metadata, including views.


The set of sites/lists (Site Data) are maintained in SQL Server or Microsoft SQL Server Desktop Engine (MSDE). Access to SQL Server is constrained to stored procedures. Access to those stored procedures happens via ISAPI (for WebDAV, FrontPage RPCs, and static HTTP GETs) or via a managed API. We call that managed API ourselves, inside ASP.NET-authored SOAP Web services, as well as by our ASP.NET-based Dynamic HTML interface.


Architecturally, the DHTML interface we provide via ASP.NET is really just one way of getting to a SharePoint site. A nice way, an important way, and a way you can extend with Web Parts to pull in non-site data or new views of site data. But ultimately, it’s not the star of the show, but rather a much-loved supporting cast member.


How do we deliver the DHTML interface?
- For each site, and for each list, there are database-defined ways to render it (e.g., Edit Item, Add Item, View List), and for each one, we effectively store the location the ASP.NET page used to do that rendering in the database. Those pages are usually stored in localized resource directories on the Web server’s file system, but if you edited a page in FrontPage, we store the edited page directly in the database itself as a BLOB.


It’s only at this point that Web Parts enter the picture. Those ASP.NET pages involve extra code to provide the infrastructure for hosting Web Parts.


And to bring it all back to lists (i.e., data), the most important Web Part we provide in the box is the List View Web Part, whose job it is to grab a list’s CAML XML data and view rendering meta data and apply the latter to the former to generate HTML. It’s much, much, much faster than iterating through object model collections in loops and building up the HTML that way. Every time you create a list, we add an instance of the List View Web Part preset to point to that list into the site’s Web Part Gallery. It is, however, one piece of code we use over and over and over again to render every list in every site.


This architecture is what enables the scalability, availability, manageability, and extensibility of the WSS platform.


What is an Audience and describe its use.
- Audiences are groups of users determined by their memberships in Microsoft Exchange distribution lists (DL) or SharePoint groups, or by rules configured by a portal administrator.


Audiences allow organizations to target content to users based on their job or task, as defined by their membership in a SharePoint group or distribution list, by the organizational reporting structure, or by the public properties in their user profiles.


Where is Metadata for a Web stored?
- Metadata for a Web is found in the Content Databases stored in SQL.


What are the Trust Levels and what is the default Trust associated with SharePoint?
- SharePoint Foundation is a Partial Trust Application by default. SharePoint Foundation can use the ASP.NET built-in trust levels but defines two trust levels of its own:


* WSS_Minimal
* WSS_Medium


These trust levels extend the ASP.NET Minimal and Medium trust levels for use with SharePoint Foundation. Trust levels are defined in policy files that can be found on the file system of each Web server.


Important: By default, the built-in SharePoint Foundation policy files in SharePoint Foundation, named wss_minimaltrust.config and wss_mediumtrust.config, are found in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG directory.


By default, SharePoint Foundation applies the WSS_Minimal trust level for the virtual server. This trust level grants all of the permissions in the ASP.NET Minimal trust as well as Web Part connections. The WSS_Minimal policy restricts the Web Part from accessing many resources for advanced operations, including the object model and file operations.


The WSS_Medium trust level grants greater access to the environment. Also, WSS_Medium allows access to the SharePoint Foundation object model and file operations including read, write, append, and path discovery. This trust level also allows access to environment variables.


What functionality does owssup.dll provide for client side activities?
­ – The owssup.dll provides ‘Open with’ and ‘Export to’ functions for Access, Outlook, Excel, and other Microsoft Office and third-party applications. It is a WSS Export Database Object for client side activities.


What are the differences between a SharePoint Server Administrator, SharePoint Site Collection Administrator, and SharePoint Site Owner?
- SharePoint Server Administrator: They are responsible for the physical servers, software installation, backup, etc.


SharePoint Site Collection Administrator: The user responsible for the entire site collection. They have access to Site Collection wide features in several places including Site Settings, and typically is the person responsible for a department or a group’s entire site collection.


SharePoint Site Owner: A user with ‘full control’ rights to a single site, its lists, libraries and content, and any sub sites and workspaces created below it, i.e., responsible for a ‘branch’ of a site collection.


Here’s a list of what a Site Collection Administrator can see that the Site Owner (Full Control User) can’t:


Site Actions & Site Settings


Users & Permissions: Site Collection Administrators (Only an option when at a Top Level Site)


Galleries: Workflows


Site Administration: Content and Structure Logs


Site Collection Administration: The entire column is missing which means that a Site Owner can’t access the 2nd level Recycle Bin.


Interestingly enough, a Site Owner is not trusted with the above mentioned features but they can delete the site.


STSAdm and its uses?
- The command line tool stsadm.exe is the IT Pro tool for doing a few things that aren’t exposed through the web UI. It’s also great for scripting operations that are repetitive. It enables many administrative operations in Windows SharePoint Services that cannot be done with the Central Administration application. There are a number of commands and lots to do though.


Can WSS search Sub Sites?
- WSS 3.0 has a basic search feature that will allow users to search for content. This is a big change from previous WSS versions, which required WSS to be configured to run on SQL Server 2000, using its Full-Text Indexing engine. Another important change is that WSS 3.0 will search in sub sites, while the previous version of WSS only searched in the current site. The following list summarizes the search functionality in WSS, when combined with SQL Server:


* Finds information of any type, stored in the current site, or a sub site.
* Provides free-text searching in documents, files, and all list content.


Can we register alerts for users?
- Alerts are an e-mail and Short Message Service (SMS) notification service in SharePoint Foundation. Users can create alerts to notify them of changes to list items (item-level alerts), documents, lists (list-level alerts), or document libraries.


Alerts in SharePoint Foundation are quite flexible; when you create an alert you have options such as when to be notified and what kind of changes trigger the alert. You can also select whether the alert for a particular list, item, or library will be sent by e-mail or by SMS message. Users and administrators can manage alerts, and developers can customize alerts.


Are PDFs searchable?
- Out of the box only the metadata collected in the upload form is search able. Unless you download and install the Adobe iFilter.


Describe a Large Deployment.
- Many front-end web server with a SQL cluster with the possibility of multiple international locations.
How can you synchronize custom Active Directory attributes to SharePoint?
- Via the Profile Importer.


If it is anticipated that our organization would need to store 1 terrabyte of documents, what is the recommended configuration and storage requirement?
- Multiple front-end web servers with content databases across the server farm. The amount of web-servers can depend on how many users you have and what the typical size of a document is.


Explain how you would deploy SharePoint on an extranet.
- Usually servers that are accessible from external sources are housed in DMZ’s. Depending on the requirements and the workflow for publishing content you could go with Multiple Servers hosting the same information. One server would reside inside with the SQL Cluster while the external server resides in the DMZ simply calling data. Security would be handled by the same or different active directory domain clusters as well increasing security.

More Here



Courtesy:http://livinginamoss.wordpress.com/2010/12/15/sharepoint-must-knows/