Kategorie: Microsoft

Windows 10–Linux Subsystem installieren und ´Linux Distributionen aus dem Store nutzen

Veröffentlicht 28. März 2018

Seit einer Weile enthält Windows das “Subsystem für Linux” (WSL). Damit kann man Linux-Code nativ unter Windows ausführen, ohne dafür erst eine VM starten zu müssen oder ähnliches. Di Installation ist super einfach:

Am besten und einfachsten geht es per PowerShell (womit auch sonst? Smiley )

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Wenn man nun direkt die WSL startet (wsl.exe), dann bekommt man erstmal eine “Fehlermeldung”:

Anschließend kann man im Windows Store nach seiner Lieblings-Distribution suchen:

Zur Verfügung stehen:

Debian GNU/Linux
Ubuntu
OpenSUSE
SLES
Kali Linux

Der Start kann dann direkt aus dem Startmenü erfolgen:

Die Ersteinrichtung dauert einen Moment:

Abschließend muss noch ein User mit Passwort eingerichtet werden…

… und dann kann das Linux genutzt werden.

Viel Spaß beim Ausprobieren und Benutzen!

2 Comments

Windows Server – nächste Version offiziell angekündigt

Veröffentlicht 21. März 2018

Microsoft hat vor wenigen Stunden in einem längeren Blogartikel (siehe Link) viele Details zum nächsten Windows Server veröffentlicht. Dieser wird „Windows Server 2019“ heißen und bereits in der zweiten Jahreshälfte diesen Jahres erscheinen. Über das Insider-Programm kann bereits eine Preview heruntergeladen und genutzt (natürlich nur zu Testzwecken!) werden:

https://insider.windows.com/de-de/for-business-getting-started-server/

Nach Aussage von Microsoft soll der neue Server vor allem 4 Hauptthemen adressieren:

Hybrid,
Security,
Application Platform und
Hyper-converged Infrastructure

Der neue Windows Server wird das nächste Release im LTSC (Long term servicing channel sein). In diesem wird es wieder eine GUI-Installationsoption sowie den Core-Server geben. Für den Semi-Annual-Channel (eher nicht für klassische Server-Szenarien geeignet) gibt es nur Core- und Nano-Server-Installationen.

Die Lizensierung des Server 2019 wird genau so wie bei 2016 organisiert sein. Microsoft kündigt aber eine Erhöhung der Preise für CALs an.

Details und weiteres siehe Blog-Artikel.

Quelle: https://cloudblogs.microsoft.com/windowsserver/2018/03/20/introducing-windows-server-2019-now-available-in-preview/

Schreibe einen Kommentar...

PowerShell Core und Jenkins – Continuous Integration für PowerShell auf Linux

Veröffentlicht 12. März 2018

In letzter Zeit beschäftige ich mich immer mal wieder mit DevOps-Themen. Eines davon ist Continuous Integration und das dafür gemachte Jenkins. Einige meiner Erfahrungen hierzu möchte ich gerne teilen.

Dieser Artikel beschäftigt sich mit PowerShell Core und Jenkins. In einem vorherigen Artikel habe ich in Kurzform erläutert, wie man Jenkins unter Debian Linux installiert. Das ist für diesen Artikel eine Art Voraussetzung.

Auch ohne PS Core kann Jenkins PowerShell-Code und –Skripte ausführen – allerdings braucht es dazu immer einen sogenannten “Build Slave” (also einen weiteren Jenkins-Knoten) mit Windows als Betriebssystem,

Mit der Verfügbarkeit von PowerShell Core für Linux ist es künftig nicht mehr zwingend nötig, einen Windows Buildslave zu verwenden, wenn man PowerShell benutzen möchte. Was leider NICHT funktioniert (zumindest mit Stand Heute), ist das PowerShell-Plugin für Jenkins. Dieses ruft den Code in einer Art und Weise auf, wie es nur unter Windows funktioniert. Selbst wenn man den dort verwendeten Aufruf “powershell.exe” mittels symbolic Link oder Alias auf pwsh mappt, wird es nicht funktionieren.

