Hyper-V Replika und Configuration Version

Auf einem Hyper-V Host hatte ich das Problem, dass die Hyper-V Replikation einfach nicht mehr in Gang zu bekommen war. Gewundert hat mich das schon, da diese coole Technologie seit dem Windows Server 2012R2 problemlos funktioniert hat. Unter Windows Server 2012 hatte ich gelegentlich kleinere Probleme, die aber mit dem R2 Release verschwunden waren. Doch zurück zum Problem …

Die Hyper-V Replication war im Status Critical und ließ sich auch manuell nicht mehr zur Arbeit bewegen.

Ich habe ein wenig herum gesucht, bis mir auffiel das beide VMs welche an der Replikation teilnehmen unterschiedliche Hyper-V Configuration Versionen hatten! Hier wurde wohl die Version der einen VM aktualisiert und dabei die Replika vergessen.

Damit man an die Hyper-V Configuration Version kommt, muss man diese im Hyper-V Management einblenden.

image

VMs welche auf einem Windows Server 2016 (oder auch Hyper-V 2016) angelegt werden, haben die Version 8. VMs welche auf so einen Host verschoben werden, können im ausgeschalteten Zustand auf diese Version aktualisiert werden. Das muss dann auch auf allen Replikas gemacht werden. Ist das nicht möglich, da z.B. Replikations-Hosts noch alle eine “alte” Hyper-V Version haben, muss die VM solange auf Version 5 bleiben, bis ein Upgrade stattgefunden hat. Dann klappt es auch wieder mit der Replikation.

Enjoy it, b!

Aufrüstung eines Microsoft Surface Studios

Mit dem Surface Studio hat Microsoft mal wieder ein extrem leckeres Teil vorgestellt. Schade finde ich dabei nur, dass als Datenträger eine klassische Festplatte in Verbindung mit einer 128GB kleinen SANDISK SSD zum Einsatz kommt. Da hätte ich mir ehrlich gesagt, den Einsatz einer SSD ab Werk gewünscht. 1TB und gut ist es, bei über 4000€ für die i7-Versionen, sollte das dann auch kein Problem sein. Leider ist aktuell nichts angekündigt und so bleibt nur noch der Griff zum Schraubenzieher.

Hier habe ich zwei Links welche den Upgrade Prozess ganz gut beschreiben:

http://cesardelatorre.azurewebsites.net/post/upgrading-the-surface-studio-drives-to-a-sata-ssd-2tb-and-a-m-2-nvme-ssd-1tb

https://mspoweruser.com/upgrade-surface-studio-make-much-faster-video/

Wenn ich dann selbst das erste Surface Studio in den Fingern, habe gibt noch einen Blog mit eigenen Erfahrungen dazu.

Enjoy it, b!

Instabile FRITZ!Box 7580

Neulich bin ich über ein interessantes Problem gestolpert. Eine FRITZ!Box 7580 zeigte an einem DSL-Anschluss von 1&1 ein instabiles Verhalten, welches sich in der Form äußerte, dass mehrmals am Tag die Verbindung ins Internet unterbrochen wurde.

Den ersten Punkt, welchen ich kontrollierte, war eine konfigurierte Zwangstrennung welche auch tatsächlich für morgens zwischen 4 und 5 Uhr eingestellt war, und laut den Logeinträgen auf der FRITZ!Box auch regelmäßig durchgeführt wird.

Für mich zuerst unerklärlich und interessant, trat die vermeidliche Trennung fast immer am Abend zwischen 21 und 22:30 Uhr auf. Eine weitere Analyse der Logeinträge zeigte jedoch hier keine Trennung, sondern einen vollständigen Neustart der FRITZ!Box, welcher natürlich auch eine Trennung und erneute Einwahl beim Provider mit sich bringt. Trennt nämlich der Provider oder der Router selbst die Verbindung, erfolgt das NICHT durch einen Neustart der FRITZ!Box und das WLAN bleibt darüber hinaus aktiv.

Im Verlauf meiner Analyse bin ich bei AVM auf folgenden Artikel gestoßen, welcher auch prompt die Erklärung für das Verhalten der FRITZ!Box 7580 lieferte:

Wenn Ihr AVM-Gerät mit einem ungeeigneten Netzteil am Stromnetz angeschlossen ist, kann es zu Funktionsstörungen kommen.”

