Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

13Jan/180

PowerShell Core 6.0: Generally Available (GA)

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!

17Dez/170

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

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:

1
2
3
4
5
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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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:
22Mrz/170

PowerShell – RAM-Konfiguration eines Systems auslesen

Bei der Frage, ob ein Server (oder auch Client) noch etwas mehr RAM vertragen kann, stellt sich oft die Frage, wieviel RAM dann aktuell in wie vielen Modulen verbaut ist und wieviele Slots noch frei sind. Natürlich gibt es dazu auch bereits grafische Werkzeuge, die das können, aber spätestens, wenn mehrere Maschinen (ggf. auch Core-Server ohne GUI) abgefragt werden sollen, kann die PowerShell ihre Stärken ausspielen. Daher habe ich ein kleines Skript gebaut, welches diese Aufgabe erfüllt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[Cmdletbinding()]
Param(
    [string]$Computername = "localhost"
)
cls
$PysicalMemory = Get-WmiObject -class "win32_physicalmemory" -namespace "root\CIMV2" -ComputerName $Computername
 
Write-Host "Memory Modules:" -ForegroundColor Green
$PysicalMemory | Format-Table Tag,BankLabel,@{n="Capacity(GB)";e={$_.Capacity/1GB}},Manufacturer,PartNumber,Speed -AutoSize
 
Write-Host "Total Memory:" -ForegroundColor Green
Write-Host "$((($PysicalMemory).Capacity | Measure-Object -Sum).Sum/1GB)GB"
 
$TotalSlots = ((Get-WmiObject -Class "win32_PhysicalMemoryArray" -namespace "root\CIMV2" -ComputerName $Computername).MemoryDevices | Measure-Object -Sum).Sum
Write-Host "`nTotal Memory Slots:" -ForegroundColor Green
Write-Host $TotalSlots
 
$UsedSlots = (($PysicalMemory) | Measure-Object).Count 
Write-Host "`nUsed Memory Slots:" -ForegroundColor Green
Write-Host $UsedSlots
 
If($UsedSlots -eq $TotalSlots)
{
    Write-Host "All memory slots are filled up, none is empty!" -ForegroundColor Yellow
}

Die Ausgabe sieht dann etwa so aus:

PS_Memory1

Auf meinem Notebook mit nur zwei RAM-Slots (beide belegt) kommt zusätzlich noch eine kleine “Warnung”:

PS_Memory2

Ihr könnt das Skript auch hier herunterladen:

https://gallery.technet.microsoft.com/scriptcenter/Get-Memory-RAM-configuratio-35dda12e

29Sep/160

Windows 8 / 8.1 / 10: Bestimmte WLAN-Verbindungen per GPO als getaktet festlegen

Seit Windows 8 gibt es die Möglichkeit, eine WLAN- oder WWAN-Verbindung als “getaktet” (metered) festzulegen. Das hat Auswirkungen auf die Nutzung dieser Verbindung. Ziel ist es dabei, eine Verbindung mit beschränktem Datenvolumen oder Kosten pro kB/MB, möglichst wenig mit Dingen zu belasten, die man später auch über unbeschränkte Datenverbindungen machen kann, z.B. das Herunterladen von Windows Updates oder die Bereitstellung neuer Software, die erst aus dem Netzwerk geladen werden muss.

Wenn man nun z.B. in einer kleinen Außenstelle, auf einer Baustelle oder sonst wo einen LTE- oder UMTS-Hotspot bereitstellt, damit einige Mitarbeiter darüber arbeiten können, dann haben diese Verbindungen in der Regel ein Datenlimit pro Monat, nach dessen Erreichen die Geschwindigkeit massiv gedrosselt wird, z.B. 3, 5 oder 10GB. Will man nun für diese Mitarbeiter erreichen, dass z.B. keine Windows-Updates über diese Verbindung geladen werden, dann kommen die getakteten Verbindungen zum Einsatz und es wäre wünschenswert, das entsprechende WLAN per Gruppenrichtlinie als “getaktet” zu bestimmen.

