Partager via

Fichier lisez-moi Microsoft Web Deploy v3

  • Article

par Harsh Mittal

Vue d’ensemble

Web Deploy est un outil qui simplifie la migration, la gestion et le déploiement d’applications web, de sites et de serveurs. Il peut être utilisé pour intégrer un site Web, en incluant automatiquement le contenu, la configuration, les certificats et les bases de données. Il peut être utilisé pour effectuer la synchronisation entre IIS 6.0, IIS 7.x et IIS8.0, ou pour migrer à partir d’IIS 6.0 et IIS7.x vers IIS 7.x et versions ultérieures. Les packages créés peuvent être utilisés pour le versionnage, la sauvegarde ou le déploiement.

Fonctionnalités

Web Deploy inclut les fonctionnalités clés suivantes :

Intégration de sites web et d’applications : les développeurs et les administrateurs peuvent intégrer la configuration et le contenu des applications web installées, y compris les bases de données SQL, et utiliser les packages pour le stockage ou le redéploiement. Ces packages peuvent ensuite être déployés à l’aide de l’interface du Gestionnaire IIS sans nécessiter de privilèges administrateur sur un serveur distant.

Déléguer des tâches de déploiement à des non-administrateurs. Les administrateurs de serveur peuvent choisir de déléguer des tâches de déploiement aux utilisateurs qui ne sont pas administrateurs. Par exemple, dans les environnements d’hébergement partagé et les environnements d’entreprise, le déploiement du contenu et le marquage d’un dossier en tant qu’application peuvent être délégués. Des tâches plus avancées adaptées à un environnement spécifique, telles que l’autorisation de déployer un certificat, un site Web ou un assembly GAC peuvent également être activées.

Simplifier le déploiement pour les administrateurs. Les administrateurs de serveur trouveront la délégation utile, car le déploiement d’une application web comprenant un assembly GAC, un certificat et un pool d’applications peut prendre du temps, même avec toutes les autorisations requises.

Migration à partir d’IIS 6.0 et d’IIS7 : l’opération de migration fournit aux administrateurs un moyen de migrer des sites ou des serveurs entiers d’IIS 6.0 vers IIS 7 et versions ultérieures, d’IIS7 vers IIS8, y compris leurs paramètres et leur contenu. Une migration est essentiellement un moyen de synchronisation, filtré par des règles de migration.

Synchronisation d’IIS 6.0 / IIS 7/IIS8.0 L’opération de synchronisation permet aux administrateurs de synchroniser rapidement un site ou un serveur et de déployer des modifications sur des sites et serveurs existants. Une synchronisation vous permet de synchroniser une source avec une destination. Par exemple, vous pouvez synchroniser deux chemins d’accès de répertoire ou deux serveurs web. La synchronisation peut être effectuée avec des objets locaux ou distants.

Capture instantanée IIS 7.0 et versions ultérieures La fonctionnalité de capture instantanée, ou d’archivage, permet aux administrateurs ou aux développeurs d’utiliser rapidement une archive de leur site web ou serveur à des fins de restauration ou de sauvegarde. La fonctionnalité de capture instantanée automatique permet également aux administrateurs de site web d’effectuer certaines des tâches ci-dessus.

Analyse des dépendances sur IIS 6.0 et versions ultérieures L’opération d’analyse permet aux administrateurs de vérifier quels composants sont installés sur le serveur source. De cette façon, ils peuvent déterminer si les fonctionnalités dont ils auront besoin dans IIS 7.0 sont présentes, ou s’ils nécessitent une configuration plus élaborée que la simple copie de fichier.

Résolution des problèmes et validation. Pour valider une opération, le paramètre -whatif permet aux administrateurs de voir quelles actions se produisent lorsqu’ils effectuent une opération. Cela est particulièrement utile lors de la synchronisation ou de la migration, quand les administrateurs souhaitent valider les modifications qui seront apportées avant de les exécuter. Pour la résolution des problèmes, le paramètre -verbose permet aux administrateurs d’obtenir des informations détaillées sur les opérations en cours d’exécution et en cas d’échec, la possibilité de diagnostiquer le problème.

Synchronisation différentielle. L’outil synchronise uniquement ce qui a changé entre la source et la destination.

