Enable ULS logging during App deployment

Troubleshooting is always afterwards, meaning you need logging information to backtrack the origin of the errors. But normally the logging level is set to default and the actual interesting data is missing from the ULS logs.

This post provides an approach to enable logging before deploying your apps and reverting to the default afterwards.

Before making changes to the ULS diagnostic settings you want to backup/export your settings. Doing this from the Central Administration is not your preferred way or you must love to copy and past a lot.

LoggingInCentralAdmin

Export the diagnostic logging levels

You can easy export your settings by using PowerShell. Below a script which exports the diagnostic settings for the ULS logging levels. This script will export the logging levels to a CSV-file.

Get-SPLogLevel | Export-Csv "$($env:USERPROFILE)\Downloads\$((Get-Date).ToString("yyMMddHHmmss"))_LogLevels.csv" -NoTypeInformation

After opening the export in Excel, you get the data shown below.

ExportLoggingLevelsInExcel

Use PowerShell to get and/or update logging level

To get and/or update a particular log level via PowerShell you need to know how to scope the identity of the logging level. Once you know it, it’s pretty simple! The identifier is a combination of Area and Name.

Get-SPLogLevel -Identity "Search:General"

Change logging levels for App deployment

The general steps you want to include in your deployment scripts is based on lowering the logging for a predefined set of logging levels. Next execute the deployment and afterwards revert to the default.

  • Lower logging levels to Verbose
  • Execute deployment
  • Revert to default logging levels

Download the full PowerShell script here.

Lower the logging levels to Verbose

Below you find a script which sets a predefined set of logging levels. This set can be used as a basic for every deployment or configuration change. It is not set in stone that this is all you need, please update it to fit your needs.

Set-SPLogLevel -identity 'Search:Logging Correlation Data' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Logging Correlation Data' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Server:Logging Correlation Data' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Configuration' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Database' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Feature Infrastructure' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:General' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Timer' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Topology' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Upgrade' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:PowerShell' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Deployment' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Management' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Marketplace' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Application Authentication' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:Authentication Authorization' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:CSOM' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:CSOM Api' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Hosting Quota Management' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Monitoring' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Foundation:App Auth' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Portal Server:Runtime' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Portal Server:Long Running Operation' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Server:General' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Server:Setup and Upgrade' -EventSeverity Verbose -TraceSeverity Verbose Set-SPLogLevel -identity 'SharePoint Server:Database' -EventSeverity Verbose -TraceSeverity Verbose

Revert back to the default logging levels

Revert the logging levels to the default, after executing the deployment or configuration changes.

Clear-SPLogLevel

Advertisements

Developing hybrid SharePoint apps that run on-premise and in the cloud – ESPC 2014

