> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/fr/getting-started/upgrading.md).

# Mise à niveau

## Vue d'ensemble

Ce document couvre le processus de mise à niveau pour les instances PowerShell Universal en production. Nous aborderons les sujets suivants.

1. Sauvegarde des données
2. Processus de mise à niveau
3. Validation de la mise à niveau

Les binaires de l'application Universal peuvent généralement être mis à niveau sans avoir à modifier manuellement la configuration ou la base de données, mais nous recommandons tout de même de sauvegarder les données de production.

## Recommandations

Pour les environnements de production, nous recommandons de déployer PowerShell Universal dans un environnement de staging ou de développement avant les mises à niveau majeures. Cela permet d'effectuer des tests avant que les utilisateurs finaux ne soient affectés. Vous pouvez utiliser les [licences de développement](/powershell-universal/fr/licensing.md#developer-licenses) pour tester les modifications dans des instances PowerShell Universal sans avoir à acheter une licence supplémentaire.

## 1. Sauvegarde des données

PowerShell Universal utilise un système de configuration basé sur des scripts ainsi qu'une base de données utilisée pour la rétention d'entités telles que les jetons d'application, l'historique des tâches et les identités. Dans la mesure du possible, vous devriez sauvegarder ces éléments avant d'exécuter une mise à niveau afin de faciliter la restauration en cas de problème lors de la validation.

### Base de données

La sauvegarde de la base de données garantit que tous les jetons d'application, l'historique des tâches, les identités et les secrets de la base de données sont conservés en cas d'échec de la mise à niveau. Les bases de données SQL peuvent également modifier le schéma de la base de données et peuvent nécessiter une restauration non seulement des données, mais aussi du schéma des tables.

#### SQLite

Par défaut, PowerShell Universal utilise une base de données à fichier unique appelée SQLite. Sauf configuration contraire, la base de données est stockée dans `%ProgramData%\UniversalAutomation`. Vous devriez avoir un fichier `database.db` et éventuellement un fichier `database-log.db`. Ces deux fichiers doivent être sauvegardés. Le service doit être arrêté pour pouvoir sauvegarder les fichiers.

#### SQL

Lorsque vous utilisez SQL pour la persistance, sauvegardez la base de données entière (y compris le schéma). Il n'est pas nécessaire d'arrêter le service PowerShell Universal lors de la sauvegarde de la base de données, mais celui-ci peut continuer à écrire dans la base de données (par exemple lors de l'exécution de tâches planifiées) après la fin de la sauvegarde.

### Scripts de configuration

Les scripts constituent les principales données de configuration à sauvegarder lors de la mise à niveau d'une instance PowerShell Universal en production. Pour la production, nous recommandons d'utiliser un système de contrôle de version. Vous pouvez également tirer parti de l'intégration git intégrée. Si vous utilisez une synchronisation bidirectionnelle pour l'intégration git de PowerShell Universal, envisagez de baliser votre branche git avant la mise à niveau afin de faciliter la restauration en cas de modifications inattendues dans le référentiel git.

## 2. Déroulement de la mise à niveau

Les sections suivantes décrivent les étapes à suivre pour chaque type de mise à niveau système, en fonction de la méthode d'installation initiale de PSU.

### MSI

Lors d'une installation via le MSI, vous devrez suivre les mêmes procédures de sauvegarde décrites ci-dessus.

#### appsettings.json

Vous devrez sauvegarder le fichier `appsettings.json` stocké dans `%ProgramData%\PowerShellUniversal`. Ce fichier contient des informations telles que le port, l'emplacement de stockage des données et d'autres paramètres du serveur. En règle générale, le MSI ne modifie pas ce fichier une fois créé. Il utilisera les paramètres trouvés pour la version mise à niveau. Cela dit, si nécessaire, le MSI apportera des modifications au fichier appsettings. Ces modifications sont considérées comme des ruptures de compatibilité et seront répertoriées dans le journal des modifications de la version.

#### Compte de service

Lors d'une mise à niveau via MSI, le service PSU n'est pas désinstallé ; par conséquent, le compte de service sera toujours configuré une fois le service démarré.

{% hint style="info" %}
Si vous effectuez une désinstallation puis une installation à l'aide du MSI, le compte de service sera supprimé.
{% endhint %}

#### Processus de mise à niveau

Une fois que tous les fichiers de configuration et la base de données ont été sauvegardés, vous pouvez exécuter le nouveau programme d'installation MSI.

Le programme d'installation peut demander un redémarrage de la machine si des fichiers sont verrouillés. Le MSI PSU désinstallera tous les fichiers du répertoire d'installation et installera des fichiers entièrement nouveaux.

Une fois le MSI terminé, vous pouvez accéder à votre console d'administration PowerShell Universal pour effectuer la validation de l'installation.

### IIS

Vous trouverez ci-dessous des informations sur la mise à niveau d'une installation IIS.

#### web.config

En plus des fichiers listés à sauvegarder ci-dessus, vous devrez également envisager de sauvegarder votre fichier `web.config`. Si vous n'avez apporté aucune modification à ce fichier, il n'est pas nécessaire de le sauvegarder.

Le fichier `web.config` inclus dans le répertoire d'installation de l'application sera écrasé lors des mises à niveau. Si vous avez déplacé votre fichier web.config vers un autre emplacement, il ne sera pas écrasé. Lors de la création d'un site web IIS, vous pouvez simplement inclure le fichier `web.config` dans le répertoire de l'application web et conserver les [binaires dans un emplacement différent](/powershell-universal/fr/config/hosting/hosting-iis.md).

#### Processus de mise à niveau

Lors d'une mise à niveau avec IIS, vous devrez d'abord arrêter votre pool d'applications pour vous assurer que les binaires utilisés par IIS ne sont plus utilisés, puis remplacer les binaires par les nouveaux. Pour vous assurer que la mise à niveau fonctionne correctement, il est recommandé de supprimer tous les fichiers de l'application, puis de décompresser les nouveaux dans le même répertoire afin d'éviter les conflits d'assemblages.

{% hint style="info" %}
Comme pour toute installation à partir d'un fichier ZIP, assurez-vous d'exécuter `Get-ChildItem -Recurse | Unblock-File` depuis une invite de commandes avec élévation de privilèges sur les fichiers PowerShell Universal pour vous assurer qu'ils peuvent être exécutés correctement.
{% endhint %}

Une fois que vous avez copié les nouveaux fichiers et les avez débloqués, démarrez le pool d'applications, accédez à la console d'administration PowerShell Universal et effectuez la validation de l'installation.

### Module Universal

Le module Universal peut être utilisé pour mettre à niveau les installations de PowerShell Universal précédemment installées par le module.

{% hint style="warning" %}
N'utilisez pas le module Universal pour mettre à niveau des instances installées via MSI.
{% endhint %}

Suivez les procédures de sauvegarde ci-dessus, puis effectuez la mise à niveau.

Commencez par mettre à niveau le module PowerShell Universal local et vérifiez que la version attendue est installée.

```powershell
Update-Module Devolutions.PowerShellUniversal
Import-Module Devolutions.PowerShellUniversal -PassThru
```

Ensuite, exécutez `Update-PSUServer` pour télécharger et décompresser la nouvelle instance PSU.

```powershell
Update-PSUServer
```

Une fois la mise à niveau terminée, accédez à la console d'administration PowerShell Universal et commencez la validation de la mise à niveau.

### ZIP

Effectuez les procédures de sauvegarde nécessaires et téléchargez le dernier fichier ZIP de PowerShell Universal.

Arrêtez le service PowerShell Universal. Supprimez les fichiers d'application PowerShell Universal existants. Extrayez les fichiers ZIP dans le même répertoire. Enfin, exécutez `Unblock-File` sur le répertoire pour vous assurer que PSU peut s'exécuter correctement. Exécutez toujours cette commande en tant qu'administrateur.

```powershell
Get-ChildItem -Recurse | Unblock-File
```

Une fois la mise à niveau terminée, accédez à la console d'administration PowerShell Universal et commencez la validation de la mise à niveau.

### Base de données

Par défaut, le service PSU migre vers la dernière version de la base de données lors du démarrage.

La base de données peut également être mise à niveau avant la mise à niveau de l'application. Cela est recommandé pour les installations plus importantes qui peuvent nécessiter un certain temps pour effectuer la mise à jour du schéma. Dans certains environnements, laisser le service mettre à niveau la base de données peut entraîner un délai d'expiration, comme avec le Gestionnaire de contrôle des services sous Windows.

Si vous utilisez SQL, vous trouverez des fichiers SQL générés et placés dans le dossier SQL du support d'installation PSU. Exécutez ces scripts sur votre base de données avant la mise à niveau.

Tous les types de bases de données prennent en charge l'outil en ligne de commande `psu` pour les mises à niveau.

```powershell
psu db schema latest --connection-string "Data Source=C:\ProgramData\UniversalAutomation\database.db"
```

## 3. Validation de la mise à niveau

Après avoir effectué une mise à niveau, vous devriez effectuer une validation de base de votre serveur PSU pour vous assurer qu'il est pleinement fonctionnel.

### Notifications

Vérifiez qu'il n'y a aucune erreur dans le menu déroulant des notifications. Celles-ci peuvent être le signe de problèmes survenus lors de la mise à niveau.

### Modules

Les mises à niveau de PowerShell Universal peuvent modifier les versions des assemblages des DLL fournies avec la plateforme. Cela peut entraîner l'échec du chargement d'autres modules. Bien que cela ne soit pas toujours évident au premier abord, vous pouvez envisager de faire un inventaire des modules utilisés dans votre plateforme pour vous assurer que les versions sont cohérentes avant et après la mise à niveau afin de limiter les changements.

Si vous avez installé une version du module `Universal` en dehors de PowerShell Universal (par exemple avec `Install-Module`), vous devez vous assurer de mettre à jour le module, sinon il peut entrer en conflit avec le nouveau installé avec PowerShell Universal.

### Applications

Les problèmes de mise à niveau les plus courants sont liés aux modifications apportées au framework Universal App. Les applications peuvent être complexes et les corrections de bogues ou les nouvelles fonctionnalités peuvent parfois provoquer des problèmes pour l'application d'un utilisateur tout en corrigeant des problèmes liés à l'application d'un autre utilisateur. Veuillez lire le journal des modifications avant la mise à niveau pour comprendre l'impact des modifications apportées au framework d'application et envisagez de tester l'application avec des données de développement avant de mettre à niveau en production.

## Problèmes courants lors de la mise à niveau

### Le pool d'applications IIS ne démarre pas après la mise à niveau

Le problème de mise à niveau le plus courant est que `Unblock-File` n'est pas appelé correctement sur les fichiers extraits lors d'une mise à niveau d'une installation IIS via ZIP. Assurez-vous également d'exécuter la commande `Unblock-File` de manière récursive et depuis une session administrateur.

Un autre problème courant est l'extraction des fichiers par-dessus les fichiers existants. Cela peut provoquer des conflits d'assemblages et mettre l'application dans un état indéfini. Suivez la documentation de mise à niveau IIS et supprimez les fichiers avant de les extraire.

### Erreurs de commande introuvable

Lorsque de nouvelles fonctionnalités sont ajoutées à PowerShell Universal, elles sont généralement implémentées via de nouvelles cmdlets. Si des versions plus anciennes du module PowerShell Universal sont installées sur le système, elles peuvent entrer en conflit avec celle fournie dans le support d'installation. Assurez-vous d'avoir supprimé les versions plus anciennes du module `Universal` si vous rencontrez ces erreurs.

### Erreur de table/colonne introuvable lors de l'utilisation de la persistance SQL

Cela peut se produire si les mises à niveau du schéma SQL ne sont pas exécutées lors des mises à niveau. Si vous avez défini le paramètre `RunMigrations` sur `false` dans `appsettings.json`, vous devez exécuter les migrations manuellement, sinon le service PowerShell Universal ne fonctionnera pas correctement.

### Modification de composant d'application avec rupture de compatibilité

Ces modifications peuvent être visuelles ou fonctionnelles. Assurez-vous de consulter le journal des modifications pour les éléments pouvant être liés à la modification que vous observez. Envisagez de publier sur les forums ou d'ouvrir un ticket GitHub pour vérifier si le problème est intentionnel et s'il existe une solution de contournement viable.

{% hint style="info" %}
Nous faisons de notre mieux pour prendre en charge les applications de tous sans apporter de modifications avec rupture de compatibilité. Cela dit, chaque configuration est assez unique, et nous sommes plus que disposés à résoudre les problèmes que vous pourriez rencontrer. N'hésitez pas à nous en faire part.
{% endhint %}

### Problèmes de licence après la mise à niveau

Le modèle de licence de PowerShell Universal permet aux utilisateurs sous licence de mettre à niveau vers la dernière version disponible tant qu'ils disposent d'une licence perpétuelle ou d'abonnement active. Si vous tentez de mettre à niveau un serveur dont la fenêtre de licence est expirée, le serveur ne fonctionnera pas comme prévu. Vous devrez revenir à la version précédente pour restaurer la fonctionnalité.

De plus, vous pouvez rencontrer des problèmes en raison du redémarrage du service PSU. Au démarrage, le service vérifie le statut de l'abonnement à la licence. En cas d'échec, la licence peut ne pas être correctement activée, ce qui peut entraîner d'autres problèmes. La cause principale est généralement des problèmes réseau lors de la tentative d'accès au site web IronmanSoftware.com pour l'activation. Les clés de licence hors ligne ne contactent pas le site web IMS pour l'activation et ne rencontreront pas ce problème.

### Versions mixtes

Le mélange de versions de serveurs PowerShell Universal utilisant la même base de données peut causer des problèmes, car les modifications de schéma de la base de données ou les modifications de protocole dans les API internes peuvent ne pas correspondre. Nous recommandons de planifier vos mises à niveau de manière à ce que tous les serveurs PowerShell Universal fonctionnent éventuellement avec la même version.

{% hint style="warning" %}
Il existe un problème de compatibilité connu entre PSU 5.5.4 et versions antérieures et PSU 5.6.0 et versions ultérieures. Nous ne recommandons pas de mélanger ces versions. La planification des tâches peut échouer sur les serveurs 5.5.4 existants lorsqu'ils sont combinés avec des serveurs 5.6.0.
{% endhint %}

## Modifications avec rupture de compatibilité de la version 5.0

### Suppression des pages

Le concepteur de pages par glisser-déposer a été supprimé au profit des [pages de portail](/powershell-universal/fr/portail/portal-pages.md) et des [widgets](/powershell-universal/fr/portail/portal-widgets.md).

### Suppression du concepteur de pages d'application

Le concepteur de pages par glisser-déposer pour les applications a été supprimé. Les applications créées avec le concepteur continueront de fonctionner.

### Suppression des contrôles d'accès

Les contrôles d'accès ont été supprimés au profit des [autorisations](/powershell-universal/fr/securite/enterprise-security/permissions.md). Vous pouvez également utiliser le [portail](https://github.com/Devolutions/doc-gitbook/blob/master/translations/fr/powershell-universal/getting-started/broken-reference/README.md) pour attribuer des ressources, comme des scripts, aux utilisateurs sans avoir besoin de configurations d'autorisations complexes.

### Modifications du canal de communication des cmdlets et de l'autorisation

Avant la version 5, les cmdlets envoyaient des données via HTTP ou en utilisant un canal gRPC interne. Désormais, toutes les cmdlets utilisent un canal gRPC externe protégé par l'authentification et l'autorisation. Il n'utilise plus les appels HTTP REST standard.

Cela peut poser problème pour les instances PowerShell Universal derrière des [proxies inverses](/powershell-universal/fr/config/hosting/reverse-proxy.md) et requiert que les valeurs d'en-tête appropriées soient envoyées.

Veuillez consulter la documentation du [module](/powershell-universal/fr/config/module.md) pour plus d'informations.

#### Erreurs courantes de cmdlets que vous pouvez rencontrer lors de la mise à niveau

#### Code de statut HTTP 403

La cmdlet que vous appelez n'a pas accès aux API PowerShell Universal. Vous devrez spécifier un paramètre -AppToken sur les cmdlets pour pouvoir les utiliser.

Vous pouvez également activer le [modèle de sécurité API permissif](/powershell-universal/fr/config/module.md#authorization-security-model) pour autoriser les cmdlets appelées en interne depuis PowerShell Universal sans avoir besoin d'autorisation.

#### URI non défini

Les cmdlets ne parviennent pas à déterminer comment appeler les API PowerShell Universal. Vous devrez soit spécifier un paramètre -ComputerName, soit configurer l'URL de l'API dans appsettings.json.

```json
{
   "API" : {
      "URL": "http://localhost:5000"
   }
}
```

#### Erreur de certificat SSL

Si vous utilisez un certificat auto-signé, vous devrez spécifier le paramètre `-TrustCertificate` des cmdlets.

### L'environnement PowerShell 7 n'utilise plus Pwsh.exe

L'environnement PowerShell 7 par défaut utilise une version .NET de l'exécutable Universal.Agent.exe exécutant PowerShell 7.5. Cela permet une compatibilité maximale avec les bibliothèques PowerShell Universal et d'autres modules.

Il est toujours possible d'utiliser le processus pwsh.exe dans des configurations d'environnement personnalisées.

### Package d'hébergement IIS

Si vous hébergez dans IIS, assurez-vous d'installer le [bundle d'hébergement .NET 9.0](https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-aspnetcore-9.0.4-windows-hosting-bundle-installer).

### Version PowerShell de l'environnement intégré

L'environnement intégré utilise désormais PowerShell 7.5.

### SQLite par défaut

SQLite est la méthode de persistance par défaut. Vous devrez effectuer une conversion manuelle depuis LiteDB avant d'installer la version 5.

### Prise en charge de LiteDB supprimée

LiteDB a été supprimé en tant que moteur de base de données pris en charge. Les fichiers d'installation de PowerShell Universal incluent `psu.exe`, qui peut être utilisé pour convertir une base de données LiteDB en base de données SQLite. Utilisez la ligne de commande suivante.

```powershell
.\psu.exe db convert --Path "$ENV:ProgramData\UniversalAutomation\database.db"
```

L'outil créera un fichier `database.bak` avant d'effectuer la conversion. La progression sera affichée dans la console.

Après la conversion de la base de données, vous devrez mettre à jour le fichier `appsettings.json` pour utiliser le nouveau plugin SQLite et mettre à jour la chaîne de connexion au format SQLite. Voici un extrait que vous pouvez utiliser pour appliquer à votre fichier de configuration.

```json
{
    "Plugins": [
        "SQLite"
    ],
    "Data": {
        "ConnectionString": "Data Source=C:\ProgramData\UniversalAutomation\database.db"
    }
}
```

#### Conversion d'une base de données pour une mise à niveau via MSI

Pour que le programme d'installation de PowerShell Universal s'exécute correctement, vous devrez mettre à jour la base de données avant d'exécuter le programme d'installation MSI. Voici les étapes à suivre.

1. Téléchargez le package ZIP pour Windows et extrayez-le dans un répertoire local.
2. Arrêtez le service PowerShell Universal.
3. Exécutez la commande psudb.exe depuis le répertoire ZIP, comme indiqué ci-dessus, pour convertir le fichier de base de données dans %ProgramData%\UniversalAutomation.
4. Mettez à jour le fichier %ProgramData%\PowerShellUniversal\appsettings.json pour utiliser le plugin SQLite plutôt que le plugin LiteDB.
5. Exécutez le programme d'installation de PowerShell Universal v5 pour mettre à niveau les fichiers de l'application.

### Mode bureau supprimé

Le mode bureau a été supprimé. Les ressources telles que les raccourcis clavier, les associations de fichiers et les raccourcis ne sont plus prises en charge. Le MSI prend désormais en charge les installations en portée utilisateur qui s'exécuteront en tant qu'utilisateur actuel et démarreront lors de la connexion.

### Install-PSUServer sous Windows installe à partir du MSI

Dans les versions précédentes de PowerShell Universal, cette commande installait dans un répertoire et créait le service manuellement. Cette commande installe désormais à partir du MSI. Si vous avez précédemment installé avec ce module, vous devez supprimer l'installation existante avec une version précédente du module, puis installer avec la nouvelle version du module.

```powershell
Install-Module Universal -RequiredVersion 4.4.0
Remove-PSUServer
```

Ouvrez une nouvelle invite de commandes et exécutez ce qui suit.

```powershell
Uninstall-Module Devolutions.PowerShellUniversal
Install-Module Devolutions.PowerShellUniversal
Install-PSUServer
```

### Stockage de la base de données Git supprimé

PowerShell Universal ne prend plus en charge le stockage du référentiel git directement dans la base de données. Nous recommandons d'utiliser un fournisseur git distant tel que GitHub, GitLab ou Gitea. PowerShell Universal v5 prend en charge les référentiels git locaux sans avoir besoin de synchronisation avec un dépôt distant. Cela permet de stocker l'historique des fichiers directement sur le serveur PowerShell Universal.

### Suppression de la carte de chaleur et du regroupement de marqueurs dans New-UDMap

Les cartes ne prennent plus en charge les cartes de chaleur ni les regroupements de marqueurs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.devolutions.net/powershell-universal/fr/getting-started/upgrading.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
