Comment faire disparaitre certaines erreurs suite à une installation SharePoint 2013

DCOM 10016

J’ai déjà traité des erreurs DCOM 10016 dans une entrée de blogue Comment faire disparaitre les erreurs DCOM 10016 suite à une installation SharePoint publiée il y a quelques années et suscitant encore beaucoup de traffic. Les erreurs ressemblent à:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {61738644-F196-11D0-9953-00C04FD919C1}
to the user <Nom de l’utilisateur du AppPool> SID <SID du AppPool>.
This security permission can be modified using the Component Services administrative tool.

Avec SharePoint 2013, il y a de nouveaux GUIDs qui s’affichent dans le Event Viewer. Aussi, il est recommandé par Microsoft d’utiliser un compte de service différent pour le site d’administration (ex. cs-webadmin) que pour les autres applications Web (ex. cs-web). Si Microsoft SQL Server Integration Services est installé, vous pouvez aussi recevoir des erreurs similaires pour le compte de service SQL (ex. cs-sql).

Voici donc la liste complète des GUIDs pour lesquels on doit suivre mon guide précédent, ainsi que les utilisateurs pour lesquels on doit attribuer des droits:

GUID

Component Service

Utilisateur(s)

{61738644-F196-11D0-9953-00C04FD919C1} IIS WAMREG admin Service cs-webadmin, cs-web
{000C101C-0000-0000-C000-000000000046} {000C101C-0000-0000-C000-000000000046} cs-webadmin, cs-web
{83B33982-693D-4824-B42E-7196AE61BB05} Microsoft SQL Server Integration Services 11.0 cs-sql

Erreurs Reporting Services pour les extensions de données

Par exemple, vous avez peut-être ces erreurs dans les journaux SharePoint (ULS) et SSRS:

Exception caught instantiating TERADATA report server extension:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.

Voici un script PowerShell qui désactive les extensions qui ne sont pas utilisées la plupart du temps:

$ssrs = Get-SPRSServiceApplication

$ext = Get-SPRSExtension -Identity $ssrs.Id

$e = $ext | Where-Object {$_.Name -eq « TERADATA » -and $_.ExtensionType -eq « Data »}

Remove-SPRSExtension -Name $e.Name -ExtensionType $e.ExtensionType -Identity $ssrs.Id

$e = $ext | Where-Object {$_.Name -eq « TERADATA » -and $_.ExtensionType -eq « SemanticQuery » }

Remove-SPRSExtension -Name $e.Name -ExtensionType $e.ExtensionType -Identity $ssrs.Id

$e = $ext | Where-Object {$_.Name -eq « TERADATA » -and $_.ExtensionType -eq « ModelGeneration » }

Remove-SPRSExtension -Name $e.Name -ExtensionType $e.ExtensionType -Identity $ssrs.Id

$e = $ext | Where-Object {$_.Name -eq « SQLPDW » -and $_.ExtensionType -eq « Data » }

Remove-SPRSExtension -Name $e.Name -ExtensionType $e.ExtensionType -Identity $ssrs.Id

$e = $ext | Where-Object {$_.Name –eq « SQLPDW » -and $_.ExtensionType -eq « SemanticQuery » }

Remove-SPRSExtension -Name $e.Name -ExtensionType $e.ExtensionType -Identity $ssrs.Id

Erreurs SQL Server 2012 et SSAS 2012

Si vous avez les erreurs suivantes dans votre observateur d’événements, veuillez suivre ce guide pour les faire disparaître.

SQL Server

sqlservr (3472) tentative d’ouvrir le fichier « C:\Windows\system32\LogFiles\Sum\Api.log » pour uniquement un accès en lecture a échoué avec l’erreur système 5 (0 x 00000005): « Accès refusé ». L’opération d’ouverture de fichier échouera avec l’erreur -1032 (0xfffffbf8).

sqlservr (3472) erreur 1032 (0xfffffbf8) s’est produite lors de l’ouverture du fichier journal C:\Windows\system32\LogFiles\Sum\Api.log.

sqlservr (3472) An attempt to open the file « C:\Windows\system32\LogFiles\Sum\Api.log » for read only access failed with system error 5 (0x00000005): « Access is denied. « . The open file operation will fail with error -1032 (0xfffffbf8).