Script facile via PowerShell : les tâches courantes de l’outil Web Deploy peuvent être automatisées à l’aide d’applets de commande PowerShell.

Notes d’installation

Spécifications

Les conditions préalables suivantes doivent être remplies pour installer l’outil :

· .NET 2.0 SP1 ou version ultérieure doit être installé.

Téléchargement et installation

Il existe deux packages téléchargeables distincts pour l’outil ; vous devrez télécharger le package approprié. Vous pouvez télécharger les versions (x86) ou (x64).

Problèmes importants résolus dans cette version :

Modification : Dans les versions précédentes de Web Deploy, le service tempAgent s’exécutait toujours sur le port 80. Dans Web Deploy v3 RC, ce port peut être modifié en spécifiant le nouveau port dans l’argument computername à l’aide du format computername=serverName :###, tempagent=true (où #### est le numéro de port à utiliser)

Modification : correction d’un problème avec Web Deploy où le nombre de modifications n’était pas exact pour les opérations -whatif lors de l’utilisation de l’option -useCheckSum.

Modification: Web Deploy V3 désactive automatiquement les paramètres de proxy. Il s’agissait précédemment d’un problème pour certains clients, qui devaient ouvrir Internet Explorer pour y désactiver les paramètres de proxy avant de démarrer une synchronisation.

Modification: ajout de la prise en charge des liaisons de style IPv6 dans la logique de synchronisation de certificat. Les versions précédentes ne pouvaient pas synchroniser correctement les liaisons IPv6.

Modification: lors de la synchronisation d’une clé de Registre enfant sur un serveur où la clé de Registre parente n’existe pas, les clés de Registre parentes jusqu’à la clé enfant sont désormais créées (sans valeurs) et cela ne mène pas à l’échec de la synchronisation. Par exemple, si on synchronise la clé de Registre HKEY_LOCAL_MACHINE\SOFTWARE\MySoft\TestWeb1 là où la clé MySoft n’existe pas sur l’ordinateur de destination, la clé MySoft est créée sur l’ordinateur de destination, ce qui permet la synchronisation.

Modification : Dans certains cas, la publication Web Deploy supprimait les autorisations héritées sur le dossier racine du site. Web Deploy V3 résout ce problème.

Problèmes connus

Problème : la mise à niveau de Web Deploy v3 interrompt les synchronisations SQLite qui fonctionnaient à l’aide de Web Deploy v2

Les fichiers de configuration par défaut exécutables Web Deploy v3 (msdeploy.exe.config et msdepsvc.exe.config) ont été mis à jour de .Net 2.0 vers .Net 4.0, ce qui entraîne cette interruption.

Solution de contournement :

  • SQLite dispose d’une version compatible .Net 4. La copie de sqlite3.exe à partir de cette version dans le répertoire «%ProgramFiles%\IIS\Microsoft Web Deploy V3 » résout le problème.
  • Remplacez la version par défaut de .Net pour WebDeploy V3 msdeploy.exe.config par .Net 2.0, comme indiqué ci-dessous
<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727" />
    <supportedRuntime version="v4.0" />
  </startup>
</configuration>

Problème :le service Agent Web Deploy ne fonctionne pas avec les comptes d’utilisateurs locaux qui ne sont pas le compte d’utilisateur Administrateur, mais sont membres du groupe Administrateurs. L’erreur ERROR_USER_NOT_ADMIN est retournée.

Le service d’agent distant accepte les informations d’identification d’administrateur ou d’administrateur de domaine intégrées , toutes les autres informations d’identification d’administrateur ne fonctionnent pas et provoquent cette erreur.

Solution de contournement :

Utilisez un compte d’utilisateur administrateur intégré ou un compte d’utilisateur de domaine (partie du groupe d’administration sur l’ordinateur local). Le service d’agent distant accepte les informations d’identification d’administrateur ou d’administrateur de domaine intégrées. Si vous avez une configuration non-domaine et que vous souhaitez utiliser un compte autre que l’administrateur intégré, procédez comme suit :

  • Créez un groupe d’utilisateurs distinct MSDepSvcUsers sur un ordinateur distant.
  • Créez un compte local A sur l’ordinateur local et distant.
  • Ajoutez A à MSDepSvcUsers sur l’ordinateur distant.
  • Utilisez le compte A pour publier. Cela vous permettra de publier sans avoir à utiliser un compte d’administrateur intégré.