Ein möglicher Weg führt aber über den Einsatz eines Batch-Skriptes. Und das könnte so aussehen:

Mit Hilfe von Parametern kann später flexibler mit dem Build Job umgegangen werden (siehe weiter unten):

Der Einfachheit halber sollte der Parametername keine Leer- oder Sonderzeichen enthalten.

Für den eigentlichen Build (also die Aktionen, die durch den Job auszuführen sind), muss man hier nun auf “Shell ausführen” zurückgreifen. Der Menüpunkt “Windows PowerShell” wird nicht funktionieren (er steht auch nur zur Verfügung, wenn das Plugin bereits installiert ist).

Mein Aufruf für die Shell lautet hier beispielhaft:

pwsh -command „(Get-Variable -Name ${VariableName}).Value“

Mit ${PARAMETER} kann man auf den oben definierten Parameter zurückgreifen.

Anschließend kann man den Buildjob über “Bauen mit Parametern” aufrufen. Dabei kann man dann den Wert des/der Parameter definieren (oder, falls man Defaultwerte definiert hat, diese einfach beibehalten):

Anschließend kann man mit einem Klick auf den kleinen Pfeil neben dem Buildjob unten bei “Build-Verlauf” die “Konsolenausgabe” aufrufen:

Dort sieht man dann entweder den/die Fehler, falls welche aufgetreten sind, oder eben die Ausgabe des Jobs:

Schreibe einen Kommentar...

Azure Cloud Shell – PowerShell für Azure

Veröffentlicht 7. März 2018

Auch wenn es nicht erst seit gestern verfügbar ist, wollte ich gern auf ein cooles Feature in Azure hinweisen: Azure Cloud Shell.

Kurz gesagt handelt es sich hier um ein Zugang zu Azure und seine Funktionen über PowerShell oder Linux Bash. Diese Shell läuft in einem Container auf Azure und kann ganz einfach über den Browser verwendet werden. Dazu ruft man einfach

https://shell.azure.com

auf. Nach der Anmeldung muss einmalig ein Storageaccount eingerichtet werden, der dann in die Shell gemountet wird

und dort als Speicher zur Verfügung steht:

Nach der Anmeldung bei Azure muss die gewünschte Subscription ausgewählt werden:

Dann erfolgt die Auswahl der gewünschten Shell – Bash auf Linux oder PwerShell auf Windows:

Außerdem muss ein Storageaccount ausgewählt oder angelegt werden, wozu die Auswahl des gewünschten Abonnements erfolgen muss:

Das Anlegen des Storage Accounts und der erste Start der Shell dauern dann leider etwas…

Fortan steht die Shell auch etwas schneller zur Verfügung. Sie kann auch aus dem Azure Portal aufgerufen werden – dazu ist der Button in der oberen Leiste gedacht:

Es gilt, ein paar Kleinigkeiten zu beachten:

Es gibt einen 20-Minuten-Timeout in der Shell. Nach 20 Minuten Inaktivität wird die Shell recycelt.
Änderungen im Dateisystem sind nur innerhalb von $Home und clouddrive persistent
Man kann jederzeit zwischen Bash und PowerShell umschalten – aber man kann immer nur eine Shell gleichzeitig laufen haben
Der Power-Button oben startet die Shell (bzw. deren Container) neu – dabei gehen dann z.B. die Variablen und deren Werte verloren
Das Starten einer auf PowerShell basierenden Cloudshell kann ca. 60 Sekunden dauern – Bash geht deutlich schneller

Weitere Details siehe hier:

https://docs.microsoft.com/en-us/azure/cloud-shell/overview

Schreibe einen Kommentar...

Win32 OpenSSH unter Windows 10 1709 aktivieren und nutzen

Veröffentlicht 6. März 2018

