Korrekte Systemzeitsynchronisierung

Wenn Sie sicherstellen wollen, dass in Ihrem Netzwerk immer die korrekte Systemzeit angezeigt wird gibt es mehrere Wege. Im Folgenden Beispiel zeige ich Ihnen, wie einfach Sie das ganze in Server-Eye lösen können. So kommen Sie dann auch pünktlich zu Ihren Terminen.

 

Einleitung

Wenn Sie eine Systemzeitsynchronisierung vornehmen wollen, dann ist der erste Schritt die Auswahl eines NTP-Servers. NTP steht dabei für Network Time Protocol und stellt den Standard für die Synchronisation in Computernetzen dar. Aktuell verwenden wir in Server-Eye noch den Dienst der Physikalisch-Technischen Bundesanstalt (PTB), diesen werden wir allerdings demnächst ablösen durch Server des NTP Projektes. Nähere Informationen zu dem Projekt und dem aktuellen Serverumfang finden Sie http://www.pool.ntp.org/zone/de

Das liegt vor allem daran, das zum Zeitpunkt der Erstellung dieses Artikels ganze 504 Server sich daran beteiligen und so eine zuverlässige Synchronisierung gewährleistet wird.

Zusätzlich empfiehlt es sich in Ihrem Netzwerk einen Server zu beauftragen, der die Zeit gegen diese externe Quelle synchronisiert. Klassisch übernimmt das der Domänencontroller. Alle anderen Systeme synchronisieren sich dann wiederum gegen diesen. So muss nicht jedes System eine Internetverbindung vorweisen und Sie minimieren auch die Anfragen an den entsprechenden NTP Server selbst.

 

Sollten Sie bereits eine Überwachung in Server-Eye nutzen, stellen Sie diese bitte auf den NTP-Server de.pool.ntp.org um.

 

Monitoring in Server-Eye

Nun müssen Sie nichts aufwendig konfigurieren, sondern Sie können Server-Eye die ganze Arbeit überlassen.

Dazu nutzen Sie einfach unseren Sensor Zeitdienstüberwachung. Die vorgeblendete Konfiguration ist dabei schon ausreichend.

Zeitdienst-Sensor

 

 

Unsere Vorschläge geben dabei direkt schon die richtige Konfiguration je nach System vor. Auf einem DC erscheint ein Vorschlag mit dem Vermerk "Extern" und auf anderen Systemen wird der Vermerk (Intern) angezeigt. Die Interne Prüfung hat dann automatisch als Zeitserver schon den entsprechenden Domaincontroller eingetragen.

Im OCC sieht das jeweils so aus:

Vorschlag Extern

Vorschlag Intern

 

 

Sobald eine Abweichung vorliegt, erhalten Sie eine Fehlermeldung und die Information das die Zeit automatisch für Sie korrigiert wurde. So können Sie sich protokollieren lassen wie häufig eine Korrektur vorkommt. Sollte es dann wirklich öfters zu Zeitkorrekturen kommen, macht es Sinn die automatische Korrektur per Einstellung zu deaktivieren und auf dem System auf Problemsuche zu gehen.

zeitkorrektur

 

Nutzen Sie dazu die Windows-Ereignisanzeige, die nützliche Informationen dazu liefern kann.


Fujitsu ServerRaid in VMware Umgebungen - Tipps und Tricks

Normalerweise ist der Status in einer virtuellen Umgebung direkt vom Hypervisor zu beziehen (Beispiel VMware). Fujitsu bietet jedoch zusätzlich zu diesem Weg an, den Festplattenstatus klassisch über das ServerRaid Tool zu prüfen.

Dieser Artikel befasst sich mit den Schritten die notwendig sind, damit diese Kommunikation korrekt funktioniert.

Schritt 1 - Voraussetzungen

Setup prüfen

Zu aller erst ersparen Sie sich viel Ärger wenn Sie bereits eine von Fujitsu vorkonfigurierte VMware Version nutzen.