Das Problem dabei:

In den GPOs lassen sich zwar die Kosten für WLAN festlegen (es gibt dabei 3 Stufen, “unrestricted”, “fixed” und “variable”, wobei “fixed” bedeutet, dass die Kosten pro übertragenem Kilo- oder Megabyte entstehen und “variable” für ein monatliches Limit steht), dies gilt dann aber für ALLE WLAN-Verbindungen:

MeteredConn1

Als Alternative kann man nun aber das gute, alte “netsh” benutzen. Damit lassen sich Verbindungsdetails zeigen:

MeteredConn2

Der Befehl dazu lautet:

netsh wlan show profile WLANSSID

Will man nun für eine Verbindung die Kosten verändern, so geht dies folgendermaßen:

MeteredConn3

Der Befehl dazu lautet:

netsh wlan set profileparameter name=WLANSSID cost=variable  (oder alternativ “fixed”)

Daraus braucht man nun nur noch ein passendes kleines Script basteln und dieses per GPO wirken lassen:

MeteredConn4

24Jun/160

Windows Server / Client: Alle geplanten Tasks per PowerShell auslesen

Insbesondere auf Servern kann es schnell vorkommen, dass hier sehr viele Gepante Tasks ("Aufgaben") vorhanden sind, die aber über viele Ordner im Taskplaner verteilt sind:

TaskPlaner

Wenn man nun einen bestimmten Task sucht oder einfach wissen möchte, was so an Aufgaben alles geplant ist, dann ist die GUI hier leider keine große Hilfe. Aber mit der PowerShell bekommt man schnell das Gewünscht:

1
Get-ScheduledTask | Select URI,@{n="LastRun";e={($_ | Get-ScheduledTaskInfo).LastRunTime}} | Sort-Object LastRun

TaskPlaner2

Viel Spaß damit!

22Mrz/162

Digitizer / Touchscreen von Surface Pro oder anderem Tablet remote bzw. als erweiterten Bildschirm benutzen

Kürzlich stand ich vor der Aufgabe, altes Fotomaterial aufzuarbeiten um dabei insbesondere Schäden an den Fotos und andere Bildfehler zu korrigieren. Für derartige Aufgaben nutze ich sehr gern Photoshop Elements. Für einen schmalen Taler bekommt man viele Funktionen (natürlich nicht so viel wie beim “richtigen” Photoshop, aber das kostet fast 10x soviel). Das von mir sonst benutzte Adobe Lightroom kann das leider nicht oder nur mit riesigem Aufwand.

Nachdem ich das erste Bild bearbeitet hatte, kam mir die Idee, auf meinem Surface Pro weiter zu machen, da dieses ja über einen Digitizer verfügt und mir somit das Arbeiten mit einem Stift ermöglicht hätte. Ein Grafiktablet ala Wacom o.ä. habe ich leider nicht, bin davon aber auch nicht so überzeugt. Bei den halbwegs bezahlbaren ist kein Display enthalten, so dass man auf dem Tablet nur arbeitet, das Ergebnis aber auf dem Monitor zu sehen ist. Beim Surface hingegen kann ich mit dem Stift direkt “im Bild” arbeiten.

Nun hatte ich aber kein Photoshop Elements auf dem Surface und mangels DVD-Laufwerk hätte ich erst die DVD auf USB.-Stick kopieren müssen. Also habe ich nach einer Möglichkeit gesucht, das Surface einfach nur als zweiten Bildschirm an meinem “Haupt-PC” (wo das Photoshop läuft) zu benutzen – und ich wurde fündig. Die Lösung nennt sich “Splashtop”. Wie das genau funktioniert, seht ihr in einem meiner YouTube-Videos:

21Okt/150

Windows 10: VPN-Verbindungen nutzen immer Remote-Gateway

Unter früheren Windows-Versionen konnte man bei VPN-Verbindungen noch den gesamten IPv4-Teil konfigurieren. Dort gab es eine Option “Standardgateway für das Remotenetzwerk verwenden”, die man abschalten konnte:

43e8230241a19524c77c2973e1ce137b

Standardmäßig war/ist diese Option eingeschaltet und sorgt dafür, dass SÄMTLICHER Datenverkehr über das Remote-Netz geleitet wird, auch das, was eigentlich “DIREKT” ins Internet gehen könnte. Der Vorteil dabei ist, dass der Traffic vom eigenen Endgerät bis zum Firmennetzwerk verschlüsselt ist, was insbesondere dann nützlich ist, wenn man in einem Internetcafe oder Hotel-WLAN sitzt und nicht klar ist, wer den Verkehr mithören kann.

Will man nun auf einem Windows 10 Client dieses Verhalten ändern – also erreichen, dass nur Traffic, der für das Remote-Netzwerk gedacht ist, über VPN geht, der Rest direkt ins Internet, müsste man diesen Haken entfernen, was bei Windows 10 nicht mehr geht, da sich die IPv4-Optionen der VPN-Verbindung nicht mehr öffnen lassen.

Was man aber tun kann, ist dieses Verhalten mit Hilfe der PowerShell herbeizuführen, und zwar mit diesem Aufruf:

123

Damit wird für alle VPN-Verbindungen das “Split-Tunneling” aktiviert, was eben diesem Haken entspricht.

Hier der Aufruf nochmal zum direkt Kopieren:

1
 Get-VpnConnection | Set-VpnConnection -SplitTunneling $True

456

29Jul/150

Windows 10 wird als RTM in MSDN angeboten

Nur als kurze “Randnotiz”: Seit heute kann man die Windows 10 ISOs in der MSDN als RTM-Version herunterladen!

Windows10_in_MSDN

Dabei stehen zur Verfügung:

  • Windows 10 Home 1
  • Windows 10 Pro 1
  • Windows 10 Education 1
  • Windows 10 Enterprise 1
  • Windows 10 Enterprise 2015 LTSB
  • Windows 10 Features on Demand 2
  • Windows 10 Language Interface Packs
  • Windows 10 Symbols
  • Windows 10 Symbols Debug/Checked
  • Windows 10 IoT Core for MinnowBoard MAX (x86)
  • Windows 10 IoT Core for Raspberry Pi 2 (ARM)
16Jul/150

Windows 10 wird in RTM-Build 10240 an Insider ausgerollt

Seit heute Morgen wird Windows 10 in dem Build 10240 an die Teilnehmer des Insider-Programms (Fast-Ring) ausgerollt. Dabei handelt es sich nun scheinbar um die finale RTM Version. Der Hinweis auf die Preview ist nach dem Update und Neustart vom Desktop verschwunden.

Was ich bisher gar nicht geprüft hatte, mich aber nun sehr interessiert hatte: Windows 10 heisst nun endlich auch “intern” Windows 10 und nicht etwa “Windows 6.4” oder so. Klasse!

win10_10240_1

win10_10240_2

10Jul/150

Der nächste Windows 10 Build – 10166 – get ready for RTM!

Der nächste Build von Windows 10 wird im fast-Ring ausgerollt: 10166! Es geht jetzt also weiter Schlag auf Schlag in Richtung RTM. Vermutlich wird 10166 aber eine der letzten Vorab-Versionen sein.

Einzige Neuerungen, von der man etwas sehen kann: Die Microsoft Wi-Fi App. Damit kann man gegen Gebühr WLAN-Netze nutzen. Aktuell ist dies aber auf das Areal rund um den Microsoft-Sitz in Seattle beschränkt, soll aber zeitnah in ganz Amerika zur Verfügung stehen. Für Europa gibt es noch keine Ankündigungen in diese Richtung.

Build10166

Der schnellste Weg zur Build 10166 ist (nach dem Update aus dem Vorgänger) der Download der ISO mit Build 10162 und anschließendem Upgrade:

http://windows.microsoft.com/en-us/windows/preview-iso