PowerShell: Exécution d'une commande en tant qu'administrateur
Vous savez que si vous êtes l'administrateur d'un système et que vous pouvez simplement cliquer avec le bouton droit de la souris sur un script batch et l'exécuter en tant qu'administrateur sans entrer le mot de passe de l'administrateur?
Je me demande comment faire cela avec un script PowerShell. Je ne veux pas avoir à entrer mon mot de passe Je veux juste imiter le clic droit Exécuter en tant qu'administrateur méthode.
Tout ce que j'ai lu jusqu'à présent nécessite que vous fournissiez le mot de passe de l'administrateur.
Si la console actuelle n'est pas élevée et que l'opération que vous essayez d'exécuter nécessite des privilèges élevés, vous pouvez démarrer PowerShell avec l'option "Exécuter en tant qu'administrateur"
PS> Start-Process powershell -Verb runAs
Voici un ajout à la suggestion de Shay Levi (ajoutez simplement ces lignes au début du script):
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
$arguments = "& '" + $myinvocation.mycommand.definition + "'"
Start-Process powershell -Verb runAs -ArgumentList $arguments
Break
}
Ainsi, le script en cours est transmis à un nouveau processus powershell en mode administrateur (si l'utilisateur actuel a accès au mode administrateur et que le script n'est pas lancé en tant qu'administrateur).
Script PowerShell à élévation automatique
Windows 8.1/PowerShell 4.0 +
Une ligne :)
if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs; exit }
# Your script here
Benjamin Armstrong a publié un excellent article sur les scripts PowerShell à auto-élévation }. Il y a quelques problèmes mineurs avec son code; une version modifiée basée sur les corrections suggérées dans le commentaire est ci-dessous.
Fondamentalement, il obtient l'identité associée au processus actuel, vérifie s'il s'agit d'un administrateur et, dans le cas contraire, crée un nouveau processus PowerShell avec des privilèges d'administrateur et met fin à l'ancien processus.
# Get the ID and security principal of the current user account
$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent();
$myWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($myWindowsID);
# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator;
# Check to see if we are currently running as an administrator
if ($myWindowsPrincipal.IsInRole($adminRole))
{
# We are running as an administrator, so change the title and background colour to indicate this
$Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)";
$Host.UI.RawUI.BackgroundColor = "DarkBlue";
Clear-Host;
}
else {
# We are not running as an administrator, so relaunch as administrator
# Create a new process object that starts PowerShell
$newProcess = New-Object System.Diagnostics.ProcessStartInfo "PowerShell";
# Specify the current script path and name as a parameter with added scope and support for scripts with spaces in it's path
$newProcess.Arguments = "& '" + $script:MyInvocation.MyCommand.Path + "'"
# Indicate that the process should be elevated
$newProcess.Verb = "runas";
# Start the new process
[System.Diagnostics.Process]::Start($newProcess);
# Exit from the current, unelevated, process
Exit;
}
# Run your code that needs to be elevated here...
Write-Host -NoNewLine "Press any key to continue...";
$null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown");
Vous pouvez créer un fichier de commandes (*.bat) qui exécute votre script Powershell avec des privilèges administratifs lorsque vous double-cliquez dessus. De cette façon, vous (n'avez rien à modifier) dans votre script powershell. Pour ce faire, créez un fichier de commandes portant le même nom et le même emplacement que votre script PowerShell, puis insérez le contenu suivant:
@echo off
set scriptFileName=%~n0
set scriptFolderPath=%~dp0
set powershellScriptFileName=%scriptFileName%.ps1
powershell -Command "Start-Process powershell \"-ExecutionPolicy Bypass -NoProfile -NoExit -Command `\"cd \`\"%scriptFolderPath%\`\"; & \`\".\%powershellScriptFileName%\`\"`\"\" -Verb RunAs"
C'est tout!
Voici l'explication:
En supposant que votre script powershell se trouve dans le chemin C:\Temp\ScriptTest.ps1, votre fichier de commandes doit avoir le chemin C:\Temp\ScriptTest.bat. Lorsque quelqu'un exécute ce fichier de commandes, les étapes suivantes seront effectuées:
La cmd exécutera la commande
powershell -Command "Start-Process powershell \"-ExecutionPolicy Bypass -NoProfile -NoExit -Command `\"cd \`\"C:\Temp\`\"; & \`\".\ScriptTest.ps1\`\"`\"\" -Verb RunAs"Une nouvelle session powershell s'ouvrira et la commande suivante sera exécutée:
Start-Process powershell "-ExecutionPolicy Bypass -NoProfile -NoExit -Command `"cd \`"C:\Temp\`"; & \`".\ScriptTest.ps1\`"`"" -Verb RunAsUne autre nouvelle session PowerShell avec des privilèges d’administration s’ouvrira dans le dossier
system32et les arguments suivants lui seront transmis:-ExecutionPolicy Bypass -NoProfile -NoExit -Command "cd \"C:\Temp\"; & \".\ScriptTest.ps1\""La commande suivante sera exécutée avec les privilèges d'administrateur:
cd "C:\Temp"; & ".\ScriptTest.ps1"Une fois que les arguments de chemin et de nom de script ont été mis entre guillemets, ils peuvent contenir des caractères espace ou guillemets simples (
').Le dossier actuel passera de
system32àC:\Tempet le scriptScriptTest.ps1sera exécuté. Une fois que le paramètre-NoExita été passé, la fenêtre ne sera plus fermée, même si votre script powershell lève une exception.
Vous pouvez facilement ajouter des entrées de registre pour obtenir un menu contextuel "Exécuter en tant qu'administrateur" pour les fichiers .ps1:
New-Item -Path "Registry::HKEY_CLASSES_ROOT\Microsoft.PowershellScript.1\Shell\runas\command" `
-Force -Name '' -Value '"c:\windows\system32\windowspowershell\v1.0\powershell.exe" -noexit "%1"'
(mis à jour vers un script plus simple de @Shay)
Fondamentalement, à HKCR:\Microsoft.PowershellScript.1\Shell\runas\command, définissez la valeur par défaut pour appeler le script à l'aide de Powershell.
En utilisant
#Requires -RunAsAdministrator
n'a pas encore été précisé. Il semble être là seulement depuis PowerShell 4.0.
http://technet.Microsoft.com/en-us/library/hh847765.aspx
Lorsque ce paramètre de commutateur est ajouté à votre instruction require, il spécifie que la session Windows PowerShell dans laquelle vous vous trouvez L'exécution du script doit être démarrée avec des droits d'utilisateur élevés (Exécuter en tant qu'administrateur).
Pour moi, cela semble être un bon moyen de s'y prendre, mais je ne suis pas encore sûr de l'expérience sur le terrain. Les exécutions de PowerShell 3.0 ignorent probablement ceci, ou pire encore, donnent une erreur.
Lorsque le script est exécuté en tant que non-administrateur, l'erreur suivante est générée:
Le script 'StackOverflow.ps1' ne peut pas être exécuté car il contient un "# nécessite" l'instruction pour l'exécution en tant qu'administrateur. Le courant La session Windows PowerShell ne s'exécute pas en tant qu'administrateur. Début Windows PowerShell en utilisant l'option Exécuter en tant qu'administrateur, puis essayez de relancer le script.
+ CategoryInfo : PermissionDenied: (StackOverflow.ps1:String) [], ParentContainsErrorRecordException + FullyQualifiedErrorId : ScriptRequiresElevation
Le code posté par Jonathan et Shay Levy ne fonctionnait pas pour moi.
Veuillez trouver le code de travail ci-dessous:
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
#"No Administrative rights, it will display a popup window asking user for Admin rights"
$arguments = "& '" + $myinvocation.mycommand.definition + "'"
Start-Process "$psHome\powershell.exe" -Verb runAs -ArgumentList $arguments
break
}
#"After user clicked Yes on the popup, your file will be reopened with Admin rights"
#"Put your code here"
Vous devez réexécuter le script avec les privilèges d'administrateur et vérifier si le script a été lancé dans ce mode. J'ai écrit ci-dessous un script qui remplit deux fonctions: DoElevatedOperations et DoStandardOperations . Vous devez placer votre code qui requiert des droits d’administrateur dans le premier et des opérations standard dans le second. La variable IsRunAsAdmin est utilisée pour identifier le mode admin.
Mon code est un extrait simplifié du script Microsoft généré automatiquement lorsque vous créez un package d'applications pour les applications du Windows Store.
param(
[switch]$IsRunAsAdmin = $false
)
# Get our script path
$ScriptPath = (Get-Variable MyInvocation).Value.MyCommand.Path
#
# Launches an elevated process running the current script to perform tasks
# that require administrative privileges. This function waits until the
# elevated process terminates.
#
function LaunchElevated
{
# Set up command line arguments to the elevated process
$RelaunchArgs = '-ExecutionPolicy Unrestricted -file "' + $ScriptPath + '" -IsRunAsAdmin'
# Launch the process and wait for it to finish
try
{
$AdminProcess = Start-Process "$PsHome\PowerShell.exe" -Verb RunAs -ArgumentList $RelaunchArgs -PassThru
}
catch
{
$Error[0] # Dump details about the last error
exit 1
}
# Wait until the elevated process terminates
while (!($AdminProcess.HasExited))
{
Start-Sleep -Seconds 2
}
}
function DoElevatedOperations
{
Write-Host "Do elevated operations"
}
function DoStandardOperations
{
Write-Host "Do standard operations"
LaunchElevated
}
#
# Main script entry point
#
if ($IsRunAsAdmin)
{
DoElevatedOperations
}
else
{
DoStandardOperations
}
C:\Users\"username"\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell est l'endroit où réside le raccourci de PowerShell. Il reste également dans un emplacement différent pour invoquer le "exe" (%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe).
Dans la mesure où PowerShell est géré par le profil de l'utilisateur lorsque les autorisations sont concernées. Si votre nom d'utilisateur/profil dispose des autorisations nécessaires pour effectuer certaines tâches, vous pourrez généralement le faire également dans PowerShell. Cela étant dit, il serait logique de modifier le raccourci situé sous votre profil d'utilisateur, par exemple, C:\Users\"username"\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell.
Cliquez avec le bouton droit et sélectionnez Propriétés. Cliquez sur le bouton "Avancé" sous l'onglet "Raccourci" situé juste en dessous du champ de texte "Commentaires" adjacent à la droite de deux autres boutons, "Emplacement du fichier ouvert" et "Icône de changement", respectivement.
Cochez la case "Exécuter en tant qu'administrateur". Cliquez sur OK, puis Apply et OK. Cliquez à nouveau avec le bouton droit de la souris sur l'icône "Windows PowerShell" située dans C:\Users\"username"\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell et sélectionnez "Épingler au menu Démarrer/barre des tâches".
Désormais, chaque fois que vous cliquerez sur cette icône, le programme UAC sera escaladé. Après avoir sélectionné "OUI", vous remarquerez que la console PowerShell est ouverte et qu’elle sera étiquetée "Administrateur" en haut de l’écran.
Pour aller plus loin ... vous pouvez cliquer avec le bouton droit sur le même raccourci d'icône dans l'emplacement de votre profil de Windows PowerShell et attribuer un raccourci clavier qui fera exactement la même chose que si vous avez cliqué sur l'icône récemment ajoutée. Donc, là où il est écrit "Touche de raccourci", mettez une combinaison de touches/boutons du clavier comme: Ctrl + Alt + PP (pour PowerShell) . Cliquez sur Apply et OK.
Il ne vous reste plus qu'à appuyer sur la combinaison de boutons que vous avez attribuée et vous verrez UAC être invoqué. Après avoir sélectionné "OUI", une console PowerShell apparaît et "Administrateur" apparaît dans la barre de titre.
Vous pouvez également forcer l'application à s'ouvrir en tant qu'administrateur. Si vous avez un compte administrateur bien sûr.
Localisez le fichier, faites un clic droit> propriétés> raccourci> avancé et cochez Exécuter en tant qu'administrateur
Puis cliquez sur OK.
Ajout de mes 2 cents. Ma version simple basée sur la session réseau qui fonctionne tout le temps jusqu’à présent dans Windows 7/Windows 10. Pourquoi la compliquer?
if (!(net session)) {$path = "& '" + $myinvocation.mycommand.definition + "'" ; Start-Process powershell -Verb runAs -ArgumentList $path ; exit}
ajoutez simplement en haut du script et il fonctionnera en tant qu'administrateur.
Un certain nombre de réponses sont proches, mais un peu plus de travail que nécessaire.
Créez un raccourci vers votre script et configurez-le pour "Exécuter en tant qu'administrateur":
- Créez le raccourci.
- Cliquez avec le bouton droit sur le raccourci et ouvrez
Properties... - Editez
Targetde<script-path>àpowershell <script-path> - Cliquez sur Advanced... et activer
Run as administrator
Ce comportement est voulu. Il existe plusieurs couches de sécurité, car Microsoft ne souhaitait vraiment pas que les fichiers .ps1 soient le dernier virus de messagerie. Certaines personnes trouvent que cela va à l’encontre de la notion même d’automatisation des tâches, qui est juste. Le modèle de sécurité de Vista + consiste à "désautomatiser" des éléments, ce qui permet à l'utilisateur de les accepter.
Cependant, je soupçonne que si vous lancez powershell lui-même en tant qu’élévé, il devrait pouvoir exécuter des fichiers de traitement par lots sans demander à nouveau le mot de passe jusqu’à la fermeture de powershell.
J'utilise la solution ci-dessous. Il gère stdout/stderr via la fonctionnalité de transcription et transmet correctement le code de sortie au processus parent. Vous devez ajuster le chemin de la transcription/le nom du fichier.
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
echo "* Respawning PowerShell child process with elevated privileges"
$pinfo = New-Object System.Diagnostics.ProcessStartInfo
$pinfo.FileName = "powershell"
$pinfo.Arguments = "& '" + $myinvocation.mycommand.definition + "'"
$pinfo.Verb = "RunAs"
$pinfo.RedirectStandardError = $false
$pinfo.RedirectStandardOutput = $false
$pinfo.UseShellExecute = $true
$p = New-Object System.Diagnostics.Process
$p.StartInfo = $pinfo
$p.Start() | Out-Null
$p.WaitForExit()
echo "* Child process finished"
type "C:/jenkins/transcript.txt"
Remove-Item "C:/jenkins/transcript.txt"
Exit $p.ExitCode
} Else {
echo "Child process starting with admin privileges"
Start-Transcript -Path "C:/jenkins/transcript.txt"
}
# Rest of your script goes here, it will be executed with elevated privileges
Le problème avec les réponses de @pgk et @Andrew Odri est lorsque vous avez des paramètres de script, en particulier lorsqu'ils sont obligatoires. Vous pouvez résoudre ce problème en utilisant l’approche suivante:
- L'utilisateur clique avec le bouton droit sur le fichier .ps1 et sélectionne «Exécuter avec PowerShell»: demandez-lui les paramètres via des zones de saisie (il s'agit d'une bien meilleure option que l'attribut de paramètre HelpMessage);
- L'utilisateur exécute le script via la console: lui permettre de transmettre les paramètres souhaités et de laisser la console le forcer à informer les paramètres obligatoires.
Voici comment serait le code si le script avait les paramètres obligatoires NomOrdinateur et Port:
[CmdletBinding(DefaultParametersetName='RunWithPowerShellContextMenu')]
param (
[parameter(ParameterSetName='CallFromCommandLine')]
[switch] $CallFromCommandLine,
[parameter(Mandatory=$false, ParameterSetName='RunWithPowerShellContextMenu')]
[parameter(Mandatory=$true, ParameterSetName='CallFromCommandLine')]
[string] $ComputerName,
[parameter(Mandatory=$false, ParameterSetName='RunWithPowerShellContextMenu')]
[parameter(Mandatory=$true, ParameterSetName='CallFromCommandLine')]
[UInt16] $Port
)
function Assert-AdministrativePrivileges([bool] $CalledFromRunWithPowerShellMenu)
{
$isAdministrator = ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if ($isAdministrator)
{
if (!$CalledFromRunWithPowerShellMenu -and !$CallFromCommandLine)
{
# Must call itself asking for obligatory parameters
& "$PSCommandPath" @script:PSBoundParameters -CallFromCommandLine
Exit
}
}
else
{
if (!$CalledFromRunWithPowerShellMenu -and !$CallFromCommandLine)
{
$serializedParams = [Management.Automation.PSSerializer]::Serialize($script:PSBoundParameters)
$scriptStr = @"
`$serializedParams = '$($serializedParams -replace "'", "''")'
`$params = [Management.Automation.PSSerializer]::Deserialize(`$serializedParams)
& "$PSCommandPath" @params -CallFromCommandLine
"@
$scriptBytes = [System.Text.Encoding]::Unicode.GetBytes($scriptStr)
$encodedCommand = [Convert]::ToBase64String($scriptBytes)
# If this script is called from another one, the execution flow must wait for this script to finish.
Start-Process -FilePath 'powershell' -ArgumentList "-ExecutionPolicy Bypass -NoProfile -EncodedCommand $encodedCommand" -Verb 'RunAs' -Wait
}
else
{
# When you use the "Run with PowerShell" feature, the Windows PowerShell console window appears only briefly.
# The NoExit option makes the window stay visible, so the user can see the script result.
Start-Process -FilePath 'powershell' -ArgumentList "-ExecutionPolicy Bypass -NoProfile -NoExit -File ""$PSCommandPath""" -Verb 'RunAs'
}
Exit
}
}
function Get-UserParameters()
{
[string] $script:ComputerName = [Microsoft.VisualBasic.Interaction]::InputBox('Enter a computer name:', 'Testing Network Connection')
if ($script:ComputerName -eq '')
{
throw 'The computer name is required.'
}
[string] $inputPort = [Microsoft.VisualBasic.Interaction]::InputBox('Enter a TCP port:', 'Testing Network Connection')
if ($inputPort -ne '')
{
if (-not [UInt16]::TryParse($inputPort, [ref]$script:Port))
{
throw "The value '$inputPort' is invalid for a port number."
}
}
else
{
throw 'The TCP port is required.'
}
}
# $MyInvocation.Line is empty in the second script execution, when a new powershell session
# is started for this script via Start-Process with the -File option.
$calledFromRunWithPowerShellMenu = $MyInvocation.Line -eq '' -or $MyInvocation.Line.StartsWith('if((Get-ExecutionPolicy')
Assert-AdministrativePrivileges $calledFromRunWithPowerShellMenu
# Necessary for InputBox
[System.Reflection.Assembly]::Load('Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a') | Out-Null
if ($calledFromRunWithPowerShellMenu)
{
Get-UserParameters
}
# ... script code
Test-NetConnection -ComputerName $ComputerName -Port $Port
Voici un extrait auto-élévateur pour les scripts Powershell qui conserve le répertoire de travail :
if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
Start-Process PowerShell -Verb RunAs "-NoProfile -ExecutionPolicy Bypass -Command `"cd '$pwd'; & '$PSCommandPath';`"";
exit;
}
# Your script here
La préservation du répertoire de travail est importante pour les scripts effectuant des opérations relatives au chemin. Presque toutes les autres réponses ne conservent pas ce chemin, ce qui peut provoquer des erreurs inattendues dans le reste du script.
Si vous préférez ne pas utiliser de script ou d'extrait auto-élévateur, mais plutôt un moyen simple de lancer un script en tant qu'administrateur (par exemple, à partir du menu contextuel de l'Explorateur), consultez mon autre réponse ici: https : //stackoverflow.com/a/57033941/2441655
J'ai trouvé un moyen de faire ça ...
Créez un fichier de commandes pour ouvrir votre script:
@echo off
START "" "C:\Scripts\ScriptName.ps1"
Ensuite, créez un raccourci, sur votre bureau par exemple (clic droit Nouveau -> Raccourci ).
Collez ensuite ceci à l'emplacement:
C:\Windows\System32\runas.exe /savecred /user:*DOMAIN*\*ADMIN USERNAME* C:\Scripts\BatchFileName.bat
Lors de la première ouverture, vous devrez entrer votre mot de passe une fois. Cela va ensuite l'enregistrer dans le gestionnaire des informations d'identification Windows.
Après cela, vous devriez pouvoir exécuter en tant qu'administrateur sans avoir à entrer un nom d'utilisateur ou un mot de passe administrateur.
Une autre solution plus simple est que vous pouvez également cliquer avec le bouton droit de la souris sur "C:\Windows\System32\cmd.exe" et choisir "Exécuter en tant qu'administrateur" pour pouvoir exécuter n'importe quelle application en tant qu'administrateur sans fournir de mot de passe.
Le moyen le plus fiable que j'ai trouvé est de l'envelopper dans un fichier .bat à élévation automatique:
@echo off
NET SESSION 1>NUL 2>NUL
IF %ERRORLEVEL% EQU 0 GOTO ADMINTASKS
CD %~dp0
MSHTA "javascript: var Shell = new ActiveXObject('Shell.application'); Shell.ShellExecute('%~nx0', '', '', 'runas', 0); close();"
EXIT
:ADMINTASKS
powershell -file "c:\users\joecoder\scripts\admin_tasks.ps1"
EXIT
Le .bat vérifie si vous êtes déjà administrateur et relance le script en tant qu'administrateur si nécessaire. Cela empêche également l'ouverture de fenêtres "cmd" superflues avec le 4ème paramètre de ShellExecute() défini sur 0.
En plus de la réponse de Shay Levy, suivez la configuration ci-dessous (une seule fois)
- Démarrer un PowerShell avec des droits d'administrateur.
- Suivez la question relative au dépassement de capacité PowerShell indique que "l'exécution des scripts est désactivée sur ce système.".
- Placez votre fichier .ps1 dans l'un des dossiers
PATH, par exemple. Dossier Windows\System32
Après l'installation:
- Presse Win + R
- Invoquer
powershell Start-Process powershell -Verb runAs <ps1_file>
Vous pouvez maintenant tout exécuter en une seule ligne de commande. Ce qui précède fonctionne sur Windows 8 Basic 64 bits.
Je n'ai jamais vu ma propre façon de le faire, alors essayez-le. C'est beaucoup plus facile à suivre et a une empreinte beaucoup plus petite:
if([bool]([Security.Principal.WindowsIdentity]::GetCurrent()).Groups -notcontains "S-1-5-32-544") {
Start Powershell -ArgumentList "& '$MyInvocation.MyCommand.Path'" -Verb runas
}
Très simplement, si la session Powershell actuelle a été appelée avec des privilèges d’administrateur, le SID bien connu du groupe d’administrateurs apparaîtra dans les groupes lorsque vous récupérerez l’identité actuelle. Même si le compte est membre de ce groupe, le SID n'apparaît que si le processus a été appelé avec des informations d'identification élevées.
Presque toutes ces réponses sont une variante de la méthode extrêmement populaire de Ben Armstrong de Microsoft, qui explique comment la réaliser sans vraiment comprendre ce qu’elle fait et comment émuler la même routine.
Pour ajouter le résultat de la commande à un nom de fichier texte contenant la date du jour, procédez comme suit:
$winupdfile = 'Windows-Update-' + $(get-date -f MM-dd-yyyy) + '.txt'
if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -Command `"Get-WUInstall -AcceptAll | Out-File $env:USERPROFILE\$winupdfile -Append`"" -Verb RunAs; exit } else { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -Command `"Get-WUInstall -AcceptAll | Out-File $env:USERPROFILE\$winupdfile -Append`""; exit }
Ceci est une clarification ...
Le justificatif d'identité RUNAS/SAVECRED powershell "n'est pas sûr", a essayé et il ajoute l'identité et le mot de passe de l'administrateur dans le cache des justificatifs d'identité et peut être utilisé ailleurs OOPS! Si vous avez fait cela, je vous suggère de vérifier et de supprimer l'entrée.
Examinez votre programme ou votre code car la stratégie de Microsoft stipule que vous ne pouvez pas avoir un code utilisateur/administrateur mélangé dans le même blob de code sans le UAC (point d'entrée) pour exécuter le programme en tant qu'administrateur. Ce serait Sudo (même chose) sur Linux.
L'UAC a 3 types, ne pas voir, une invite ou un point d'entrée généré dans le manifeste du programme. Il n’élève pas le programme, donc s’il n’ya pas d’UAC et qu’il a besoin d’administrateur, il échouera. En tant qu'exigence d'administrateur, le contrôle de compte d'utilisateur est correct, il empêche l'exécution de code sans authentification et empêche le scénario de codes mixtes de s'exécuter au niveau de l'utilisateur.