PowerShell

Ich bin zwar noch nicht all zu lange ein Anhänger der PowerShell (Im Gegensatz zu Java, Perl, Bash, …), jedoch nutze ich es inzwischen für fast alle Sachen, die sich damit machen lassen.

Besonders im Zusammenhang mit PowerCLI kann man VMware Umgebungen wunderbar verbiegen ;-)

Mysterium 'ExecutionPolicy'

Powershell Nutzer setzen als erstes die ExecutionPolicy, die steuert, welche Scripte (Sicherheit) gestartet werden dürfen. Ich arbeite meist mit RemoteSigned.

Die meisten wissen jedoch nicht, dass es mehrere Scopes gibt. Bei der normalen Set-ExecutionPolicy Methode wird nur der Scope LocalMachine gesetzt. Gerade beim Aufruf aus anderen Progammen mittels process() o.ä. wird die PS jedoch im Scope CurrentUser ausgeführt, der für gewöhnlich unknown ist → AllSigned.

Prüfen kann man dies mit

Get-ExecutionPolicy -List
 
Scope                             ExecutionPolicy
-----                             ---------------
MachinePolicy                     Undefined
UserPolicy                        Undefined
Process                           Undefined
CurrentUser                       Undefined
LocalMachine                      Bypass

Die Policy Bypass ist übrigens sehr unsicher und sollte mit bedach gewählt werden. Besser ist da schon RemoteSigned.

Gesetzt wird dies für die verschiedenen Scopes mittels des Scope Parameters

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned -Force

Eine kurzer Überblick über powershell.exe Parameter und deren Auswirkung ist auch unter https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/ zu finden.

PowerCLI

PowerCLI ist die CMDlet Erweiterung der Powershell von VMware um eine VMware ESX/VI3/vSphere/wieauchimmer Umgebung effizient zu managen. Es gibt für fast alles fertige CMDlets und wenn die nicht reichen, kann man ja immer noch direkt auf die API gehen.

Alle VMs eines Datastores im Inventory registrieren

$VMFolder = "test"
$vmhost = "esxhost"
$DatastoreName = get-vmhost $vmhost | Get-Datastore | where {$_.Name -like "snap*"}
 
ForEach($regDS in $DatastoreName){
 
$ds = Get-Datastore -Name $regDS | %{Get-View $_.Id}
$SearchSpec = New-Object VMware.Vim.HostDatastoreBrowserSearchSpec
$SearchSpec.matchpattern = "*.vmx"
$dsBrowser = Get-View $ds.browser
$DatastorePath = "[" + $ds.Summary.Name + "]"
 
#Find all .VMX file paths in datastore, filtering out ones with .snapshot (useful for NetApp NFS)
$SearchResult = $dsBrowser.SearchDatastoreSubFolders($DatastorePath, $SearchSpec) | where {$_.FolderPath -notmatch".snapshot"} | %{$_.FolderPath + ($_.File | select Path).Path}
 
#Register all .vmx files as VMs on the datastore
foreach($VMXFile in $SearchResult) { New-VM -VMFilePath $VMXFile -ResourcePool $vmhost -Location $VMFolder -RunAsync }}

Was sind primary HA Nodes?

Im VMware HA Umfeld vor vSphere5 gibt es zwei Arten von Knoten. Primary und Secundary. Natürlich kann ich über PowerShell heraus bekommen, welche Primary Knoten sind.

$cluster = Get-View (Get-Cluster <ClusterName>).id
$infos   = $cluster.RetrieveDasAdvancedRuntimeInfo()
$prim_hosts =  $infos.DasHostInfo.PrimaryHosts

Protokollfehlermeldung bei Connect-VIServer

Falls man beim PowerShell CMDlet Connect-VIServer einen Fehler bzgl. falsches Protokoll bekommt, sind meist “schräge” Proxy Einstellungen schult. Die Proxy Nutzung kann durch

Set-PowerCLIConfiguration -ProxyPolicy NoProxy

abgeschaltet werden.

Datastore evakuieren

PowerShell allgemein

Windows SID zu Nutzer auflösen

Ab und zu habe ich das Problem, eine Windows SID zum Real-Name aufzulösen. Nach einiger Suche habe ich eine Lösung bei Eric Sarakaitis gefunden.

Hier der Codeschipsel:

$objSID = New-Object System.Security.Principal.SecurityIdentifier `
  ("s-1-5-21-1220945662-573735546-1417001333-500")
$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
$objUser.Value
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International