Wednesday, 28 September 2011

Creating a shared logging block

Overview:  A client host multiple applications on there SharePoint on premise farm and these need to be logged consistanly.

Hypothesis:  SP2010 provide easy logging ability to the ULS, Microsoft have the SharePoint Best Practices that includes the assemblies for logging, these can be extended to create a easy re-useable set of logging functions.  Key areas to cover are where are you logging to: ULS, Event Viewer.  Sandbox solution can be logged to ULS and the event viewer using a full trust proxy solution.  SharEPoint Online will need to log to a list on the hosted farm.

Microsofts Patterns and Practices code library for SharePoint 2010, is useful for providing the core logging functionality.  The Parrerns and Practices can be extended so the custom method for all application on the farm would call the logging code block that is hosted in the GAC.

More Info:

Updated 28 May 2020:
For C#, Power Platform, React, .... I advise to use: App Insights or
Log4Net is still very common

SharePoint 2010 Language Packs MUI & Variations

Language Packs, MUI & Variations

Multi-lingual User Interfaces (MUI) differ from Multi-lingual Sites (Variations). I.e. application may need labels change but content is not translated. I think of MUI as chrome language resource switching whereas variations are used for translating content.

Language packs I would load :
  • en-US (default & in place)
  • fr-FR
  • es-ES
  • zh-CH (Chinese)
  • Japanese?  But it really comes down to your situation. 
Note: If you do not run the SharePoint Products and Technologies Configuration Wizard after you install a language pack, the language pack will not be installed properly. From MS but I believe this can be done using Powershell. There will be down time on the production farm.

  • MUI can be added at any time and allow the site/application to display multiple languages.
  • MUI can be enabled at site collection or web level.
  • Not all site definitions and templates support MUI so we should apply it only at the web level, is my current thinking.
  • Language packs cannot be uninstalled.
  • Variations may be needed either for translating content in SP2010 or for delivering to specific devices such as Smart Phones and tablets. Having the language packs is the easy part, implementing variations needs design/is complex.
  • Install language packs on all WFE and app servers in the farm
  • Language packs are a good idea to install even if you are not using MUI or Variations as it helps index documents in search when the documents are run in another language.
Update 8 July 2015: Regional browser setting dictate which language is used in SharePoint 2013 and SP2013 does not allow you to change between languages via the UI as it did in SP2010 on the Welcome Menu. 

More Info:

Monday, 12 September 2011

CBA for Developement

Problem: Claims Base Authentication (CBA) requires swapping certificates with each machine that will use CBA on a development domain, if you have 20 dev machines you will need to swap certs with ADFS and 20 developer machines. 

Note: This post assumes all dev machines are on a single domain however several approaches will work on a standalone machine however.  If ADFS is present on the local dev use it for CBA in your development environment.

Initial Hypothesis:
If your VM's are all on the same domain you can always use classic mode authentication and test the CBA on a build server.  This does not make the dev env mimic the test, QA & production servers that are using claims for authentication.
Resolution:You could setup your own STS server/Service (feeding off SQL or LDAP) or use the WIF toolkit to create a claims service.
Or use SelfSTS tool to generate claims that SharePoint can consume.

More info:
Setting up and testing your own STS Service
Simple channel 9 Video explain CBA & WIF