Uruchamianie polecenia jako administrator przy użyciu programu PowerShell?

Wiesz jak, jeśli jesteś administratorem systemu i możesz po prostu kliknąć prawym przyciskiem myszy powiedz, skrypt wsadowy i uruchomić go jako Administrator bez podawania hasła administratora?

Zastanawiam się, jak to zrobić za pomocą skryptu PowerShell. Nie chcę wprowadzać hasła; Chcę tylko naśladować metodę Uruchom jako administrator prawym przyciskiem myszy .

Wszystko, co do tej pory czytałem, wymaga podania hasła administratora.

Jeśli bieżąca konsola nie jest podniesiona, a operacja, którą próbujesz wykonać, wymaga podniesionych uprawnień, możesz uruchomić PowerShell z Run as administratoropcją:

PS> Start-Process powershell -Verb runAs

Oto dodatek do sugestii Shay Levi (wystarczy dodać te wiersze na początku skryptu):

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
}

Powoduje to, że bieżący skrypt jest przekazywany do nowego procesu PowerShell w trybie administratora (jeśli bieżący użytkownik ma dostęp do trybu administratora, a skrypt nie jest uruchamiany jako administrator).

Samopodnoszący się skrypt PowerShell

Windows 8.1 / PowerShell 4.0 +

Jedna linia :)

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 opublikował doskonały artykuł o samodoskonalących się skryptach PowerShell . Jest kilka drobnych problemów z jego kodem; zmodyfikowana wersja oparta na poprawkach sugerowanych w komentarzu znajduje się poniżej.

Zasadniczo pobiera tożsamość powiązaną z bieżącym procesem, sprawdza, czy jest administratorem, a jeśli nie jest, tworzy nowy proces PowerShell z uprawnieniami administratora i kończy stary proces.

# 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");

Możesz utworzyć plik wsadowy ( *.bat), który uruchamia skrypt PowerShell z uprawnieniami administratora po dwukrotnym kliknięciu. W ten sposób nie musisz nic zmieniać w skrypcie PowerShell. Aby to zrobić, utwórz plik wsadowy o tej samej nazwie i położeniu skryptu PowerShell, a następnie umieść w nim następującą treść:

@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"

Otóż ​​to!

Oto wyjaśnienie:

Zakładając, że skrypt PowerShell znajduje się na ścieżce C:\Temp\ScriptTest.ps1, plik wsadowy musi mieć ścieżkę C:\Temp\ScriptTest.bat. Gdy ktoś uruchomi ten plik wsadowy, zostaną wykonane następujące kroki:

1. Polecenie cmd wykona polecenie

   powershell -Command "Start-Process powershell \"-ExecutionPolicy Bypass -NoProfile -NoExit -Command `\"cd \`\"C:\Temp\`\"; & \`\".\ScriptTest.ps1\`\"`\"\" -Verb RunAs"

2. Otworzy się nowa sesja PowerShell i zostanie wykonana następująca komenda:

   Start-Process powershell "-ExecutionPolicy Bypass -NoProfile -NoExit -Command `"cd \`"C:\Temp\`"; & \`".\ScriptTest.ps1\`"`"" -Verb RunAs

3. W system32folderze otworzy się kolejna nowa sesja PowerShell z uprawnieniami administracyjnymi, do której zostaną przekazane następujące argumenty:

   -ExecutionPolicy Bypass -NoProfile -NoExit -Command "cd \"C:\Temp\"; & \".\ScriptTest.ps1\""