sqlservr (3472) Error -1032 (0xfffffbf8) occurred while opening logfile C:\Windows\system32\LogFiles\Sum\Api.log.

SSAS

msmdsrv (4680) tentative d’ouvrir le fichier « C:\Windows\system32\LogFiles\Sum\Api.chk » pour la lecture / écriture a échoué avec l’erreur système 5 (0 x 00000005): « Accès refusé ». L’opération d’ouverture de fichier échouera avec l’erreur -1032 (0xfffffbf8).

msmdsrv (4680) erreur 1032 (0xfffffbf8) s’est produite lors de l’ouverture du fichier journal C:\Windows\system32\LogFiles\Sum\Api.log.

msmdsrv (4680) An attempt to open the file « C:\Windows\system32\LogFiles\Sum\Api.chk » for read / write access failed with system error 5 (0x00000005): « Access is denied. « . The open file operation will fail with error -1032 (0xfffffbf8).

msmdsrv (4680) Error -1032 (0xfffffbf8) occurred while opening logfile C:\Windows\system32\LogFiles\Sum\Api.log.

Erreur SharePoint pour SPUsageImportJobDefinition

Si vous avez l’erreur suivante:

The Execute method of job definition Microsoft.SharePoint.Administration.SPUsageImportJobDefinition (ID ef497ec2-0cbf-4458-91ea-db75422fd9da) threw an exception. More information is included below.

Utilisez la soution décrite ici.

Virtualisation, plate-forme BI de Microsoft et économie d’énergie

Introduction

Les utilisateurs n’aiment pas attendre. Les entreprises comme Amazon et Google prennent cela très au sérieux, tel qu’indiqué dans cet article:

Surprising as all this may be, the implications of this impatience are even more shocking. Amazon‘s calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year. Google has calculated that by slowing its search results by just four tenths of a second they could lose 8 million searches per day–meaning they’d serve up many millions fewer online adverts.

On est d’accord sur le fait qu’un rapport BI est plus complexe à générer qu’une page listant les produits électroniques en solde. Mais les utilisateurs vont quand même exiger des performances acceptables, autrement ils n’utiliseront pas l’application.

C’est pourquoi vous devez faire passer les performances avant les économies d’énergie sur vos serveurs desservant la solution BI.

Plusieurs CPU modernes supportent des fonctions d’économie d’énergie afin de diminuer la consommation d’énergie quand les serveurs ne sont pas trop occupés. Cependant, cette mécanique ne réagit pas assez vite et fait en sorte que la peformance de l’application BI sera médiocre … sauf lors de pointes d’utilisation (charge).

The theory is in “Balanced” mode the CPU will run at a lower clock speed when it is under low workload, and bring more resources online when there is more to do. As great as it sounds, this won’t always be your best option. If your workload is incredibly bursty (quick moments of intense work), your SQL query speeds will take a hit, as by the time Windows has decided it needs more resources the work may already be done.

Symptômes

Si vous ne contrôlez que les paramètres du système d’exploitation “Guest” (machine virtuelle), voici les symptômes qui peuvent indiquer que l’hôte utilise des fonctions de gestion d’énergie:

  1. Si vous utilisez un outil de Benchmark, comme NovaBench, les résultats varient beaucoup d’un test à l’autre.
  2. Si vous demandez un rapport, les temps sont mauvais. Si vous demandez X rapports où X est le nombre de vCPU, les temps individuels sont meilleurs …

Recommandation

Il peut y avoir trois niveaux de configuration:

  1. BIOS
  2. Hypervisor
  3. OS

La recommandation est de soit désactiver la gestion de l’énergie dans le BIOS, soit l’activer en laissant le contrôle à l’OS (OS Controlled). Dans ce dernier cas, il faut s’assurer que l’hypervisor et / ou l’OS guest utilise High Performance.

Par défaut, VMWare ESX/ESXi utilise High Performance par défaut.

Par défaut, Windows Server 2008 R2 est à Balanced Performance, ce qui n’est pas désirable dans un environnement BI de Microsoft.

Références

Does CPU power management affect server performance?
http://serverfault.com/questions/94212/does-cpu-power-management-affect-server-performance

Consider CPU Power Optimization Versus Performance When Virtualizing
http://workinghardinit.wordpress.com/2011/06/20/consider-cpu-power-optimization-versus-performance-when-virtualizing/

