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

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

13Mrz/170

Windows Server Usergroup Leipzig–Übersicht über die bisherigen Treffen und Recordings

Auf den bisher drei Treffen der in 2016 neu gegründeten Windows Server Usergroup Leipzig (WSUG L.E. – organisiert über Meetup unter meetup.com/de-DE/wsugle/) haben bereits diverse Leute Vorträge gehalten, darunter auch einige MVPs.

Hier möchte ich eine kurze Übersicht der Video geben, die ihr dann ganz bequem von zuhause anschauen könnt. Die Qualität der Videos variiert leider recht stark – seid also bitte nicht gleich abgeschreckt, wenn das erste Video das ihr euch zum Anschauen ausgewählt habt nicht so toll ist. Danke!

11.08.2016 – 1. Treffen – Begrüßung & Einleitung (Haiko Hertes) Link
11.08.2016 – 1. Treffen – Windows Server 2016 (Eric Berg) Link
11.08.2016 – 1. Treffen – Storage Spaces Direct S2D (Florian Klaffenbach) Link
03.11.2016 – 2. Treffen – Begrüßung & Einleitung (Haiko Hertes) Link
03.11.2016 – 2. Treffen – Windows PowerShell DSC (Haiko Hertes) Link
02.03.2017 – 3. Treffen – Begrüßung & Einleitung (Haiko Hertes) Link
02.03.2017 – 3. Treffen – Active Directory Security (Jan-Henrik Damaschke) Link
02.03.2017 – 3. Treffen – Übersicht System Center (Haiko Hertes) Link
02.03.2017 – 3. Treffen – Übersicht Altaro Hyper-V Backup (Haiko Hertes) Link

 

Diese und auch alle folgenden Videos werdet ihr auch über diese YouTube-Playlist finden:

https://www.youtube.com/playlist?list=PLPK8RW8p4Ok8-2qVVi0AHdoKuC448OEcM

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:

16Mrz/152

SCCM + WSUS + SCUP: Updates für 3rd-Party-Anwendungen mit Hilfe des Update Publishers über SCCM verteilen

Mit Hilfe des System Center Configuration Manager 2012 / 2012 R2 ist es sehr einfach möglich, Windows- und Microsoft-Updates an die Clients und Server des eigenen Netzwerkes zu verteilen. Im Hintergrund arbeitet hierzu der bekannte WSUS-Dienst, welcher wiederum mit Microsoft kommuniziert, um die Updates von dort zu beziehen.

Wäre es nicht auch gut, wenn man auf ähnliche Weise auch Anwendungen von anderen Herstellern patchen könnte? JA! Und man kann!

Das einzige was man neben WSUS und dem SCCM braucht, ist der System Center Update Publisher, kurz SCUP. Mit diesem kann man Updates anderer Hersteller aus “externen Katalogen” beziehen. Und das beste: SCUP ist kostenlos!

Im Folgenden möchte ich die Installation und Einrichtung von SCUP zeigen. Ausgangslage ist ein installierter SCCM mit einer einzigen Primary Site (stand-alone), einem installierten WSUS und einem darauf laufenden Software Update Point (SUP).

Installation SCUP

Als erstes muss SCUP heruntergeladen werden. Dies geht über diese Quellen:

https://technet.microsoft.com/de-de/systemcenter/bb741049.aspx

bzw.

https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11940

Nach dem Download kann die Installation durchgeführt werden, welche jedoch Admin-Rechte benötigt:

scup2 scup3 scup4

Wenn es sich bei dem WSUS-Server um einen Windows Server 2008 R2 oder älter handelt, dan ist die Installation eines Patches nötig, der während des SCUP-Setup angeboten wird:

 scup5

Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0!

scup6

Konfiguration WSUS-Berechtigungen

Um nun überhaupt Updates via SCUP auf dem WSUS veröffentlichen zu können, ist noch etwas Vorarbeit nötig. Diese Vorgänge sind etwas genauer hier dokumentiert (dies betrifft idR nur den Windows Server 2012 / 2012 R2):

https://technet.microsoft.com/en-us/library/hh134747.aspx#PublishToServer2012

Folgende Schritte sind im Wesentlichen nötig:

Regedit.exe, dort bis HKEY_CLASSES_ROOT\AppID\{8F5D3447-9CCE-455C-BAEF-55D42420143B} durchhangeln und dann den Eigentümer von diesem Pfad ändern sowie für “SYSTEM” und die “Administratoren” den Vollzugriff vergeben (Durch einen Klick auf die Bilder werden diese in größerer Auflösung gezeigt):

scup10  scup11 scup12 scup13 scup14

 

Einrichtung SCUP

Nun kann der “System Center Update Publisher” über das Startmenü gestartet werden – dies sollte aber “Als Administrator” geschehen, da es sonst später zu einem Fehler kommt / kommen kann.

scup7

Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet:

scup9

Als erstes sind die Optionen zu öffnen:

scup8

Dort muss nun die Verbindung zum WSUS-Server konfiguriert werden (dabei Port beachten – WSUS 4.0 läuft auf 8530 (non-SSL) bzw. 8531 (SSL)):

scup16

