steps to setup reporting service in sharepoint

Make Report by Reporting Service with SharePoint List

First at all we see what is report by Reporting Service on SharePoint Foundation look like

Can be export the report to Excel, PDF, Word, Tiff, XML, CSV, MHTML

 Now let follow 47 steps to make report by Reporting Service with data from SharePointList then show it on SharePoint as a datasource of Reporting Service Webpart

1. Open SQL Server Business Intelligence Development Studio

2. File ->  New -> Project...

3. Make new project from Report Server project

4. Reports - Add New Report

5. Report Wizard -> Next >

6. JobOrder SPList look like

7. Filling Connection string for SharePointList DataSource

8. Data Source Credentials

9. Select the Data Source -> Next >

10. Unable to connect to data source. Support Windows Integrated Security only

11.  Back to Credentials...

12. Use Windows Authentication (Intergrated Security)

13.Click Next after change Credential to Windows Authentication

14. Query Builder ...

15. Choose JobOrder list then click OK

16. Design the Query -> Next >

17. Choose Tabular then click Next >

18. Choose columns for detail of report then click Next

19. Choose the Table Style then click Next

20. Choose a name for the report then click Finish

21. Click on Preview

22. The first look like of report on Visual Studio

23. View Code of the report

24. The original of SharePointListDataSource

25.Replace DataSource reference by a SharePointList Dataprovider and a ConnectionString

26. Add Document to Share Documents

27. Click Browse...

28. Browse to folder location of the report, choose it then click Open

29. Click OK after choose the report

30. Click Edit icon

31. Click Insert

32. Click Web Part

33. Click SQL Server Reporting

34. Click on SQL Server Reporting Services Report Viewer

35. After choose SQL Reporting Services Report Viewer then click on Add

36. Click on Page

37. Click on Save & Close

38. Click on Report Viewer Web Part Menu

39.  Click Edit Web Part

40. Click on ... to choose the report on Share Document

41. Click Up icon

42.Click on Shared Documents

43. Choose JobOrderReport then click OK

44. Click on Appearance

45. Change width of report webpart then click Apply

46. Click OK at Tool Part

47.The JobOrder Report look like on SharePoint Foundation 2010

48. More information that how to integrate Reporting Service With SharePoint 2010
Intergration Reporting Service with SharePoint 2010 by 84 steps / Giải pháp miển phí tích hợp Reporting Service với SharePoint

49. Download code and list template
Report code: http://www.divshare.com/direct/15579552-347.zip
List template: http://www.divshare.com/direct/15579557-002.stp

God bless us!
Thomas Trung Vo
-------------------------------------------------------------------------------------------------------

You can either use filter or CAML where clause to set the query condition. Add parameter in reporting service and set it in reporting service webpart programmatically.  

Bypassing the Multi Authentication Provider Selection Page in SharePoint 2010

Bypassing the Multi Authentication Provider Selection Page in SharePoint 2010

Steve Peschka

30 Apr 2011 9:23 PM

• SIDE NOTE:  Yet another kudos to the fabulous folks that run this site.  This latest version now retains even LESS formatting from Word and Visual Studio than before!  I didn't think it was possible to make this site any worse than it was, and yet you've shattered, dare I say blown away, my expectations in this regard.  Congrats!  I hope to follow suit soon myself and ditch Word, Excel and PowerPoint for notepad - who needs formatting anyways?

I recently needed to bypass the provider selection page that you get when you enable multiple authentication providers on a single zone in SharePoint 2010.  The scenario I had was a fairly simple one, but the methodology can be extended quite a bit to support much more complicated scenarios.  In my case, I had Windows authentication and forms based authentication (FBA) enabled on a zone.  However I always wanted to redirect users to use FBA for this particular scenario.
Accomplishing this was relatively straightforward by following these steps:

1. MAKE A BACKUP COPY of default.aspx in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\IDENTITYMODEL\LOGIN folder.
2. Open Visual Studio and create  new Windows Class Library project.
3. Add references to System.Web, Microsoft.SharePoint.dll and Microsoft.SharePoint.IdentityModel.dll.  Unfortunately the identity model assembly is only found in the GAC so I had to get a copy of it and put it in the root of my drive to add my reference.  For a suggestion of how to find it and copy it up you can review my posting that describes getting it here:  http://blogs.technet.com/b/speschka/archive/2010/07/21/writing-a-custom-forms-login-page-for-sharepoint-2010-part-1.aspx.  
4. Strong-name the assembly because it will be going in the GAC.
5. Add a new ASPX page to your project.  Honestly I find the easiest way to do this is to just copy a page from an existing ASP.NET web application project; that way can copy over the .aspx, the .aspx.cs, and .aspx. designer. cs files all at once.  Remember in this case we want a file called “default.aspx” and it will be easier if there’s no code written in it yet and minimal markup in the page.
6. In the code-behind (.aspx.cs file) change the namespace to match the namespace of your current project.
7. Change the class so it inherits from Microsoft.SharePoint.IdentityModel.Pages.MultiLogonPage.
8. Override the OnLoad event.  What happens when users hit a site with multiple authentication providers enabled is that they are sent first to the /_login/default.aspx page (the one I described in #1 above).  On that page a user will select which authentication provider to use and then he or she is redirected to the correct page to authenticate.  In this scenario I’ve said that I always want users to authenticate with FBA, so I’ll always want to send them to /_forms/default.aspx.  If you step through a normal login, you’ll see that you are redirected to /_login/default.aspx, you make your selection and then you post back to /_login/default.aspx, and then you are redirected to the correct login page.  So in this case I merely looked to see if my login page was being posted back.  If it isn’t, then I know that no selection has been made yet for the authentication provider.  So I just enumerate all of the query string values and then append them to /_forms/default.aspx and redirect the user there.  Here’s what the entire code snippet looks like:

protected override void OnLoad(EventArgs e)
{
   base.OnLoad(e);

   try
   {
       //if this isn't a postback, then the user hasn't selected which
       //auth provider they want to use
       //in this case we want to always refer the person to forms login
       if (!this.IsPostBack)
       {
          //grab all the query string parameters
          System.Text.StringBuilder qp = new System.Text.StringBuilder(2048);

          foreach (string key in this.Request.QueryString.Keys)
          {
             qp.Append(key + "=" + this.Request.QueryString[key] + "&");
          }

          //redirect to the forms login page
          this.Response.Redirect("/_forms/default.aspx?" + qp.ToString());
       }
   }
   catch (Exception ex)
   {
       Debug.WriteLine(ex.Message);
   }
}

1. Now compile the application so you can get the strong name for it and add it to the markup for default.aspx.
2. Paste the following into default.aspx; you will just need to change the class from which the page inherits (highlighted below); note that all I did was just copy it from /_login/default.aspx and replace the Inherits value with my custom class info:

<%@ Page Language="C#" CodeBehind="Default.aspx.cs" Inherits="MultiAuthLoginPage._Default,MultiAuthLoginPage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=907bf41ebba93579" MasterPageFile="~/_layouts/simple.master" %>
<%@ Assembly Name="Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SharepointIdentity" Namespace="Microsoft.SharePoint.IdentityModel" Assembly="Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Assembly Name="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>
<%@ Import Namespace="Microsoft.SharePoint.WebControls" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<asp:Content ID="Content1" ContentPlaceHolderId="PlaceHolderPageTitle" runat="server">
                <SharePoint:EncodedLiteral runat="server"  EncodeMethod="HtmlEncode" Id="ClaimsLogonPageTitle" />
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderId="PlaceHolderPageTitleInTitleArea" runat="server">
                <SharePoint:EncodedLiteral runat="server"  EncodeMethod="HtmlEncode" Id="ClaimsLogonPageTitleInTitleArea" />
</asp:Content>
<asp:Content ID="Content3" ContentPlaceHolderId="PlaceHolderSiteName" runat="server"/>
<asp:Content ID="Content4" ContentPlaceHolderId="PlaceHolderMain" runat="server">
<SharePoint:EncodedLiteral runat="server"  EncodeMethod="HtmlEncode" Id="ClaimsLogonPageMessage" />
<br />
<br />
<SharepointIdentity:LogonSelector ID="ClaimsLogonSelector" runat="server" />
</asp:Content>

1. Register your assembly in the GAC.
2. Copy your new custom default.aspx page into the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\IDENTITYMODEL\LOGIN folder.  AGAIN, MAKE A BACKUP OF THE ORIGINAL BEFORE YOU DO THIS!
3. Do steps 1, 11, and 12 on every web front end in your farm.

That’s all there is to it.  I tested this with a standard user login, as well as opening documents directly from the Microsoft Office 2010 clients.  One other thing worth noting here:  this changes the behavior for ALL web applications in your farm!  Again, that’s why it’s a simple example.  However you could easily look at the host name of the request (which maps to your web application) and make different authentication decisions based on which web application is being accessed or even which site collection.  You can obviously also make other decisions based on information you have about the current user.  The HttpRequest.Context.Current, Page.Request and Page.Response classes can provide you with a lot of information to make these kinds of decisions.

Bypassing the Multi Authentication Provider Selection Page in SharePoint 2010.docx

The root of the certificate chain is not a trusted root authority

Saturday, December 04, 2010

Sharepoint 2010 -“The root of the certificate chain is not a trusted root authority”while setting up Text Messaging

Getting the following error on Sharepoint when you enter smster.in’s or ManageFieldStaff.com’s url and clicking Test?

The following is what comes on event viewer…

Solution:
Add your root certificate to the certificate store…
That’s the solution given on MSDN and on various forums on google.But unfortunately,its not working for me on a paticular server.
Contacted godaddy and Microsoft support…waiting for their reply.I’ll post an update on this soon.
Update:  None of those guys actually responded.
So,here’s the solution…Just figured it out..
First,open the this url on your browser..
https://login.managefieldstaff.com/smsservice/service1.asmx
You would see this..

Notice the lock sign () on the addressbar on your IE?
Click on that!

Click on
You should see the certificate details..
 
Click on the tab
You would see something like this…

Double click on each certificate on that list and repeat the steps I’m going to show for each of those certificates.

Click on the  tab
Click on
Follow the wizard…
Select
Then,select where you want to save by clicking
and hit
Repeat the above steps for each of the certificates in the certificate path and save those certificates somewhere.

Importing certificates into Sharepoint

Now,we need to import these certificates into Sharepoint…
Open
Go to
Under ,click on
Now,click on the on the RIBBON..
You would see the Trust Relationship Window…

Provide a name and select each of those saved certificates..
Hit ok and we’re done with solving this error.
The end result should be something like this..

May your work be Blessed! Cheers!

John 8:12“[The Validity of Jesus’ Testimony] When Jesus spoke again to the people, he said, “I am the light of the world. Whoever follows me will never walk in darkness, but will have the light of life.”” Brought to you by BibleGateway.com. Copyright (C) . All Rights Reserved.

Sliding sessions

Sliding sessions in SharePoint 2010

Published by fboerr on April 15th, 2011 3:29 pm under identity

No Comments

The scenario

In a SharePoint federated scenario, the user session has the same validity time as the SAML token.
If the user is inactive during a certain period of time, the session must expire.

Implementation in SharePoint

To achieve this behavior, SharePoint provides a configuration called LogonTokenCacheExpirationWindow.
The way it works is detailed in the chart below.

Global.asax

Re-issuing the token in every request to the server may have performance penalties so the code below is optimized to issue the session token after a certain period of time. Note that, by implementing this approach, the inactivity time after the user is signed out is half of the LogonTokenCacheExpirationWindow.
E.g.: If the LogonTokenCacheExpirationWindow is 40 minutes:

• For the first 20 minutes the token is not reissued.
• If the user interacts with the server during the last 20 minutes, a new session token is issued.
• If the user is inactive during the last 20 minutes, he will be signed out.

The Global.asax of the SharePoint website has to be replaced/updated with the following code:

<%@ Application Language=”C#” Inherits=”Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication”%> <%@ Import Namespace=”System” %> <%@ Import Namespace=”Microsoft.IdentityModel.Web” %> <%@ Import Namespace=”Microsoft.SharePoint.IdentityModel” %> <script Language=”C#” RunAt=”server”> public override void Init() { base.Init(); SessionAuthenticationModule sam = FederatedAuthentication.SessionAuthenticationModule; sam.SessionSecurityTokenReceived += SessionAuthenticationModule_SessionSecurityTokenReceived; } private void SessionAuthenticationModule_SessionSecurityTokenReceived(object sender, SessionSecurityTokenReceivedEventArgs e) { double sessionLifetimeInMinutes = (e.SessionToken.ValidTo – e.SessionToken.ValidFrom).TotalMinutes; TimeSpan logonTokenCacheExpirationWindow = TimeSpan.FromSeconds(1); Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(delegate() { logonTokenCacheExpirationWindow = Microsoft.SharePoint.Administration.Claims.SPSecurityTokenServiceManager.Local.LogonTokenCacheExpirationWindow; }); DateTime now = DateTime.UtcNow; DateTime validTo = e.SessionToken.ValidTo – logonTokenCacheExpirationWindow; DateTime validFrom = e.SessionToken.ValidFrom; if ((now < validTo) && (now > validFrom.AddMinutes((validTo – validFrom).TotalMinutes / 2))) { SPSessionAuthenticationModule spsam = sender as SPSessionAuthenticationModule; e.SessionToken = spsam.CreateSessionSecurityToken(e.SessionToken.ClaimsPrincipal, e.SessionToken.Context, now, now.AddMinutes(sessionLifetimeInMinutes), e.SessionToken.IsPersistent); e.ReissueCookie = true; } } </script>

Updating the LogonTokenCacheExpirationWindow in SharePoint using PowerShell

To update the LogonTokenCacheExpirationWindow, the following PowerShell has be ran.
This example shows how to set the window time to 40 minutes:
$sts = Get-SPSecurityTokenServiceConfig $sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 40)
$sts.Update()
iisreset

