Thumbnails aktivieren im Windows Explorer (Windows Server)

Da ich in meinen Kursen immer öfters an die Frage stoße wie man Vorschaubilder im Windows Explorer anzeigen kann. Heute mal ein kurzer Blogartikel dazu. Im Normalfall sieht man Bilder im Datei Explorer nur als Symbol Da es aber gerade für Web oder Fileserver interessant sein kann auch am Server die Bilder sehen zu können ohne diese extra öffnen zu müssen hier der kurze Weg. Und der Einfachheit halber einfach kurz mit dem “Problem Steps Recorder” (psr.exe) aufgenommen. Step 1: Klick mit der linken Maustaste durch Benutzer auf "Registerkarte 'Datei' (Schaltfläche)" in "Bilder" Step 2: Klick mit der linken Maustaste durch Benutzer auf "Ordner- und Suchoptionen ändern (Menüelement)" Step 3: Klick mit der linken Maustaste durch Benutzer auf "Ansicht (Registerkartenelement)" in "Ordneroptionen" Step 4: Klick mit der linken Maustaste durch Benutzer auf "Immer Symbole statt Miniaturansichten anzeigen (Strukturelement)" in "Ordneroptionen" Step 5: Klick mit der linken Maustaste durch Benutzer auf "OK (Schaltfläche)" in "Ordneroptionen" Step 6: Klick mit der linken Maustaste durch Benutzer auf "Elementansicht (Liste)" in "Bilder"

Betriebssysteme mit WDS verteilen

Wer kennt es nicht? Die bestellten PC’s von letzter Woche sind endlich in der IT angekommen. Nun wir [Mehr]

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:    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:   Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0! 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):       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. Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet: Als erstes sind die Optionen zu öffnen: 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)): 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: Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert: 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: 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: Beispielhaft verwende ich hier den “Adobe Reader X” Katalog: Danach können die Updates aus diesem Katalog in den SCUP importiert werden: Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden: 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. Dabei sollten die Updates vom SCUP signiert werden: 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: Um den Vorgang zu beobachten bietet der SCCM ein eigenes Werkzeug, alternativ würde auch CMTrace gegen die WSyncMgr.log funktionieren: 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: 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”. 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: Viel Spaß damit! Sie benötigen weitere Informationen zum SCCM und den Möglichkeiten, Updates zu verteilen? Dann schauen Sie sich unseren Kurs zum System Center Configuration Manager 2012 R2 an!

Server 2012 R2: WDS macht Probleme beim Aufzeichnungsabbild