Im Zuge der Weiterentwicklung von PowerShell Core und der Ausrichtung auf Linux-Systeme hat Microsoft eine neue Strategie für die Remote-Verwaltung von Systemen entwickelt. Diese beinhaltet u.a. die Verwendung von OpenSSH unter Windows. Das an sich ist nicht wirklich neu – zumindest etwas neuer ist aber die Tatsache, dass diese Technologie jetzt seit dem 1709 Build (“Fall Creators Update”) als Beta im System integriert ist. Allerdings müssen die Komponenten bei Bedarf noch aktiviert / installiert werden. Und das geht so:

Startmenü / Einstellungen (Zahnrad) / Apps / Optionale Features verwalten / Feature hinzufügen:

Dort finden sich dann die beiden OpenSSH Optionen:

Beide Optionen sollten eigentlich selbst-erklärend sein…

Alternativ kann die Installation auch über PowerShell erfolgen:

# Installieren von Server und Client
Add-WindowsCapability -Online -Name OpenSSH*
# Nur Server
Add-WindowsCapability -Online -Name OpenSSH.Server*
# Nur Client
Add-WindowsCapability -Online -Name OpenSSH.Client*

Der SSH Client läuft jetzt völlig problemlos von der Kommandozeile – wenn man den vollen Pfad benutzt:

C:\Windows\System32\OpenSSH\ssh.exe

Spätestens nach dem nächsten Neustart ist dann der Pfad auch in PATH und damit von überall aus aufzurufen.

Die Konfiguration des OpenSSH-Servers ist ein kleines bisschen aufwändiger. Diesem Thema werde ich demnächst einen weiteren Blogartikel widmen. Stay tuned!

1 Kommentar

PowerShell & Fotobox – Fotos zu einem bestimmten Hashtag von Instagaram laden

Veröffentlicht 30. Januar 2018

Auf meiner in den letzten Wochen und Monaten gebauten Fotobox (Mehr dazu hier) gibt es einen extra Bildschirm für eine Slideshow der aufgenommenen Fotos. Diese zeigt die neuesten x Fotos aus der Liste aller aufgenommenen Bilder, wobei ein neues Foto immer das älteste Bild ablöst (zu der technischen Realisierung hier werde ich später noch einen größeren Artikel schreiben).

Nun kam mir in diesem Zusammenhang die Idee, aus den sozialen Medien ebenfalls die aktuellsten Bilder zu einem bestimmten Hashtag abzurufen, damit die Gäste unter diesem Hashtag Handyfotos posten könnten, die dann wiederum in die Slideshow einfließen sollten. Hierzu gibt es ein paar Lösungen im Internet, die aber fast alle recht teuer sind und auch größtenteils nur im Browser ablaufen. Ich wollte aber gern die einzelnen Dateien lokal auf dem Rechner haben. Also habe ich mir ein PowerShell-Skript geschrieben, welches genau diese Anforderung erfüllt – allerdings vorerst nur für Instagram.

# What are you searching for?
$Hashtag = "PUTYOURHASHTAGHERE"
 
# How long to wait for the next retry - set to 0 to only search once
$SecondsBetweenRequests = 10
 
# Where do you want to store the downloaded pictures? Use no "\" at the end!
$WhereToStorePictures = "D:\Pictures\" 
 
### Don't change anything below here unless you know what you are doing! ###
 
# If the destination folder does not exist, we need to create it first
If(!(Test-Path $WhereToStorePictures -PathType Container)) 
{
    New-Item $WhereToStorePictures -ItemType Directory
}
 
$URI = "https://www.instagram.com/explore/tags/$Hashtag/"
 