4. Następujące polecenie zostanie wykonane z uprawnieniami administratora:

   cd "C:\Temp"; & ".\ScriptTest.ps1"

   Gdy argumenty ścieżki i nazwy są podwójnie cytowane, mogą zawierać spacje lub znaki pojedynczego cudzysłowu ( ').

5. Bieżący folder zmieni się z system32na C:\Tempi skrypt ScriptTest.ps1zostanie wykonany. Po przekazaniu parametru -NoExitokno nie zostanie zamknięte, nawet jeśli skrypt PowerShell zgłasza wyjątek.

Oto samopodnoszący się fragment dla skryptów Powershell, który zachowuje katalog roboczy :

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

Zachowanie katalogu roboczego jest ważne dla skryptów wykonujących operacje względne względem ścieżki. Prawie wszystkie inne odpowiedzi nie zachowują tej ścieżki, co może powodować nieoczekiwane błędy w pozostałej części skryptu.

Jeśli wolisz nie używać samowznoszącego się skryptu / fragmentu, a zamiast tego chcesz po prostu w łatwy sposób uruchomić skrypt jako administrator (np. Z menu kontekstowego Eksploratora), zobacz moją inną odpowiedź tutaj: https: // stackoverflow .pl / a / 57033941/2441655

Za pomocą

#Requires -RunAsAdministrator

jeszcze nie zostało powiedziane. Wydaje się, że istnieje tylko od wersji PowerShell 4.0.

http://technet.microsoft.com/en-us/library/hh847765.aspx

Gdy ten parametr przełącznika zostanie dodany do instrukcji wymaganej, określa, że ​​sesja Windows PowerShell, w której uruchamiany jest skrypt, musi zostać uruchomiona z podwyższonymi uprawnieniami użytkownika (Uruchom jako administrator).

Wydaje mi się, że to dobry sposób, ale nie jestem jeszcze pewien doświadczenia w terenie. Środowiska wykonawcze PowerShell 3.0 prawdopodobnie ignorują to, lub nawet gorzej, powodują błąd.

Gdy skrypt jest uruchamiany jako użytkownik inny niż administrator, pojawia się następujący błąd:

Nie można uruchomić skryptu „StackOverflow.ps1”, ponieważ zawiera on instrukcję „#requires” do działania jako administrator. Bieżąca sesja Windows PowerShell nie działa jako administrator. Uruchom program Windows PowerShell, używając opcji Uruchom jako administrator, a następnie spróbuj ponownie uruchomić skrypt.

+ CategoryInfo          : PermissionDenied: (StackOverflow.ps1:String) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ScriptRequiresElevation

Możesz łatwo dodać niektóre wpisy rejestru, aby uzyskać menu kontekstowe „Uruchom jako administrator” dla .ps1plików:

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"'

(zaktualizowany do prostszego skryptu z @Shay)

Zasadniczo w HKCR:\Microsoft.PowershellScript.1\Shell\runas\commandustaw wartość domyślną, aby wywołać skrypt za pomocą programu PowerShell.

Kod opublikowany przez Jonathana i Shay Levy nie działał dla mnie.

Poniżej znajdziesz działający kod:

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"

Musisz ponownie uruchomić skrypt z uprawnieniami administracyjnymi i sprawdzić, czy skrypt został uruchomiony w tym trybie. Poniżej napisałem skrypt, który ma dwie funkcje: DoElevatedOperations i DoStandardOperations . Powinieneś umieścić swój kod, który wymaga uprawnień administratora w pierwszym, a standardowe operacje w drugim. IsRunAsAdmin zmienna jest używana do określenia trybu administratora.

Mój kod to uproszczony wyciąg ze skryptu Microsoft, który jest generowany automatycznie podczas tworzenia pakietu aplikacji dla aplikacji ze Sklepu Windows.

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
}

Dodając moje 2 centy. Moja prosta wersja oparta na sesji sieciowej, która do tej pory działa w systemie Windows 7 / Windows 10. Po co to komplikować?

if (!(net session)) {$path =  "& '" + $myinvocation.mycommand.definition + "'" ; Start-Process powershell -Verb runAs -ArgumentList $path ; exit}

po prostu dodaj na górę skryptu, a uruchomi się on jako administrator.

To zachowanie jest zgodne z projektem. Istnieje wiele warstw zabezpieczeń, ponieważ Microsoft naprawdę nie chciał, aby pliki .ps1 były najnowszymi wirusami pocztowymi. Niektórzy uważają, że jest to sprzeczne z samym pojęciem automatyzacji zadań, co jest sprawiedliwe. Model bezpieczeństwa Vista + ma na celu „zautomatyzowanie” rzeczy, dzięki czemu użytkownik jest w porządku.

Podejrzewam jednak, że jeśli sam uruchomisz PowerShell jako podniesiony, powinien on być w stanie uruchamiać pliki wsadowe bez żądania hasła, dopóki nie zamkniesz PowerShell.

Możesz również zmusić aplikację do otwarcia jako administrator, jeśli oczywiście masz konto administratora.

Znajdź plik, kliknij prawym przyciskiem myszy> właściwości> Skrót> Zaawansowane i sprawdź Uruchom jako administrator

Następnie kliknij OK.

C:\Users\"username"\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShelljest miejscem, w którym znajduje się skrót PowerShell. On również nadal udaje się w inne miejsce, aby wywołać rzeczywiste „exe” (%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe ).

Ponieważ PowerShell jest oparty na profilu użytkownika, jeśli chodzi o uprawnienia; jeśli twoja nazwa użytkownika / profil ma uprawnienia do zrobienia czegoś, to pod tym profilem w PowerShell na ogół będziesz mógł to zrobić. Biorąc to pod uwagę, sensowne byłoby zmodyfikowanie skrótu znajdującego się pod Twoim profilem użytkownika, na przykładC:\Users\"username"\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell .

Kliknij prawym przyciskiem myszy i kliknij właściwości. Kliknij przycisk „Zaawansowane” pod zakładką „Skrót” znajdującą się tuż pod polem tekstowym „Komentarze” sąsiadującym z prawej strony dwóch innych przycisków, odpowiednio „Otwórz lokalizację pliku” i „Zmień ikonę”.

Zaznacz pole wyboru brzmi „Uruchom jako administrator”. Kliknij OK, a następnie Applyi OK. Ponownie kliknij prawym przyciskiem myszy ikonę „Windows PowerShell” znajdującą się wC:\Users\"username"\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell i wybierz „Przypnij do menu Start / paska zadań”.

Teraz za każdym razem, gdy klikniesz tę ikonę, wywoła ona UAC w celu eskalacji. Po wybraniu „TAK” zauważysz, że konsola PowerShell jest otwarta, a na górze ekranu będzie oznaczona etykietą „Administrator”.

Aby pójść o krok dalej ... możesz kliknąć prawym przyciskiem myszy ten sam skrót ikony w lokalizacji profilu Windows PowerShell i przypisać skrót klawiaturowy, który zrobi dokładnie to samo, jakbyś kliknął ostatnio dodaną ikonę. Więc tam, gdzie jest napisane „Klawisz skrótu”, wstaw kombinację klawiszy / przycisków, na przykład: Ctrl+ Alt+ P P(dla PowerShell) . Kliknij Applyi OK.

Teraz wystarczy nacisnąć przypisaną kombinację przycisków, a zobaczysz wywołanie UAC, a po wybraniu „TAK” zobaczysz konsolę PowerShell, a na pasku tytułu wyświetli się „Administrator”.

Znalazłem sposób, aby to zrobić ...

Utwórz plik wsadowy, aby otworzyć skrypt:

@echo off
START "" "C:\Scripts\ScriptName.ps1"

Następnie utwórz skrót, powiedz na pulpicie (kliknij prawym przyciskiem myszy Nowy -> Skrót ).

Następnie wklej to do lokalizacji:

C:\Windows\System32\runas.exe /savecred /user:*DOMAIN*\*ADMIN USERNAME* C:\Scripts\BatchFileName.bat

Przy pierwszym otwarciu musisz raz wpisać hasło. Spowoduje to zapisanie go w menedżerze poświadczeń systemu Windows.

Po tym powinieneś być w stanie uruchomić się jako administrator bez konieczności wprowadzania nazwy użytkownika lub hasła administratora.

Problem z odpowiedziami @pgk i @Andrew Odri polega na tym, że masz parametry skryptu, zwłaszcza gdy są one obowiązkowe. Możesz rozwiązać ten problem, stosując następujące podejście:

1. Użytkownik kliknie prawym przyciskiem myszy plik .ps1 i wybierze „Uruchom za pomocą programu PowerShell”: zapytaj go o parametry w polach wejściowych (jest to znacznie lepsza opcja niż użycie HelpMessage parametru );
2. Użytkownik wykonuje skrypt za pośrednictwem konsoli: pozwól mu przekazać pożądane parametry i pozwól konsoli zmusić go do poinformowania o obowiązkowych.

Oto, jak wyglądałby kod, gdyby skrypt miał obowiązkowe parametry ComputerName i 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

Wiele odpowiedzi tutaj jest blisko, ale trochę więcej pracy niż potrzeba.

Utwórz skrót do skryptu i skonfiguruj go do „Uruchom jako administrator”:

• Utwórz skrót.
• Kliknij skrót prawym przyciskiem myszy i otwórz Properties...
• Edytuj Targetod <script-path>dopowershell <script-path>
• Kliknij Advanced...i włączRun as administrator

Innym prostszym rozwiązaniem jest to, że możesz także kliknąć prawym przyciskiem myszy „C: \ Windows \ System32 \ cmd.exe” i wybrać „Uruchom jako administrator”, a następnie możesz uruchomić dowolną aplikację jako administrator bez podawania hasła.

Korzystam z rozwiązania poniżej. Obsługuje stdout / stderr poprzez funkcję transkrypcji i poprawnie przekazuje kod wyjścia do procesu nadrzędnego. Musisz dostosować ścieżkę / nazwę pliku transkrypcji.

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

Oto jak uruchomić podniesioną komendę PowerShell i zebrać jej formę wyjściową w pliku wsadowym Windows w jednym poleceniu (tj. Nie pisać skryptu PowerShell dla PS1).

