pixel
Seite wählen

NETWAYS Blog

Windows 11 Release und was ihr wissen müsst!

 

Windows 11 steht vor der Tür! Seit dem 5. Oktober wird auf ausgewählten Systemen das Upgrade des neuen Betriebssystems angeboten. Ein neues Design sowie weitere Features erleichtern euch die Bedienung und Anpassung eures Systems. Ein Schelm wer die Ähnlichkeit zu MacOs erkennt. Vom neuen Startmenü über Updates zu Microsoft Teams bis hin zu der nativen Unterstützung von Android Apps bietet Windows 11 noch eine Vielzahl an Neuerungen wobei einige Features erst später implementiert werden sollen. Wer bereits vor einigen Wochen eine Preview von Windows 11 geladen hat, wird wohl gemerkt haben, dass die Systemanforderungen auf neuere Systemhardware zielt. Die wichtigsten Anforderungen auf einen Blick:

  • Prozessor: 1 Gigahertz (GHz) oder schneller mit 2 oder mehr Kernen auf einem kompatiblen 64-Bit-Prozessor oder SoC (System on a Chip)
  • RAM: 4 Gigabyte (GB)
  • Speicher 64 GB oder größeres Speichergerät
  • Systemfirmware UEFI, aktiviert für sicheren Start
  • TPM Trusted Platform Module (TPM) Version 2.0
  • Grafikkarte Kompatibel mit DirectX 12 oder höher mit WDDM 2.0-Treiber
  • Außerdem wird eine Internetverbindung mit einem Microsoft-Konto vorausgesetzt

Die komplette Liste der Systemanforderungen und Features seht ihr hier: Windows 11-Spezifikationen, -Funktionen und -Computeranforderungen

 

Features für Entwickler

Windows 11 bietet den neuen PWABuilder3, bei dem Entwickler in kürzester Zeit eine PWA aus ihrer Web-App erstellen können. Für die Erstellung hybrider Webanwendungen, stellt Windows 11 die WebView2-Runtime zur Verfügung. Das Windows Terminal und die neuen Microsoft Edge DevTools können weiterhin verwendet werden, da sie jetzt in Windows 11 enthalten sind. Die Windows App SDK macht es einfacher, Windows 11 Features für Apps zu integrieren. Entwickler können mit dem neuen ARM64 Emulation Compatible ABI Apps erstellen, die nativ unter Windows auf ARM laufen, unabhängig davon, ob als Win32, Universal Windows App oder ein anderes App-Framework.

 

Neuerungen für Gaming-Enthusiasten

Mit der Xbox-Technologie gibt es nun auch AutoHDR für Titel, die DirectX 11 oder DirectX 12 verwenden, selbst wenn diese die HDR-Ausgabe nicht unterstützen. Ebenfalls kommen neue Features wie DirectStorage (auch für Windows 10 verfügbar), die eine mindestens 1 TB große NVMe-SSD voraussetzen, um Ladezeiten zu verkürzen und schneller ins Spielgeschehen eintreten zu können. Bei DirectStorage werden die Daten der schnellen NVMe-SSD direkt an den RAM weitergegeben, so wie es bereits bei der Xbox Series X|S der Fall ist.

 

Weitere Features die zu erwähnen sind, ist die Integration von Microsoft Teams, das ein neues Design erhält und nun wie bei macOS direkt auf der Taskleiste liegt. Zusätzlich können Widgets die wir noch von Windows Vista kennen auch an der Taskleiste fixiert und abgerufen werden.

 

Für alle die noch nicht updaten können oder wollen: Windows 10 wird nach aktuellen Angaben von Microsoft bis 14. Oktober 2025 supported wobei man hier von einem “Retirement Date” spricht.

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Icinga for Windows v1.6.0 – Einfacher. Zentraler. Sicherer.

Die Kollegen von Icinga haben letzte Woche Icinga for Windows in Version v1.6.0 veröffentlicht. Auch wenn diese Version keine neuen Plugins für die Überwachung bietet, hat sich im Bereich des Icinga PowerShell Frameworks einiges getan. Dadurch ist die Lösung nicht nur einfacher zu verwenden, sondern auch noch zentraler verwaltbar und sicherer.

Dürfen wir vorstellen: Die IMC