# We are running this from now one until CTRL-C is pressed
Write-Host "To stop the process, press CTRL+C - otherwise it runs forever!" -ForegroundColor Yellow
While($true)
{
    # Get the whole content according to the hashtag search
    $HTML = Invoke-WebRequest -Uri $URI 
 
    # Get all the filenames of pictures with that hashtag from the HTML
    $URLs = ($HTML.Content | Select-String -Pattern '"display_url":\s.*?"edge_liked_by"' -AllMatches).Matches.Value | ForEach-Object {$_.Substring(16,$_.Length-34)}
 
    # Iterate through all the pics on the website
    ForEach($URL in $URLs)
    {
        # We need the filename to see if it was allready downloaded
        $Filename = $URL.Substring($URL.LastIndexOf('/')+1,$URL.length-$URL.LastIndexOf('/')-1) 
 
        # If the pic is not allready in the destination folder, download it
        If(!(Test-Path -PathType Leaf -Path "$WhereToStorePictures$Filename"))
        {
            Write-Host "`nNew Picture found!" # You can remove this if you want
            Start-BitsTransfer $URL -Destination "$WhereToStorePictures\" # The actual download
        }
    }
    If($SecondsBetweenRequests -eq 0) # Then we just do the download-thing once
    {
        break
    }
    else
    {
        Start-Sleep -Seconds $SecondsBetweenRequests
        Write-Host "." -NoNewline # Just to let you know it is still working... - you can remove this if you want
    }
 
}

# What are you searching for? $Hashtag = "PUTYOURHASHTAGHERE" # How long to wait for the next retry - set to 0 to only search once $SecondsBetweenRequests = 10 # Where do you want to store the downloaded pictures? Use no "\" at the end! $WhereToStorePictures = "D:\Pictures\" ### Don't change anything below here unless you know what you are doing! ### # If the destination folder does not exist, we need to create it first If(!(Test-Path $WhereToStorePictures -PathType Container)) { New-Item $WhereToStorePictures -ItemType Directory } $URI = "https://www.instagram.com/explore/tags/$Hashtag/" # We are running this from now one until CTRL-C is pressed Write-Host "To stop the process, press CTRL+C - otherwise it runs forever!" -ForegroundColor Yellow While($true) { # Get the whole content according to the hashtag search $HTML = Invoke-WebRequest -Uri $URI # Get all the filenames of pictures with that hashtag from the HTML $URLs = ($HTML.Content | Select-String -Pattern '"display_url":\s.*?"edge_liked_by"' -AllMatches).Matches.Value | ForEach-Object {$_.Substring(16,$_.Length-34)} # Iterate through all the pics on the website ForEach($URL in $URLs) { # We need the filename to see if it was allready downloaded $Filename = $URL.Substring($URL.LastIndexOf('/')+1,$URL.length-$URL.LastIndexOf('/')-1) # If the pic is not allready in the destination folder, download it If(!(Test-Path -PathType Leaf -Path "$WhereToStorePictures\$Filename")) { Write-Host "`nNew Picture found!" # You can remove this if you want Start-BitsTransfer $URL -Destination "$WhereToStorePictures\" # The actual download } } If($SecondsBetweenRequests -eq 0) # Then we just do the download-thing once { break } else { Start-Sleep -Seconds $SecondsBetweenRequests Write-Host "." -NoNewline # Just to let you know it is still working... - you can remove this if you want } }

Das Skript ist wie üblich auch im Microsoft Script Center zu finden: https://gallery.technet.microsoft.com/scriptcenter/PowerShell-Get-Instagram-7d9ddb44

Viel Spaß beim Ausprobieren oder adaptieren!

1 Kommentar

Hyper-V & PowerShell – Kerberos Delegierung für LiveMigration für mehrere Server gegenseitig eintragen

Veröffentlicht 26. Januar 2018

Hinweis: Wer mehr zu diesem Thema wissen möchte, kann gerne meinen ausführlichen Artikel zu diesem Thema lesen!

Nichts neues, aber da es mir heute wieder über den Weg gelaufen ist: Wenn man mittels Hyper-V Manager eine VM von einem Host auf einen anderen live verschieben, dann gibt es im Wesentlichen zwei mögliche Protokolle: CredSSP und Kerberos.

CredSSP ist in der Anendung grundsätzlich einfach, hat aber einen entscheidenden Nachteil: Man muss interaktiv (!) an dem Host angemeldet sein, von dem man die VM (weg) verschieben will. Andernfalls bekommt man einen hübschen Fehler:

Der Fehlertext lautet:

Fehler beim Herstellen einer Verbindung mit dem Host “DERHOSTNAME”: Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt. (0x8009030D).

Failed to establish a connection with host “THEHOSTNAME”: No credentials are available in the security package (0x8009030E)

Insbesondere auf Core-Servern bleibt hier also nur eine Möglichkeit: Man muss auf Kerberos umstellen! Dazu jedoch müssen sich die Server, zwischen denen man verschieben möchte, für das Protokoll “cifs” und “Microsoft Virtual System Migration Service” vertrauen.

Das könnte man jetzt im ActiveDirectory manuell konfigurieren – aber spätestens bei einer zweistelligen Anzahl an Hosts ist das eine sehr mühsame Klickerei. Also warum nicht PowerShell bemühen? Ich habe mir dazu schon vor einer ganzen Weile ein recht kurzes Skript geschrieben, was jeden der aufgeführten Host gegen jeden anderen berechtigt bzw. die Kerberos-Delegierung einrichtet.

Hier das Skript im Textlaut. Viel Spaß damit!

$Domain = 'domain.local'
 
# Actually not needed anymore, but who knows...
Import-Module ActiveDirectory
# Put the NetBIOS names of your hosts here
$HyperVHosts = "HOST1","HOST2","HOST3","HOST4","HOST5"
 
ForEach($Host1 in $HyperVHosts)
{
    ForEach($Host2 in $HyperVHosts)
    {
        If($Host1 -ne $Host2)
        {
            "Delegating from $Host1 to $Host2..."
            Get-ADComputer $Host1 | Set-ADObject -Add @{"msDS-AllowedToDelegateTo" = "Microsoft Virtual System Migration Service/$($Host2).$($Domain)", "cifs/$($Host2).$($Domain)", "Microsoft Virtual System Migration Service/$Host2", "cifs/$Host2"}
            Get-ADComputer $Host1 | Set-ADAccountControl -TrustedForDelegation:$false -TrustedToAuthForDelegation:$true
        }
    }
}

Download des Skriptes siehe hier:

https://github.com/HaikoHertes/scripts/blob/master/HyperV/SetTrustedForDelegationOnAllHyperVHosts.ps1

Schreibe einen Kommentar...

PowerShell – Geeigneten Host für neue VM finden

Veröffentlicht 23. Januar 2018

Wer kennt das nicht? Da will man eine neue VM installieren und stellt sich dabei unweigerlich folgende Frage:

Welcher meiner Hyper-V Hosts ist dafür am besten geeignet?

Klar, jetzt könnte man einfach im SCVMM nachsehen, ja gar die Bereitstellung darüber abwickeln und sich den besten Host vorschlagen lassen. Was aber, wenn man keinen SCVMM hat (so wie wir)? Dann hilft einem zum Glück die PowerShell – und mein kleines Script!

Dieses fragt alle aufgelisteten Hyper-V-Hosts nach deren Hardware-Ressourcen ab und listet diese dann auf. Dabei werden folgende Informationen ausgegeben:

Anzahl physischer und logischer Cores
Anzahl bereits verwendeter vCores
Verhältnis zwischen logischen und virtuellen Cores (Sollte 1:8 nicht übersteigen)
Vorhandener RAM gesamt
Belegter RAM

Im Script enthalten ist eine Funktion, die entsprechende Objekt liefert, wodurch sich das Script auch in andere Automatisierungen einbauen lässt. Ihr findet das Script als Download weiter unten. Hier erstmal das Listing:

$AllHyperVHosts = "HOST1","HOST2","HOST3","HOST4"
 
