====== 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 ;-)

===== Links =====

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


===== 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 
<code powershell>
Get-ExecutionPolicy -List

Scope                             ExecutionPolicy
-----                             ---------------
MachinePolicy                     Undefined
UserPolicy                        Undefined
Process                           Undefined
CurrentUser                       Undefined
LocalMachine                      Bypass
</code>

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
<code powersehll>
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned -Force
</code>


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/|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 =====

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

</code>

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

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

</code>


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

<code powershell> 
Set-PowerCLIConfiguration -ProxyPolicy NoProxy
</code>

abgeschaltet werden.


==== Datastore evakuieren ====

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

===== 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:

<code powershell> 
$objSID = New-Object System.Security.Principal.SecurityIdentifier `
  ("s-1-5-21-1220945662-573735546-1417001333-500")
$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
$objUser.Value

</code>