token expiration

Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users

Steve Peschka

As I was working on understanding the process for expiring login cookies recently, I found what seemed like a pretty big problem.  For SAML claims users, once they got their login cookie from ADFS, they would never seem to time out.  Meaning they could close the browser, and several minutes or even hours later open the browser again and just navigate directly to the site without having to reauthenticate to ADFS.  In addition the Office 2010 client applications worked the same way.  I finally figured out the multiple pieces that were causing that and so I’m documenting them here.

 First a really, really brief background.  When you navigate to a SharePoint site secured with SAML claims the first time, it will redirect you to get authenticated and get your claims.  Your SAML identity provider (a.k.a. IP-STS) does all that and redirects you back to SharePoint.  When you come back into SharePoint we create a FedAuth cookie and that’s how we know you’ve been authenticated.  To make for smoother end user experience we write the FedAuth cookie value to the local cookies folder.   On subsequent requests for that site, if we find a valid FedAuth cookie for the site we’ll just read the cookie and take you right to the SharePoint content without authenticating again.  This can be a bit of a jolt to those of you who are used to ADFS 1.x and SharePoint 2007, because with them all Web SSO cookies were session based so we didn’t save them to disk.  When you closed your browser for instance, the cookie went away so you had to reauthenticate each time you closed and opened your browser.  That is not the case with SharePoint 2010. 