Problème : certaines règles de délégation du service de gestion ne fonctionnent pas après la mise à niveau de Web Deploy vers Web Deploy 3.0

Si un serveur IIS 7+ utilise une configuration partagée, certaines règles de délégation dont l’identité runAs est définie sur SpecificUser cesseront de fonctionner. En effet, le programme d’installation Web Deploy et le script .\AddDelegationRules.ps1 créent des comptes d’utilisateur d’ordinateur local et les définissent en tant qu’identité runAs sur certaines règles de délégation. Ces comptes d’utilisateur ne seront pas reconnus sur d’autres ordinateurs et les règles ne fonctionneront donc pas dans la configuration partagée.
Solutions de contournement :

· Si vos règles de délégation ont déjà été remplacées, recréez les règles affectées manuellement.

Problème : Impossible de publier sur le site créé avec le script PowerShell SetupSiteForPublish.ps1 ou configuré pour la publication Web Deploy via la commande « Configurer pour la publication Web Deploy... » UI

Le script de création de site ainsi que l’interface utilisateur pour configurer Web Deploy pour un site existant définissent l’URL de publication sur https://myserver:8172/msdeploy.axd. Ce nom d’ordinateur est généralement accessible au sein d’un réseau. Toutefois, il n’est souvent pas accessible à partir de l’extérieur du réseau. Il doit donc être remplacé par un nom DNS public.

Solutions de contournement :

  • À partir du script : le script n’avertit pas de cette erreur. Remplacez l’URL par l’URL correcte (comme ci-dessous) dans le fichier de paramètres généré.
  • À partir de l’interface utilisateur : entrez le nom DNS public dans le champ « Spécifier l’URL de la connexion au serveur de publication », par exemple, au lieu de https://myserver:8172/msdeploy.axd, entrez https://some.publicDnsName.com:8172/msdeploy.axd.

Problème: le package créé avec Web Deploy V3 ne fonctionne pas avec WebDeploy V2. Il aboutit à System.NullReferenceException.

Solutions de contournement :

  • Mettre à niveau l’ordinateur cible vers Web Deploy v3
  • Utilisez Web Deploy V2 pour créer un package.

Problème: l’interface utilisateur de Web Deploy dans le Gestionnaire IIS donne une erreur « Impossible de caster l’objet de type »

Si Web Deploy v1.1 est installé sur l’ordinateur de destination et que la version 2 de l’ordinateur source est installée, cette erreur peut s’afficher. Il s’agit d’une incompatibilité entre versions.

Solutions de contournement :

  • Mettre à niveau l’ordinateur source vers Web Deploy v2
  • Désinstaller toutes les versions de Web Deploy sur l’ordinateur source

Problème : si vous synchronisez une machine IIS 6.0 avec un grand nombre de sites (ce qui entraîne une taille supérieure à 500 Mo), l’outil peut se bloquer et cesser de répondre.
Solution de contournement :

Créez une liste des sites et synchronisez chaque site individuellement.

Problème : Si vous effectuez une synchronisation entre un ordinateur et un ordinateur distant où le contenu ou la configuration partagée se trouve sur un troisième ordinateur distinct (c’est-à-dire UNC), l’agent distant ne pourra pas s’authentifier correctement.
Solution de contournement :

Synchronisez manuellement ou utilisez le gestionnaire de déploiement web à la place.

Problème : si vous modifiez les paramètres de configuration partagés (par exemple, activer ou désactiver la configuration partagée), vous devez redémarrer l’agent distant par la suite.
Solution de contournement :

Redémarrez l’agent après avoir apporté une modification à la configuration partagée.

Problème : si vous synchronisez un site Web où le chemin d’accès est %systemdrive%\wwwroot vers un site Web de destination où le lecteur système est différent (C : au lieu de D :), le chemin d’accès de votre site web est développé à la destination. Cela signifie que si vous avez partagé des moyens de configuration avec différents lecteurs système et que vous vous appuyez sur le %systemdrive% pour garantir que le contenu fonctionne, vous pouvez interrompre le site sur une machine.
Solution de contournement :