https://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/434_Fuer-AVM-Geraete-geeignete-Netzteile/

Nicht besonders überraschend für mich war, dass je leistungsfähiger eine FRITZ!Box ist umso größer das zu verwendende Netzteil sein muss. Was war hier also passiert?

Bevor die FRITZ!Box 7580 zum Einsatz kam, wurde am Anschluss ein 1&1 HomeServer, die FRITZ!Box 7362SL verwendet, für dieses Gerät sieht AVM die Verwendung der folgenden beiden Netzteile vor.


AVM-Gerät Passendes Netzteil
FRITZ!Box 7362 SL 311P0W067, 311P0W068

Im Rahmen der Aufrüstung, also des Wechsels von dem 1&1 HomeServer auf die FRITZ!Box 7580 wurde vom Techniker einfach das “alte” Netzteil weiter verwendet, der Stecker passt ja und so “sparte” man sich die Änderung an der Verkabelung!

Das Problem trat auf, wenn die FRITZ!Box zur “Prime Time” so richtig was arbeiten durfte (gegen 21 bis in die Nacht wurde gerne von Amazon und NetFlix gestreamt), das Netzteil die dafür notwendige Leistung nicht mehr liefern konnte und es dadurch zum Absturz der FRITZ!Box kam. Vergleich man nur die physikalischen Abmessungen und auch die maximale Leistung beider Geräte sieht man hier schon den Unterschied und auch AVM verweist hier auf ein anderes Netzteil (welches sich zum Glück noch im Karton der 7580 FRITZ!Box befand).

AVM-Gerät Passendes Netzteil
FRITZ!Box 7580

311P0W106

Seitdem ich das richtige Netzteil in Einsatz gebracht habe, läuft die FRITZ!Box 7580 auch zur “Prime Time” ohne Probleme.

Enjoy it, b!

Windows 10 und der Hibernation Mode

Unter Windows 10 ist der Hibernation Mode erst einmal nicht aktiviert. Diesen nutze ich aber sehr gerne, da ich damit zum Beispiel mein Surface Book definitiv “schlafen” legen kann und es nicht aus welchem Grund auch immer im Rucksack vor sich hinköchelt …

Der Hibernation Mode wird über die folgenden Schritte aktiviert:

Öffnen einer Eingabeaufforderung als Admin (Elevated Command Prompt), dazu im Startmenü nach cmd.exe suchen und mit der rechten Maustaste die Option als Administrator ausführen wählen

In der Eingabeaufforderung dann den folgenden Befehl eingeben.

powercfg -h on

Nun ist der Hibernation Mode aktiviert, damit dieser aber in den Optionen zu herunterfahren mit angezeigt wird, muss man noch einen Haken in den Energiesparoptionen setzen und diese neuen Einstellungen abspeichern.

image

Sieht gut aus, würde ich sagen ..

image

Enjoy it, b!

Office 365 Home alternativ installieren

Das 5er Paket der Microsoft Office 365 Home Edition ist nach meiner Meinung eine attraktive Sache, um die Funktionen soll es hier aber gar nicht gehen, sondern um die Möglichkeit Office 365 alternativ, also in einer anderen Sprache und für eine andere Plattform (x64, also 64Bit anstatt 32Bit) zu installieren.

Diese Optionen hat man wenn man im Dialog zur Installation folgende Auswahl trifft.

image

Damit erscheint die Möglichkeit, sowohl die Sprache als auch die Plattform zu wählen.

Untitled2

Wer dazu noch einen Offline Installer (ISO) haben will, wählt diesen weiter unten aus und fertig.

Wenn an nun im Anschluss, so wie in diesem Fall ein englisches Office mit deutscher Korrekturhilfe haben will, kann man diese unter dem folgendem Link herunterladen und installieren.

https://www.microsoft.com/de-DE/download/details.aspx?id=52668

Enjoy it, b!

Updates gegen WannaCrypt …

… bietet Microsoft in seinem Microsoft Update-Catalog unter dem folgenden Link an:

http://www.catalog.update.microsoft.com/Search.aspx?q=KB4012598

Die relevante Bezeichnung für alle Updates ist KB4012598, weitere hilfreiche Infos gibt es unter:

https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

 

Enjoy it, b!

Installation von KB3000850 auf Windows Server 2012 R2 schlägt fehl …

