Partager via

Installer côte à côte Reporting Services et Internet Information Services

  • Article

S’applique à : SQL Server 2016 (13.x) Reporting Services et versions ultérieures Power BI Report Server

Pour obtenir du contenu lié aux versions précédentes de SQL Server Reporting Services (SSRS), consultez Présentation de SQL Server Reporting Services.

Vous pouvez installer et exécuter SQL Server 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.

Version des services IIS (Internet Information Services) Problèmes Description
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.

Utilisez des noms de répertoires virtuels uniques pour le service Web Report Server et le portail web afin d’éviter ce conflit.

Des informations détaillées sur ce scénario sont fournies dans cet article.

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
https://123.234.345.456:80/reports Reçoit toutes les requêtes envoyées à https://123.234.345.456/reports ou https://<computername>/reports si un service de nom de domaine peut convertir l’adresse IP vers ce nom d’hôte.
https://+: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 ».
https://123.234.345.456:80 Reçoit toute requête spécifiant https://123.234.345.456 ou https://<computername> si un service de nom de domaine peut convertir l’adresse IP vers ce nom d’hôte.
https://+: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é.
https://*: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 8.0, 8.5 avec SQL Server 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 https://+: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 à https://<nom_ordinateur>/reportserver.
Portail web https://+: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 portail web reçoit toutes les demandes adressées à https://<nom_ordinateur>/reports.
IIS https://*: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 Reporting Services sur IIS 8.0, 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 aux noms 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 ».

  • Instance du serveur de rapports installée dans la configuration par défaut, où la réservation d’URL spécifie également le port 80 et où l’application du portail web utilise aussi « Reports » comme nom de répertoire virtuel.

Compte tenu de cette configuration, une requête envoyée à https://\<computername>:80/reports est reçue par le portail web. L’application accessible via le répertoire virtuel Reports dans IIS ne reçoit plus de requêtes une fois que l’instance du serveur de rapports est installée.

Si vous exécutez des déploiements côte à côte d'anciennes et de nouvelles versions de Reporting Services, il est probable que vous rencontriez ce problème de routage. Ce problème est dû au fait que 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 portail web , ce qui augmente le risque d’avoir des répertoires virtuels « reports » 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 la version 2016 (13.x) ou une version plus récente de SQL Server Reporting Services (SSRS) en tant qu’instance nommée, incluez le nom de l’instance lors de la création d’un répertoire virtuel.

Contenu connexe

D’autres questions ? Posez une question dans le forum Reporting Services.