UPDATE #1:  We found a change that can be made to the SharePoint STS to make it work with session cookies again, as it did in SharePoint 2007.  This PowerShell will make the change:

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset

After doing this you will see that there is no longer a FedAuth cookie written to disk.  To change things back to the default behavior just reverse your steps:

$sts.UseSessionCookies = $false
$sts.Update()
iisreset

 So, how do we configure this behavior to get a SAML token with a nice manageable lifetime?  Here are the things you need to look at:

1. The TokenLifetime property can be set per relying party in ADFS.  Unfortunately it seems to only be settable at the time you create the relying party.  This is a bit of a problem because that means the default behavior is that once you get a cookie you’re good to go for a really, really long time (I haven’t actually tested to see how long it’s good for).

UPDATE #2:  Rich Harrison was good enough to provide this nugget for updating the TokenLifetime in ADFS for the relying party:

Set-ADFSRelyingPartyTrust -TargetName "SPS 2010 ADFS" -TokenLifetime 5

where "SPS 2010 ADFS" is the name of the Relying Party Trust entity in AD FS 2.0.

So, if you want to set the TokenLifetime of the relying party in ADFS at creation time, you need to do so using PowerShell.  Here’s the little one line script I used to create my relying party:

 Add-ADFSRelyingPartyTrust -Name "FC1" -Identifier "https://fc1/_trust/" -WsFedEndpoint "https://fc1/_trust/" -TokenLifetime 2 -SignatureAlgorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1

After creating the relying party this way you need to manually:

1. Add the realm to the list of identifiers (i.e. urn:sharepoint:foo)
2. Add an Issuance Authorization Rule to permit access to all users
3. Add an Issue Transform Rule to send over email address and roles

3. If you just try and login now you will likely find that after you authenticate to ADFS, you’ll get caught up in this endless loop where you go back and forth between SharePoint and ADFS.  If you look at the traffic in Fiddler it turns out that you are authenticating successfully to ADFS, you’re coming back to SharePoint and it is successfully issuing the FedAuth cookie, it redirects you to /_layouts/authenticate.aspx on the SharePoint site which clears out the FedAuth cookie and redirects you back to the ADFS site.  You basically ping pong back and forth until ADFS stops it and gives you an error message along the lines of “The same client browser session has made ‘6’ requests in the last ‘12’ seconds.”.  It turns out that this actually makes sense.  That’s because the default LogonTokenCacheExpirationWindow for the SharePoint STS is 10 minutes.  In this case when I created my relying party I set the token lifetime in ADFS to be 2 minutes, so as soon as it authenticated it knew the cookie was good for less time than the LogonTokenCacheExpirationWindow value, so it went back to ADFS to authenticate again.  And so it went, back and forth.  So to fix that part of you just need to change the LogonTokenCacheExpirationWindow to be less than the SAML TokenLifetime, and then you can log into the site.  Here’s an example of setting the LogonTokenCacheExpirationWindow in SharePoint:

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

$sts.Update()

Iisreset

Now, once you configure these settings correctly the login expiration for SAML users works correctly.  I can open and close my browser window and continue to get back into the site without being redirected back to SharePoint for 2 minutes.  After that time though it correctly makes me reauthenticate to ADFS.

Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users.doc