Auf VMware Seite ist es wichtig das die CIM Konfiguration wie folgt aussieht:

  • Installation CIM Provider (wenn nicht vorkonfiguriertes VMware)
  • Einträge im VCenter unter "Konfiguration - Erweitertete Einstellungen - UserVars"
    • UserVars.CIMvwm_emulex-cim-providerPrvoviderEnabled = 1
    • UserVars.CIMvwm_LSIProviderPrvoviderEnabled = 1

Desweiteren müssen für die Kommunikation die folgenden Dienste gestartet sein:

  • Secure CIM-Server auf Port 5989
  • CIM-Server auf Port 5988

Detaillierte Informationen zu diesen Schritten finden Sie natürlich auch direkt bei Fujitsu in der folgenden Anleitung: http://manuals.ts.fujitsu.com/file/10342/sv-install-cim-prov-de.pdf

Schritt 2 - Anpassungen auf einer ausgewählten VM

CLI-Befehle

Der Fujitsu ServerRaid Manager kann auf einer beliebigen virtuellen Maschiene installiert werden. Es muss nur der betreffende Host über IP erreichbar sein und natürlich die Anforderungen der Software erfüllt werden.

Jetzt erfolgt die weitere Konfiguration mittels des CLI des Raid Managers, amCLI.

Dies finden Sie normalerweise unter "C:\program files\fujitsu\serverview suite\raid manager\bin"

Die folgende Befehlszeile müssen Sie nur um Ihre Werte ergänzen:

amCLI -e 21/0 add_server name=<FQDN oder Hostname oder IP> port=5989 username=root password=<ESXi Root Passwort>

Ob alles geklappt hat können Sie mit dem Befehl "verify_server" überprüfen:

amCLI –e 21/0 verify_server name=<FQDN oder Hostname oder IP>

Ein "No Error" signalisiert, dass alles funktional ist.

Bezüglich spezieller Zeichen in dem ESXi Passwort und weiteren Einstellungsmöglichkeiten sehen Sie bitte in die von Fujitsu bereitgestellte Anleitung: http://manuals.ts.fujitsu.com/file/4338/sv-serverview-raid-de.pdf (Kapitel 2.1.2 VMware ESXi)

Nun nur noch den Server View Raid Manager Dienst neustarten und im Raid Manager anmelden. Voilá!

Schritt 3 - Überwachung

Monitoring des Raid

Anstatt unsere PowerCLI basierenden Sensoren zu nutzen, können Sie nun auch wie bisher unseren SNMP Sensor "Festplattenüberwachung für Fujitsu Siemens® Server" anlegen um den RAID Status zu überwachen.
Beachten Sie hier nur das eine weitere Konfiguration von SNMP notwendig ist.

Dies wurde aber bereits hier beschrieben:

https://support.server-eye.de/support/customer.pl?Action=CustomerFAQZoom;ItemID=34

Danach können Ihnen solche Fehler nie wieder entgehen:

Fujitsu - Lost Redundancy

 

Vielen Dank an der Stelle auch an unseren Kunden ParIT GmbH für den tollen Denkanstoß und das Bereitstellen von Informationen für diesen Eintrag!


Korrekte Übertragung des Schattenspeichers (MPS)

Viele Städte und Gemeinden haben damit zu kämpfen, das sie regelmäßig prüfen müssen, ob die Schattenspeicher-Datei korrekt übertragen wurde. Dabei gibt es zwei Abhängigkeiten in Form des Programmes MPS (welches die Schattenspeicherdatei erstellt) und EWO Transfer welches den Upload dieser XML-Datei über FTP übernimmt.

Ich zeige Ihnen nun an Hand von wenigen Schritten, wie Sie dieses Problem zuverlässig überwachen können und eine Sorge weniger haben :).Der erste Schritt zur erfolgreichen Überwachung sollte sein, folgende Dienste zu überwachen:

  • DW-DBCControl_mpsEM
  • DW-DBCControl_mpsNF
  • DW-DBControl_EM_OSCI

