Partager via

Installation côte à côte de Reporting Services et d'Internet Information Services (SSRS en mode natif)

  • Article

Vous pouvez installer et exécuter SQL Server 2014 Reporting Services (SSRS) et Internet Information Services (IIS) sur le même ordinateur. La version des services IIS (Internet Information Services) que vous utilisez détermine les problèmes d'interopérabilité que vous devez traiter.
S’applique à : Reporting Services mode natif
Version des services IIS (Internet Information Services) Problèmes Description
IIS 6.0, 7.0, 8.0, 8.5 Les requêtes prévues pour une application sont acceptées par une autre application.

HTTP.SYS applique des règles de priorité pour les réservations d'URL. Les requêtes envoyées aux applications qui ont le même nom de répertoire virtuel et qui surveillent conjointement le port 80 risquent de ne pas atteindre la cible prévue si la réservation d'URL est faible par rapport à la réservation d'URL d'une autre application.		 Dans certaines conditions, un point de terminaison inscrit qui remplace un autre point de terminaison d'URL dans le schéma de réservation d'URL peut recevoir des requêtes HTTP destinées à l'autre application.

L'utilisation de noms de répertoires virtuels uniques pour le service Web Report Server et le Gestionnaire de rapports vous aide à éviter ce conflit.

Des informations détaillées sur ce scénario sont fournies dans cette rubrique.

Règles de priorité pour les réservations d'URL

Pour pouvoir traiter les problèmes d’interopérabilité entre les services IIS et Reporting Services, vous devez comprendre le fonctionnement des règles de priorité pour la réservation d’URL. Les règles de priorité peuvent être généralisées à l'aide de la formule suivante : la réservation d'URL dont la définition des valeurs est la plus explicite est la première à recevoir les requêtes qui correspondent à l'URL.

  • Une réservation d'URL qui spécifie un répertoire virtuel est plus explicite qu'une réservation d'URL qui omet un répertoire virtuel.

  • Une réservation d'URL qui spécifie une adresse unique (via une adresse IP, un nom de domaine complet, un nom d'ordinateur réseau ou un nom d'hôte) est plus explicite qu'un caractère générique.

  • Une réservation d'URL qui spécifie un caractère générique fort est plus explicite qu'un caractère générique faible.

Les exemples suivants illustrent une plage de réservations d'URL, de la plus explicite à la moins explicite :

 Exemple Requête
http://123.234.345.456:80/reports Reçoit toutes les demandes envoyées à http://123.234.345.456/reports ou http://< nom>/rapports de l’ordinateur si un service de nom de domaine peut résoudre l’adresse IP en ce nom d’hôte.
http://+:80/reports Reçoit toutes les requêtes envoyées à une adresse IP ou un nom d'hôte valide pour cet ordinateur, tant que l'URL contient le nom de répertoire virtuel « reports ».
http://123.234.345.456:80 Reçoit toute demande qui spécifie http://123.234.345.456 ou http://< nom> d’ordinateur si un service de nom de domaine peut résoudre l’adresse IP en ce nom d’hôte.
http://+:80 Reçoit les requêtes qui ne sont pas déjà reçues par d'autres applications, pour tous les points de terminaison d'application mappés à Assigné.
http://*:80 Reçoit les requêtes qui ne sont pas déjà reçues par d'autres applications, pour les points de terminaison d'application mappés à Non assigné.

Le message d'erreur suivant indique un conflit de ports : « System.IO.FileLoadException : Le processus ne peut pas accéder au fichier, car il est utilisé par un autre processus. (Exception de HRESULT : 0x80070020). »

Réservations d’URL pour IIS 6.0, 7.0, 8.0, 8.5 avec SQL Server 2014 Reporting Services