Alle die meinen Blog verfolgen, wissen – der WSUS und ich haben ein schwieriges Verhältnis … zumindest wollte mir dieser partout nicht der Update Windows8.1-KB3014442-x64.msu zur Installation anbieten, welches neben Windows8.1-KB3016437-x64.msu und dem Windows8.1-KB3003057-x64 die Voraussetzung für Windows8.1-KB3000850-x64 darstellt.

Die Vorgehensweise ist eigentlich immer die gleiche, zu erst auf der Microsoft Webseite nach dem Update suchen, welches fehl schlägt. Dann werden hier manchmal weitere Updates im gleichen Download mit angeboten. Hier einfach alle Updates runter laden und probieren welche sich installieren lassen. Bei mir waren alle drauf, mit Ausnahme von KB3014442-x64.msu und der scheint die Grundlage für Windows8.1-KB3000850-x64.msu zu sein.

image

Danach hat es problemlos funktioniert Smile

 

Enjoy it, b!

Azure VPN-Verbindung (S2S) über den Azure Resource Manager und Windows Server 2012 R2

Fangen wir mal an

Auch für kleine Firmen kann die Nutzung von Diensten aus der Cloud sinnvoll sein, lässt sich damit doch der eine oder andere Test oder die Beschaffung zusätzlicher Server-Hardware umgehen.

Neben einer Vielzahl von Diensten (Azure-Backup), welche einfach über die Ports 80 oder 443 genutzt werden, kann es dennoch notwendig sein, eine VPN Verbindung nach Azure zu bauen (also das lokale Netzwerk mit Azure zu koppeln, was man auch Site-2-Site-VPN/S2S-VPN nennt). Um es gleich vorne weg zu sagen, in Azure kocht man auch nur mit Wasser … oder anders rum, mit Virtuellen Maschinen (VM), was bedeutet das ein VPN-Gateway in Azure nichts anderes ist, als ein Windows Server (Stand heute 2012R2). Zwar gibt es bei Microsoft Azure eine Liste von Routern und Beschreibungen wie diese für eine VPN-Verbindung mit Azure konfiguriert werden müssen, für kleine Firmen tut es aber auch ein Windows Server und genau diese Konfiguration soll hier beschrieben werden.

Um z.B. eine FRITZ!Box mit Azure zu verbinden gibt es eine Reihe von Anleitungen, dass Problem mit den FRITZ!Boxen ist aktuell, dass diese keinen IKEv2 support liefern und deshalb die Verbindung nach Azure über den ARM (Azure Resource Manager) nicht ganz so einfach zu konfigureren ist.

Microsoft hat in Azure zwei Möglichkeiten um Ressourcen zu verwalten:

  • ASM = Azure Service Manager (alt und nicht mehr auf Höhe der Zeit, der ASM wird nur noch aus Gründen der Kompatibilität bereit gestellt)
  • ARM = Azure Resource Manager (aktuell und die empfohlene Lösung)

Ich habe z.B. festgestellt, dass sich Azure GPU VMs (N-series) nur über den ARM bereitstellen lassen und auch nur auf ARM Ressourcen zurückgreifen können. Ich hatte die Situation, dass ich es nicht hinbekommen habe auf eine VPN Verbindung zwischen meiner FRITZ!Box und meinem lokalen Netzwerk (ASM basierend) mit einer N-Series VM zu zugreifen. Vielleicht saß das Problem auch vor dem Rechner, zumindest war eine einfache Lösung nicht möglich (ein VNet-Peering oder VNet-Routing wollte ich nicht konfigurieren).

Voraussetzungen

Damit nun eine VPN-Verbindung zwischen Azure und einem lokalen Netzwerk mit einem Windows Server konfiguriert werden kann, müssen wir uns, über ein paar Dinge klar werden:

  1. IPv4-Adressbereiche in Azure
  2. Lokale IP-Adressbereich(e) und die externe IP des Routers
  3. Auf welchem Server installieren wir RRAS (Remote Routing and Access)?

Gleich mal zu Punkt 3 … auf einem Windows Server mit geladener Essentials Role würde ich von einer Konfiguration von RRAS absehen … Da ich inzwischen die Standard Edition von Windows Server verwende und die seit geraumer Zeit den Betrieb von 2 VMs möglich macht, gehe ich von der folgenden Konfiguration aus:

  • Host mit Hyper-V
  • VM 1, Windows Server mit installierter Essentials Role
  • VM 2, Windows Server mit RRAS und weiteren Diensten