Sind diese Dienste nämlich nicht gestartet, funktioniert das Erstellen der Schattenspeicher-Datei schon gar nicht.

Dazu bietet Server-Eye den Sensor "Windows Dienst Gesundheit", der alle automatisch gestarteten Dienste im System überwacht.

Danach kommt das Herzstück der Überwachung, das Überprüfen der Logdateien wofür wir den Sensor "Log-Datei Ordnerüberwachung" anbieten.

Diesen füllen Sie einfach wie folgt aus:

Log Sensor Konfig

 

Sobald nun eine neue Logdatei hinzukommt, die nicht das Schlüsselwort "Datei erfolgreich" enthält, erhalten Sie eine Alarmierung.

Wenn Sie die beiden Sensoren nun noch als Template abspeichern, können Sie diese Form der überwachen schnell und einfach auf Ihre Server anwenden.


Aktionen dank PowerShell

Manchmal ist es notwendig einen Prozess oder Dienst neuzustarten um ein bestimmtes Problem zu lösen. Vielleicht haben Sie ein solches Problem in Ihrer Umgebung, für die Software gibt es keinen Patch mehr der Abhilfe schaffen kann, oder es handelt sich einfach um ein Task der regelmäßig neu angestoßen werden muss. Genau das sind typische Beispiele wo Aktionen hilfreich sein können. In diesem Artikel zeige ich Ihnen wie Sie Aktionen in Server-Eye mittels PowerShell nutzen können.

Die Macht der PowerShell

Die PowerShell ist eine mächtige Shell mit der sich fast jede Aktion umsetzen lässt. So gibt es vorgefertigte Befehle um einen Prozess zu beenden und wieder zu starten, einen Dienst und sogar den eigenen Rechner (oder einen fremden) neuzustarten.

In unserem Partnerbereich bieten wir bereits eine kurze Einführung in die PowerShell-API, also wie Sie eigene Überwachungen auf Basis eines PowerShell-Skripts erstellen können.

Die Infos finden Sie hier:

Erweiterte PowerShell Sensor Doku

Ich habe auch ein Beispielskript angehängt an diesen Eintrag, in welchem ein gewählter Prozess auf CPU und Arbeitsspeicher Verbrauch überwacht werden kann. Werden die Schwellwerte erreicht, wird der Prozess beendet und wieder gestartet.

Die Befehle dafür sind

  • Stop-Process
  • Start-Process

Für Dienste neuzustarten oder gar den PC gibt es folgende Befehle:

  • Restart-Service
  • Restart-Computer

Das Skript ist funktionsfähig, kann aber auch einfach als Anreiz für andere Szenarien genutzt werden.

 

Ausschnitt eines PowerShell Skripts
Ausschnitt Skript

 

Skript in Server-Eye einbinden[/vc_custom_heading]

Um ein Skript in Server-Eye zu nutzen müssen Sie es im Installationsverzeichnis in das Unterverzeichnis "Scripts" kopieren. Dies liegt standardmäßig unter C:\Program Files (x86)\Server-Eye\service\current\Scripts\.

 

Wenn Sie solche System-Aktionen durchführen wollen starten Sie zur Sicherheit den Sensorhub Dienst auf dem System als Administrator starten, da sonst die PowerShell-Kommandos in einem UAC Dialog hängen bleiben könnten. Außerdem kann es durchaus sein, das Prozesse mit einer grafischen Oberfläche nicht korrekt neugestartet werden können.

 

Danach ist es über den Sensor "Erweiterte PowerShell Überprüfung" auswählbar und lässt sich überwachen.

 

ServerEye_Auswahl

 

 

Falls Sie Argumente in Ihrem Skript nutzen wollen können Sie dies über die entsprechende Einstellung tun. In unserem Falle gibt es die Argumente

  • process
  • maxRamMB
  • maxCPU

Ich rufe das Skript also mit folgenden Parametern auf:

ServerEye_Arguments

 

Die Ausgabe des Sensors sind dann wie folgt aus:

ServerEye_Skript

 