My session at the European SharePoint Conference (#ESPC14) was around developing hybrid apps with the SharePoint App Model. Below you can find the slide deck and PowerShell scripts I used during the demo.

Before you start building hybrid apps who are depending on the authentication done by Azure Control Services (ACS) you need to setup a trust between your on-premise farm and ACS.

  1. Replace the default STS certificate and reboot machine afterwards (Replace-STSCertificate.ps1)
  2. Install Microsoft Online Services Sign-In Assistant for IT Professionals RTW (64-bit), http://www.microsoft.com/en-us/download/details.aspx?id=41950
  3. Install Microsoft Online Services Module for Windows PowerShell (64-bit), http://go.microsoft.com/fwlink/p/?linkid=236297
  4. Run script to connect on-premise SharePoint farm to ACS (Connect-SPFarmToAAD.ps1)

Some important side notes:

  • When replacing the STS certificate, all current trusts who are depending on the STS become invalid. Meaning you have to recreate your existing Trusted Security Token Issuers (Install-TrustedSecurityTokenIssuer.ps1 & Remove-TrustedSecurityTokenIssuer.ps1)
  • Ensure you are using the RTW version of Microsoft Online Services Sign-In Assistant instead of the BETA (which is linked in the TechNet article)

Download PowerShell scripts.

Scripts originate from How to: Use an Office 365 SharePoint site to authorize provider-hosted apps on an on-premises SharePoint site (http://msdn.microsoft.com/en-us/library/office/dn155905(v=office.15).aspx), I don’t own the scripts but only provide them for easy of use.

SharePoint Connections Amsterdam 2013 slide deck and Silly Facts demo source code

Last Tuesday and Wednesday the SharePoint Connections Amsterdam 2013 were held in Amsterdam, Netherlands. I did a session on Developing SharePoint 2013 Apps with Visual Studio 2012 and enjoyed it very much.

Besides my session I was on the Ask The Experts team for the DIWUG. Handed out the new edition of the DIWUG SharePoint eMagazine (download for free) and helped people with their questions. At the start of the conference is was quite, but along the way more and more people came up the Ask The Experts panel. Some interesting question, a big thanks for that!

In this article:

Demo 1: Silly Facts SharePoint-hosted App

The Silly Facts demo is about creating a list with silly facts, like the ones below. The list is provisioned in the App web using a Content Type and List Instance artifact.

Site Contents showing the Silly Facts app Default page as part of the app displaying the Facts list instance with generated silly facts 

Once the list is in place I added a App Part (Client Web Part) to the Host web which shows a random fact every time the page gets loaded.

Adding the App Part onto the page (simular like a web part) App Part showing random silly fact on page load

Next to generating silly facts via the JavaScript CSOM a Custom Action is hooked to an Announcement list in the Host web allowing users to easily add new facts to the Facts list.

Extending the context menu via the Custom Action 

Demo 2: Provider-hosted App retrieving data via CSOM and REST

The next demo is extending demo 1 and changing it to a Provider-Hosted app and adding logic for retrieving data with SharePoint via CSOM (Taxonomy) and REST (Search). Changing the SharePoint-Hosted app to a Provider-Hosted app is done in the AppManifest.xml. Here you can change the type and instantly it will ask to generate a Web Project for you.

Next step is adding the chrome which allows you to add a custom menu shown in the top right corner. You can add you own options which integrate with the chrome.

Changing the app type in the AppManifest.xml (in Visual Studio) Provider-Hosted app with chrome and menu customizations (top right corner) 

With everything in place we will retrieve Taxonomy data via the CSOM and perform search queries via the REST API. This is done via code-behind of the Default.aspx on the button click.

After clicking the button "Get Facts" it shows the silly facts with actual data from SharePoint The retrieved data is stored as a facts in the Facts list

Downloads

You can check the slide deck and source if you want. When you have question, please use the comments section below.

Source code is found on Codeplex: https://sillyfacts.codeplex.com/

SharePoint 2013 Client Browser: Now support for Taxonomy and User Profiles

It’s been around 2 months since the last release of the SharePoint 2o13 Client Browser but work has progressed! Today I updated the tool with two new features.

  • Taxonomy support by showing the hierarchy of Term Store, Groups, Term Sets and Terms.
  • Limited support for User Profiles by showing the User Profile of the current user with the related properties and peers.

Download the SharePoint 2013 Client Browser here!

Taxonomy

By using the Microsoft.SharePoint.Client.Taxonomy namespace it’s possible to get the complete hierarchy of the Term Store and even manipulate it.

SharePoint 2013 Client Browser showing the Taxonomy

User Profiles

Next to the Taxonomy SharePoint 2013 client object model is extended with the Microsoft.SharePoint.Client.UserProfiles namespace for interaction with the User Profiles. For now I only included the current user profile. Future releases will be extended with other properties and showing more user profiles of other users within the environment.

SharePoint 2013 Client Browser showing the User Profile of the current user

Slide deck and demos SharePoint Saturday 2013 Holland (#SPSNL13)

Last Saturday I presented at the SharePoint Saturday Holland 2013. It was a good vibe and the audience made it an interactive session. Below you can find the slide deck and parts of PowerShell scripts and source code which I used during my demos.

SharePoint Saturday Holland 2013

Developing hybrid SharePoint apps that run on-premise and in the cloud

With the new SharePoint App model running outside the SharePoint worker process it introduces new authentication models. As a developer you don’t want to build multiple versions of the same app implementing each authentication model separately. This session explains the differences between securing SharePoint apps with OAuth in Office 365 and S2S High Trust in on-premise deployments. You will learn how to build a single app that will run on-premise, online and hybrid SharePoint environments.

Demo: Configure the on-premise SharePoint with Trusted Security Token Issuer

To support high-trust (S2S) apps you need to configure the Trusted Security Token Issuer in your on-premise SharePoint farm. This script is used during the demo to configure the SharePoint farm.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ea 0 # Get the .cer file that you want to use with your app. $certificate = Get-PfxCertificate "C:\Apps\AppCertSP2013.cer" # Get the issuer ID of your app. All the letters in the issuer ID GUID must be lowercase. $issuerId = 'a58e2347-0ead-4ba0-b4b7-75120aa09e4e' # Get the current authentication realm for your SharePoint site $realm = Get-SPAuthenticationRealm -ServiceContext "http://vm-sp-01/sites/dev" # Get the issuer ID together with the realm value. $fullIssuerIdentifier = $issuerId + '@' + $realm # Create a trusted security token service. This fetches metadata from your app (for example, the certificate) and establishes trust with it, so that SharePoint 2013 can accept tokens that are issued by your app. New-SPTrustedSecurityTokenIssuer -Name $issuerId -Certificate $certificate -RegisteredIssuerName $fullIssuerIdentifier –IsTrustBroker

Demo: Build Hybrid app with a single codebase for on-premise and cloud

My last demo was building a Hybrid app that consists of a single codebase which runs both on-premise and in the cloud. The logic which determines if SharePoint is hosted in on-premise or in the cloud is below.

public partial class Default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { Uri hostWeb = new Uri(Request.QueryString["SPHostUrl"]); string contextTokenString = TokenHelper.GetContextTokenFromRequest(Request); if (string.IsNullOrEmpty(contextTokenString)) { using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(hostWeb, Request.LogonUserIdentity)) { clientContext.Load(clientContext.Web, web => web.Title); clientContext.ExecuteQuery(); Response.Write(clientContext.Web.Title); } } else { using (var clientContext = TokenHelper.GetClientContextWithContextToken(hostWeb.OriginalString, contextTokenString, Request.Url.Authority)) { clientContext.Load(clientContext.Web, web => web.Title); clientContext.ExecuteQuery(); Response.Write(clientContext.Web.Title); } } } }