Grâce aux règles de priorité décrites dans la section précédente, vous pouvez comprendre comment les réservations d'URL définies pour Reporting Services et les services IIS (Internet Information Services) favorisent l'interopérabilité. Reporting Services reçoit des requêtes qui spécifient explicitement les noms de répertoires virtuels de ses applications ; les services IIS (Internet Information Services) reçoivent toutes les requêtes restantes, lesquelles peuvent être adressées ensuite aux applications qui s'exécutent dans le cadre du modèle de processus IIS.

Application Réservation d'URL Description Réception de requête
Serveur de rapports http://+:80/ReportServer Caractère générique fort sur le port 80, avec le répertoire virtuel du serveur de rapports. Reçoit toutes les requêtes sur le port 80 qui spécifient le répertoire virtuel du serveur de rapports. Le service Web Report Server reçoit toutes les demandes adressées à http://< nomordinateur>/serveur de rapports.
Gestionnaire de rapports http://+:80/Reports Caractère générique fort sur le port 80, avec le répertoire virtuel Reports. Reçoit toutes les requêtes sur le port 80 qui spécifient le répertoire virtuel reports. Le Gestionnaire de rapports reçoit toutes les demandes de http://< nom> d’ordinateur/rapports.
IIS http://*:80/ Caractère générique faible sur le port 80. Reçoit toutes les requêtes restantes sur le port 80, qui ne sont pas reçues par une autre application.

Déploiements côte à côte de SQL Server 2014 et SQL Server 2005 Reporting Services sur IIS 6.0, 7.0, 8.0 et 8.5

Des problèmes d'interopérabilité entre les services IIS (Internet Information Services) et Reporting Services se produisent lorsque les sites Web IIS ont des noms de répertoires virtuels identiques à ceux utilisés par Reporting Services. Prenons l'exemple de la configuration suivante :

  • Site Web IIS assigné au port 80 et répertoire virtuel nommé « Reports ».

  • Un serveur de rapports SQL Server 2014 instance installé dans la configuration par défaut, où la réservation d’URL spécifie également le port 80 et l’application du Gestionnaire de rapports utilise également « Rapports » pour le nom du répertoire virtuel.

Compte tenu de cette configuration, une demande envoyée à http://< computername>:80/reports sera reçue par le Gestionnaire de rapports. L’application accessible via le répertoire virtuel Rapports dans IIS ne recevra plus de demandes après SQL Server instance du serveur de rapports 2014 est installé.

Si vous exécutez des déploiements côte à côte de versions plus anciennes et plus récentes de Reporting Services, vous risquez de rencontrer le problème de routage décrit précédemment. En effet, toutes les versions de Reporting Services utilisent « ReportServer » et « Reports » comme noms de répertoires virtuels pour le serveur de rapports et les applications du Gestionnaire de rapports, ce qui augmente la probabilité que vous ayez des répertoires virtuels « rapports » et « reportserver » dans IIS.

Pour vous assurer que toutes les applications reçoivent des requêtes, suivez ces instructions :

  • Pour les installations Reporting Services, choisissez des noms de répertoires virtuels qui ne sont pas déjà utilisés par un site Web IIS sur le même port que Reporting Services. En cas de conflit, installez Reporting Services en mode « fichiers uniquement » (via le programme d'installation, mais ne configurez pas l'option serveur dans l'Assistant Installation) afin de pouvoir configurer les répertoires virtuels, une fois l'installation terminée. Le message d'erreur suivant indique un conflit au niveau de votre configuration : « System.IO.FileLoadException : Le processus ne peut pas accéder au fichier, car il est utilisé par un autre processus. (Exception de HRESULT : 0x80070020). »

  • Pour les installations que vous configurez manuellement, adoptez les conventions d'affectation des noms par défaut dans les URL de configuration. Si vous installez SQL Server 2014 Reporting Services (SSRS) en tant que instance nommée, incluez le nom instance lors de la création d’un répertoire virtuel.

Voir aussi

Configurer les URL du serveur de rapports (SSRS Configuration Manager)
Configurer une URL (Gestionnaire de configuration de SSRS)
Installer le serveur de rapports Reporting Services en mode natif