Bzw. im Fehlerfall, wenn der Prozess zuviel schluckt so:

ServerEye_Fehler

 

Viel Spaß beim Skripten :)

ProcessMonitor Skript!


Blacklist dnsbl.ahbl.org stellt Dienst ein!

Aus aktuellem Anlass! Der Betreiber ahbl.org stellte zum 05.01.2015 unter anderem die Dienste dnsbl.ahbl.org ein. Das bedeutet das Sie in aller Voraussicht eine Fehlermeldung in Server-Eye erhalten.

Im Folgenden zeige ich Ihnen wie Sie diese Fehlermeldung beheben können.

Weiterlesen


UPSMan SNMP Konfiguration

Besitzt Ihre USV keine eigene SNMP-Karte bietet die UPSMan Software Abhilfe für viele Hersteller wie AEG, Online USV , Eaton, Generex, Riello, Effekta uvm.

Eine schöne Übersicht finden Sie hier http://www.generex.de/content/view/113/194/lang,ge/

UPSMan stellt dabei die SNMP-Funktionalität softwareseitig bereit, in dem es den Windows-SNMP Agenten nutzt. In diesem kleinen Beitrag zeige ich euch wie man das ganze konfiguriert und anschließend überwachen kann.

Konfiguration in Windows

Zu allererst benötigen Sie den Window SNMP Dienst auf Ihrem System. Ist dieser noch nicht vorhanden können Sie dies entweder über den Server-Manager oder aber die Windows-Features schnell hinzufügen.

 

SNMP hinzufügen (PC)

SNMP hinzufügen (Server)

 

Ist der Dienst installiert muss er noch konfiguriert werden, sodass SNMP Anfragen durchgeführt werden können. Dazu setzen Sie die "Read" Community am besten auf public. Sie können den Zugriff auf bestimmte IPs einschränken.

 

SNMP Konfig Dienst

 

Konfiguration UPSMan SNMP

Ist dieser Schritt abgeschlossen, können Sie in der UPSMan Software nun die SNMP Funktionalität konfigurieren.

Dies finden Sie unter dem Punkt System. Setzen Sie hier das Häkchen bei Enable SNMP Support und Restart SNMP Service.

Danach sollten Sie zur Sicherheit nochmal manuell den Windows SNMP Dienst neustarten.

 

UPSMan Config

 

Jetzt können Sie die Funktionalität mit einem MIB-Browser bestätigen und mit der Überwachung der Gesundheit Ihrer USV beginnen.

 

Monitoring in Server-Eye

Kommen wir nun zum einfachsten Schritt.

Wir bieten zur Überwachung schon unseren USV Status über UPSMan® Sensor an. Dieser benötigt auch keine weitere Konfiguration und ist direkt einsatzbereit. Viele wichtige Informationen werden auch als Messwerte zur Langzeitanalyse bereitgestellt.

Das ganze sieht dann wie folgt aus:

 

OCC-Ansicht

 

Frohes Monitoring!


LSI Raid Controller Integration in VMware ESX Server

Die Virtualisierung ist mittlerweile nicht mehr wegzudenken. Mit Ihr kommen neue technischen Herausforderungen und es ist wichtiger den je alles im Überblick zu haben. Wenn Sie einen LSI Raid Controller auf Ihrer ESX Hardware nutzen, möchte ich Ihnen in diesem Artikel kurz aufzeigen, wie Sie diesen korrekt integrieren, sodass der Status auch im ESX berücksichtigt wird. Viele Hersteller bieten extra Tools an, die zugeschnitten sind auf die genutzte Virtualisierungslösung, so auch LSI.

Den ersten Schritt den Sie durchführen müssen, ist es von der LSI Webseite www.lsi.com die notwendigen MegaRAID Treiber herunterzuladen.

MegaRaid Driver

 

Bevor wir mit der Installation beginnen, sehen Sie hier noch einmal der Urzustand des ESX nach Installation:

ESX_NAKED

 