Die IMC (Icinga Management Console) wurde im Rahmen vergangener Icinga for Windows als experimental eingeführt. Ziel war es, ein einfaches Management zu schaffen, um die meisten Funktionalitäten über eine UI abbilden zu können. Dadurch ist es nicht mehr notwendig, sich alle Befehle von Icinga for Windows zu merken oder diese zu kennen – sondern die Konfiguration erfolgt direkt darüber.

Im Zuge der Einführung der IMC, wurde ebenfalls ein neuer Setup Wizard generiert, welcher nicht nur einfacher und intuitiver ist als der alte, sondern auch noch über eine Hilfe verfügt, welche einem erklärt, welche Eingaben im jeweiligen Bereich notwendig sind und was diese bedeuten. Die Konfiguration ist hierbei im nicht-advanced Modus auf die absoluten Grundlagen beschränkt, um schnell ans Ziel zu kommen. Die restlichen Einstellungen im advanced Teil, können simpel eingesehen und geändert werden, wurden jedoch so ausgewählt, dass man in vielen Umgebungen auf eine Änderung sogar verzichten könnte.

Zentrale Verwaltung mit Repositories

Einer der großen Kritikpunkte an Icinga for Windows war die Komponenten Installation. Bisher musste jede Komponente einzeln heruntergeladen und mit einem Pfad bei der Installation hinterlegt werden. Mit Icinga for Windows v1.6.0 wurde nun ein Repository-Management hinzugefügt. Hierdurch können direkt entweder die offiziellen Repositories von Icinga for Windows auf packages.icinga.com angebunden werden oder ein eigenes, zentrales. Icinga for Windows bietet dabei die Möglichkeit, vorhandene Repositories zu synchronisieren, um diese in seiner lokalen Umgebung zu spiegeln. Dadurch kann die Installation von Systemen, welche nicht in das Internet können, deutlich vereinfacht werden. Ein Beispiel wäre hier, die offiziellen Icinga Repositories auf seinen Icinga 2 Master zu synchronisieren, um dort ein Repository für alle Systeme bereitzustellen.

Im Falle von DMZ Systemen kann das Repository wiederum von zentralen Icinga 2 Master auf Icinga Satellitensysteme synchronisiert oder aber auf zentrale File-Shares abgelegt werden, um von dort die Komponenten zu installieren. Für das Update von Repositories gibt es ebenfalls Kommandos, die eine Aktualisierung ermöglichen.

Der Vorteil des Repositories liegt darin, dass direkt die aktuellen Versionen der jeweiligen Komponenten installiert oder mit einem simplen Befehl die gesamte Umgebung aktualisiert werden kann. Sollte es aus bestimmen Gründen notwendig sein, kann die Version von einzelnen Komponenten auch gelockt werden. Das bedeutet, sofern eine ältere Version installiert ist, wird bis zur gelockten Version aktualisiert. Ist bereits die gelockte Version installiert und eine neue verfügbar, wird diese übersprungen.

Weitere Details hierzu gibt es direkt in der Icinga for Windows Repository Dokumentation.

Mehr Sicherheit durch JEA

JEA steht für Just-Enough-Administration und ist eine Lösung von Microsoft für PowerShell. Durch JEA können einzelne Benutzer, welche keine Administratoren sind, Befehle mit erhöhten Rechten im System Kontext ausführen. Die Funktionalität ist dabei ähnlich wie sudo auf Linux.

In der Vergangenheit gab es des Öfteren Probleme, das diverse Überwachungsmöglichkeiten nicht genutzt werden können, da der Benutzer beispielsweise nicht in der Hyper-V Administrator Gruppe ist und deshalb den Status der virtuellen Maschinen nicht abfragen kann. Ein weiteres Problem ergibt sich auch, wenn man diverse Services oder Tasks überwachen möchte, welchen mit einem normalen Standardbenutzer nicht eingesehen werden können.

Durch ein JEA-Profil wird es erlaubt, dass ein bestimmter Benutzer diese Plugins nun im Systemkontext mit erhöhten Rechten ausführt. Dabei wird von Icinga for Windows ein Profil basierend auf allen installierten Komponenten erstellt. Dieses Profil deckt jedoch nur die notwendigen Befehle zum Ausführen von Plugins und Komponenten ab. Für Icinga for Windows notwendigen Befehle für das Management der Umgebung, werden dabei nicht berücksichtigt.

