Drücke "Enter", um den Text zu überspringen.

Kategorie: Windows Client

Azure Virtual Desktop – ein merkwürdiger Fehler und seine banale Lösung

Veröffentlicht 11. August 2021

Vor kurzem kam mir in einer frisch aufgebauten Azure Virtual Desktop (AVD) Umgebung ein merkwürdiger Fehler unter. Nach dem Login und der Auswahl der gewünschten App startet der Verbindungsaufbau. Dieser schlägt dann jedoch mit folgender Fehlermeldung fehl:

Wir konnten leider keine Verbindung mit „Outlook“ herstellen.

Mit dem Gateway konnte aufgrund eines Fehlers keine Verbindung hergestellt werden. Sollte das Problem wiederholt auftreten, wenden Sie sich an Ihren Administrator oder an den technischen Support.

Auf englischsprachigen Systemen sieht es dann so aus:

Oops, we couldn’t connect to „Outlook“

We couldn’t connect to the gateway because of an error. If this keeps happening, ask your admin or tech support for help.

Meine Suche im Internet zu möglichen Ursachen brachte leider nichts passendes. Da ich den Grund des Fehlers dann aber kurz darauf selber bemerkt habe, dachte ich, ich dokumentiere das Ganze hier kur, falls noch andere Nutzer in diese „Falle“ tappen:

Die Ursache des Fehlers hat nichts mit Netzwerk oder anderen Verbindungsproblemen zu tun, wie die Meldung zunächst vermuten lässt.

Ich hatte mich schlichtweg am AVD Webclient mit einem User angemeldet, den es in der Windows Server Domäne (ADDS / NTDS) nicht gibt, sondern nur im Azure AD. Die Anmeldung am Host des Hostpools erfolgt aber gegen einen regulären Domänencontroller! Der cloud-only User kann sich noch problemlos am AVD Webclient anmelden, dieser gibt auch keine Warnung o.ä., aus. Nur das Starten der Apps geht dann eben nicht…

Wenn ihr also auch auf diesen Fehler stoßt: Stellt sicher, dass der verwendete Benutzer in der Domäne bekannt und das Passwort dort identisch ist!

1 Kommentar

PowerShell – Windows Client oder Windows Server als NTP Server benutzen

Veröffentlicht 28. Juni 2018

Sicherlich ist den Meisten bekannt, dass Windows seit vielen Generationen out-of-the-box als NTP-Client genutzt werden kann – also die Uhrzeit von einem NTP-Server beziehen kann. Aber dass sowohl Windows Server (seit WS2003) als auch Windows Client (seit Win XP) auch mit Bordmitteln als NTP-Server genutzt werden können, dürfte weitgehend unbekannt sein. Das Ganze lässt sich in einigen wenigen Schritten erreichen:

  • Windows Zeitdienst W32Time auf automatischen Start setzen
  • W32Time als NTP-Server konfigurieren (Registrierungsschlüssel)
  • W32Time Dienst neustarten
  • Firewall auf udp/123 für Verbindungen von außen öffnen

Natürlich kann man das sehr effizient mittels PowerShell erledigen. Dazu habe ich ein einfaches Script geschrieben:

# This script makes a Windows 10 PC acting as a NTP server 
 
#Enable autostart for W32Time Service
Set-Service -Name W32Time -StartupType Automatic
 
# Configure W32Time Service to act as a NTP server
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer -Name Enabled -Value 1
 
# Update W32Time service
w32tm.exe /config /update
 
# Restart W32Time service
Restart-Service -Name W32Time
 
# Check configuration - VMICTimeProvider / Enabled should be "1" now
w32tm.exe /query /configuration
 
# Create an inbound rule for the Windows Firewall
New-NetFirewallRule -DisplayName "Allow NTP UDP/123 Incomming" -Profile Any -Action Allow -Direction Inbound -LocalPort 123 -Protocol udp -Enabled true
1 Kommentar

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)

image

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

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

image

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

image

Zur Verfügung stehen:

  • Debian GNU/Linux
  • Ubuntu
  • OpenSUSE
  • SLES
  • Kali Linux

Der Start kann dann direkt aus dem Startmenü erfolgen:

image

Die Ersteinrichtung dauert einen Moment:

image

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

image

… und dann kann das Linux genutzt werden.

image

Viel Spaß beim Ausprobieren und Benutzen!

2 Comments

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:

image

image

Dort finden sich dann die beiden OpenSSH Optionen:

image

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*

image

image

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.

image

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

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:
Schreibe einen Kommentar...

PowerShell – RAM-Konfiguration eines Systems auslesen

Veröffentlicht 22. März 2017

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

Schreibe einen Kommentar...

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

Veröffentlicht 29. September 2016

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

Schreibe einen Kommentar...

Windows Server / Client: Alle geplanten Tasks per PowerShell auslesen

Veröffentlicht 24. Juni 2016

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!

Schreibe einen Kommentar...