function Get-HyperVHostInfo([string]$HyperVHost)
{
 
    $vCores = ((Get-VM -ComputerName $HyperVHost).ProcessorCount | Measure-Object -Sum).Sum
 
    $Property = "numberOfCores", "NumberOfLogicalProcessors"
    $CPUs = Get-Ciminstance -class Win32_Processor -Property  $Property -ComputerName $HyperVHost| Select-Object -Property $Property 
    $Cores = ($CPUs.numberOfCores | Measure-Object -Sum).Sum
    $logCores = ($CPUs.NumberOfLogicalProcessors | Measure-Object -Sum).Sum
 
    $os = Get-Ciminstance Win32_OperatingSystem -ComputerName $HyperVHost
    $MemFreePct = [math]::Round(($os.FreePhysicalMemory/$os.TotalVisibleMemorySize)*100,2)
 
    $object = New-Object -TypeName PSObject
    $object | Add-Member –MemberType NoteProperty –Name PhysicalCores –Value $Cores
    $object | Add-Member –MemberType NoteProperty –Name LogicalCores –Value $logCores
    $object | Add-Member –MemberType NoteProperty –Name VirtualCores –Value $vCores
    $object | Add-Member –MemberType NoteProperty –Name MemTotalGB -Value ([int]($os.TotalVisibleMemorySize/1mb))
    $object | Add-Member –MemberType NoteProperty –Name MemFreeGB -Value ([math]::Round($os.FreePhysicalMemory/1mb,2))
    $object | Add-Member –MemberType NoteProperty –Name MemFreePct -Value $MemFreePct
 
    Return $object
}
 
ForEach($OneHost in $AllHyperVHosts)
{
    $HostData = Get-HyperVHostInfo -HyperVHost $OneHost
 
    Write-Host "$OneHost has $($Hostdata.PhysicalCores) physical cores, $($Hostdata.LogicalCores) logical cores and $($Hostdata.VirtualCores) virtual cores are used in all VMs overall." -ForegroundColor Yellow
    Write-Host "The Core:vCore ratio is `t`t1:$([math]::Round(($Hostdata.VirtualCores) /  ($Hostdata.PhysicalCores),2))"
    Write-Host "The Log.Core:vCore ratio is `t1:$([math]::Round(($Hostdata.VirtualCores) /  ($Hostdata.LogicalCores),2))"
    Write-Host "The system has $($Hostdata.MemFreeGB)GB of free memory and $($Hostdata.MemTotalGB)GB memory at all, which is $($Hostdata.MemFreePct)% free"
    Write-Host ""
 
}
Write-Host "The conservative approach for logical cores is `t1:8 "

$AllHyperVHosts = "HOST1","HOST2","HOST3","HOST4" function Get-HyperVHostInfo([string]$HyperVHost) { $vCores = ((Get-VM -ComputerName $HyperVHost).ProcessorCount | Measure-Object -Sum).Sum $Property = "numberOfCores", "NumberOfLogicalProcessors" $CPUs = Get-Ciminstance -class Win32_Processor -Property $Property -ComputerName $HyperVHost| Select-Object -Property $Property $Cores = ($CPUs.numberOfCores | Measure-Object -Sum).Sum $logCores = ($CPUs.NumberOfLogicalProcessors | Measure-Object -Sum).Sum $os = Get-Ciminstance Win32_OperatingSystem -ComputerName $HyperVHost $MemFreePct = [math]::Round(($os.FreePhysicalMemory/$os.TotalVisibleMemorySize)*100,2) $object = New-Object -TypeName PSObject $object | Add-Member –MemberType NoteProperty –Name PhysicalCores –Value $Cores $object | Add-Member –MemberType NoteProperty –Name LogicalCores –Value $logCores $object | Add-Member –MemberType NoteProperty –Name VirtualCores –Value $vCores $object | Add-Member –MemberType NoteProperty –Name MemTotalGB -Value ([int]($os.TotalVisibleMemorySize/1mb)) $object | Add-Member –MemberType NoteProperty –Name MemFreeGB -Value ([math]::Round($os.FreePhysicalMemory/1mb,2)) $object | Add-Member –MemberType NoteProperty –Name MemFreePct -Value $MemFreePct Return $object } ForEach($OneHost in $AllHyperVHosts) { $HostData = Get-HyperVHostInfo -HyperVHost $OneHost Write-Host "$OneHost has $($Hostdata.PhysicalCores) physical cores, $($Hostdata.LogicalCores) logical cores and $($Hostdata.VirtualCores) virtual cores are used in all VMs overall." -ForegroundColor Yellow Write-Host "The Core:vCore ratio is `t`t1:$([math]::Round(($Hostdata.VirtualCores) / ($Hostdata.PhysicalCores),2))" Write-Host "The Log.Core:vCore ratio is `t1:$([math]::Round(($Hostdata.VirtualCores) / ($Hostdata.LogicalCores),2))" Write-Host "The system has $($Hostdata.MemFreeGB)GB of free memory and $($Hostdata.MemTotalGB)GB memory at all, which is $($Hostdata.MemFreePct)% free" Write-Host "" } Write-Host "The conservative approach for logical cores is `t1:8 "

Das Script als *.ps1 Datei gibt es hier:

https://gallery.technet.microsoft.com/scriptcenter/PowerShell-Get-vCore-507be5dc

Schreibe einen Kommentar...

PowerShell Core 6.0: Generally Available (GA)

Veröffentlicht 13. Januar 2018

Wie Microsoft vor wenigen Tagen berichtet hat (siehe Blogartikel), ist PowerShell Core 6.0 seit dem 10.01.2018 GA und wird von Microsoft voll supported!

Den Download für PowerShell Core 6.0 findet man hier:

PowerShell Core für Windows

PowerShell Core für Linux / macOS

Microsoft empfiehlt das Entfernen alter PS Core Versionen und eine saubere Neuinstallation:

sudo apt remove powershell && sudo apt-get install powershell

Die Liste der unterstützen Betriebssysteme ist lang:

Windows 7, 8.1, and 10
Windows Server 2008 R2, 2012 R2, 2016
Windows Server Semi-Annual Channel
Ubuntu 14.04, 16.04, and 17.04
Debian 8.7+, and 9
CentOS 7
Red Hat Enterprise Linux 7
OpenSUSE 42.2
Fedora 25, 26
macOS 10.12+

Wichtig ist ein Hinweise am Ende des Artikels:

Windows PowerShell 3.0, 4.0, and 5.1 will continue to be supported on supported versions of Windows and Windows Server.
(Note: While Windows PowerShell 2.0 is still in support, it has been deprecated, and it’s recommend that workloads be migrated to newer versions of PowerShell.)

Für Windows PowerShell ab Version 3.0 gibt es also weiterhin Support – aber Neuerungen/Verbesserungen darf man hier wohl nicht mehr erwarten.

Viel Spaß beim Ausprobieren!

Schreibe einen Kommentar...

Erstellen einer Windows PE (WinPE) mit dem Windows Assessment and Deployment Kit (ADK)

Veröffentlicht 17. Dezember 2017

UPDATE für Windows ADK siehe unten! – Ursprünglicher Artikel vom 18.10.2012

Eine WinPE auf dem USB-Stick oder als CD/DVD ist außerordentlich praktisch. Man kann damit ein defektes Windows reparieren, seine Daten aus einem kaputten Rechner „rausholen“, ein System aus einem WIM-Image installieren, Images erzeugen und und und…

Zum Erzeugen einer solchen WinPE benötigt man entweder das Windows AIK (Automated Installation Kit) oder eben das ADK. In einer kurzen Anleitung möchte ich erklären, wie hier nun vorzugehen ist:

1.) Windows ADK herunterladen und installieren

Siehe hier: http://www.microsoft.com/de-de/download/details.aspx?id=30652

Bei der Installation reicht es, die „Windows Preinstallation Environment“ auszuwählen, der Rest ist hierzu nicht notwendig.

2.) Es gibt jetzt im Startmenü beim ADK eine „Umgebung für Bereitstellungs- und Imageerstellungstools“. Diese muss (evtl. als Administrator) gestartet werden