Ajoutez une règle de remplacement pour modifier le chemin d’accès pendant la synchronisation.

Problème : si vous essayez d’empaqueter un fichier de package existant, cela peut ne pas fonctionner correctement.
Solution de contournement :

Utilisez un nouveau nom ou supprimez l’ancien fichier de package avant de créer un nouveau package.

Problème : Microsoft Web Deploy ne déplace pas les fichiers physiques pour les mappages de script et les éléments référencés dans la liste des restrictions d’extension de service web, sauf si les fichiers se trouvent dans les répertoires de contenu d’un site Web. Cela est dû au fait que de nombreux ISAPIs peuvent ne pas migrer correctement, par exemple :

  • ASP.NET (nécessite une installation).
  • WebDAV (qui n’est pas inclus dans Windows Server 2008 par défaut et nécessite une installation supplémentaire).
  • Les extensions serveur FrontPage (qui ne sont pas incluses dans Windows Server 2008 par défaut et nécessitent une installation supplémentaire).

Solution de contournement :

Incluez manuellement les mappages de script ou les fichiers qui ne nécessitent pas d’installation dans un fichier manifeste. Pour plus d’informations sur la création de fichiers manifestes, consultez l’Aide.

Problème : les fichiers d’approbation personnalisés référencés dans les paramètres de stratégie web.config et de sécurité d’accès au code (CAS) au niveau racine ne seront pas déplacés.
Solution de contournement :

Spécifiez manuellement le fichier d’approbation personnalisé et le fichier de stratégie CAS, security.config, dans un fichier manifeste. Pour plus d’informations sur la création de fichiers manifestes, consultez le fichier d’aide.

Problème : Si vous déplacez un site vers un serveur dont le niveau d’approbation est différent, vous ne recevrez pas d’avertissement.
Solution de contournement :

Assurez-vous que le niveau d’approbation est correctement défini sur l’ordinateur de destination lors de la synchronisation ou de la migration au niveau du site.

Problème : si vous disposez d’un fichier manifeste personnalisé qui pointe vers une source non valide, vous risquez de ne pas recevoir d’erreur.
Solution de contournement :

Si vous ne voyez pas la sortie attendue lors de l’utilisation d’un fichier manifeste, essayez chaque élément individuellement pour voir s’ils sont mal typés ou non valides.

Problème : FTP et SMTP ne sont pas inclus dans les définitions par défaut pour webserver60.
Solution de contournement :

Si vous devez synchroniser ces emplacements, synchronisez-les manuellement à l’aide du fournisseur de métakeys, c’est-à-dire metakey=lm/msftpsvc.

Problème : les propriétés héritées ne sont pas migrées avec une migration de site IIS 6.0. Un exemple courant est l’authentification définie au niveau du serveur avec tous les sites qui héritent de cette propriété. Lorsque vous migrez un site unique, il hérite désormais des paramètres du nouveau serveur de destination. Si les paramètres du serveur de destination ne sont pas identiques, votre site peut s’interrompre. Cela s’applique à chaque propriété héritée, y compris les cartes mime, les cartes de script, etc.
Solution de contournement :

Utilisez l’indicateur metadataGetInherited pour copier les paramètres hérités au niveau du site lorsque vous synchronisez ou migrez un site web sur IIS 6.0. Ou vérifiez que les paramètres du serveur sont identiques sur les serveurs source et de destination ou définissez manuellement le site pour qu’il utilise les paramètres appropriés.

Résolution des problèmes d’installation

Si vous rencontrez des problèmes lors de l’installation, vous pouvez exécuter la commande appropriée répertoriée ci-dessous pour votre version de Windows afin de créer un fichier journal contenant des informations sur le processus d’installation :

msiexec /L msdeployinstall.log /I <path_to_msi>

msiexec /L msdeployinstall.log /I <path_to_msi>

Vous pouvez analyser ce fichier journal après une installation ayant échoué pour déterminer la cause de l’échec.

Pour plus d'informations

Les ressources supplémentaires suivantes pour Web Deploy sont disponibles sur IIS.net :