Um nun fortzufahren müssen Sie in den Firewall Eigenschaften den SSH Dienst aktivieren und auch starten. Das ist notwendig um den heruntergeladenen MegaRaid Treiber auf das System kopieren zu können.

 

SSH_FirstStep
Dienst aktivieren

 

SSH_SecondStep
Dienst starten

 

Jetzt können Sie Ihr Tool der Wahl (zum Bsp WinSCP) benutzen um die heruntergeladene .zip Datei zu übertragen. Am besten in das Verzeichnis /tmp.

Bauen Sie nun mit PuttY ebenfalls eine Verbindung auf, und beginnen Sie mit der Treiberinstallation wie folgt:

 

esxcli software vib install -v /tmp/vmware-esx-provider-lsiprovider.vib

 

Eine erfolgreiche Installation können Sie am Ausgabetext erkennen, der in etwa wie folgt lautet:

Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.

 

Folgen Sie der Anweisung und tätigen Sie einen Neustart.

Herzlichen Glückwunsch! Jetzt sollte die Ansicht in Ihrem vSphere Client genau so aussehen:

 

ESX DONE!
Alles im Grünen :)

 

Jetzt bekommen Sie alle Fehler mit, die an dem LSI Controller anliegen. Das könnte dann wie folgt aussehen:

ESX_DONE_ERROR
Fehlerfall

 

 

Damit Sie nun nicht ständig Ihren vSphere Client aufhaben müssen und Hoffen und Bangen das alles gut gehen wird, können Sie das ganze natürlich auch zuverlässig überwachen mit Server-Eye. Sobald nämlich der Status sauber im vSphere Client ersichtlich ist, können unsere Sensoren über die VMware PowerCLI diese Werte abgreifen.

In diesem Fall wäre dies über den Sensor Host Gesundheit für VMware® PowerCLI abzubilden.

 

ServerEyeBAD
Server-Eye Integration

 

In einem meiner nächsten Blog-Artikel werde ich nochmal gezielt auf die Thematik "VMware in Server-Eye" eingehen, damit Sie sehen wie einfach es ist Ihre virtuelle Umgebung zu überwachen.


Logdateien zuverlässig bereinigen – Tipps und Tricks

Es gibt Programme oder auch Serverumgebungen die viel protokollieren und unter Umständen massig an Logdateien generieren. Dies kann unter Umständen regelmäßig dazu führen, dass die Fesplatte voll läuft.

Jetzt kann man natürlich jedes Mal händig diese Log-Verzeichnisse aufräumen, aber dies ist sehr zeit intensiv und nerven raubend.

Typische Anwendungsgebiete sind Exchange Server, Server wo ein IIS genutzt wird, SBS und Sharepoint Logs oder aber auch das Programm X das einfach zuviel Logdateien generiert.

Ich stelle Ihnen in diesem Beitrag ein kleines Skript vor, dass Ihnen ihr Leben erheblich erleichtern kann, und wenn Sie doch mal Hand anlegen müssen auch darüber informiert werden.

 

Logs,Logs,Logs...
Logs,Logs,Logs...

 

Wir bedienen uns dabei der PowerShell, da dort diese Aufgabe am einfachsten und sinnigsten umgesetzt werden kann.

Ich will jetzt nicht speziell auf Details eingehen bezüglich PowerShell Befehlen und Syntax, aber hier ist das Herzstück des Skriptes, ein Befehl welcher sich um das Ermitteln der zu alten Dateien kümmert und zur weiteren Verarbeitung in die Variable $itemsFound speichert.

 

#PsIsContainer means if it is a folder..and compare to the lastWriteTime tresh we have given above..
$itemsFound = Get-ChildItem $LogFolder -Recurse | where{!$_.PsIsContainer -and $_.LastWriteTime -lt (Get-Date).AddDays(-$DateToDelete)}

 

Es werden also auch nur Logdateien gelöscht, die älter als x Tage als sind. Dies ist auch immer zu empfehlen da aktuelle Logs (egal in welchem Anwendungsgebiet) sehr wichtige Analysemöglichkeiten darstellen.