3.) In der sich nun öffnenden DOS-Box wird nun das Grundgerüst der WinPE erzeugt. Dazu verwendet man den Befehl:

1	copype.cmd [x86 \| amd64] C:\WinPE

Der erste Parameter gibt an, ob die Umgebung für 32- oder 64-Bit gebaut wird. Mit einer 32-Bit-Variante ist man natürlich deutlich flexibler. Der zweite Parameter gibt an, wo die WinPE erzeugt werden soll, es habdelt sich hier um einen Pfad, der noch nicht existieren darf!

Nach dem Ausführen des Kommandos (welches einige Dateien kopiert) landet man im als Ziel angegebenen Ordner. Unter „media“ befindet sich nun das, was später Bestandteil der WinPE sein wird. Hier kann man weitere Tools hinzufügen, z.B. „imagex.exe“ (einfach mit in den media-Ordner kopieren):

1	copy "C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Deployment Tools\x86\DISM\imagex.exe" C:\WinPE\media\

4.) WinPE mit deutschem Tastaturlayout

Das „original“ WinPE ist in Englisch mit englischem Tastaturlayout – das kann stören. Mit ein wenig Arbeit lässt sich das deutsche Layout installieren und aktivieren. Dazu muss die boot.wim, welche sich im meda\sources-Pfad befindet mit dism.exe gemountet und verändert werden.

Das deutsche Language-Pack befindet sich in „C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\de-de“

1
2
3

dism /Mount-Wim /MountDir:C:\WinPE\mount /wimfile:C:\WinPE\media\sources\boot.wim /index:1
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\de-de\lp.cab"
dism /image:C:\WinPE\mount /Set-AllIntl:de-DE

Dieser befehl wollte abgeschlossen werden mit:

Das Eingabegebietsschema wurde festgelegt auf: de-DE
Das Systemgebietsschema wurde festgelegt auf: de-DE
Das Benutzergebietsschema wurde festgelegt auf: de-DE
Die Benutzeroberflächensprache wurde festgelegt auf: de-DE
Der Vorgang wurde erfolgreich beendet.

Sonst liegt ein Fehler vor…

Nun noch das Image zurückschreiben:

1	dism /Unmount-Wim /MountDir:C:\WinPE\mount /commit

5.) Erzeugen der WinPE

Es gibt 2 Möglichkeiten: Einmal in Form einer ISO-Datei (für CD/DVD) oder direkt auf einen USB-Stick (Vorsicht: Dieser wird dabei formatiert, vorhandene Daten gehen verloren!)

Die beiden Befehle lauten:

1	MakeWinPEMedia /ISO C:\WinPE C:\WinPE\WinPE.iso

-> Für CD-ISO

1	MakeWinPEMedia /UFD C:\WinPE G:

-> Für USB-Stick/-HDD, G: ist der Buchstabe des USB-Datenträgers, hier kein \ verwenden

Das wäre es schon gewesen – die ISO bzw. der USB-Stick lassen sich jetzt booten…

Update vom 17.12.2017:

Für Windows ADK 10 ändern sich die Pfade und damit auch die Kommandos. Ich habe diese hier nochmal für 64 Bit (amd64) zusammengestellt. Dabei werden auch ein paar nützliche Pakete (u.a. PowerShell) hinzugefügt.

copype.cmd amd64 C:\WinPe
dism /Mount-Wim /MountDir:C:\WinPE\mount /wimfile:C:\WinPE\media\sources\boot.wim /index:1
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\lp.cab"
 
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-NetFx.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-NetFx_de-de.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-PowerShell.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-PowerShell_de-de.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-Scripting.cab"
dism /image:C:\WinPE\mount /Add-Package /PackagePath:"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-Scripting_de-de.cab"
 
dism /Unmount-Wim /MountDir:C:\WinPE\mount /commit
 
MakeWinPEMedia /UFD C:\WinPE G:

Schreibe einen Kommentar...