script - run command as administrator from powershell

No se puede acceder a la unidad de red en PowerShell ejecutándose como administrador

Question

Estoy ejecutando PowerShell en una máquina virtual Windows 7 x64. Tengo una carpeta compartida en el host mapeada como una unidad de red (Z :). Cuando ejecuto PS normalmente, puedo acceder a ese disco correctamente, pero si lo ejecuto "como administrador", me dice:

Set-Location : Cannot find drive. A drive with the name ''Z'' does not exist.
At line:1 char:13
+ Set-Location <<<< Z:
+ CategoryInfo : ObjectNotFound: (Z:String) [Set-Location], DriveNotFoundException
+ FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

¿Cómo accedo a las unidades de red como administrador?

Answer 1

¿Qué tal mapear un nuevo psdrive para acceder a esos datos? Los PSDrives funcionan igual de bien o incluso mejor que las unidades asignadas al sistema cuando se escriben scripts o se accede a los almacenes de datos de red en powershell.

Las instrucciones para usar el cmdlet New-PSDrive están aquí: Technet:New-PSDrive

Si no desea tener que crear una nueva unidad psdrive cada vez, puede agregarla a los perfiles tanto del administrador como de su cuenta de usuario y estará disponible automáticamente cada vez que abra PowerShell.

~ Dan

Answer 2

Al final, la solución fue simplemente volver a mapear la letra de la unidad mientras se ejecutaba como Administrador :

net use Z: "//vmware-host/Shared Folders"

No tiene que hacerse desde la misma instancia de PowerShell (o desde PowerShell en absoluto); es algo que debe hacerse una vez para toda la sesión de inicio de sesión.

Answer 3

En mi caso, pude simplemente usar la ruta UNC en lugar de la asignación de unidad y funcionó bien.

Entonces, según su ejemplo, en lugar de usar la unidad asignada Z: /, acabo de usar "// vmware-host / Shared Folder" como la ruta.

Answer 4

Estoy usando la siguiente solución de hacky, donde recreo PSDrives "faltantes" en profile.ps1 cuando Powershell se ejecuta en modo elevado.

Gist

# Reconnect PSDrives for network connections when running with elevated privileges
$elevated = (([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
if( $elevated ) {
net use | ?{ $_ -match ":/s+////" -and !$_.StartsWith("Unavailable") } | %{
$tokens = $_.split(":")
$psdrivename = $tokens[0][$tokens[0].length-1]
$path = $tokens[1].trim().split(" ")[0].trim()
if( !(get-psdrive | ?{ $_.Name -eq $psdrivename } )) {
write-host ( "Restoring PSDrive for {0}: {1}" -f $psdrivename, $path )
new-psdrive $psdrivename FileSystem $path | out-null
}
}
}

Answer 5

Otra solución alternativa que me llevó años encontrar es ejecutar net use de una tarea programada como la cuenta NT AUTHORITY / SYSTEM . Aparentemente las unidades mapeadas bajo esta cuenta aparecen para todos los usuarios y todos los niveles de elevación .

He probado esto y funciona incluso en recursos compartidos de NFS (que pueden ser un poco quisquillosos). Simplemente cree un conjunto de tareas programadas para que se ejecuten al inicio del sistema y especifique el comando habitual:

net use Z: //server/share /persistent:no

Es posible que funcione ejecutarlo solo una vez con /persistent:yes , pero no lo he intentado. De acuerdo, "simplemente asócielo de nuevo" también funciona, pero ese disco aún no será visible para las tareas programadas que se ejecutan en diferentes contextos. La desventaja es que todos los usuarios reales lo ven también, por lo que no es tan bueno para configuraciones multiusuario.

Answer 6

Parece un problema conocido para Microsoft desde Vista.
Artículo base de Microsoft Knowled con arreglo de registro inseguro .

Actualmente estamos evaluando este enfoque ya que algunos de nuestros muchachos tienen la sensación de que la máquina no puede comenzar después de esto ;-)