Im Skript können Sie dabei einen ganzen Ordner angeben oder aber auch mit Wildcards arbeiten um wirklich nur einen speziellen Typ von Dateien zu löschen (Zum Beispiel C:\temp\*.log) Ich habe zwei Skripte angehängt für die potentiellen Szenarien:

 

1. Einfaches PowerShell-Skript über geplanten Task (Aufgabenplanung)

  • Öffnen Sie die Datei "ClearAnnoyingLogs.ps1" und ändern Sie die Variablen "daysToDelete" und "LogFolder" nach Ihren Wünschen ab.
  • Öffnen Sie die geplante Task Ansicht von Windows und lassen Sie das Skript mindestens 1 mal pro Tag laufen.
    • Unter "Programm starten geben Sie die powershell.exe an und als Argumente -noninteractive -file "pfad zum ps1 script"
    • Es kann notwendig sein das Sie den genauen Pfad zur powershell.exe angeben müssen.
  • Erstellen Sie in Server-Eye einen geplanten Task Sensor. An Hand des positiven Rückgabewertes (0) bekommen Sie direkt mit ob der Task erfolgreich durchgelaufen ist.

 

 

Aufgabenplanung
Aufgabenplanung

 

Aufgabenplanung in Server-Eye
Aufgabenplanung in Server-Eye

 

2. Eigener Sensor in Server-Eye über PowerShell API

  • Kopieren Sie Die Datei "ClearAnnoyingLogsSensor.ps1" in das Server-Eye Verzeichnis unter "scripts".
  • Gehen Sie nun in Ihr OCC und legen auf dem Server den Sensor "Erweiterte PowerShell Skript Überprüfung" an.
  • Tragen Sie als Parameter "-days xyz -path "C:\meinpfad" ein und wählen Sie anschließend das Skript aus der Liste aus.
  • Wenn Sie möchten können Sie nun das Intervall auf Ihre Bedürfnisse anpassen oder sogar Pausenzeiten definieren

Der Vorteil ist das Sie die direkte Ausgabe des Skripts immer in Ihrem OCC haben und von den Vorteilen eines eigenen Sensors profitieren.
So liefert das Skript zum Beispiel auch Messwerte, damit Sie immer wissen wie viele Dateien bereinigt wurden.

 

Das Skript in Server-eye
Das Skript in Server-eye

 

Weitere Infos, wie Sie PowerShell Skripte zu eigenen Sensoren in Server-Eye umwandeln finden Sie unter

https://support.server-eye.de/support/customer.pl?Action=CustomerFAQZoom;ItemID=80

ch hoffe ich konnte Ihnen mit diesen zwei Lösungen etwas helfen die tägliche Logbelastung zu bekämpfen und den Techniker-Alltag etwas einfacher gestallten.

Zum Skript-Paket


Exchange Server zu langsam

Wenn Sie mit einem langsamen Exchange Server in Ihrer Umgebung zu kämpfen haben, ist die manuelle Analyse und Ursachenforschung oft zeitraubend und aufwendig. Es gibt unzählige Gründe warum ein Exchange Server seine Funktion nur mit angezogener Handbremse ausführt und im Folgenden möchte ich Ihnen gerne ein paar Ansätze zeigen, wie Sie solche Probleme besser "greifen" können und vor allem proaktiv handeln, damit die Ursache gar nicht erst entstehen kann.

 

Schritt 1 - Rahmenbedingungen des Servers

Serverprüfungen

Zuerst einmal sollten man das Offensichtliche prüfen. Ist mein Exchange Server vielleicht einfach unterdimensioniert?

Gerade dieser Aspekt wird nämlich oft vernachlässigt oder fällt erst bei einer längerfristigen Betrachtung ins Auge.

Mit Hilfe von einfachen Sensoren können Sie dies in Server-Eye abbilden, Sie müssen nur CPU, Arbeitsspeicher und Festplattenauslastung überprüfen.