Follow Up on Power Options for Performance When Virtualizing
http://workinghardinit.wordpress.com/2011/07/01/follow-up-on-power-options-for-performance-when-virtualizing/

Best Practices in Power Management
http://en.community.dell.com/techcenter/power-cooling/w/wiki/best-practices-in-power-management.aspx

(VMWare) Using CPU Power Management Policies
http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp#managing_cpu_resources/c_managing_cpu_power_efficiency.html

Degraded overall performance on Windows Server 2008 R2
http://support.microsoft.com/kb/2207548/en-us

SQL Server on Power-Saving CPUs? Not So Fast.
http://www.brentozar.com/archive/2010/10/sql-server-on-powersaving-cpus-not-so-fast/

Why Microsoft Windows Server 2012 produces slow and inconsistent SQL query speeds
http://www.masterofmalt.com/software-development/blog/why-microsoft-windows-server-2012-produces-slow-and-inconsistent-sql-query-speeds/

Authentification par formulaire, SharePoint, SSRS et sécurité des données dans SSAS

Introduction à l’authentification par formulaire

L’authentification par formulaire dans SharePoint est basée sur la mécanique ASP.Net Membership Provider. Celle-ci date du .NET Framework 2.0, donc elle bien comprise des développeurs. Il y a aussi plusieurs providers disponibles, dont ceux fournis par Microsoft (ex. SqlAspNetMemberShipProvider).

Les raisons d’utiliser une authentification par formulaire sont variées:

  1. Une authentification propriétaire doit être utilisée. Dans ce cas, il faut développer un Custom Membership Provider.
  2. L’application est déployée sur Internet et l’utilisation de comptes Windows (ex. via un serveur ISA) est exclue.
  3. Plusieurs personnes utilisent un poste Windows sous le même compte et l’application doit les distinguer.

Claims et authentification par formulaire

Dans la version 2010 de SharePoint, Microsoft a ajouté un mode d’authentification Claims pour les applications Web. Le mode classique est toujours disponible mais ne fonctionne qu’avec l’authentification Windows. Cela veut dire que dès que l’on utilise l’authentification par formulaire, il faut configurer l’application Web en Claims.

image

Et il faut cocher l’authentification par formulaire en spécifiant le Membership Provider et le Role Provider:

image

Si vous avez activé plusieurs modes d’authentifications simultanément, les utilisateurs devront choisir la méthode avec laquelle ils souhaitent s’authentifier:

image

Claims et SSRS 2008 R2

Reporting Services 2008 R2 n’est pas Claims-Aware mais peut fonctionner lorsque SharePoint 2010 est configuré pour utiliser les Claims. Vous pouvez consulter ceci et ceci dont voici un extrait:

Because this functionality is built into SharePoint 2010 products, Reporting Services can work with this authentication model. Reporting Services is not claims-aware; instead it communicates with SharePoint through a trusted account. The proxy service within the SQL Server 2008 R2 add-in uses the SharePoint object model to convert the claims token into a corresponding SharePoint user context in the form of a SharePoint user token that the Report Server can understand and use to validate against the SharePoint database.

Par exemple, si l’utilisateur s’authentifie via l’authentification Windows, la variable User!Name contiendra i:0#.w|domain\user.

Claims et SSRS 2012

Pour sa part, Reporting Services 2012 est bel et bien Claims-Aware. Il est intégré comme un SharePoint shared service. Quelques extraits de l’article What’s New (Reporting Services):

The new architecture is implemented as a SharePoint 2010 shared service. The shared service architecture allows Reporting Services to leverage many of the IT features of SharePoint products.

(…)

The new Reporting Services service applications support Claims based authentication.

Claims et SQL Server

Pour sa part, SQL Server (engin relationnel et SSAS) n’est pas Claims-Aware. La seule manière de communiquer avec celui-ci est d’utiliser un compte Windows. Dès lors que SSRS est intégré à un SharePoint configuré en Claims, il faut définir un utilisateur pour exécuter les requêtes:

image

Claims et sécurité des données dans SSAS

SSAS permet de définir des rôles ayant des droits différents sur une base de données. C’est très pratique car cette sécurité est effective peu importe l’outil client utilisé pour se connecter aux données (ex. Excel).

image