Wie mein Kollege Eik bereits vor geraumer Zeit festgestellt hat, gibt es ein Problem bei einer konkreten Konstellation in Bezug auf WDS: In den Windows Bereitstellungsdiensten gibt es die Möglichkeit, ein “Aufzeichnungsabbild” aus einem regulären “Startabbild” zu erzeugen. So natürlich auch beim aktuellen Windows Server 2012 R2: Häufig kommt es dann aber bei dieser Server-Version später beim Booten der aufzuzeichnenden Maschine zu einem Fehler: Dieser Fehler tritt dann auf, wenn man: auf einem Windows Server 2012 R2 (mit oder ohne Update1) im WDS ein Startabbild (Boot Image) auf Basis eines Windows Server 2012 R2 MIT Update1 oder Windows 8.1 MIT Update1 hinzufügt (dabei ist es dann später egal, auf welchem Startabbild das Aufzeichnungsabbild basiert) auf einem Windows Server 2012 (“R1”) im WDS ein Startabbild auf Basis eines Windows Server 2012 R2 mit Update1 oder Windows 8.1 mit Update1 erzeugt Der Fehler würde NICHT auftreten, wenn man vor dem Erzeugen des Aufzeichnungsabbildes noch nie ein Startabbild von Windows 8.1 Update1 oder Windows Server 2012 R2 Update1 importiert hatte. Natürlich kann man den Fehler aber auch anderweitig umgehen bzw. beheben: Dazu hinterlegt man zunächst das gewünschte Startabbild (dabei spielt es keine Rolle, ob bisher ein Update-1-Startabbild hinterlegt wurde oder nicht, das zu hinterlegende Abbild selbst darf auch von einer Update-1-Version stammen): Danach erzeugt man aus diesem ein Aufzeichnungsabbild: Dabei sollte man dass entstehende Abbild nicht direkt dem WDS Server hinzugefügt wird: Anschließend muss das entstandene WIM-File (in meinem Beispiel “C:\aufz.wim”) mittels DISM gemountet werden: Für das Mounten verwendet man einen Aufruf in dieser Form: dism /Mount-Wim /WimFile:C:\aufz.wim /index:1 /MountDir:C:\mount (Achtung: Keine Leerzeichen nach den Doppelpunkten!) Im Anschluss kann die Datei direkt wieder “unmounted” werden (ohne dass sie dabei inhaltlich wirklich verändert wurde): Hierzu wird folgender Aufruf verwendet: dism /Unmount-Wim /MountDir:C:\mount /commit Das nun neu erzeugte WIM-File kann jetzt als funktionsfähiges Aufzeichnunge-/Startabbild auf dem WDS-Server hinterlegt werden: Nun kann eine (Test-)Maschine per PXE gebootet werden, es sollte nun, da es mehrere Startabbilder gibt, eine Auswahl möglich sein: Wenn man das Aufzeichnungsabbild gewählt und die Maschine komplett gebootet hat sollte in etwa folgendes Menü zu sehen sein: Nun kann die Festplatte der (Test-)Maschine aufgezeichnet werden. Wichtig ist dabei allerdings, dass dies nur funktioniert, wenn man das dort laufende Betriebssystem vorher mit sysprep vorbereitet hat. Wie man mit dem WDS-Server den Alltag erleichtert und die Installation von Client- und Server-Betriebssystemen automatisieren kann erfahren Sie in unseren Kursen “Windows Server 2012 R2 Administration” und “Windows Server 2012 R2 Powerwoche”.

Stand-alone DHCP-Server plus DHCP-Server in Domäne gleich Problem?!

Wenn man einen DHCP-Server betreibt, dann sollte dies bevorzugter Weise in einer Domäne geschehen – also mit dem DHCP-Server als Mitglied des Active Directory. Dort benötigt dieser eine Autorisierung, welche dafür sorgt, dass dieser Server dann auf eingehende Anfragen (DHCP Request) reagiert. Solange er nicht autorisiert ist, vergibt er auch keine Adressen. Soweit so gut. Wenn man einen DHCP-Server NICHT in Active Directory integriert, kann man ihn auch nicht autorisieren, er verrichtet dennoch seine Dienste – bis er auf einen autorisierten Server trifft! Dann nämlich wird der nicht autorisierte Server (der nicht Mitglied der Domäne ist) seinen Dienst einstellen und selbst wenn man ihn wieder manuell aktiviert sich sofort wieder abschalten. Damit ist es also nicht so ohne Weiteres möglich, zwei DHCP-Server im selben Netz zu betreiben. Nun kann es aber sein, dass genau das gewünscht ist – weil die Server z.B. Adressen für unterschiedliche MAC-Adressen verteilen. Hier muss man also eingreifen und den nicht-autorisierten DHCP Server daran hindern, sich abzuschalten. Das “Zauberwort” hier heißt “Rogue Detection” – und genau die muss deaktiviert werden. Dies geht nicht über eine GUI, sondern muss über eine Registrierungswert geändert werden. Dieser heisst KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters \DisableRogueDetection Mittels des folgenden Aufrufs lässt sich der Eintrag recht schnell anlegen: reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\DHCPServer\Parameters /v DisableRogueDetection /t REG_DWORD /d 1 Dieser Schlüssel ist sehr oberflächlich in folgendem KB-Artikel bei Microsoft beschrieben: https://support.microsoft.com/kb/949530