Orientieren können Sie sich dabei an folgendem Aufbau

  • CPU  (10 Minuten-Durchschnitt, 85% maximale Last)
  • Arbeitsspeicher (10 Minuten-Durchschnitt, 90% maximale Last)
  • Festplattenspeicher (5 Minuten, 15% freier Speicher)

Die obigen Werte richtigen sich dabei nach Empfehlungen von Microsoft. Werden diese Werte regelmäßig überschritten bzw bei freiem Speicherplatz unterschritten, kann eine korrekte Funktionsweise nicht mehr gewährleistet werden.

 

Schritt 2 - Interne Verarbeitung

Verarbeitung

Ist der Server ausreichend dimensioniert, ist dies natürlich noch keine Garantie für einen fehlerfreien Ablauf. Der Exchange Server selbst kann zum Beispiel durch massig Spam oder auch fehlerhafte Zustellungen belastet werden und so den normalen Mailflow negativ beeinflussen. Vielleicht werden aber auch gerade E-Mails versendet, die eine größere Menge an Daten beeinhalten.

Für genau diesen Fall haben wir Sensoren entwickelt, die über den Tellerand von Statusinformationen schauen und die Verarbeitung an sich überprüfen.

Der Sensor Exchange Nachrichtenübersicht liefert Statistiken über folgende Werte:

  • Gesendete/Empfangene Nachrichten inklusive Datenverkehr
  • Zustellungsfehler als Prozentwert (im Vergleich zu erfolgreichen Mails)
  • "Vergiftete" Nachrichten
  • Top 3 der fehlgeschlagenen Sender
  • Top 5 der größten Postfächer
  • Top 5 der nicht genutzten Postfächer

Gerade wenn bestimmte Email-Adressen (die vielleicht in einem nicht mehr aktiven Tool genutzt werden) zu hohen Zustellungsfehlern führen, hilft die Top 3 der fehlgeschlagenen Sender schnell die Ursache zu finden.

Durch die vom Sensor bereitgestellten Messwerte ist es außerdem auch möglich Lastszenarien zu erkennen, zu welchen Zeiten besonders viel Emailaufkommen stattfindet und dementsprechend zu reagieren.

Ein weiterer Sensor der die interne Verarbeitung überprüft ist der Exchange Warteschlange Sensor. Hier können Sie schnell und einfach überprüfen ob sich zu viele Emails in einer Warteschlange befinden und deswegen die Mailzustellung nur verzögert oder sogar gar nicht stattfindet.

 

Schritt 3 - Performancewerte zur Bottleneck Analyse

Performance

Es gibt Punkte die lassen sich ziemlich schwer greifen und vielleicht will man auch nicht direkt einen Alarm generieren, sondern nur ein Verhalten beobachten. Mit den Performance Countern lassen sich bequem verschiedene Aspekte des Systems analysieren und Auswertungen erstellen. Mit der von uns bereitgestellten PowerShell API können Sie sogar komplett eigene Sensoren auf Basis eines PowerShell Skripts erstellen. Oder Sie nutzen unsere vorhandenen Sensoren, wie die WMI Überprüfung, um gezielte Abfragen durchzuführen.

Ein Beispiel für interessante PerformanceCounter sind die sogenannten "Database Page Fault Stalls/sec". Dieser Wert wird jedes Mal um 1 erhöht wenn der Datenbank Cache Manager eine neue Page anfordert. Sollte dieser Wert durchschnittlich größer als 10 sein, deutet dies darauf hin das sogenannte "Dirty Pages" nicht schnell genug von der Datenbank entfernt werden. Ein Bottleneck für den Server.

Dies kann man mit dem vorhanden WMI Sensor in Server-Eye überwachen.

Dazu müssen Sie nur folgende Abfrage durchführen:

select * from Win32_PerfFormattedData_ESE_MSExchangeDatabase where Name = 'Information Store'

Als Parameter verwenden Sie "DatabasePageFaultStallsPersec"

WMI quert performance counter

 