powershell -Command 'Start-Process powershell -ArgumentList "-Command (Get-Process postgres | Select-Object Path | Select-Object -Index 0).Path | Out-File -encoding ASCII $env:TEMP\camp-postgres.tmp" -Verb RunAs'

Powyżej widać, że najpierw uruchamiam PowerShell z podwyższonym monitem, a następnie pytam, aby uruchomić inną PowerShell (podpowłoka), aby uruchomić polecenie.

Oprócz odpowiedzi Shay Levy, wykonaj poniższe ustawienia (tylko raz)

1. Uruchom PowerShell z uprawnieniami administratora.
2. Podążaj za pytaniem o przepełnienie stosu PowerShell mówi: „wykonywanie skryptów jest wyłączone w tym systemie”. .
3. Umieść na przykład plik .ps1 w dowolnym folderze PATH. Folder Windows \ System32

Po instalacji:

1. Naciśnij Win+R
2. Odwołać się powershell Start-Process powershell -Verb runAs <ps1_file>

Możesz teraz uruchomić wszystko w jednym wierszu poleceń. Powyższe działa w systemie Windows 8 Basic w wersji 64-bitowej.

Najbardziej niezawodny sposób, jaki znalazłem, to zawinięcie go w samopodnoszący się plik .bat:

@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

.Bat sprawdza, czy jesteś już administratorem i w razie potrzeby ponownie uruchamia skrypt jako Administrator. Zapobiega również otwieraniu zewnętrznych okien „cmd” przy czwartym parametrze ShellExecute()ustawionym na 0.

Nie widziałem wcześniej swojego sposobu, więc wypróbuj to. Jest o wiele łatwiejszy do naśladowania i ma znacznie mniejszą powierzchnię:

if([bool]([Security.Principal.WindowsIdentity]::GetCurrent()).Groups -notcontains "S-1-5-32-544") {
    Start Powershell -ArgumentList "& '$MyInvocation.MyCommand.Path'" -Verb runas
    }

Bardzo prosto, jeśli bieżąca sesja PowerShell została wywołana z uprawnieniami administratora, dobrze znany identyfikator SID grupy administratorów pojawi się w grupach, gdy pobierzesz bieżącą tożsamość. Nawet jeśli konto należy do tej grupy, identyfikator SID nie pojawi się, chyba że proces został wywołany z podwyższonymi referencjami.

Prawie wszystkie te odpowiedzi są odmianą niezwykle popularnej metody Bena Armstronga Microsoftu, w jaki sposób to osiągnąć, nie tak naprawdę pojmując, co faktycznie robi i jak inaczej naśladować tę samą procedurę.

Aby dołączyć wynik polecenia do pliku tekstowego zawierającego bieżącą datę, możesz zrobić coś takiego:

$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 }

To jest wyjaśnienie ...

Poświadczenie PowerShell RUNAS / SAVECRED „nie jest bezpieczny”, wypróbował go i dodaje tożsamość administratora oraz hasło do pamięci podręcznej poświadczeń i może być używany w innym miejscu OOPS !. Jeśli to zrobiłeś, sugeruję sprawdzenie i usunięcie wpisu.

Przejrzyj swój program lub kod, ponieważ zgodnie z zasadą Microsoft nie można mieszać kodu użytkownika i administratora w tym samym obiekcie blob bez UAC (punktu wejścia), aby uruchomić program jako administrator. To byłoby sudo (to samo) w systemie Linux.

UAC ma 3 typy, nie patrz, monit lub punkt wejścia wygenerowany w manifeście programu. Nie podnosi poziomu programu, więc jeśli nie ma UAC i potrzebuje administratora, zakończy się niepowodzeniem. Kontrola konta użytkownika, choć jako wymóg administratora, jest dobra, zapobiega wykonywaniu kodu bez uwierzytelnienia i zapobiega wykonaniu scenariusza z mieszanymi kodami na poziomie użytkownika.

Okazuje się, że było to zbyt łatwe. Wszystko, co musisz zrobić, to uruchomić cmd jako administrator. Następnie wpisz explorer.exei naciśnij klawisz Enter. To otwiera Eksploratora Windows . Teraz kliknij prawym przyciskiem myszy skrypt PowerShell, który chcesz uruchomić, wybierz „uruchom z PowerShell”, który uruchomi go w PowerShell w trybie administratora.

Może pojawić się prośba o włączenie zasad do uruchomienia, wpisz Y i wciśnij Enter. Teraz skrypt będzie działał w PowerShell jako administrator. W przypadku, gdy świeci na czerwono, oznacza to, że Twoje zasady jeszcze nie wpłynęły. Następnie spróbuj ponownie i powinno działać dobrze.