Nun fehlt noch ein Zertifikat zum signieren der Updates. Hier kann auch ein selbstsigniertes Zertifikat erzeugt und verwendet werden. Dies geschieht über den “Create”-Button:

scup16b

Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert:

scup17

Zertifikat passend einbinden

Das WSUS-/SCUP-Zertifikat muss nun in die “Trusted Publishers” (Vertrauenswürdige Herausgeber) und die “Trusted Root Certificates” (Vertrauenswürdige Stammzertifizierungsstellen) des Computer-Kontos (WSUS/SCUP-Server) importiert werden, vorher muss es natürlich exportiert werden:

scup18 scup18b scup19 scup20

Updates über SCUP an den WSUS veröffentlichen

Nun können die ersten Updates über den SCUP veröffentlicht werden. Dazu muss zunächst ein Katalog hinzugefügt werden:

scup21

Beispielhaft verwende ich hier den “Adobe Reader X” Katalog:

scup22

Danach können die Updates aus diesem Katalog in den SCUP importiert werden:

scup23

scup24

scup25

scup26

scup27

Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden:

scup28

scup29

Diese neue Veröffentlichung (Bei mir heißt sie “März 2015”) kann nun veröffentlicht werden. Dazu wird sie unter “Publications” ausgewählt, die jeweiligen Updates markiert und dann auf “Publish” geklickt.

scup30

Dabei sollten die Updates vom SCUP signiert werden:

scup31

scup32 scup33

Updates über SCCM verteilen

Nun kann im SCCM eine erste Synchronisierung durchgeführt werden. Diese ist nötig, damit der SUP (SCCM) “erfährt”, dass es nun auch Adobe als neuen Hersteller und Adobe Reader als Produkt gibt:

scup34 Um den Vorgang zu beobachten bietet der SCCM ein eigenes Werkzeug, alternativ würde auch CMTrace gegen die WSyncMgr.log funktionieren:

scup35 scup36 scup37scup38

Die letzte Meldung zeigt an, dass die Synchronisierung abgeschlossen ist. Nun kann das neue Produkt (in meinem Fall der Adobe Reader) für die Verteilung durch den SUP aktiviert werden:

scup39 scup40

Dabei ist auch der Reiter “Klassifizierungen” zu beachten – wenn das gewünschte Update ein “Sicherheitsupdate” ist, SUP aber nur “Wichtige Updates” synchronisiert, dann wird man nicht zu einem positiven Ergebnis kommen.

Nun ist noch einmal eine Synchronisierung des SUP nötig, damit dieser die bekannten Updates vom WSUS “kennenlernt”.

scup34

Danach stehen die Updates, in meinem Fall für den Adobe Reader, im SCCM wie ein reguläres Windows Update zur Verfügung und können verteilt und bereitgestellt werden:

scup41

Viel Spaß damit!

18Dez/140

AutoAdminLogon für Windows Server 2012 R2 und andere OS

Manchmal besteht der Wunsch, auf einem Windows-System eine automatische Anmeldung nach dem (Neu)Start durchzuführen. Dies ist mit sehr einfachen Mitteln möglich und funktioniert sowohl bei Client- als auch Server-Betriebssystemen, auch bei älteren. Nötig ist dazu nur der Zugriff auf die Registry und ein passendes Benutzerkonto.

Als erstes wird der Registrierungseditor mittels “regedit.exe” geöffnet:

autoadminlogon1

Dort muss zu dem Schlüssel unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon navigiert werden.

Abschließend sind folgende Schlüssel nötig (alle als Zeichenfolge, REG_SZ)

  • AutoAdminLogon = “1”
  • DefaultUserName = BENUTZER
  • DefaultPassword = PASSWORT
  • DefaultDomainName = DOMÄNE

So etwa wie im Screenshot…

autoadminlogon2

Das war es schon gewesen. Beim nächsten Neustart ist die automatische Anmeldung aktiv…

9Okt/140

Änderung bei Microsoft’s Update-Strategie

Wie Jim Alkove, Windows Enterprise Program Manager,  in einem Blog-Artikel vor wenigen Tagen bekannt gegeben hat, wird es bei künftigen Betriebssystemen eine Änderung bezüglich Updates geben.

Enterprise-Kunden können dann aus einem von drei Pfaden wählen, der bestimmt, wie Updates verteilt werden. Ein Pfad sieht vor, alle Updates so schnell wie möglich zu bekommen und zu verteilen, um immer up-to-date zu sein. Ein weiterer Pfad sieht vor, nur die kritischen und Sicherheits-Updates zu bekommen. Der dritte Pfad wird ein Mittelweg zwischen den beiden Extremen sein.

Dabei soll auch die Möglichkeit bestehen, die eigenen Benutzer aufzuteilen und gruppenabhängig die Zuweisung zu einem dieser Pfade vorzunehmen.

Was Bestand haben wird ist, das Sicherheitsupdates und andere kritische Updates monatlich veröffentlicht werden. Vermutlich wie bekannt zum “Patch-Tuesday”.

Nun bleibt also abzuwarten, wie sich das alles entwickelt und wie Microsoft diese Ankündigungen umsetzt.