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

https://blog.uprightvinyl.co.uk/2018/03/07/installing-vmware-powercli-10-on-a-raspberry-pi/

https://blogs.vmware.com/PowerCLI/2018/02/powercli-10.html

https://github.com/eschek87/scripts/tree/master/vmware

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 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.

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

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

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.

http://practical-admin.com/blog/powercli-evacuate-a-datastore/

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