Um das ganze abzurunden und die Trennung perfekt zu machen, bietet Icinga for Windows die Möglichkeit an, einen Managed User mit dem Namen icinga anzulegen. Dieser Benutzer ist ein lokaler Benutzer auf dem System, ohne Berechtigungen sich lokal oder per RDP anzumelden. Der einzige Zweck ist, dass er als Service Benutzer fungiert und den Icinga Agent sowie den Icinga for Windows Dienst startet. Im Zusammenspiel mit dem von Icinga for Windows generierten JEA-Profil, kann dann das System vollständig überwacht werden. Die Verwaltung des Benutzers obliegt dabei vollständig Icinga for Windows und im Rahmen der Erstellung des Benutzers oder bei diversen Änderungen an den Services während der Icinga for Windows Installation oder Updates, wird jedes Mal ein neues, zufälliges 60-stelliges Password generiert und dem Benutzer zugewiesen. Dieses Password wird nach Ende der jeweiligen Installationsschritte intern wieder verworfen und wird nirgends abgelegt. Hierdurch wird eine Kompromittierung des Systems ohne bereits vorhandene Administratorrechte deutlich erschwert.

Weitere Details sowie Anforderungen, finden sich direkt in der Icinga for Windows JEA Dokumentation.

Performance Gewinn durch API-Check Forwarder

Ein weiteres Thema welches mit Icinga for Windows v1.6.0 von experimental als stabil gilt, ist der API-Check Forwarder, welcher in vergangenen Versionen eingeführt wurde. Hintergrund dieser Lösung ist, dass das Starten sowie die Ausführung von PowerShell Befehlen innerhalb der von Icinga 2 gestarteten Shells vor allem bei Systemen mit weniger Kernen eine erhöhte Systemlast verursachen. Durch den API-Check Forwarder wird zumindest der Ausführungsteil ausgelagert, da alle Befehle für die Plugin-Ausführung innerhalb des Icinga for Windows Dienstes durchgeführt und lediglich das Ergebnis an die lokale Shell weitergereicht wird.

Für diese Lösung werden zwei zusätzliche von Icinga bereitgestellte Komponenten benötigt, um eine REST-Api bereitzustellen sowie die Checks per API auszuführen. Beides kann direkt über die neuen Icinga Repositories installiert werden. Für eine sichere Verbindung werden direkt die Zertifikate des Icinga Agent verwendet. Nach Bedarf können jedoch auch eigene Zertifikate verwendet werden. Wichtig dabei ist, dass eine Erstellung des REST-Api Sockets ohne ein TLS Zertifikat nicht möglich ist.

In der zugehörigen Dokumentation zum API-Check Forwarder von Icinga for Windows gibt es weitere Details.

Was bringt die Zukunft?

Die nächste Version von Icinga for Windows v1.7.0 ist bereits zur diesjährigen OSMC eingeplant. Hier werden wir noch weiter den Schwerpunkt auf Performance sowie eine Vielzahl von Optimierungen für Entwickler legen, um es noch einfacher zu machen eigene Plugins und Komponenten zu entwickeln. Ein entsprechender Talk ist ebenfalls eingereicht.

Wir freuen uns auf eine rege Teilnahme und wünschen bis dahin alles Gute!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Putty mit tmux

Nachdem ich öfters mit dem Tool Putty  zu tun bekommen habe, um mich von einer Windows-Umgebung auf einen Linux-Host zu verbinden, habe ich recherchiert wie man beim verbinden einer SSH-Session von Putty direkt eine Tmux-Session auf dem Linux-Server eröffnen kann.
Also habe ich mich mit den Einstellungen von Putty etwas näher befasst, getestet und siehe da es geht doch, dann dachte ich mir, das interessiert doch bestimmt mehr SysAdmins.
Öffnet man Putty, sieht man die Session mit der Liste von Hosts und Links in der Sidebar verschiedene Dropdown-Punkte unter anderem den Punkt SSH, diesen wenn man anwählt kann man einige Einstellung vornehmen unter anderen “Remote command” und hier trägt man “exec tmux” ein und speichert das beim Host ab und schwups hat mein beim nächsten SSH-Login eine Tmux-Session parat, Klasse. Dann viel Spaß beim ausprobieren.

Siehe Screenshot:
Und denkt daran immer schön weiterbilden, wir haben hier tolle Trainings im Bereich OpenSource und die Macht wird mit Dir sein.

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Windows: One Framework to Monitor them all by Christian Stein | OSMC 2019

This entry is part 4 of 4 in the series OSMC 2019 | Recap