Der Grund warum wir hier eine WMI Abfrage verwenden ist dabei relativ einfach. Nur in der WMI sind die Namen der PerformanceCounter nicht lokalisiert. Diese Prüfung können Sie also auf einem deutschen Exchange Server wie auf einem englischen oder spanischen durchführen. Ansonsten haben Sie mit den lokalisierten Namen der Zähler zu kämpfen und Sie müssen Ihr Skript immer anpassen.

Die Werte die zurückkommen werden natürlich auch in einem Graph festgehalten. Hier im Bild sieht man das zum Glück nicht viel los ist.

wmiabfrageCHART

Eine Übersicht verfügbarer/sinnvoller PerformanceCounter inklusive vorgeschlagener Schwellwerte für den Exchange finden Sie in diesem Technet-Artikel

In einem meiner kommenden Blogbeiträge widme ich mich außerdem der Problematik des Mailversandes.

Wie stellen Sie sicher, dass Ihr Server Emails zuverlässig versendet und empfägt?


.NET 2.0/3.5 Installationsprobleme unter Windows Server 2012 - Tipps und Tricks

Normalerweise ist das Hinzufügen des .NET 2.0/3.5 Frameworks unter Windows 2012 kein Problem. Allerdings kann es leider durchaus vorkommen das Sie folgende Fehlermeldung erhalten beim Hinzufügen des Features über den Server-Manager:

Fehler bei der Installation von mindestens einer Rolle, einem Rollendienst oder einem Feature. Die Quelldateien konnten nicht gefunden werden.

Um das Problem zu lösen können Sie mehrere Ansätze durchführen, die ich Ihnen kurz aufzeigen möchte.

 

 

Lösung 1 - DVD/USB

  • Legen Sie die Windows 2012 via DVD oder USB-Medium ein
  • Ein Netzwerkpfad geht prinzipiell auch, aber hier häufen sich Problemberichte
  • Nun im Server-Manager das Feature .NET 3.5 auswählen wie gehabt
  • Im Schritt "Bestätigung" wählen Sie "Alternativen Quellpfad angeben"
  • In dem folgenden Dialog nun einfach den Pfad F:\Sources\SxS , ausgehend davon das F: das Wechselmedium darstellt.
  • Nach einem Klick auf "OK" läuft die Installation nun erfolgreich durch.

 

SourceSelect

 

 

Lösung 2 - Die gute alte Kommandozeile

  • Starten Sie die CMD.exe als Administrator.
  • Führen Sie danach folgenden Befehl aus: "DISM /online /enable-feature /featurename:NetFx3 /all /Source:F:\Sources\SxS /LimitAccess"

DISM

 

Eine Dokumentation zum Befehl DISM finden Sie unter folgendem Link : http://msdn.microsoft.com/de-de/library/hh825265.aspx.

Sollten beide Hilfestellungen zu keinem Erfolg führen bietet Microsoft auch ein Fix-It Tool an. Den Download finden Sie hier:

http://blogs.technet.com/b/askpfeplat/archive/2014/09/29/attempting-to-install-net-framework-3-5-on-windows-server-2012-r2-fails-with-error-code-0x800f0906-or-the-source-files-could-not-be-downloaded-even-when-supplying-source.aspx

 

Wichtiger Nachtrag:

Von einem sehr netten Kunden, haben wir die Info über eine weitere Möglichkeit erhalten, wie man dieses Problem lösen kann. Erstmal danke dafür!

So tritt das oben beschriebene Problem besonders häufig in Umgebungen auf, in der ein WSUS 3.0 verwendet wird. Durch die lokalen Gruppenrichtlinien (gpedit.msc) können Sie das Verhalten bei der Quellensuche aber verändern, sodass der lokale Windows Update Dienst miteinbezogen wird.

Die Änderungen wird dabei direkt wirksam und ein Neustart wird nicht benötigt.

WSUS 3.0 :___:
Konfig der lokalen Gruppenrichtlinie

 

Nun sollten die nächsten Installationsprobleme des .NET Framework keine Probleme mehr darstellen für Sie :)