Windows Server 2012 R2: WSUS automatisch bereinigen

Mit der Zeit sammeln sich auf einem WSUS (Windows Server Update Service) einige Updates an. Da können auch schnell mehrere hundert Gigabyte an Daten zusammenkommen. Nicht jedes Update, welches auf dem WSUS gespeichert ist, wird aber noch benötigt. Daher ist es aus Gründen der Speicherplatzeffizienz sinnvoll, von Zeit zu Zeit etwas aufzuräumen. Dafür gibt es schon seit längerem einen passenden Assistenten in der WSUS-Konsole: Dieser Assistent ließ sich “früher” (also z.B. unter Windows Server 2008 R2, WSUS 3.0 SP2) nur manuell oder über komplizierte Skripte ausführen. Seit Windows Server 2012 lässt sich WSUS aber auch über PowerShell steuern. Hier gibt es ein passendes Commandlet “Invoke-WsusServerCleanup”, welches die Bereinigung durchführt. Als Parameter kann verwendet werden: Invoke-WsusServerCleanup [-CleanupObsoleteComputers] [-CleanupObsoleteUpdates] [-CleanupUnneededContentFiles] [-CompressUpdates] [-DeclineExpiredUpdates] [-DeclineSupersededUpdates] [-UpdateServer <IUpdateServer> ] [-Confirm] [-WhatIf]   Damit lässt sich unkompliziert steuern, welche Komponenten beräumt werden sollen. Dieses PowerShell-Commandlet kann nun z.B. im Rahmen eines kleinen Skriptes regelmäßig und automatisch (z.B. per Aufgabenplanung) ausgeführt werden. Damit spart man sich die regelmäßige, manuelle (aufwändige) Bereinigung mit Hilfe des Assistenten. Die komplette Syntax zum angesprochenen PowerShell-Commandlet findet sich hier: http://technet.microsoft.com/en-us/library/hh826162.aspx   Sie haben Interesse, mehr über den WSUS Server zu erfahren? Dann besuchen Sie unsere Windows Server 2012 R2 Kurse! Oder vielleicht möchten Sie mehr über PowerShell lernen?

Auswertung zum StoragePool-Benchmark

Dies ist ein Update zu meinem vorherigen Beitrag über die Storage-Pools im Windows Server 2012 R2 http://blog.ppedv.de/post/2014/08/13/windows-server-2012-r2-storage-pools-mit-ssd-tiering.aspx Ich habe noch ein paar weitere Tests bezüglich der Storage-Pools gemacht und diese in einer Tabelle ausgewertet:   Zusammenfassend kann man hier nun also sehen: In den lesenden Disziplinen ist ein “echtes” RAID0 mittels RAID-Controller und den beiden SSDs am schnellsten In den schreibenden Disziplinen ist der Storage-Pool mit einem Simple-Laufwerk am LSI-Controller am besten – dabei auch deutlich schneller als das controllereigene RAID0 von LSI und HP mit den SSDs Der direkte Vergleich zwischen den Storage-Pools am HP-Controller und am LSI-Controller geht erstaunlicherweise zu Gunsten des LSI-Controllers aus und dies auch durchweg, obwohl der LSI-Controller (im Gegensatz zum HP-Controller) über keinen eigenen Cache verfügt (mit aktiviertem BBWC würde der HP-Controller wohl beim Schreiben noch deutlich besser werden) Geht es um Datenredundanz (hier also RAID1 o.ä.), dann ist der Storage-Pool im Mirror-Modus mit der Kombination HDD plus SSD am besten! Ein Storage-Pool mit 2 HDDs im Mirror-Mode ist fast genau so gut (oder genau so schlecht) wie die RAID1-Implementierung des HP- oder des LSI-Controllers

Windows Server 2012 R2: Storage Pools mit SSD-Tiering