At the Open Source Monitoring Conference (OSMC) 2019 in Nuremberg, Christian Stein captivated the entire conference room with his presentation “Windows: One Framework to Monitor them all”. His demo was the highlight of his presentation, which ended up with enthusiastic applause. You have missed him speaking? We have got something for you: Watch the video of Christian’s presentation and read a short summary (below).

At OSMC international monitoring experts meet annually to set and discuss future trends and objectives. Since 2006 the event takes place every autumn in Nuremberg, Germany. Leading specialists present the full scope of Open Source monitoring and are ready to answer your hardest questions. Discuss with top developers, exchange knowledge and learn wen techniques.

You want more? In-depth workshops the day prior to the conference and a Hackathon provide further possibilities to extend your skills and deepen your knowledge in IT monitoring and management.

The next OSMC takes place in 2021 in Nuremberg.

More information and tickets at osmc.de.


Windows: One Framework to Monitor them all

Christian Stein signed up with a talk titled “Windows: One Framework to Monitor them all” and the intention to turn the Windows side of Icinga upside down. After giving a short run down of the the current issue with “Icinga for Windows” and his attempts at fixing them, we get to the good stuff.

An Icinga PowerShell Framework supported by Powershell 4.0 or higher, but let‘s get into the juicy details: The framework comes with a lot of features, to easily extend it within your environment and to simplify monitoring on Windows as well. Additionally, there is a dev-toolkit, which offers plenty of possibilities for developers to give the framework their own tweak. As of now, there are four repositories beyond the framework itself. Up first and most important to mention is icinga-powershell-kickstart, which provides a basic PowerShell script to interactively install the framework. Also rather essential for the framework is the icinga-powershell-plugins repository, which provides a collection of Windows check plugins.

Want to run the framework as a service? Glad you asked. There is a repository for that as well. It’s also covered by the kickstart wizard. Check icinga-powershell-service to find out more or to give some feedback. If you’ve always asked yourself why you should run appliances as a service, there are several benefits. Like the service running before a user logs on and continuing to run, without a logged on user.

Last but not least, even most essential, the framework itself. If we look at the current ways to make Icinga work on windows, they are good, but not great. The icinga-monitoring-framework provides tools and configuration to make icinga monitoring on windows possible, almost natively, except for said repositories.

Having said all that and more, Christian went on with a live demo of the Framework, gave some installation advice and by that I mean, delved deeper into the kickstart script. He also showed off some features and gave some best practice advice. So, all that was left to say is… whats next?

Christian announced, that it will be available on PowerShell Gallery, which will not only help the project grow, but make it even more available as is. And of course, there will be more plugins. For those eagerly waiting for one of these, the next release hopefully provides MSSQL, Active-Directory, Exchange and Hyper-V plugins.

The community’s and the customer’s interest in better windows monitoring is undeniable, but we depend on your feedback and support on this, the respective repository is the place to be, and if you can’t figure, which one it fits, just post your issue at: https://github.com/Icinga/icinga-powershell-framework/issues

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Plugins, Provider, PowerShell

Im Icinga-Windows-Kosmos passiert in letzter Zeit sehr viel, vor allem durch das Zauberwort PowerShell. Framework, Plugins, Kickstart und Service, das alles hört man recht oft und auch neue Releases sind da oder stehen an. Doch wie schreibe ich meine eigenen Checks beziehungsweise Plugins? Gibt es Vorschriften an die ich mich halten sollte? Und kann ich mich auch an dem Projekt beteiligen?

Plugins und Provider

Als das Projekt gestartet worden ist, war es bereits angedacht, dass Plugins individuell anpassbar sein sollten. Um dies zu gewährleisten, war es wichtig die Daten, die zur Prüfung genutzt werden in einer normierten Form gesammelt zurückzugeben und hier kommen die Provider ins Spiel.

Was ist ein Provider?

Ein Provider sammelt Daten vom System und stellt sie zur Verfügung um in Plugins genutzt zu werden. Sehen wir uns das ganze im icinga-powershell-plugins repository an:
└── provider
├── bios
├── cpu
├── directory
├── disks
├── enums
├── eventlog
├── memory
├── process
├── services
├── updates
├── users
└── windows

Innerhalb dieser Verzeichnisse befinden sich in der Regel zwei Dateien. Im Falle von CPU wären das Icinga_ProviderCpu.psm1 und Show-IcingaCpuData.psm1. Respektive Dateien existieren auch in allen anderen Verzeichnissen.

