Microsoft Web Deploy v2 : Lisez-moi

2024-03-25

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 synchroniser entre IIS 6.0 ou IIS 7.0 ou pour migrer d’IIS 6.0 vers IIS 7.0. Les packages créés peuvent être utilisés pour le versionnage, la sauvegarde ou le déploiement.

Notez que IIS 8.0 est pris en charge uniquement avec Web Deploy V3.

Fonctionnalités

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

Empaqueter des sites web et des 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. Désormais, 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 de IIS 6.0. 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.0 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.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 6.0 / IIS 7.0. 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.

Analyse des dépendances sur IIS 6.0 / IIS 7.0. 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.

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é :

https://www.iis.net/download/WebDeploy

Vous devez exécuter le package d’installation en tant qu’administrateur. Pour ce faire, vous pouvez procéder de l’une des façons suivantes :

Connectez-vous à votre serveur à l’aide du compte réel nommé « Administrateur ».
Connectez-vous à l’aide d’un compte avec des privilèges d’administrateur et ouvrez une invite de commandes en faisant un clic droit sur l’élément de menu Invite de commandes situé dans le menu Accessoires pour les programmes Windows et en sélectionnant « Exécuter en tant qu’administrateur », puis en tapant la commande appropriée répertoriée ci-dessous pour que votre version de Windows exécute l’installation :

msiexec /I <path_to_msi>
msiexec /I <path_to_msi>

Remarque importante ! Par défaut, le programme d’installation vous offre le choix d’installer le service distant et utilise une URL de service distant par défaut, http://+:80/MSDEPLOY.

Vous pouvez définir l’URL du service distant sur une URL personnalisée en exécutant la configuration à partir de la ligne de commande : (où le port et l’URL sont spécifiés, personnalisez) :

msiexec /i <path_to_msi> /passive ADDLOCAL=ALL LISTENURL=http://+:8080/MSDEPLOY2/

Problèmes connus

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 2.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 :

N’installez pas Web Deploy 2.0 à l’aide du programme Web Platform Installer. Au lieu de cela, installez-le directement à partir de l’instance MSI et désactivez le composant Configurer pour les déploiements non administrateur
Si vos règles de délégation ont déjà été remplacées, recréez les manuellement.

Problème : le site créé avec le script PowerShell .\SetupSite.ps1 n’est pas accessible

Lorsque ce script crée un site, il tente de l’affecter à un numéro de port compris entre 8000 et 8200, qui n’est pas déjà pris. Il peut s’agir du cas où aucun port libre n’est disponible, auquel cas le port affecté à ce site ne fonctionnera pas. En outre, éventuellement, le port affecté au site peut être bloqué par un pare-feu.

Solutions : affectez manuellement le site à un port différent de l’interface utilisateur du Gestionnaire IIS. Vérifiez également que le port n’est pas bloqué par le pare-feu, par exemple sur Windows Server 2008 R2, exécutez cette commande : « netsh advfirewall firewall add rule name="MySite » dir=in action=allow protocol=TCP localport=8080 », où MySite est remplacé par le nom de votre site.

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 : Web Deploy consomme 100 % de temps processeur pendant quelques minutes

Si le niveau de journalisation est trop élevé, Web Deploy consomme 100 % du processeur lorsqu’une opération de synchronisation est en cours. Cela peut se produire si le niveau de journalisation est défini sur verbose (4) ou informations (3).

Solutions : définissez le niveau de journalisation plus bas :

Démarrez l’éditeur du registre
Accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\2\WMSVCTracing et définissez-le sur 1 ou 2, selon les besoins.
Redémarrez le Service de gestion Web en ouvrant une invite de commandes avec élévation de privilèges et en tapant « net stop wmsvc » suivi de « net start wmsvc »

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 : Web Deploy ne peut pas récupérer le numéro USN à partir du serveur distant

Le commutateur « incrémentiel », lorsqu’il est utilisé avec le fournisseur dirPath, retourne un numéro USN à utiliser avec les prochaines synchronisations pour permettre la synchronisation incrémentielle.
Par exemple : msdeploy -verb:dump -source:dirpath=c:\Temp –incremental
Retourne : c:\Temp
Informations : le numéro USN pour la synchronisation du chemin source « c :\Temp » est « 2140379512 ».
Toutefois, si la source est distante, le numéro USN n’est pas retourné par l’opération. Il s’agit d’une limitation étant donné que Web Deploy v2 ne prend pas en charge la récupération d’un numéro USN à partir d’un serveur distant.

Solution : utilisez un autre outil pour récupérer le numéro USN à partir du serveur distant.

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 :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 :synchronisez manuellement ou utilisez le gestionnaire de déploiement web à la place.

Problème : si vous essayez d’empaqueter ou d’archiver un dossier qui a une boucle d’un certain type (par exemple, vous essayez de créer le package à l’intérieur d’un dossier que vous empaquetez), l’outil peut se bloquer ou planter.
Solution : ne synchronisez pas les dossiers en boucle.

Problème : si vous synchronisez un site web avec plus de 100 sous-répertoires (1\2\3..\100\101), l’outil peut se bloquer.
Solution : ne synchronisez pas les structures de dossiers qui ont une profondeur de 120 sous-répertoires.

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 :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 :ajoutez une règle de remplacement pour modifier le chemin d’accès pendant la synchronisation.

Problème : si vous synchronisez un dossier marqué comme une application dans IIS 6.0 vers une archive ou un package, parfois le contenu ne sera pas collecté automatiquement.
Solution : ajoutez manuellement les dossiers de contenu à un manifeste personnalisé et synchronisez le manifeste. Pour plus d’informations sur la création de fichiers manifestes, consultez l’Aide.

Problème : si vous essayez d’empaqueter un fichier de package existant, cela peut ne pas fonctionner correctement.
Solution : 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 : 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 : 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 : 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 : 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 : 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 : 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 :

Procédures pas à pas pour Web Deploy. Décrit comment télécharger et installer Web Deploy, comment l’utiliser pour les opérations de synchronisation ou de migration, etc.
Veillez également à consulter le blog de l’équipe de déploiement web pour obtenir des conseils, des astuces et des informations les plus récentes sur l’outil.