Mais si tous les rapports s’exécutent avec le même compte Windows, comment utiliser la sécurité de données?

La réponse passe par l’utilisation de la clé EffectiveUserName dans la chaîne de connexion, qui doit devenir dynamique (et non partagée).

Data Source=Serveur;Initial Catalog=Catalogue;EffectiveUserName=UtilisateurÀUtiliserPourLaSécuritéDeDonnées

image

image

Dans cet exemple, j’ai défini un Dataset pour aller extraire les paramètres de la chaîne de connexion:

image

image

La procédure stockée accepte le nom de l’utilisateur (User!Name) comme paramètre et doit retourner le nom du serveur SSAS, le nom du catalogue SSAS ainsi que le nom de l’utilisateur Windows à impersonifier avec EffectiveUserName.

image

Ce DataSet, sert à alimenter trois paramètres internes:

image

Voici un exemple de ces paramètres:

image

image

Lorsque le rapport SSRS s’exécutera, les 3 premiers paramètres seront résolus en se connectant à SQL Server pour appeler la procédure stockée. Puis la chaîne de connexion dynamique vers SSAS sera résolue et contiendra un EffectiveUserName.

Prérequis pour utiliser EffectiveUserName avec SSAS

Avec ce qu’on a fait dans l’étape précédente, nous aurons le bon compte Windows dans le paramètre EffectiveUserName pour la connexion SSAS. Cependant pour que cela fonctionne il faut que le compte qui exécute la requête SSAS soit administrateur du serveur SSAS:

image

Puis il faut assigner chaque utilisateur pouvant être placé dans EffectiveUserName à un rôle SSAS.

Mais comme on le disait plus haut, lorsque l’authentification par formulaire est utilsée, il faut stoker l’identié du compte de service qui exécutera réellement les requêtes. Dans le cas des connexions vers SSAS, il faudra utiliser un compte de service qui sera dans la liste des administrateurs.

Si vous n’avez qu’une poignée de rapports, ce n’est peut-être pas trop difficile d’aller manuellement entrer ces informations au moyen de l’interface graphique de SharePoint:

image

Mais si les rapports sont mis à jour régulièrement ou que vous en avez plusieurs, cela peut devenir fastidieux.

Automatiser l’affectation des informations  d’identification stockées

Les services Web de Reporting Services vous donnent la possibilité de de spécifier l’utilisateur Windows à utiliser pour vous connecter à SSAS. Vous pourriez facilement développer un programme qui:

  1. Liste tous les rapports d’une librairie de documents SharePoint.
  2. Pour chacun, énumère les sources de données personnalisées (non partagées).
  3. Pour celles-ci, changer leur mode pour stocker l’identité spécifique.
  4. Affecte la liste des connexions modifiées au rapport déployé.

Vous pouvez utiliser le service Web accessible via un hyperlien ressemblant à ceci:

http://WebApplicationUrl/_vti_bin/ReportServer/ReportService2006.asmx

La documentation est ici:

http://technet.microsoft.com/en-us/library/reportservice2006.reportingservice2006(v=sql.105).aspx

La méthode ListChildren, acceptant en paramètre l’Url vers la librairie de documents contenant les rapports, retournera un tableau de CatalogItem.

Il est facile d’itérer sur les CatalogItem de type rapport:

foreach (ReportService2006.CatalogItem pCurItem in apItems.Where(pCI => pCI.Type == ReportService2006.ItemTypeEnum.Report)

Puis la méthode GetItemDataSources permet d’obtenir le tableau de DataSource du rapport. Il peut d’agir d’un DataSourceDefinition ou DataSourceReference.

Il faut donc itérer sur les sources de données personnalisées:

foreach (ReportService2006.DataSource pCurDataSource in apCurDataSources.Where(pDS => pDS.Item is ReportService2006.DataSourceDefinition)

Puis il suffit de modifier la DataSourceDefinition:

ReportService2006.DataSourceDefinition pCurDefinition = (ReportService2006.DataSourceDefinition)pCurDataSource.Item;pCurDefinition.CredentialRetrieval = ReportService2006.CredentialRetrievalEnum.Store;
pCurDefinition.UserName = sUserName;
pCurDefinition.Password = sPassword;
pCurDefinition.WindowsCredentials = true;
pCurDefinition.ImpersonateUser = false;
pCurDefinition.ImpersonateUserSpecified = true;

Puis il faut affecter la liste des connexions modifiées au rapport via la méthode SetItemDataSources.

Références

Working Together: SQL Server 2008 R2 Reporting Services Integration in SharePoint 2010
http://technet.microsoft.com/en-us/magazine/ff686706.aspx

Claims Authentication and Reporting Services
http://technet.microsoft.com/en-us/library/ff487970(v=sql.105).aspx

What’s New (Reporting Services 2012)
http://msdn.microsoft.com/en-us/library/ms170438.aspx#bkmk_sharepoint

Using EffectiveUserName To Impersonate in SSAS
https://www.artisconsulting.com/blogs/greggalloway/Lists/Posts/Post.aspx?ID=18&fwLinkID=301385

Oui vous pouvez utiliser C2WTS sur un serveur unique (Single Server Install) avec SharePoint 2013

Problématique

Un article de TechNet crée de la confusion au niveau de la configuration de SharePoint 2013 lorsque tout est sur le même serveur.

Le paragraphe suivant est le coupable:

Note: Some of the configuration steps may change, or may not work in certain farm topologies. For instance, a single server install does not support the Windows Identity Foundation C2WTS services so claims to windows token delegation scenarios are not possible with this farm configuration.

Ou en français:

Remarque : certaines étapes de configuration peuvent changer, ou peuvent ne pas fonctionner dans certaines topologies de batteries de serveurs.  Par exemple, une installation de serveur unique ne prend pas en charge les services C2WTS Windows Identity Foundation, c’est pourquoi les scénarios de délégation de jetons Windows ne sont pas possibles avec cette configuration de batterie de serveurs.

Cela laisse sous-entendre que la sécurité de données (SSAS) ne peut être utilisée avec SharePoint 2013, SSRS et SSAS. Il faudrait donc configurer les sources de données pour utiliser un compte en particulier ce qui empêcherait de retourner des données différentes selon l’utilisateur du rapport.

Plusieurs forums discutent de cette affirmation donc celui-ci. Une hypothèse est que Single Server Install a probablement été inversé pour “Standalone” qui signifie que Windows Internal Database est utilisée plutôt qu’une vrai version de SQL Server.

Solution

Peu importe, nous l’avons testé et cela fonctionne parfaitement!

Dans mon article Reporting Services 2012 et la configuration Kerberos: désolé vous devrez utiliser la constrained delegation avec C2WTS je disais que dès que C2WTS est utilisé, la constrained Kerberos delegation doit être utilisée. Je maintiens mon affirmation avec l’exception suivante: pas si tout est sur le même serveur.

Quand tout est sur le même serveur, utilisez vos comptes de services réguliers qui délèguent vers “Any Services”:

Service Compte
SQL Server (engin relationnel) cs-sql
Analysis Services cs-ssas
Reporting Services cs-ssrs ou cs-web
SharePoint (Web Apps) cs-web
C2WTS Local System

La clé pour que cela fonctionne sur un seul serveur est d’utiliser “Local System” comme compte de service pour C2WTS.

Si vous utilisez un compte de domaine pour C2WTS ça ne fonctionnera pas. Vous n’avez même pas besoin de configurer la délégation Kerberos pour le serveur (i.e. servername$).

Cela vous permettra d’avoir le scénario suivant:

  1. Frédérick demande l’affichage d’un rapport SSRS 2012 stocké dans SharePoint 2013.
  2. IIS l’authentifie via Windows Authentication et la plomberie Microsoft .NET convertira le jeton Windows en Claim.
  3. SharePoint et SSRS fonctionnent en claims.
  4. Puis lorsqu’il est temps d’interoger la source de données (SSAS) il faut obtenir une identité Windows car SSAS n’est pas Claim-Aware. C’est là qu’intervient C2WTS et celui-ci génère un jeton pour Frédérick qu’il envoie à SSAS.
  5. SSAS peut donc retourner les données propres à Frédérick (sécurité de données).

image

Le déploiement sur un seul serveur est pratique pour réaliser des tests ou pour des solutions de moindres envergures.

J’espère donc que cet article contribura à réduire la confusion sur ce sujet.

Et vous, utilisez-vous les déploiement sur un seul serveur avec de la sécurité de données?

Références

Claims to Windows Token Service (C2WTS)
http://technet.microsoft.com/en-us/library/hh231678.aspx

Claims to Windows Token Service (c2WTS) Overview
http://msdn.microsoft.com/en-us/library/ee517278.aspx

Does C2WTS work on a single server install??
http://social.technet.microsoft.com/Forums/sharepoint/en-US/85bd9bf4-ce25-4faf-85ea-6e3bbf081f24/does-c2wts-work-on-a-single-server-install?forum=sharepointadminprevious

L’authentification Claims à travers la plate-forme Microsoft BI

Un collègue m’a transmis un article qui résume bien les capacités de la plate-forme Microsoft BI vis-à-vis l’authentification Claims.

En gros, ni Analysis Services (SSAS), ni SQL Server ne supportent l’authentification Claims. Ils ont besoin d’une identité Windows pour fonctionner. Extrait de l’article:

No SQL Server service, including Windows Azure SQL Database, is Claims-aware. If you are building a custom BI solution that includes SQL Server features, you will need a Windows user identity (or a SQL Server database user identity) to authenticate to the backend server.

Pour ce qui est de Reporting Services (SSRS), si le Claim a été créé via une authentification Windows, il sera possible de le convertir en jeton Window via le service Claims To Windows Token Service (C2WTS). C’est d’ailleurs ainsi que la délégation Kerberos fonctionne avec SSRS 2012.

Autrement, l’exécution du rapport se fera via le Trusted Account et vous devrez spécifier un utilisateur à utiliser pour vous connecter à vos bases de données:

Requirements include configuring the report server to use Trusted Accounts. 

(…)

Once you deploy the report to SharePoint, you must modify data source connection information to use stored credentials (a windows user identity or database credentials).

Je vous suggère fortement de lire l’article:

Using Claims Authentication across the Microsoft BI Stack
http://social.technet.microsoft.com/wiki/contents/articles/15274.using-claims-authentication-across-the-microsoft-bi-stack.aspx

Problème de connexion OLEDB avec SSAS et Kerberos

Nous avons rencontré un problème d’authentification Kerberos sous Windows 2008 en utilisant une connexion OLEDB vers Analysis
Services.

Il est parfois nécessaire d’utiliser le pilote OLEDB comme source de données avec Reporting Services. Le pilote par défaut, Microsoft Analysis Services, nous force à requêter des mesures sur les colonnes et le reste sur les lignes. Dans certains cas particulier, le MDX à utiliser ne peut respecter cette règle et il faut alors utiliser le pilote OLEDB.

Dans notre situation, il y avait un serveur pour SharePoint/SSRS et un autre pour SQL/SSAS. Il fallait donc configurer ceux-ci pour la délégation Kerberos.

Il y a cependant un bogue avec Windows 2008 (R1) et Kerberos qui est corrigé uniquement via un Hot Fix.

Voici l’erreur qu’on obtient:

The following system error occurred:
Errors in the compression library: The data could not be decompressed.

La fonction demandée n’est pas prise en charge
Erreurs de la bibliothèque de compression : Impossible de décompresser les données.

La solution est de demander le Hot Fix à Microsoft en fournissant une adresse de courriel. Presqu’immédiatement on reçoit le Hot Fix et il suffit de l’appliquer sur le serveur Windows 2008.

Voici le lien vers le Hotfix (kb 969083):

http://support.microsoft.com/kb/969083

Le problème survient avec les versions suivantes de Windows:

  1. Windows Server 2008 Datacenter
  2. Windows Server 2008 Enterprise
  3. Windows Server 2008 Standard
  4. Windows Vista Enterprise 64-bit Edition
  5. Windows Vista Home Basic 64-bit Edition
  6. Windows Vista Home Premium 64-bit Edition
  7. Windows Vista Ultimate 64-bit Edition
  8. Windows Vista Business
  9. Windows Vista Business 64-bit Edition
  10. Windows Vista Enterprise
  11. Windows Vista Home Basic
  12. Windows Vista Home Premium
  13. Windows Vista Ultimate

Kerberos est bien configuré mais votre SSRS ne marche pas en mode distribué

La manière la plus facile d’intégrer SSRS à SharePoint est de l’installer sur le même serveur que celui utilisé par SharePoint (WSS ou MOSS).

Cependant, il peut être plus logique, plus performant, plus flexible dans l’avenir d’installer SSRS sur un autre serveur. Par exemple, le mode Scale-Out de la version Enterprise permet d’avoir plus d’un serveur Reporting Services pour une ferme SharePoint.

Vous décidez d’aller de l’avant avec une installation distribuée sur deux ordinateurs :

clip_image001[6]
Source : How to: Install and Configure SharePoint Integration on Multiple Servers
http://msdn.microsoft.com/en-us/library/bb677365.aspx

Vous suivez les instructions correctement afin d’installer et configurer les bons logiciels sur les deux machines. Vous créez vos SPNs pour chaque service (SQL Server, SSAS, SSRS et SharePoint). Vous avez configuré la délégation Kerberos standard (unconstrained) ou spécifique (constrained).

Vous avez déployé un projet SSRS de test sur votre site SharePoint et cela fonctionne correctement quand vous naviguez localement (à partir du serveur #1).

Par contre, dès que vous tentez d’exécuter un rapport à partir d’un fureteur distant, vous obtenez l’erreur suivante :

Une erreur inattendue s’est produite au cours de la connexion au serveur de rapports. Vérifiez que le serveur de rapports est disponible et configuré pour le mode SharePoint intégré.

 

An unexpected error occurred while connecting to the report server. Verify that the report server is available and configured for SharePoint integrated mode.

clip_image003[5]

Vous lisez sur la sécurité SSRS en mode SharePoint  et suivez leur recommandation:
image
Source: Security Overview for Reporting Services in SharePoint Integrated Mode
http://msdn.microsoft.com/en-us/library/bb283324.aspx

Quelques points dignes de mention:

Et là vous ne comprenez pas pourquoi ça ne marche toujours pas … Vous êtes en train de vous demander si votre installation est corrompue et vous vous apprêtez à tout réinstaller. Continuez à lire!

En utilisant l’outil WireShark et en utilisant « kerberos » comme filtre, je pouvais voir passer les AS_REQ, AS_REP, TGS_REQ, TGS_REP qui passent entre les serveurs et le contrôleur de domaine. Dans mon cas, je ne voyais jamais la demande de délégation d’identité du compte de service SharePoint vers le SPN de SSRS.

Normalement, sur votre serveur #1 (SharePoint sans SSRS), vous devriez voir ce trafic Kerberos lors de l’exécution d’un rapport à partir d’un fureteur distant :

clip_image007[6]

Vous voyez que suite à la requête à RSViewerPage.aspx, il y a une demande (TGS-REQ) pour le service http/ms-sql2008r2.syntell.com qui est le site IIS du serveur SSRS. Si cette demande n’a pas lieu c’est que votre serveur SSRS n’est pas configuré pour fonctionner en mode Kerberos. La réponse (TGS-REP) devrait inclure l’identité de l’utilisateur qui a exécuté le rapport à partir d’un fureteur distant.

Un autre indice, dans l’observateur d’événements sur la machine SSRS, dans la section Sécurité, vous voyez une tentative d’authentification pour un utilisateur anonyme (ANONYMOUS LOGON).

clip_image009[5]

En plus de dire à IIS qu’il faut être en mode Negociate,NTLM il faut aussi le dire à ReportServer. C’est ce que j’ai découvert à la dure …

Ce dernier a un fichier de configuration (rsreportserver.config) situé ici :

C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config

Dans ce fichier il y a une section Authentication -> AuthenticationTypes qui doit être mise à RSWindowsNegotiate ou RSWindowsKerberos :

<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate />
</AuthenticationTypes>

La valeur par défaut dépend du compte de service qui a été mis initialement pour le service de SSRS. Normalement on met un utilisateur de domaine dès l’installation alors on se retrouve avec RSWindowsNTLM ce qui désactive l’utilisation de Kerberos avec SSRS …

Voyez par vous-même :

By default, the RSReportServer.config file includes the RSWindowsNegotiate setting if the Report Server service account is either NetworkService or LocalSystem; otherwise, the RSWindowsNTLM setting is used. You can add RSWindowsKerberos if you have applications that only use Kerberos authentication.

http://msdn.microsoft.com/en-us/library/cc281253.aspx

Et enfin ça marche!

clip_image011[6]