Partager via

Problème PowerShell SQL Server quand RemoteSigned n’est pas défini dans le contrôleur de domaine pour SQL Server

Cet article vous aide à résoudre le problème qui se produit lorsque la stratégie de machine du contrôleur de domaine n’est pas définie sur RemoteSigned by GPO pour SQL Server.

Version du produit d’origine : SQL Server
Numéro de base de connaissances d’origine : 2995870

Symptômes

Lorsque vous ouvrez la console SQL Server PowerShell de Microsoft SQL Server 2012 ou Microsoft SQL Server 2014 et que la stratégie de machine du contrôleur de domaine n’est pas définie sur RemoteSigned by Group Policy Object (GPO), vous pouvez recevoir le message d’erreur suivant :

set-executionpolicy : Windows PowerShell a mis à jour votre stratégie d’exécution avec succès, mais le paramètre est remplacé par une stratégie définie dans une étendue plus spécifique. En raison du remplacement, votre interpréteur de commandes conserve sa stratégie d’exécution effective actuelle de Non restreint. Tapez Get-ExecutionPolicy -List pour afficher les paramètres de votre stratégie d’exécution.
Pour plus d'informations, consultez la rubrique
« Get-Help Set-ExecutionPolicy ».
À la ligne : 1 caractère : 1
+ set-executionpolicy RemoteSigned -scope process -Force

En outre, syspolicy_purge_history le travail échoue à la troisième étape si le contrôleur de domaine n’est pas défini sur RemoteSigned par objet de stratégie de groupe et que vous pouvez recevoir le message d’erreur suivant :

Exécuté en tant qu’utilisateur : AJ\devARsqlagt. Une étape du travail a reçu une erreur à la ligne 1 d’un script PowerShell. La ligne correspondante est « set-executionpolicy RemoteSigned -scope process -Force ». Corrigez le script et replanifiez le travail. Les informations d’erreur retournées par PowerShell sont les suivantes : « Erreur de sécurité. '. Traiter le code de sortie -1. L'étape a échoué.

Cause

Ce problème se produit parce que la stratégie d’ordinateur n’est pas définie sur RemoteSigned par objet de stratégie de groupe et qu’elle est envoyée aux serveurs membres. Par exemple, si la stratégie d’exécution de la configuration du contrôleur de domaine est la suivante :

Scope -                   ExecutionPolicy
--------------------------------------------------------------
MachinePolicy -           Unrestricted
UserPolicy -              Undefined
Process -                 RemoteSigned
CurrentUser -             Undefined
LocalMachine -            RemoteSigned

MachinePolicy est prioritaire sur toutes les autres stratégies.

La stratégie de groupe est envoyée du contrôleur de domaine aux serveurs membres associés à cette stratégie de groupe. Cela définit le MachinePolicy mode Illimité et SQL Server PowerShell tente de s’exécuter avec RemoteSigned la stratégie d’exécution. Par conséquent, une situation conflictuelle se produit et le syspolicy_purge_history travail échoue. Le même travail s’exécute correctement dans SQL Server, quelle que soit la stratégie d’ordinateur dans le contrôleur de domaine.

Solution de contournement

En guise de mesure de sécurité, SQL Server 2012 démarre SQL PowerShell dans la stratégie RemoteSigned. Cela provoque l’échec du travail et le problème précédent se produit.

Non restreint n’est certainement pas recommandé du point de vue de la sécurité, car cela signifie Qu’il ne s’agit pas de restrictions. C’est la raison pour laquelle vous démarrez à partir de SQL 2012, les scripts PowerShell s’exécutent correctement lorsque MachinePolicy est défini comme RemoteSigned dans le contrôleur de domaine.

Pour contourner ce problème, appliquez l’une des méthodes suivantes :

  • Ne définissez pas la stratégie d’ordinateur du contrôleur de domaine par objet de stratégie de groupe. S’il n’est pas défini, cela signifie que la stratégie de niveau suivant (par exemple, UserPolicy, puis Process, CurrentUser et au dernier LocalMachine) est prioritaire.

  • Créez une unité d’organisation dans Utilisateurs et ordinateurs Active Directory et liez cette unité d’organisation à votre stratégie de groupe. Activez-la ensuite pour la stratégie RemoteSigned. Pour ce faire, procédez comme suit :

    1. Accédez à Utilisateurs et ordinateurs Active Directory.

    2. Cliquez avec le bouton droit sur votre domaine ->Nouvelle unité> organisationnelle pour créer une unité d’organisation.

    3. Tapez gpmc.msc dans Exécuter, puis cliquez avec le bouton droit sur Objet de stratégie de groupe ->Nouveau pour créer un objet de stratégie de groupe.

    4. Cliquez avec le bouton droit sur l’objet de stratégie de groupe nouvellement créé ->Modifier. Il ouvre une nouvelle fenêtre.

    5. Accédez à Configuration ordinateur ->Stratégies ->Modèles d’administration ->Composants Windows ->Windows PowerShell -> double-cliquez sur Activer l’exécution du script.

    6. Définissez la stratégie d’exécution pour autoriser les scripts locaux et les scripts signés distants.

    7. Cliquez sur Appliquer, puis sur OK.

    8. Accédez à Utilisateurs et ordinateurs Active Directory, puis cliquez sur Ordinateurs. Vous trouverez la liste des ordinateurs pour le domaine. Cliquez avec le bouton droit sur les ordinateurs que vous souhaitez déplacer dans l’unité organisationnelle nouvellement créée. De cette façon, vous pouvez déplacer un seul ou un groupe d’ordinateurs vers une unité organisationnelle.

    9. Accédez à Gestion des stratégies de groupe, cliquez avec le bouton droit sur l’unité organisationnelle nouvellement créée, cliquez sur Lier un objet de stratégie de groupe existant, sélectionnez l’objet de stratégie de groupe nouvellement créé, puis cliquez sur OK.

    10. Mettez à jour la stratégie sur le contrôleur de domaine et sur l’ordinateur client en exécutant cette commande dans PowerShell.

      gpupdate /force

    11. Vérifiez la stratégie de l’ordinateur pour l’unité organisationnelle et le composant client, elle doit être RemoteSigned.

References

À propos des stratégies d’exécution

  • Last updated on