Hello,

Web performance/load testing can sound like an intimidating thing, but it is not. And web performance/load testing SharePoint has been made a lot easier with Visual Studio 2012 Update 1. So here is a quick introduction into the subject.

Prerequisites: 

1. Visual Studio 2012 Ultimate Edition (preferably with Update 1 as it provides the new features for testing SharePoint).
2. A SharePoint OOB installation
3. A SQL Server instance (any edition) to create the LoadTestResultsRepository database required by VS 2012's load testing features. To create the database, browse to C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE from a command prompt window and run SQLCMD /S <yoursqlinstance> -i loadtestresultsrepository.sql

Steps:

1. Launch Visual Studio 2012 Ultimate > New Project > Test > Web Performance and Load Test Project

When the web performance test is created successfully, an IE window will load with the Web Test Recorder plugin loaded and recording is started. Browse the SharePoint site as the scenario dictates and the Web Test Recorder will record each and every web request (URL) you visit (explicitly or implicitly).

* if you receive any error messages when loading the Web Test Recorder Plugin, Enable 3rd party extensions in IE advanced options

3. When done, click Stop in the Web Test Recorder plugin. Visual Studio will save the Web performance test and replay it for one time.

4. If a ProcessQuery request fails, it is because it is expecting a header (X-RequestDigest). So how do we pass this header to the request? Right click the first request in the web performance tree, Add an extraction rule to extract the form input __REQUESTDIGEST and save it in a context parameter (name it for example digest). Right click the ProcessQuery request and click add header. The header name should be X-RequestDigest and the value should be bound to the parameter context digest we created in the extraction rule.

5. Try to replay the test and it should work out successfully.

For more information on Web performance/load testing SharePoint, see the following.

• Web Performance and Load Testing SharePoint 2010 and 2013 Applications http://msdn.microsoft.com/en-us/library/vstudio/jj710162.aspx
• SharePoint load testing made easier with Visual Studio 2010 Update http://blogs.msdn.com/b/visualstudioalm/archive/2013/02/01/sharepoint-load-testing-made-easier-with-visual-studio-2012-update.aspx
• How to: Create a Load Test Results Repository Using SQL http://msdn.microsoft.com/en-us/library/vstudio/ms182600.aspx
• Getting Stared with Load and Web Performance Test Walkthroughs http://msdn.microsoft.com/en-us/library/vstudio/ee923685.aspx

Good Luck!

Yousef

As I was recently working on SQL Server Reporting Services (SSRS) I complied a list of references that can be used as a quick guidance for SSRS Logging, Monitoring & Troubleshooting. This list includes links and quick description on each link to act as an Index. Hope you will find it useful:

· Monitoring Report Server Performance: Describes the performance objects you can use to track the processing load on your server.

· Setting Report Processing Properties: Describes ways of configuring a report to run on demand, from cache, or on a schedule as a report snapshot.

· Caching Reports (SSRS): Describes report caching behavior on a report server.

· Caching Shared Datasets (SSRS): Describes shared dataset caching behavior on a report server.

· Processing Large Reports: Provides recommendations on how to configure and distribute a large report.

· Setting Time-out Values for Report and Shared Dataset Processing (SSRS): Explains how to set time outs on query and report processing.

· Troubleshooting Reports: Report Performance: Provides recommendations on report performance.

· Reporting Services Log Files: Provides information about two basic categories of logging, execution logging and trace logging.

· Errors and Events Reference (Reporting Services): Provides information about errors and events for SQL Server Reporting Services

· Troubleshooting Techniques for Report Problems: Useful information to troubleshoot problems you have with designing a report, previewing a report, publishing a report to a report server in native mode or SharePoint integrated mode, viewing a report on the report server, or exporting a report to a different file format

· Performance (Reporting Services): Provides information about reporting server performance and the affecting factors including hardware, number of concurrent users accessing reports, the amount of data in a report, and output format

· Troubleshooting Concepts (Reporting Services)

At this stage, we are done with configuring the SharePoint Part

Demo:

• Go to your SharePoint Site Collection you created in part 3.
• From the drop down list, select Facebook Authentication

• You will be redacted to Facebook page to enter your credential - The good thing that you don't share your credential with third party application :)
• Click OK to make your Facebook Application access your public profile.

• After clicking OK, watch the URL of your Internet Explorer; It will take you to Access Control Namespace URL and then redirect you again to you SharePoint Site Collection URL.

• Now you are logged in to SharePoint using the Facebook credential with a full read access.

Conclusion:

ACS provides us the capability to authorize our application through different public identity providers like Hotmail, Outlook, Facebook, Gmail, and Yahoo which will save our time and effort to develop authentication application to connect to their APIs.

Go back to Part 3

Symptoms:

The symptoms as follow:

- First ADFS server is implemented.

- New Federation service is configured properly.

- ADFS is installed on the second ADFS server.

- When adding the server to the federation farm we receive the following error:

“No certificate matching the Federation Service name were found in the Local Computer certificate store. Install the certificate that represents your Federation Service name in the Local Computer certificate store, and then try again”

The following snapshot represents the error:

Explanations:

Searching ADFS shows some vague words that gave the impression that ADFS requires that the name used for ADFS must be the subject name of the certificate, check the following article as example:

- Review ADFS Requirements: http://technet.microsoft.com/en-us/library/dn151311.aspx

“The Subject name of this SSL certificate is used to determine the Federation Service name for each instance of AD FS that you deploy. For this reason, you may want to consider choosing a Subject name on any new certification authority (CA)-issued certificates that best represents the name of your company or organization to the cloud service and this name must be Internet-routable. For example, in the diagram provided earlier in this article (see “Phase 2”), the subject name of the certificate would be fs.fabrikam.com”

Also when we have configured the first ADFS server and creating the new Federation Farm, you will notice that the wizard shows the certificate subject name as the default until from the drop down you select another name as the following snapshot:

But when adding the second server to the farm it’s not even gave you that option.

So the first thing to think of is that only with the wizard and can be fixed with the command line or not?

Solution:

Doing a quick search I found this article which is talking about how to create new federation farm using the command fsconfig.exe:

http://technet.microsoft.com/en-us/library/adfs2-help-how-to-configure-a-new-federation-server(v=WS.10).aspx

The general syntax of the command:

fsconfig.exe {StandAlone|CreateFarm|CreateSQLFarm|JoinFarm|JoinSQLFarm}

And as per the article the fsconfig command in this folder:

C:\program files\Active Directory Federation Services 2.0

So all we need to do is to follow the same syntax to join an existing farm and we can use the help to get the exact parameters:

Fsconfig joinfarm /help

The command line should be:

fsconfig.exe joinfarm /primarycomputername <<this is the first ADFS server>> /serviceaccount <<service account used with the first server>> /serviceaccountpassword <<password>> /certthumbprint <<the certificate thumbprint>>

The following snapshot shows the result of executing the command:

As the snapshot the configuration is completed successfully and using the command line solved the problem.

At this stage, we are done configuring the Azure Part

Continue Configuration Steps:

• Go to your SharePoint Farm
• Create a new web application
• Make sure the claim authentication will be as the following:
• Enable Windows Authentication = Checked
• Integrated Windows authentication = Check
• Select NTLM
• PS: The Facebook authentication will be enabled later

• After creating the web application, go and create a site collection

• Run the following script:
• Red parameters need to be changed depend pon your configuration

$realm = "http://mysharepointlogin.com"
$signinurl = "https://mysharepointlogin.accesscontrol.windows.net:443/v2/wsfederation?wa=wsignin1.0&wtrealm=http%3a%2f%2fmysharepointlogin.com%2f"
$certlocation = "C:\Users\Administrator\Desktop\MySharePointLogin.cer"
$rootcertificate = Get-PfxCertificate $certlocation
New-SPTrustedRootAuthority "MSharePointLogin" -Certificate $rootcertificate
$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certlocation)
$ClaimTypingMapping1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming
$ClaimTypingMapping2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Display Name" –LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
$ClaimTypingMapping3 = New-SPClaimTypeMapping -IncomingClaimType "http://www.facebook.com/claims/AccessToken" -IncomingClaimTypeDisplayName "Access Token" -SameAsIncoming
$ClaimTypingMapping4 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "Name Identifier" –LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
$ClaimTypingMapping5 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/expiration" -IncomingClaimTypeDisplayName "Expiration" -SameAsIncoming
New-SPTrustedIdentityTokenIssuer -Name "Facebook Authentication" -Description "Facebook Identity Provider" -Realm $realm -ImportTrustCertificate $certificate -ClaimsMappings $ClaimTypingMapping1,$ClaimTypingMapping2,$ClaimTypingMapping3,$ClaimTypingMapping4,$ClaimTypingMapping5 -SignInUrl $signinurl -IdentifierClaim $ClaimTypingMapping1.InputClaimType

• realm = the URI or URL that is associated with a SharePoint web application that is configured to use a SAML token-based provider (SharePoint Web application URL)
• signinurl = Access Control Namespace URL which was created in windows Azure.
• $certloc = Physical path for the certificate. Make sure to select the .Cer
• $rootcert = Get the .pfx certificate root
• New-SPTrustedRootAuthority = Creates a trusted root authority.
• $cert = to represents an X.509 certificate.
• $ClaimTypingMapping = map between the new claim in SharePoint with the incoming claim from ACS.
• New-SPTrustedIdentityTokenIssuer  = Create a new Identity Provider named Facebook Authentication

• After running the script successfully – > Go and select the SharePoint Web Application you created – > General Setting from the top ribbon.

• Go to Claims Authentication Section and check Facebook Authentication

• Go back and select the web application –> Click User Policy

• In the pop windows –> Click Add Users

• Select All zones and click Next

• Click Browse Users

• Select All Users –> All Users (Facebook Authentication) –> Click Add –> Click OK.

• Select Full read – Has Full read-only access.

• Click OK

Go to Part 2

Go to Part 4