Mit dem gleichnamigen Befehl Show-IcingaCpuData kann man nun alle generischen Daten zur Thematik CPU abfragen. Während die Datei Icinga_ProviderCpu.psm1 verschiedene Funktionen enthält um spezifische Daten anzufordern. Darunter zum Beispiel folgende Funktionen: Get-IcingaCPUArchitecture, Get-IcingaCPUArchitecture.

Im Falle von Get-IcingaCPUs könnte der Output beziehungsweise die bezogenen Daten, wie folgt aussehen – gekürzt und in JSON konvertiert:
{
"specs":  {
"L3CacheSize":  0,
"CurrentClockSpeed":  2100,
"VoltageCaps":  0,
"L2CacheSpeed":  null,
"ThreadCount":  1,
"CurrentVoltage":  null,
"LoadPercentage":  7,
"L2CacheSize":  null
},
"errors":  {
"ErrorDescription":  null,
"ErrorCleared":  null,
"ConfigManagerErrorCode":  {
"value":  "This device is working properly.",
"raw":  0
},
"LastErrorCode":  null
},
"metadata":  {
"ProcessorType":  {
"value":  "Central Processor",
"raw":  3
},
...
"SocketDesignation":  "CPU 1",
"ProcessorID":  "078BFBFF000306A9",
"NumberOfCores":  1,
"SerialNumber":  "",
"Architecture":  {
"value":  "x64",
"raw":  9
},
"Availability":  {

},
"AddressWidth":  64,
"Status":  "OK",
"StatusInfo":  {
"value":  "Enabled",
"raw":  3
},

}

Auf diese Daten können wir nun Aufbauen. Ob die Daten direkt zuträglich sind oder ausreichend für unsere Anwendung ist individuell.

Bevor ich ein Plugin schreibe!

Bevor es dazu kommt, dass man ein Plugin schreibt und Unmengen an Cmdlets benutzt und die Daten normiert, sollte man sich darüber im Klaren sein, was es alles für Provider gibt und vorher überprüfen, ob die Daten nicht in der ein oder anderen Form bereits vorhanden sind.

Gefällt mir etwas am Invoke-IcingaCheckCPUs Check nicht, dann ist es sinnig, zumindest zunächst den Provider des Check-Plugins zu betrachten und zu prüfen ob man nicht die Informationen die der Check erhält anders nutzen kann.

Falls das nicht der Fall ist, sollte man seinen eigenen Provider schreiben oder einen vorhanden ergänzen und uns vielleicht mit einen Pull-Request überraschen.

Aber wohin das Ganze?

Damit nicht alles verloren ist beim nächsten Update oder Konflikte auftreten, gibt es im Icinga-PowerShell-Framework ein Custom-Verzeichnis. Dieses unterteilt sich wiederum in /lib und /plugins. In das plugins-Verzeichnis kommen folgerichtig natürlich die Plugins, die ihr für euch individuell anlegt und die nicht oder noch nicht Teil des Repositorys sind.

Das Gleiche gilt natürlich auf für das Library-Verzeichnis. Wenn ihr das Rad neu erfinden wollt und ein Custom-Module baut für Test-Numeric oder euch das Ausgabeformat von Convert-Bytes stört, dann sind eure Tools hier sicher. Und natürlich auch da freuen wir uns über einen Pull-Request.

Wir halten fest, wenn man also ein Plugin baut, dann sollte man ein eigenes PowerShell Modul bauen und sich dabei weitestgehend zunächst an den vorhandenen Plugins orientieren und aufpassen, wo was hingehört.

Fazit

Wer es richtig machen will, fängt langsam an und baut vor allem modular. Erst der Provider, dann das eigentliche Check-Plugin. Desto größer der Provider, desto einfacher das Bauen der Check-Plugins, weil mit bereits vorhanden Informationen ist die Logik, der Check-Prüfung das wenigste Problem.

Wem das alles noch nicht genug ist, der kann auch mal auf unserem Youtube-Channel vorbei schauen, wo wir im Umfang unserer Webinare mit unter Custom Plugin Development und Custom Daemon Development besprochen haben.

Seit in jeden Fall gespannt wie es mit dem Projekt weitergeht und für noch mehr zum Thema Plugin schreiben schaut euch den Developer-Guide an.

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.