Die folgenden Screenshots wurden auf einem Windows Server 2012 R2 (Englisch) gemacht und auch die Menübeschreibungen des Server beziehen sich auf die Englische Version …

Punkt 2 beschreibt alle lokalen Adressbereiche welche verwendet werden, und darüber hinaus brauchen wir die externe IP des Routers. Diese ist bei mir statisch, oder sagen wir mal so gut wie statisch. Bisher hat bei UnityMedia (meinem Provider) die IP höchstes 1x im Jahr gewechselt.

Meine lokalen Adressbereiche sehen wie folgt aus:

  • 192.168.2.0/24, Gateway ist immer die .1 und der DNS läuft unter 192.168.2.17
  • 192.168.12.0/24, Gateway ist immer die .1

Die externe IP ist 38.210.102.188, bzw. ein verwendeter DynDns-Name wie z.B. azuretest.remotewebaccess.com

Damit kommen wir zum letzten Punkt, was soll eigentlich in Azure gebaut werden? Meine Absicht ist es ein Subnetz für VMs zu erstellen und dieses über ein VPN Gateway mit dem Netzwerk zuhause zu koppeln. Im ARM müssen dazu 2 Netzwerke definiert werden. Ein Netzwerk, oder genauer gesagt Subnetz für die VMs und ein weiteres für das Gateway.

Diese Netze nennen wir wie folgt und verwenden die folgenden Adressbereiche:

  • SBSland-Azure-CR-Network-000, 10.1.0.0/16
  • Subnetz 1: VM-Network-250, 10.1.250.0/24
  • Subnetz 2: GatewaySubnet, 10.1.249.0/28

Darüber hinaus müssen wir im ARM eine Gruppe für diese Ressourcen anlegen:

  • SBSland-Azure-Core-RG-1

Zum Abschluss, also bevor wir die Sache angehen können brauchen wir noch einen PreShared-Key welcher im Gegensatz zu früher (im ASM) selbst erstellt werden muss. Ich mache das immer mit KeePass.

  • f75bb948e79e072503af6cf93b154321cdf88e1c00964da4569e9123456789a8

Da wir zwischen dem lokalen Netzwerk und Azure routen, dürfen sich KEINE der Adressebereiche überlappen.

Konfiguration in Azure Remote Manager (ARM)

Nach der Anmeldung in Azure, muss möglicher Weise in das neue Portal gewechselt werden … was dann so aussieht.

image

Nun erfolgt im ersten Schritt das Erstellen der Ressourcengruppe

  1. Dazu wählen wir Ressourcengruppe / Hinzufügen und geben hier den Ressourcengruppenname (SBSland-Azure-Core-RG-1) ein

    image

    An dieser Stelle wird auch ausgewählt in welcher Azure Region wir den Service laufen lassen, Westeurope = Amsterdam (stand heute)

  2. Ein Klick auf Erstellen erzeugt die Gruppe

    image

  3. Nun legen wir die Netzwerke an. + / Netzwerk / Virtual Network

    image

    Welche wie folgt benannt werden, SBSland-Azure-CR-Network-000 und darüber hinaus geben wir noch den von uns gewählten IP-Adressbereich für das VM-Subnetz 10.1.0.0/16 und das erste Subnetz VM-Network-250, 10.1.250.0/24 an.

    image

    Dazu nicht vergessen, die vorhin erstelle Ressourcengruppe aus zu wählen und natürlich mit Erstellen das virtuelle Netzwerk erzeugen zu lassen. Damit ist das erste Subnetz für die VMs angelegt

  4. Als nächstes muss das Gatewaysubnetz konfiguriert werden, dazu einfach + Gatewaysubnetz (blau markiert) auswählen und den IP-Adressbereich 10.1.249.0/28 einfügen.

    image

    Nach Auswahl der + Gatewaysubnetz Option erscheint der Dialog zur Anöage

    image

    Der Name GatewaySubnet ist vorgegeben, daher kann nur der IP-Adressbereich in CIDR Form eingegeben werden

    image

    In den nächsten Schritten wird nun das Azure Gateway und das Lokale Gateway angelegt. Beginnen wir mit dem Azure Gateway …

  5. Um das Azure Gateway an zu legen, muss + / Netzwerk / Virtuelles Netzwerkgateway ausgewählt werden

    image

    Das Gateway nennen wir SBSland-Azure-AZ-Gateway, darüber hinaus wird das angelegte Netzwerk (SBSland-Azure-CR-Network-000) ausgewählt und eine öffentliche IP erstellt

    image

    Kleiner Hinweis an dieser Stelle … hinter SKU steckt die Größe, bzw. die Leistungsfähigkeit des Gateways und damit im Prinzip nur eine größere oder kleiner VM Winking smile 

    Als Gatewaytyp lassen wir VPN, eine Expressroute haben wir ja nicht und als VPN-Typ verwenden wir Routenbasiert.

    Routenbasiert, unterstützt dynmische routen und mehrere VPN-Verbindungen basierend auf IKEv2
    Richtlinienbasiert, unterstützt statische Routen, eine single VPN-Verbindung und IKEv1

    Für die FRITZ!Boxler unter uns, wäre das eine Möglichkeit ein Richtlinienbasiertes VPN zu bauen, da hier IKEv1 verwendet wird… was ich mir aber bisher noch nicht angeschaut habe.

    Die Erstellung dauert übrigens seine Zeit, be patient … Kaffeepause …

  6. Nach dem das Azure Gateway erstellt wurde, brauchen wir das “lokale” Gegenstück, ein lokales Netzwerk Gateway, welches im Wesentlichen die externe IP des Routers repräsentiert, hier also die 38.210.102.188

    + / Netzwerk / Lokales Netzwerkgateway öffnet den Dialog zur Konfiguration

    image

    Das Netzwerk nennen wir SBSland-Azure-LN-Gateway, als öffentliche IP geben wir die externe IP des Routers ein und konfigurieren zusätzlich die IP-Subnetze welche wir lokal verwenden. In kleinen Umgebungen ist es nur eines, bei mir sind es zwei 192.168.2.0/24 und 192.168.12.0/24

    image

    Nachdem nun fast alle Ressourcen in Azure angelegt sind, fehlt noch die VPN-Verbindung und damit sind wir im ARM auch schon fertig.
    Noch ein Hinweis zu den lokalen Subnetzen, diese können natürlich im Anschluss noch erweitert werden, falls die lokale Infrasturktur zu wachsen beginnt

  7. Zum Einrichten der VPN-Verbindung wählen wir das erstellte Lokale Netzwerkgateway (SBSland-Azure-LN-Gateway) aus und klicken dort auf Verbindungen

    image

    Nach der Auswahl von Verbindungen erfolgt das Hinzufügen einer VPN-Verbindung durch + Hinzufügen rechts oben. Die Verbindung nennen wir SBSland-Azure-Local-VPN und fügen als Gateway für virtuelle Netzwerke das erstellte SBSland-Azure-AZ-Gateway hinzu und den selbst erstellten PSK-Key

    image

So, in Azure (ARM) sind wir nun erst einmal fertig, nun muss noch der Windows Server mit RRAS konfiguriert werden.

Konfiguration des Windows Servers (RRAS)

Die Installation von Routing und Remote Access erfolgt am einfachsten über PowerShell.

Install-WindowsFeature Routing -IncludeManagementTools

 

  1. Unter Routing and Remote Access / Network Interfaces fügen wir nun ein New Demand-dial Interface.. hinzu, damit das funktioniert muss der Server von Local area network (LAN) routing only auf LAN and demand-dial routing umgestellt werden.

    image

    Nun kann das neue Interface erstellt werden …

    image

    Das Demand-Dial Interface nennen wir SBSland-Local-Azure-VPN und wählen im Anschluss Connect using virutal private networking (VPN) aus

    image

  2. darauf hin als VPN Type , IKEv2 auswählen

    image

  3. In der Zusammenfassung des von uns konfigurierten Azure Gateways (SBSland-Azure-AZ-Gateway) finden wir die öffentliche Azure-IP-Adresse …

    image

    … die als Destination Address eingetragen wird

    image

    … und die Sicherheitseinstellungen belassen wir so, wie sie sind …

    image

    … und fügen eine statische Route (Static Route) in unser Azure Netzwerk (VM-Network-250) hinzu

    image

    Wenn mehr als ein Netzwerk in Azure vorhanden ist (das GatewaySubnet zählt nicht), dann hier entsprechend diese Netze ebenfalls hinzufügen.

  4. Den Dialog mit den Credentials zur Einwahl können wir dahingehend ignorieren, dass wir nur einen Benutzer eintragen (SBSland) was dem Wizard ausreicht …

    image

    … mit Finish schließen wir den Dialog und bestätigen die Konfiguration

  5. Damit die VPN-Verbindung funktioniert, muss nun die Verwendung von IKEv2 konfiguriert werden. Das erfolgt in den Eigenschaften des Interfaces unter der Option Security

    image

    Hier wird der gleiche PSK-Key eingetragen, wie schon oben bei der Konfiguration der Verbindung in Azure.

  6. Nun ist die Verbindung erstellt und wir können mit der rechten Maustaste eine Verbindung (Connect) initiieren.
  7. Das manuelle initiieren der Verbindung ist OK, aber nicht das was wir haben wollen, da immer nach einem Server-Neustart die Verbindung manuell getriggert werden muss. Daher ändern wir die Einstellungen der Verbindung wie folgt:
    Routing an Remote Access / <Servername> / Network Interfaces / SBSland-Local-Azure-VPN, rechte Maustaste und Properties / Options auswählen, hier den Haken bei Persistent Connection setzen

    image

    Damit baut der Server nach einem Neustart die Verbindng von selbst auf

Zurück in Azure

In Azure wählen wir nun das Gateway für virtuelle Netzwerke (SBSland-Azure-AZ-Gateway), mit dem Punkt Verbinden aus.

image

So, nun sind wir eigentlich fertig hier noch ein Bild mit den Objekten welche wir konfiguriert haben.

image

The End

Wenn wir aber nicht auf allen VMs im lokalen Netz eine Route nach Azure definieren wollen, ist es sinnvoll dem Router eine entsprechende Route hinzu zu fügen, um eine automatische Weiterleitung aller Paket in das Netzwerk 10.1.250.0/24 zu gewährleisten.

image

Damit sind wir nun wirklich fertig.

Enjoy it, b!

Ausführen von PowerShell über eine Batch

PowerShell Skripte oder CmdLets lassen sich auch über eine Batchdatei (.cmd / .bat) ausführen. Das geht recht einfach und sogar Parameter können mit angegeben werden. Es muss lediglich auf korrekte gesetzte Quoten (Anführungszeichen) geachtet werden.

:: Variables
set log="%temp%\Expand-Raw.log"

:: Header
echo Expand-Raw ...
echo Expand-Raw ... >%log%
echo.

for /f "tokens=*" %%a in ('dir RAW*.zip /b') do (

	rem  PowerShell -NoExit "&" ""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'"
	PowerShell ""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'"
	echo [RC=%ERRORLEVEL%], PowerShell -NoExit "&" ""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'" >>%log%

)

:_End

Schauen wir uns das PowerShell-Skript genauer an, dann sehen wir das insgesamt 4 Parameter übergeben werden:

  • -Action und die entsprechende Aktion, also –Action dis
  • -File und Dateiname, also –File ‘RAW 2017-01-08-01, Huskies auf der Alb.zip’

Der Aufruf unter PowerShell (also nicht über eine Batch sieht wie folgt aus):

.\Distribute-Pictures.ps1 -Action dis -File 'RAW 2017-01-08-01, Huskies auf der Alb.zip'

Die Batch Datei, welche nun drum herum abläuft, soll das PowerShell-Skript einfach mehrfach für eine Reihe von Dateien im gleichen Verzeichnis ausführen. Darum erfolgt ein Aufruf von PowerShell.exe mit dem Script und den Parametern aus der Batch heraus.

PowerShell ""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'"

PowerShell ruft die PowerShell.exe auf, danach wird der vollständige Aufruf für PowerShell in normale Anführungszeichen gesetzt.

""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'"

Innerhalb dieser Anführungszeichnen (“) steht dann das PowerShell-Script in weiteren Anführungszeichen, gefolgt von den Parametern. Der letzte Parameter, welcher den Dateinamen darstellt, wird in einfache Anführungszeichen (‘) gesetzt, da ihn PowerShell dann literal behandelt.

Enjoy it, b!