Seit dem Windows Server 2012 beherrschen die Microsoft-Server-Systeme die Möglichkeit, so genannte “Storage Pools” (Speicherpools) zu bilden. Dabei handelt es sich um einen Zusammenschluss verschiedener lokal angebundener oder als LUN eingebundener Datenträger, z.B. via SAS, SATA oder auch USB. Bei den LUNs stehen iSCSI und FiberChannel zur Verfügung. Die grundsätzliche Idee ist hier, eine Art Storage abzubilden, quasi eine “Storage-Virtualisierung”. Aus einem gebildeten Storage-Pool können anschließend logische Laufwerke, sogenannte “Speicherplätze” (Storage Spaces), gebildet werden. Dabei kann die Organisation des Speichers gewählt werden. Zur Verfügung stehen “Simple” (eine Art RAID0, keine Datensicherheit, aber eine Erhöhung des Durchsatzes durch die gleichzeitige Nutzung aller beteiligter Festplatten), “Mirror” (Eine Art RAID1 mit einfacher oder doppelter Spiegelung der Blöcke um ein Erhalten der Daten auch bei Ausfall einer Festplatte sicherzustellen) und “Parity” (Funktioniert wie RAID5; Paritätsdaten, die ein Wiederherstellen der Daten bei Ausfall einer Festplatte möglich machen, werden über alle beteiligten Datenträger verteilt). Dabei spielen Größe, Hersteller, Bus-Typ und Co. der Festplatten nahezu keine Rolle – ein Faktor, der die Storage Pools deutlich von klassischen RAID-Controllern unterscheidet. Ein weiterer Faktor, der Storage-Pools von üblichen “lokalen” Speichertechnologien abgrenzt, ist die Möglichkeit, nachträglich Festplatten hinzuzufügen oder durch größere auszutauschen, um den zur Verfügung stehenden Speicherplatz zu erhöhen. Seit dem zweiten Release des Server 2012 wird diese Technologie noch erweitert: Der Windows Server 2012 R2 beherrscht das sogenannte “SSD-Tiering” (Speicherebenen). Hierbei werden klassische HDDs und SSDs gemeinsam in einem Pool genutzt und die häufig gelesenen Daten auf die SSD verschoben, die seltener genutzten Daten bleiben auf der HDD. Alternativ kann man SSDs auch als Write-Back-Cache einsetzen. (Eine Anleitung, wie das genau eingerichtet werden kann, werde ich in Kürze ebenfalls veröffentlichen.) Diese Möglichkeit – sowie Speicherpools insgesamt – sind in meinen Augen vor allem für kleinere und mittlere IT-Landschaften interessant, in denen keine “ausgewachsenen” SANs zum Einsatz kommen (können). Daher war für mich interessant, wie gut diese Technologie funktioniert und welche Geschwindigkeitsvorteile hierbei erzielt werden können. Daher habe ich diverse Test-Messungen unternommen, welche ich nun hier auswerten möchte. Zum Einsatz kam ein Fujitsu-Siemens-Server mit einem 4-Kern-Xeon-Prozessor und 8GB RAM, dazu 2 SATA-Festplatten von Western Digital und 2 SATA-SSDs von Crucial, jeweils mit etwa 250GB Speicher. Zuerst habe ich die Festplatten einzeln getestet, um Vergleichswerte zu haben: Hier ist natürlich zu erkennen, dass die SSD (rechts) deutlich schneller als die HDD (links) ist – und zwar in allen Disziplinen. Weiterhin habe ich den Server-eigenen LSI RAID-Controller getestet (jeweils im RAID0, links 2x HDD, rechts 2x SSD): Beim Lesen schafft der Controller sogar etwa doppelt so schnelle Werte – beim Schreiben brechen die Werte dafür dann recht ordentlich ein, der Betrieb ist also langsamer als eine einzelne Platte! Und nun im direkten Vergleich ein Betrieb via Storage-Pool im “Simple”-Modus (links) und im “Mirror”-Modus (rechts): Hier sieht man zunächst (CrystalDiskMark) etwa folgende Ergebnisse: - Im Simple-Modus erreicht der Pool fast die Lese-Raten des RAID0 aus 2x SSD am Controller, übertrifft die Schreibraten aber deutlich - Auch bei den wahlfreien Zugriffen sind durchweg bessere Werte zu sehen als beim RAID0 oder den einzelnen Platten - Beim Mirror-Modus sind die Leseraten in etwa so wie beim Simple-Modus, beim Schreiben dafür aber nur etwa halb so hoch - Insgesamt ist der Mirror-Modus aber besser als die beiden SSDs im RAID0 des Controllers Wenn man nun aber noch HD Tach mit betrachtet, dann sieht man recht deutlich, dass die hohen Raten nur anfänglich erreicht werden (nämlich bis zu der Stelle, an der zwischen den SSDs und den HDDs gewechselt wird, hier etwa bei der Hälfte. Dennoch sind die Daten im “HDD-Bereich” recht gut! Ich denke diese Ergebnisse zeigen, dass die Technologie zu hohen Geschwindigkeiten fähig ist, die selbst mit (zumindest einfacheren) RAID-Controllern nicht erreicht werden. Ich werde zeitnah noch eine tabellarische Gegenüberstellung der Werte ausarbeiten. In diesem Beitrag habe ich weitere Tests und eine Auswertung in Tabellenform veröffentlicht: http://blog.ppedv.de/post/2014/08/15/Auswertung-zum-StoragePool-Benchmark.aspx  

PowerShell: Anmelde-Konto der Windows-Dienste überprüfen

Wenn auf einem Windows Server Dienste nicht mit dem richtigen Konto gestartet werden, können diverse Fehler auftreten, z.B. der Fehler 1079: Der Fehler entsteht, wenn mehrere Konten unter dem selben Prozess (z.B. svchost) laufen, dabei aber verschiedene Konten nutzen sollen. Nun muss man also herausfinden, welche Dienste betroffen sind. Dies geht sicherlich auch über die services.msc (also in der GUI) – ist dann aber mit viel Arbeit verbunden. Einfacher wäre es sicherlich, dies über PowerShell herauszufinden. Leider kennt das Cmdlet “Get-Service” keine Möglichkeit, die Logon-Werte auszugeben: Selbst der Aufruf “Get-Service | fl *” zeigt kein passendes Attribut: Was bleibt nun also? Eine Abfrage mittels WMI! Und tatsächlich – hier gibt es nun ein Attribut “StartName”, welches das verwendete Konto enthält. Nun kann man also eine einfache Liste aller Dienste mit ihren Konten abrufen: Will man statt den “internen” (teils kryptischen) Dienstnamen die sprechenden Namen sehen, und auch nach diesen sortieren, dann kann man folgenden Aufruf verwenden: Get-WmiObject win32_service | Sort-Object Caption | ft Caption,StartName Über Where-Object kann man nun auch gezielt nach Diensten mit einem bestimmten Konto suchen:

Windows Server 2012 R2: Netzwerk-Profil mit PowerShell von “Öffentlich” auf “Privat” ändern

Oft kommt es vor, dass ein Windows Server das Netzwerk-Profil (Domäne oder Privat) nicht sauber erkennt und stattdessen auf “Öffentlich” steht. Dies hat natürlich Auswirkungen, z.B. auf die gesetzten Firewall-Regeln: Eine kurze Überprüfung im “Netzwerk- und Freigabecenter” fördert das gleiche Ergebnis zu Tage: Auch mit Hilfe der Windows PowerShell kann man dies sehen… … und ändern! Mit Hilfe des Aufrufs Set-NetConnectionProfile –InterfaceInxe # –NetworkCategory Private wird das Verbindungsprofil auf “Privat” gesetzt (“Domain” setzt auf Domäne). Nun kann man auch im Netzwerk- und Freigabecenter das korrekte Verbindungsprofil sehen: