TechNet Blog Deutschland

News für IT-Pros & Neues aus dem TechNet-Team

TechNet Blog Deutschland

  • Das neue Surface Pro 3 - optimiert fürs Business durch leichte Bereitstellung und starke Performance

    Das neue Surface Pro 3 ist ideal, wenn Ihre Mitarbeiter zwar ein Tablet wollen, aber einen Laptop brauchen. Mit seiner Ausstattung und seinen Features erfüllt es alle Anforderungen an ein business-fähiges Tablet und ist für den Einsatz im Unternehmen optimiert.

     

    Deployment leicht gemacht – Das Deployment ist über die USB 3.0 Schnittstelle so einfach zu lösen, wie mit keinem anderen Tablet. Mit den beiden Technologien Microsoft Deployment Toolkit 2013 Server und Windows Server 2012 R2 WDS Server ist die Bereitstellung von Windows 8.1 Enterprise X64 Update in wenigen Schritten vorbereitet und durchgeführt. Mit dem PXE Boot eines MDT 2013 Lite Touch Images direkt vom WDS Server integriert sich das Surface Pro 3 nahtlos und einfach in die bestehende IT-Infrastruktur.

    Für Unternehmen optimiert – Mit der Docking Station kann das Surface Pro 3 jeden Desktop-PC ersetzen. Das 12“-HD-Display ist sowohl kompakt als auch im vorteilhaften 3:2-Format. Ein unschlagbares Duo bilden der Surface Pen und OneNote. Auf Konferenzen und in Meetings lassen sich hier im Handumdrehen Notizen machen und Fotos ablegen. Mit dem integrierten TPM-Chip können außerdem virtuelle SmartCards auf dem Surface Pro 3 anlegen.

    Performance ohne Einschränkung – Die drei frei wählbaren, performanten Prozessoren (Intel i3, i5 und i7). ermöglichen Ihren Mitarbeitern produktives Arbeiten im Büro, zu Hause aus und unterwegs. Mit der Smartphone-Pairing-Funktion verbindet sich das Surface mit einem einzigen Klick mit dem Internet. Das Einschalten des Tetherings auf dem Smartphone und die Anschaffung einer zweiten SIM-Card entfallen. Surface und Smartphone sind über den Bluetooth 4.0 Standard mit der energiesparenden Low Energy-Technologie verbunden. Das schont den Akku und trägt dazu bei, dass das Surface jeden Betriebsdauer-Vergleich mit einem herkömmlichen Laptop um Längen gewinnt.

    Erste Eindrücke – Unsere Community Expertin Martina Grom hat das Surface Pro 3 sofort für Sie getestet und ihre Eindrücke in einem Blogbeitrag festgehalten. Ihr Fazit: Es ist schnell und macht Spaß.


    Das Surface Pro 3 ist für Geschäftskunde ab sofort erhältlich – Informieren Sie sich bei Ihrem autorisierten Reseller

  • Neue Datenschutz-Funktionen in Microsofts Azure SQL Database

    Azures SQL Datenbank ist ab sofort mit neuen Funktionen wie Auditing, Geo-Replication und Geo-Restore ausgestattet, die für einen stark verbesserten Datenschutz sorgen. 

    Die neuen Funktionen sind  im Detail:

    1. Auditing

      Auditing trackt und dokumentiert alle Ereignisse, die innerhalb der Datenbank auftreten. zum Beispiel Updates und Abfragen. Reports und alle wichtige Infos zur Datenbank werden direkt im Dashboard angezeigt. So hat der Nutzer stets den Überblick über alle relevanten Aktivitäten und kann Trends und Anomalien schneller erkennen. 
      Neu sind auch Überwachungsfunktionen, die anzeigen, was in der Datenbank passiert und die Trends, Diskrepanzen und Anomalien aufzeigen. Diese dienen dazu, frühzeitig auf Sicherheitsrisiken oder verdächtige Sicherheitsverletzungen aufmerksam zu machen.
      Alle Audit-Events werden in ein Audit-Log geschrieben und in einem optionalen Azure Storage Account gespeichert, den der Nutzer selbst bestimmen kann.
    2. Geo-Replication
      Mit Geo-Replication können Anwender einen zusätzlichen Microsoft-Service nutzen, der eine zweite, laufend aktualisierte Datenbank bereitstellt – ideal für Notfälle. Die Azure-Regionen sind räumlich mindestens 500 Meilen (805 Kilometer) von einander entfernt, was für eine hohe Daten-Souveränität bei politischen Zwischenfällen sorgt. Geo-Replication ist verfügbar für Standard- und Premium-Datenbanken über das Azure Management Portal und die Standard APIs. In der Standard-Variante kostet die zweite Datenbank 75 Prozent der ersten Datenbank.
    3. Geo-Restore
      Das Feature wurde entworfen, um eine schnelle Daten-Wiederherstellung zu ermöglichen, wenn sie am dringendsten gebraucht wird: nach einem kritischen Zwischenfall. So lässt sich beispielsweise per Geo-Restore eine Datenbank wiederherstellen und retten, unabhängig davon, in welcher Azure-Region der Zwischenfall aufgetreten ist.
      Geo-Restore ist verfügbar in der Basic, Standard und Premium-Version von Azure über das Azure Management Portal und die Standard-API.

    Weitere Infos zu den technischen Details finden sich im Microsoft Azure Blog.

     Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates. 

  • So behalten Sie Kontrolle über ihren SharePoint

    Dieser Gastbeitrag wurde uns freundlicherweise von der AvePoint Deutschland GmbH zur Verfügung gestellt. Autor ist Robert Mulsow.

     

    Mit Sicherheit kennen Sie diese Situation: Ein selbsternannter „Power-User“ hat bestimmte Veränderungen in einer Site Collection vorgenommen und nun fehlen Daten und Features oder ein weiterer Nutzer hat plötzlich zu viele oder zu wenige Berechtigungen. Als SharePoint Administrator sind Sie nun in der Pflicht, die vorgenommenen Änderungen zu identifizieren und zurück zu setzen.

    Je nachdem, wie Sie Vorgänge in SharePoint aufzeichnen, kann das Auffinden und Zurücksetzen durchgeführter Änderungen schnell gehen. Dennoch bringt dieser Vorgang eine Unterbrechung für betroffene Nutzer mit sich und Sie als Administrator können sich nicht um wichtigere Projekte kümmern. Außerdem können Daten ohne Backup auch unwiderruflich gelöscht worden sein. Es macht somit Sinn, Vorgänge nicht nur aufzuzeichnen, sondern service-kritische Funktionalitäten pro-aktiv zu schützen.

    Was sind nun solche kritischen Funktionen, die man überwachen und schützen sollte? Aufgrund unterschiedlicher Unternehmensrichtlinien, des Zwecks der SharePoint Farmen und der genutzten Anwendungen kann man nicht pauschal sagen, welche bestimmten Funktionalitäten die wichtigsten sind. Basierend auf Erfahrungsberichten bei verschiedenen Großkunden vor Ort, lassen sich folgende Situationen besonders häufig feststellen:

    Inhalte werden aus Versehen gelöscht

    Basierend auf Quota-Vorlagen und den Einstellungen für die Leerung der SharePoint Papierkörbe (Site + Site Collection), kann ein Objekt schnell komplett aus dem SharePoint entfernt werden. Sollte es immerhin noch im Papierkorb auffindbar sein, könnten dennoch bereits bestimmte Metadaten bzw. Anpassungen vom Objekt entfernt worden sein. Dies kann der Fall sein, da solche Metadaten nicht vom SharePoint Papierkorb verwaltet werden können (z.B. SharePoint Designer Anpassungen). Daher sollten Löschvorgänge genau kontrolliert werden.

    Es werden zu viele Berechtigungen vergeben oder geändert

    Sehr häufig werden in Unternehmen an zu viele Mitarbeiter „Full Control“ Rechte vergeben. Dies stellt nicht nur ein Compliance Problem dar. Auch die Fehlerwahrscheinlich und -häufigkeit wird erhöht, da man mit solchen Rechten, auch unwissentlich, mit einem falschen Klick sehr kritische Funktionen lahm legen kann

    Wie kommt es zu einer derartigen Situation? Der Zustand ist von den Administratoren selbst initiiert, um schnell Nutzeranfragen vom Tisch zu haben. Um Zeit zu sparen werden kurzerhand kurzerhand „Full Control“ Rechte vergeben, anstatt sich mühsam und zeitaufwendig durch die einzelnen SharePoint Seiten und Gruppen zu klicken, um dann nur die tatsächlich erforderlichen Rechte zuzuweisen.

    Ist ein Endanwender erst einmal Site oder Site Collection Administrator, besitzt er das „Full Control“ Recht. Oft sind diese Anwender jedoch Projekt Manager oder fachliche Vorgesetzte, dieentweder keine Zeit für die Seitenadministration haben oder denen es am nötigen IT- bzw. SharePoint Wissen mangelt. So wird das „Full Control“ Recht gerne einmal an den Praktikanten oder den Werksstudenten mit IT-Hintergrund weiter gegeben. Dieser vergibt es dann wiederum an weitere Personen, die es wiederum an andere Kollegen weitergeben. Irgendwann besitzt jeder in der Farm „Full Control“ Rechte. In diese Situation möchte sicherlich kein SharePoint Administrator jemals kommen. Dementsprechend gilt es die entsprechenden Schutzmaßnahmen einzurichten.

    Deaktivierung der Versionierung in SharePoint Bibliotheken

    Manche Unternehmen verwenden die SharePoint Versionierung nicht nur für Veröffentlichungen mit Genehmigungsprozessen, sondern auch für eine Art Backup & Restore. Ein solches Vorgehen macht Sinn, wenn fehlerhafte Einträge vorgenommen oder eine finale Version korrupt wurde. Ein Dokument kann dann auf eine frühere Version zurückgesetzt werden. Was geschieht nun aber, wenn die Versionierung abgeschaltet wird, weil man annimmt, dass so sehr viel Speicherplatz eingenommen wird?* Alle Versionen gehen so bei der nächsten Änderung (ob Inhalt oder Metadaten) verloren. Sollte ein kritisches Dokument mit wichtigen Informationen bei der nächsten Speicherung sogar korrupt werden, können alle entsprechenden Daten verloren gehen. Auch das ist eine Situation, die jeder Administrator sicherlich vermeiden möchte.

     

    Welche Vorkehrungen kann ein SharePoint Administrator also dagegen treffen? Ein bloßes Training der Mitarbeiter ist aufwendig und müsste für neue Mitarbeiter wiederholt werden. Aus Compliance Perspektive entlastet diese Form den Administrator als Vorgesetzten zudem nicht von entsprechender Verantwortung. Reine Monitoring-Lösungen erfüllen nur die halbe Anforderung und mit SharePoint-nativen Mitteln könnte man jedem Nutzer nur maximal Leserechte geben, um obige Szenarien erfolgreich zu verhindern. All das ist mit Sicherheit nicht zielführend.

    Die Firma AvePoint hat für solche Fälle den „Policy Enforcer“ entwickelt, der aktiv verschiedenste Events im SharePoint auditiert (Check In/Out, Copy, Move, Change Permission etc.). Basierend auf diesen beobachteten Vorgängen, können verschiedene Regeln definiert werden. Zum Beispiel kann definiert werden, dass bestimmte, oder auch alle User, den Befehl „Löschen“ nicht ausführen dürfen (siehe Szenario 1). Es kann bestimmt werden, dass keine Berechtigungen vergeben, geändert odergelöscht werden können (siehe Szenario 2) oder die Versionierung nicht modifiziert werden darf (siehe Szenario 3).

    Der „Policy Enforcer“ ist somit eine Art zusätzliche Ebene über dem SharePoint. Das bedeutet, dass z.B. selbst ein Nutzer mit dem SharePoint „Full Control“ Recht nicht in der Lage ist, Berechtigungen zu vergeben, da dies beispielsweise nur der SharePoint Administrator selbst erledigen möchte. Diese Regeln können sowohl als „Verweigerung“ als auch „Erlaubnis“ konfiguriert werden und so kann beispielsweise einem SharePoint „Leser“ zusätzlich das Recht einräumt werden, Subseiten erstellen zu dürfen.

     

    Das ist nur ein Beispiel für eine von vielen weiteren Regeln, die der „Policy Enforcer“ standardmäßig mitbringt. Sogar entsprechende Benachrichtigungen können konfiguriert werden. Dieses Tool bietet zahlreiche Möglichkeiten die Arbeit als SharePoint Administrator zu vereinfachen.. Probieren Sie es einfach einmal aus!

    Viele Spaß beim „SharePointen“!

     

    * Anmerkung: Dies trifft für Versionen vor SharePoint 2013 zu. Mit SP2013 und dem Shredded Storage gestaltet sich die Situation anders. Dies soll jedoch in diesem Kontext nicht weiter behandelt werden.

  • Quick Tip Virtualisierung: Hyper-V Dynamic Memory aktivieren und anpassen

    Dieser Gastbeitrag wurde uns freundlicherweise vom Education Support Center zur Verfügung gestellt. Autor ist Iris Braselmann.

    Das ESCde betreibt im Auftrag von Microsoft Deutschland die TechNet Support Hotline. Mehr Infos unter www.technet.de/hotline.

    Mit dem Service Pack 1 für Windows Server 2008 R2 wurde in Hyper-V eine neue Funktion eingeführt, der dynamische Speicher. Durch dieses Feature wird der Arbeitsspeicher als freigegebene Ressource behandelt der zwischen virtuellen Maschinen verteilt werden kann. 



    Das Feature ist für Gastbetriebssysteme ab Windows Server 2003 und Windows Vista verfügbar. Windows XP wurde hierbei nicht berücksichtigt.

    Seit Hyper-V 2012 R2 kann der dynamische Speicher auch für Linux Gastbetriebssysteme genutzt werden. Lediglich aktualisierte Linux Integration Components werden hierfür benötigt.

    Bitte beachten: Dynamischer Speicher ist nicht für alle Server geeignet und wird beispielsweise nicht von Exchange-Servern [1], SQL-Servern [2] oder dem Sharepoint [3] unterstützt.

     

    Dynamischen Speicher aktivieren und anpassen

    Um den dynamischen Speicher für die virtuellen Maschinen (VM) zu aktivieren, müssen zunächst die Eigenschaften der jeweiligen VM geöffnet werden und der Bereich "Arbeitsspeicher" ausgewählt werden. Hier kann der Haken „Dynamisch“ zum Aktivieren gesetzt und im Weiteren folgende Einstellungen getroffen werden:


    ausgewählt wezum Aktivieren gesetzt und im Weiteren folgende Einstellungen getroffen werden:

    dynamic memory

    Start-RAM: Arbeitsspeicher den das Gastbetriebssystem benötigt um starten zu können. Dieser Wert sollte so niedrig wie möglich sein um eine optimale Arbeitsspeicherverwendung zu ermöglichen aber auch hoch genug sein, damit das Betriebssystem starten kann. Eine Tabelle mit den empfohlenen Start-RAM Werten für die verschiedenen Betriebssysteme befinden sich unter [4].

    Minimaler RAM: RAM der zu jeder Zeit der VM zur Verfügung stehen muss. Dieser Wert muss kleiner oder gleich groß zu dem Wert des Start-RAMs sein.

    Maximaler RAM: Legt fest wie viel Arbeitsspeicher maximal von der VM verwendet werden darf. Der Wert kann zwischen dem Minimum des RAMs beim Start und maximal 64 GB gewählt werden. Sollte das Betriebssystem jedoch nicht in der Lage sein 64 GB RAM zu nutzen, wird nur die Maximalzahl des Betriebssystem effektiv genutzt werden.

    Arbeitsspeicherpuffer: Arbeitsspeicher der nach Möglichkeit zusätzlich zum tätsächlichen Arbeitsspeicherbedarf der VM zugewiesen wird, angegeben in Prozent. Der Puffer wird jedoch nicht vergeben wenn der physische Speicher auf dem Computer nicht ausreicht.

    Arbeitsspeicherumfang: Regelt Prioritäten, falls der physikalische Arbeitsspeicher nicht ausreichen sollte um allen Maschinen den geforderten Arbeitsspeicher zuzuweisen.

     

    Dynamic Memory in System Center Virtual Maschine Manager (VMM)

    Da sich virtuelle Maschinen auch in System Center im Virtual Machine Manager verwalten lassen, können hier auch die Einstellungen für den dynamischen Speicher getroffen werden.

    Dafür muss zunächst die Virtual Machine Manager Console gestartet werden. Als nächstes wählt man den Host aus auf welchem die VM liegt, welche bearbeitet werden soll und wählt mittels Rechtsklick die Eigenschaften der VM aus. In der Hardware Konfiguration können, wie im vorliegenden Bild zu sehen, die Einstellungen wie im oberen Teil des Artikels beschrieben wurde, getroffen werden.

    Memory SC

    [1] http://technet.microsoft.com/en-us/library/jj619301(v=exchg.150).aspx

    [2] http://msdn.microsoft.com/en-us/library/hh372970.aspx

    [3] http://technet.microsoft.com/en-us/library/ff621103(v=office.15).aspx

    [4] http://technet.microsoft.com/de-de/library/ff817651(v=ws.10).aspx

  • TechNet Newsflash Ausgabe 17/2014

    Liebe Podcast-Zuhörer,

    der Podcast Ausgabe 17/2014 des TechNet Newsflash ist live.

    http://download.microsoft.com/download/B/5/6/B56DB709-07CA-4DE3-8F90-3CB99A2C01DD/TechNetFlash_17-2014.mp3

    Link zum TechNet Newsflash in Schriftform:

    http://www.microsoft.com/germany/technet/newsflash/aktuell.htm

    Link zum RSS Feed:

    http://www.microsoft.com/feeds/technet/de-de/newsflash/tn_flash_podcast_archiv.xml

    Wie immer: viel Freude beim Zuhören und späteren Durchstöbern der angekündigten Ressourcen!

    Euer TechNet-Team!

    ☁ Heike

  • PowerShell Quick-Tip: lokale und globale Variablen

    Dieser Gastbeitrag wurde uns freundlicherweise vom Education Support Center (ESCde) zur Verfügung gestellt. Autor ist Moritz Baer.

    Das ESCde betreibt im Auftrag von Microsoft Deutschland die TechNet Support Hotline. Mehr Infos unter www.technet.de/hotline.

    Beim Erstellen eines Skripts ist es oft hilfreich einzelne Programmteile als eine Funktion im Code anzulegen. Hier kann man in unerwartete Probleme mit Variablen geraten.
    Das Szenario
    Wie in fast jeder Programmiersprache, gibt es auch in der PowerShell die Unterscheidung zwischen lokalen und globalen Variablen bzw. entsprechenden Unterformen. Eine, innerhalb eines Klammer-Blocks deklarierte, Variable überschreibt für den Klammer-Block eine außerhalb definierte Variable mit dem selben Namen. Dies ist normal und auch so gewünscht.
    Das Problem
    Da in der Powershell das Zuweisen von Werten gleichbedeutend mit der Deklaration einer Variable ist, bekommt man jetzt allerdings ein Problem:
    $variable = "test"
    if($true) {
    $variable = "neuer Test"
    }
    echo $variable
    Echo gibt hier unerwarteter Weise test aus.  Die äußere Variable $variable bekommt außerhalb des IF-Blocks den Wert test. Da mit $variable auch eine neue Variable innerhalb des IF-Blocks instanziiert wird, wird der Wert neuer Test in die neue Variable und nicht in die außerhalb deklarierte Variable geschrieben. Die äußere Variable bleibt also unangetastet.
    Die Lösung
    Um ein solches ungewolltest Dilemma zu vermeiden, kann man in der PowerShell den Zugriff konkret auf den globalen-Kontext legen. Anstatt mit $NAME legt man die Variablen mit $global:NAME an:
    $global:variable = "test"
    if($true) {
    $global:variable = "neuer Test"
    }
    echo $global:variable
    Nun gibt echo wie gewünscht neuer Test aus.
     
  • TechNet Newsflash Ausgabe 16/2014

    Liebe Podcast-Zuhörer,

    der Podcast Ausgabe 16/2014 des TechNet Newsflash ist live.

    http://download.microsoft.com/download/B/5/6/B56DB709-07CA-4DE3-8F90-3CB99A2C01DD/TechNetFlash_16-2014.mp3

    Link zum TechNet Newsflash in Schriftform:

    http://www.microsoft.com/germany/technet/newsflash/aktuell.htm

    Link zum RSS Feed:

    http://www.microsoft.com/feeds/technet/de-de/newsflash/tn_flash_podcast_archiv.xml

    Wie immer: viel Freude beim Zuhören und späteren Durchstöbern der angekündigten Ressourcen!

    Euer TechNet-Team!

    ☁ Heike

  • Windows-Sicherheit: Wie Kriminelle geschützte Passwörter stehlen - und wie das zu verhindern ist

    Die Presse hat es hinlänglich berichtet: Laut der US-Sicherheitsfirma Hold Security haben russische Hacker rund 1,2 Milliarden Profildaten (Logins und Passwörter) sowie rund 500 Millionen E-Mail-Adressen von 420 000 Websites erbeutet. Für deutsche Internet-Nutzer gibt es bisher keine Hinweise, ob sie von dem rekordverdächtigen Daten-Diebstahl betroffen sind. Im Zusammenhang mit solchen Datenlecks kommt auch immer die Frage auf, wie gut Passwörter eigentlich auf Windows-Systemen beziehungsweise in Windows-Netzwerken geschützt sind.

    Das Mittel der Wahl zum Absaugen von Passwörtern im Windows-Umfeld sind “Pass-the-Hash” (PtH)-Angriffe. Ein PtH-Angriff ähnelt stark dem Passwort-Klau (“password theft attack”), basiert aber auf dem Absaugen und Weiterverwenden von verschlüsselten Passwort-Hashwerten – also den einmaligen mathematische Entsprechungen der Passwörter. Diese können auch direkt zur Authentifizierung verwendet werden, um zum Beispiel Dienste zu nutzen, die nur durch eine einmalige Anmeldung (Single Sign-On, SSO) geschützt sind. PtH ist ein spezieller Typ des Profildaten-Diebstahls, der weit verbreitet ist und Verunsicherungen auf der Seite der Nutzer verursacht.

    Um diese Technik zu nutzen, muss ein Angreifer zuerst lokalen Admin-Zugriff auf einem Computer haben, um die Profildaten von der Festplatte oder aus dem Speicher auszulesen und zu stehlen. Auf diesem privilegierten Level kann der Angreifer nicht nur die Passwort-Hashes abgreifen, sondern auch andere Profildaten, die auf dem kompromittierten Computer gespeichert sind. Lokalen Admin-Zugriff bekommt der Angreifer, indem er entweder den lokalen Admin-Account kompromittiert, oder einen Domain-Account hackt, der Zugriff auf eine lokale Admin-Gruppe hat.

    Per PtH kann ein Angreifer, der einen einzelnen Computer kompromittiert hat, auch auf andere, mit diesem verbundene Rechner zugreifen. Dazu gehören auch Domain Controller und andere Server, auf denen relevante Informationen liegen. Deshalb kann das Minimieren des Risikos eines PtH-Angriffs die Sicherheit einer Active-Directory-Umgebung wesentlich verbessern.

    Weitere Informationen, wie Windows-Anwender – vor allem in Unternehmen – sich gegen diese Angriffe schützen können, hat Microsoft online zusammengestellt. Ebenso detaillierte Informationen, wie Windows Passwörter verschlüsselt, speichert und schützt.

    Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates. 

     

  • TechNet Newsflash Ausgabe 15/2014

    Liebe Podcast-Zuhörer,

    der Podcast Ausgabe 15/2014 des TechNet Newsflash ist live.

    http://download.microsoft.com/download/B/5/6/B56DB709-07CA-4DE3-8F90-3CB99A2C01DD/TechNetFlash_15-2014.mp3

    Link zum TechNet Newsflash in Schriftform:

    http://www.microsoft.com/germany/technet/newsflash/aktuell.htm

    Link zum RSS Feed:

    http://www.microsoft.com/feeds/technet/de-de/newsflash/tn_flash_podcast_archiv.xml

    Wie immer: viel Freude beim Zuhören und späteren Durchstöbern der angekündigten Ressourcen!

    Euer TechNet-Team!

    ☁ Heike

  • IT Pro Academy - jetzt aus praxisnahen Szenarien lernen!

    Ob Sie nun den Einsatz einer Technologie planen, das Upgrade auf eine aktuelle Produktversion ansteht oder Sie sich persönlich weiterbilden möchten, die Auseinandersetzung mit neuen Technologien gehört mit zu den wichtigsten Aufgaben für Sie als IT-Professional. Um Sie bei dieser Herausforderung bestmöglich zu unterstützen, bieten wir von TechNet Deutschland Ihnen über die IT Pro Academy eine umfangreiche Ressourcensammlung.

    Dort finden Sie, nach Produkten und Vorkenntnissen aufgeschlüsselt, Fachartikel, Videos, Vortragsaufzeichnungen, Online-Trainings, Anleitungen, Partnerangebote, Downloads und vieles mehr – natürlich kostenfrei. Derzeit bietet die IT Pro Academy Ressourcen zu Windows Client, Windows Server, System Center, SQL Server, Office, Cloud OS und Microsoft Azure.

    Lernen aus Erfahrung: Praktische Szenarien von Microsoft-Partnern

    Theoretisches Wissen ist unverzichtbar, doch was wirklich wichtig ist und welche Funktionen oder Tricks Sie letztlich zum Ziel bringen, zeigt sich häufig erst in der Praxis, wo verschiedene Produkte in komplexen Lösungen zusammenspielen. Daher stellen wir Ihnen in der IT-Pro Academy seit kurzer Zeit auch eine Reihe technischer Szenarien von erfahrenen Microsoft-Partnerunternehmen zur Verfügung.

    Nutzen Sie die Erfahrung der IT-Professionals aus unserer Community, um typische Probleme kennen zu lernen oder innovative Lösungsansätze zu entdecken. Derzeit sind folgende Praxisbeispiele verfügbar, die Rubrik wird auch in Zukunft regelmäßig erweitert:

    • Reduzierung der lokalen Infrastruktur
      Um die IT-Mitarbeiter für hochqualifizierte Tätigkeiten einsetzen zu können, muss ein Unternehmen die Kapazitäten des internen Rechenzentrums verringern. Durch den Einsatz von Exchange Server 2010 und Office 365 konnten die Ziele umgesetzt werden.
    • Hochverfügbarkeit von Diensten
      Diese Szenario zeigt, wie mithilfe eines Scale-Out File Servers auf Basis von Windows Server 2012 R2 und Hyper-V die Hochverfügbarkeit von verschiedenen Diensten für rund 700 Client-Systeme orts- und geräteunabhängig gewährleistet werden konnte.
    • Ausfallsicherheit von Rechenzentren
      In diesem Szenario erfahren Sie, wie durch den Einsatz der Cloud-Plattform Microsoft Azure die Ausfallzeiten von kritischen Diensten und Kernapplikationen einer IT-Infrastruktur erheblich minimiert werden konnte.
    • Schutz vor Schadsoftware
      Dieses Szenario erklärt, wie durch die Implementierung einer zentral abgelegten und gesteuerten AppLocker-Richtlinie die Sicherheit, insbesondere der Schutz vor Trojanern, einer Unternehmensinfrastruktur verbessert werden konnte.

    Die IT Pro Academy soll noch besser werden – durch Ihr Feedback

    Um die IT Pro Academy auch weiterhin an Ihren Bedürfnissen ausrichten zu können, würden wir uns über Ihre Rückmeldung und Verbesserungsvorschläge freuen. Hierfür haben wir eine kleine fünfminütige Umfrage eingerichtet. Als Dankeschön für Ihr Feedback verlosen wir unter allen Teilnahmen insgesamt 40 Fachbücher für IT-Professionals, darunter u.a. „Microsoft SQL Server 2012 - Das Handbuch“, „Microsoft Exchange Server 2013 - Das Handbuch“, „Microsoft Windows Server 2012 R2 - Das Handbuch“ oder „Microsoft Windows 8 - Ratgeber für Administratoren“.

     Jetzt an der Umfrage teilnehmen!

    Teilnahmebedingungen.

    1. Veranstalter des Gewinnspiels ist die Microsoft Deutschland GmbH, Konrad-Zuse-Straße 1, 85716 Unterschleißheim.

    2. Teilnahmeberechtigt ist jeder, der das 18. Lebensjahr vollendet hat. Von der Teilnahme ausgenommen sind Mitarbeiter von Microsoft und deren Angehörige sowie Amtsträger und für den öffentlichen Dienst besonders Verpflichtete.

    3. Für die Teilnahme am Gewinnspiel nutzen Sie bitte das instant.ly Survey Tool, geben Sie Feedback zur IT Pro Academy und tragen Sie Ihren Namen, sowie Ihre Ihre E-Mail Adresse ein. Jeder Teilnehmer darf nur einmal teilnehmen. Mehrere Emails von demselben Teilnehmer werden von der Verlosung ausgeschlossen.

    4. Teilnahmeschluss ist Mittwoch, 27. August 2014, 18 Uhr. Es entscheidet der Zeitpunkt der abgeschlossenen Teilnahme an der Umfrage.

    5. Unter allen fristgerechten Einsendungen verlosen wir 40 Fachbücher von MS Press und Galileo Press zu aktuellen Microsoft-Technologien (darunter Windows Server 2012 R2, Exchange Server 2013, Windows 8 Konfigurieren u.v.m.)

    6. Die Gewinner werden per E-Mail benachrichtigt, nach Erhalt der Adresse werden die Gewinne anschließend per Post versandt.

    7. Die Ausbezahlung der Preise in bar ist nicht möglich.

    8. Der Rechtsweg ist ausgeschlossen.

    9. Gewährleistungsansprüche hinsichtlich der Gewinne sind gegenüber Microsoft Deutschland GmbH sind ausgeschlossen.   

  • Update für EMET 5.0 zum Download

    Microsoft hat ein neues Update für das Enhanced Mitigation Experience Tool (EMET) 5.0 veröffentlicht, unter anderem zwei neue Exploit Mitigations und neue Konfigurationsmöglichkeiten mitbringt. Das Update kommt sechs Monate nach der technischen Preview von EMET 5.0, die im Februar dieses Jahres veröffentlicht wurde. 

    Das Update enthält eine "Attack Surface Reduction" (ASR), die Windows-Admins bestimmen lässt, wann und wo Plugins wie Java oder Adobe Flash auf einem Windows Rechner laufen dürfen. Beide sind beliebte Ziele von Hackern. Durch die neue Funktion kann beispielsweise das Laden von Java-Anwendungen auf Internet-Seiten verhindert, auf Intranet-Seiten aber erlaubt werden. Mit dem Tool "Export Address Table Filtering Plus" werden zwei neue Möglichkeiten eingeführt, um moderne Angriffsarten zu verhindern. Dazu gehört auch ein Schutz namens "Page Guard", mit dem das unerwünschte Auslesen von Arbeisspeicherbereichen verhindert werden kann.

    Weitere Infos von Microsoft zum Update von EMET 5.0 finden sich auf den Webseiten der US-Kollegen.

    Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates. 

  • Sicherheitsreport: Viele Eltern wissen nicht, was ihre Kinder im Internet tun

    Laut eines Sicherheitsreports der Deutschen Telekom überblickt fast die Hälfte (49 Prozent) der befragten Eltern nicht, was ihre Kinder im Internet tun. Die Hälfte (50 Prozent) erklärt dagegen, dass sie gut über die Aktivitäten ihrer Kinder im Internet Bescheid wüssten.

    Bedenklich sei nach Ansicht der Studienautoren, dass 43 Prozent der Eltern, die nach eigenem Bekunden keinen Überblick über die Aktivitäten ihrer Kinder im Internet haben, das Gefühl haben, ihre Kinder wissen nicht ausreichend über die Gefahren im Internet Bescheid.

    Zwei von drei Befragten der Sicherheitsstudie befürchten, dass ihre Kinder im Internet zu viel von sich Preis geben - und zu lange online sind. 62 Prozent haben Angst davor, dass Kriminelle über Chats oder Foren Kontakt mit ihren Kindern aufnehmen könnten, Und 58 Prozent befürchten, dass Fotos der Kinder ohne Wissen der Eltern ins Internet gestellt werden.

    Informationen für Eltern, wie sie ihre Kinder im Internet schützen können, gibt zum Beispiel die Webseite “Schau hin, was Dein Kind mit Medien macht”. Hier geben Experten Tipps für Eltern, damit ihre Kinder den richtigen Umgang mit Smartphone und Spielkonsole lernen und klären über die Gefahren auf, die im Internet drohen. Zum Beispiel die tägliche Nutzungsdauer zu begrenzen und bestimmte Seiten im Internet für Kinder zu filtern. Tipps zum sicheren Umgang mit Passwörtern und persönlichen Informationen von Kindern und Jugendlichen gibt Microsoft im “Safety & Security Center”.

    Wirklich schlechte Erfahrungen im Netz gemacht haben nach Angaben der Eltern nur wenige Kinder: Nur knapp 20 Prozent der Eltern berichtet beispielsweise davon, dass ihre Kinder pornographische Filme oder Gewaltvideos gesehen und illegal Musik oder Filme heruntergeladen haben. Man kann nur hoffen, dass diese Einschätzung auch der Realität entspricht.

    Die Zukunft der Internet-Sicherheit schätzen die Befragten kritisch ein: 91 Prozent gehen davon aus, dass die Gefahren durch Datenbetrug im Internet, Computerviren, Missbrauch persönlicher Daten durch andere Nutzer und Unternehmen in Zukunft zunehmen werden.

    Der Sicherheitsreport 2014 stützt sich auf insgesamt 1.503 Interviews mit einem repräsentativen Querschnitt der Bevölkerung ab 16 Jahren. Befragt wurden außerdem gezielt Eltern von 6- bis 17-jährigen Kindern und Jugendlichen.

    Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates. 

  • TechNet Newsflash Ausgabe 14/2014

    Liebe Podcast-Zuhörer,

    der Podcast Ausgabe 14/2014 des TechNet Newsflash ist live.

    http://download.microsoft.com/download/B/5/6/B56DB709-07CA-4DE3-8F90-3CB99A2C01DD/TechNetFlash_14-2014.mp3

    Link zum TechNet Newsflash in Schriftform:

    http://www.microsoft.com/germany/technet/newsflash/aktuell.htm

    Link zum RSS Feed:

    http://www.microsoft.com/feeds/technet/de-de/newsflash/tn_flash_podcast_archiv.xml

    Wie immer: viel Freude beim Zuhören und späteren Durchstöbern der angekündigten Ressourcen!

    Euer TechNet-Team!

    ☁ Heike

  • Studie: Fast jedes Unternehmen hatte 2013 eine schwere Sicherheitspanne

    2013 hat sich in mehr als 96 Prozent der Unternehmen ein bedeutender IT-Sicherheitsvorfall ereignet. Das ist ein Ergebnis des "Cyber Defense Maturity Report 2014". In einem von sechs Unternehmen kam es in den letzten zwölf Monaten zu fünf oder mehr bedeutenden Sicherheitsereignissen, in 39 Prozent der Unternehmen waren es zwei oder mehr. Befragt wurden Vertreter von Unternehmen mit mehr als 500 Mitarbeitern in den USA, Großbritannien, Deutschland, Österreich und der Schweiz, die in den Sektoren Finanzwesen, Produktion, Gesundheitswesen, Einzelhandel und Bildungswesen aktiv sind.

    Die häufigsten Sicherheitsvorfälle waren dem Report zufolge Phishing, Verstöße gegen Compliance-Richtlinien, Einsatz nicht genehmigter Geräte und Anwendungen sowie unbefugte Datenzugriffe. Am häufigsten genannt wurden Sicherheitsprobleme in folgenden Bereichen: Malware, Anwendungs- und Wireless-Sicherheit, Zugriff auf Netzwerkressourcen, Einsatz nicht genehmigter Anwendungen und persönlicher Mobilgeräte sowie Datenlecks.

    Ein Grund für die zu schwachen Sicherheitsmaßnahmen sind offenbar die immer komplexer werdenden Prozesse in Unternehmen. Mehr als 43 Prozent der Befragten halten das Verhindern, Identifizieren, Diagnostizieren und Beheben von Problemen heute für schwieriger als noch vor zwei Jahren.

    Die Mehrzahl der befragten IT-Unternehmen sind sich bewusst, dass ein Teil ihrer Sicherheitsmaßnahmen unausgereift oder ineffektiv sind und nur 33 Prozent sind sehr zuversichtlich, dass sie die Sicherheitskontrollen verbessern können.

    Relativ unausgereift sind nach Ansicht der Befragten die Kontrollmaßnahmen beim Einsatz persönlicher Mobilgeräte (“BYOD”), Inventarmanagement und Endpunkt-Compliance. Zudem gebe es Sicherheitsprobleme im Zusammenhang mit Virtualisierung und der der Anwendungssicherheit. Nur 54 Prozent der Befragten glauben, dass sich die Situation in den nächsten 12 Monaten verbessern wird. 78 Prozent aller Befragten erklärten, dass BYOD Auswirkungen auf Governance, Risk & Compliance habe.

    Malware-Angriffe wurden in sämtlichen Branchen und Regionen als Top-Priorität eingestuft. Gleichzeitig scheint die Wahrscheinlichkeit geringer, dass weitere Ressourcen für deren Abwehr bereit gestellt werden.

    Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates.

     

  • Deutschland: Jeder zehnte PC mit offenen Sicherheitslücken im Netz unterwegs

    Laut Secunia PSI Country Report für das zweite Quartal 2014 verwenden zehn Prozent der deutschen, 9,3 Prozent der österreichischen und 8,4 Prozent der schweizerischen Nutzer einen Computer mit nicht aktualisiertem Betriebssystem. Betroffen von der Update-Müdigkeit ist vor allem Windows, dabei handelt es sich vor allem um ungepatchte Versionen von Windows 7, Windows 8 und Windows Vista. Dies ist insofern ungewöhnlich, da Windows ja mit dem automatischen Updatemechanismus Windows Update ausgeliefert wird, der neue Patches selbständig herunterlädt und installiert. Mehr zu Windows Update und zum Check, ob der Mechanismus aktiv ist, auf unserer Webseite.

    Laut Secunia sind auch zehn bis elf Prozent der Drittanbieter-Programme auf einem durchschnittlichen PC in Deutschland, Österreich oder der Schweiz nicht auf dem aktuellen Stand. Das heißt, dass an sich  Sicherheitsupdates nicht installiert werden. Und rund fünf Prozent der Programme werden sogar vom Hersteller nicht mehr unterstützt („End-of-Life“-Programme), teilt Secunia mit.

    In Deutschland, Österreich und der Schweiz setzen mehr als zwei Drittel der Nutzer Versionen des Adobe Flash Players 13 ein, die bereits das Ende des Lebenszyklus erreicht haben, so Secunia. Die Mehrheit der Anwender nutze immer noch die Vorgängerversion, obwohl diese ungepatchte Schwachstellen aufweist.

    Secunia ermittelte auch, dass auf einem durchschnittlichen PC in Österreich 38 Prozent aller Programme von Microsoft stammt und 62 Prozent von Drittanbietern. Diese sind die Ursache für 48 Prozent der gefundenen Schwachstellen.

    Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates.

  • Effizientes Berechtigungs-Management mit SharePoint

    Dieser Gastbeitrag wurde uns freundlicherweise von der AvePoint Deutschland GmbH zur Verfügung gestellt. Autor ist Robert Mulsow.

    Suche und Übertragung von Nutzerrechten

    SharePoint bietet die ideale Möglichkeit, um Nutzern Zugang zu Informationen zu gewähren und gleichzeitig vertrauliche Informationen vor unerwünschtem Zugang zu bewahren. Grundlage für diese Möglichkeit ist das Berechtigungskonzept im SharePoint, welches hierarchisch aufgebaut ist. AD Nutzer und Gruppen werden entweder in SharePoint Gruppen integriert (Best Practice) oder einem bestimmten Berechtigungslevel zugewiesen, z.B. dem Level „Besucher“. Zu diesem Level „Besucher“ gehören nun explizite Rechte, wie das Lesen von SharePoint-Seiten inkl. aller Funktionselemente wie Masterpage, Ansichten etc., sowie das Öffnen von Dokumenten. Dies ist gleichzeitig das letzte Element der Kette, das Objekt, auf das entsprechende Rechte angewendet werden.

    Basierend auf diesem Konzept muss ein SharePoint Administrator von unten nach oben planen. Er muss sich überlegen, auf welche Objekte er welchen SharePoint oder AD Nutzern und Gruppen mit welchen Berechtigungen Zugang ermöglichen möchte. Dabei ist ein weiterer Best Practice Ansatz sehr hilfreich: So viele Rechte wie nötig, aber so wenige wie möglich vergeben!

    Das ist in kleinen Umgebungen, die z.B. aus einem kleinen Intranet mit einem Farm Administrator und wenigen Nutzern, die Lesen und Beitragen dürfen, gar kein Problem. Was ist jedoch, wenn es mehrere Webapplikationen gibt? Als Beispiel kann man dazu ein standardisiertes Intranet Portal und eine Projekt-Webapplikation betrachten, in der es ad-hoc Projektseiten mit manuellen Rechtevergaben gibt. Weitere Beispiele sind Wiki-Seiten, die Verwendung von Content Deployments usw.… Dann kann es ganz schnell unübersichtlich werden.

    Im Idealfall gäbe es im SharePoint eine Auflistung darüber, wer welche Berechtigungen hat. Leider ist dies nicht der Fall. Hier ein Beispielszenario: Sie sind SharePoint Administrator in einem größeren Unternehmen, das demzufolge auch eine größere SharePoint Farm hat. Ein Mitarbeiter, dem schon innerhalb der Farm auf verschiedenen Ebenen Rechte zugewiesen wurden – zum Teil auch manuell und direkt vergeben – möchte sich weiterentwickeln. Ein neuer Mitarbeiter soll seinen Platz einnehmen. Somit braucht dieser idealerweise die gleichen Rechte, damit auch er die erforderlichen Aufgaben erfolgreich absolvieren kann.

    Daraus ergeben sich drei Konstellationen:

    1. Wie finden Sie all die Rechte heraus, die der bestehende Mitarbeiter in der gesamten Farm hat?

    2. Wie können Sie all diese Rechte an den neuen Mitarbeiter übertragen?

    3. (Im schlechtesten Fall:) Der Mitarbeiter verlässt das Unternehmen und zusätzlich müssen Sie nun den Account aus allen SharePoint User-Tables löschen.

    Wie können diese Szenarien nun am effizientesten im SharePoint abgebildet werden?

    1. Sie gehen in jede einzelne Seite, Liste und im worst case (Item-Level-Permission) sogar auf jedes einzelne Objekt, suchen die entsprechenden Berechtigungen zusammen und dokumentieren diese. Denken Sie dabei auch an den berühmten „Limited Access“! Diese Vorgehensweise würde Monate in Anspruch nehmen.

    2. Angenommen, Sie haben alle Berechtigungen sauber dokumentiert, dann müssen Sie dennoch, wie in Punkt 1 beschrieben, jedes einzelne Objekt im SharePoint auswählen, um dem neuen Nutzer die dortigen Rechte zuzuweisen. Ebenso kein praktikabler Ansatz. Sie möchten den Prozess abkürzen, indem Sie dem neuen Nutzer direkt „Full Control“ auf vielen, wenn nicht sogarallen Ebenen, vergeben. Zwar mag das Problem mit fehlenden Berechtigungen dann beseitigt sein, aber wie steht es bei diesem Vorgehen um Ihre Compliance-Richtlinien? Sehr wahrscheinlich ist auch dieser Ansatz wenig praktikabel.

    3. Sie können den betroffenen Nutzer aus Ihrem AD deaktivieren oder ganz löschen. Der User Profile Synchronization Service erkennt diese Änderung im ersten Sync (setzt eine Flag) und löscht den Nutzer beim zweiten Sync aus dem User Profile Service. Der Nutzer bleibt jedoch in allen User-Tables bestehen, sodass weder Deaktivieren noch Löschen eine saubere Lösung ist, um den Nutzer komplett aus Ihrer SharePoint Umgebung zu entfernen.

    Um das Berechtigungs-Management effizienter zu gestalten und stressfrei nach allen Nutzerberechtigungen zu suchen und um diese möglichst einfach übertragen zu können, muss man auf andere Lösungen, wie die „Security Search“ im DocAve Administrator der Firma AvePoint, zurückgreifen. Dort gibt es die Möglichkeit, einen kompletten Scan der Farm durchzuführen, entweder für einen bestimmten User oder für alle. Der Scan kann noch zusätzlich auf Site Collection, Site usw. eingegrenzt oder sogar ein eigener Filter gesetzt werden. So wird sauber ausgewertet, welcher Nutzer welche Rechte im betreffenden Geltungsbereich hat.

    Für das zweite Szenario können die ausgelesenen Rechte verwendet und einfach auf einen neuen Nutzer geklont oder übertragen werden. Auch dieser Schritt ist in kurzer Zeit erledigt.

    Für das dritte Szenario gibt es den sogenannte „Dead Account Cleaner.“ Mit einem einfachen Befehl kann die Farm nach sogenannten Dead Accounts, also deaktivierten Accounts, abgesucht und diese dann komplett aus der SharePoint Farm herausgelöscht werden. Es besteht zusätzlich die Möglichkeit, die Rechte, die der deaktivierte Account hatte, auf einen neuen Nutzer zu übertragen. Auch dieser Schritt ist mit wenigen Klicks erledigt und erspart dem SharePoint Administrator sehr viel Arbeit.

    Sie können natürlich auch das Rechtemanagement stark eingrenzen und nur mit Rechte-Vererbungen arbeiten. Dies erfordert allerdings sehr präzise Planung, und nimmt dem SharePoint seine Flexibilität. Nutzern könnte so eventuell kein angemessener Zugang zu notwendigen Daten bereitgestellt werden, was sich wiederum negativ auf die Produktivität auswirkt.

    Jeder Administrator wird früher oder später auf oben beschriebene Probleme stoßen. Um diesen entgegen zu wirken und den Mehrwert von SharePoint voll auszuschöpfen, muss sich jeder Administrator daher mit der dynamischen und flexiblen Rechtevergabe auseinandersetzen. Zu diesem Zeitpunkt ist es gut zu wissen, dass es dafür adäquate Lösungen gibt.

    Viel Spaß beim „SharePointen“!

  • Die Installation eines Hyper-V Failover Cluster unter Windows Server 2012 R2

    Dieser Gastbeitrag wurde uns von unserem Partner Rachfahl IT Solutions GmbH und Co. KG (Autor: Jan Kappen) zur Verfügung gestellt und erschien erstmals im Hyper-V Blog.

    Dieser Artikel behandelt die Installation eines Failover Cluster unter Windows Server 2012 R2, welches zur Ausführung von Hyper-V VMs genutzt wird. Gegenüber den vorherigen Artikeln zur Einrichtung unter Windows Server 2008 R2 und Windows Server 2012 hat sich teilweise etwas geändert, das “Grundrauschen” ist allerdings gleich geblieben. Die größte Änderung liegt darin, dass durch unterschiedliche Techniken die Anzahl der Möglichkeiten enorm gestiegen sind. Dadurch gibt es nicht mehr “die eine” optimale Lösung, es muss nun anhand der jeweiligen Hardware entschieden werden, was die beste Lösung in diesem einen Fall ist. Zusätzlich habe ich an einigen Stellen noch die genutzten PowerShell-Befehle mit aufgeführt. Diese hier beschriebene Konfiguration eignet sich primär bei der Nutzung eines Scale-Out File Servers. Dieser ist bereits eingerichtet und in diesem Artikel wird nicht auf die Einrichtung eingegangen, dies wird komplett im zweiten Teil der Serie gemacht.

    Die genutzte Hardware:

    Die Demoumgebung

    Die hier genutzte Hardware sind zwei Rechner aus unserem Hyper-V Powerkurs und einem Scale-Out Fileserver unter Windows Server 2012 R2 als SMB3-Ziel. Die Rechner besitzen zwei 1Gbit NICs und vier 10Gbit NICs, 24 GB RAM und eine Quadcore-CPU. Beide Server sind Mitglied der Active Directory powerkurs.local. Der Scale-Out File Server hat jeweils zwei 10Gbit-Ports für SMB3 und zwei 1Gbit-Ports zur Anbindung an die Active Directory pro Knoten.

    Ein paar Worte zu der Hardware, den Verbesserungs- und den Sparmöglichkeiten

    Diese hier beschriebene Konfiguration entsprecht von den Eckdaten her dem, was wir empfehlen und was wir bereits in Projekten mehrfach erfolgreich eingesetzt haben. Natürlich sollte als Server ein wirklicher Server zum Einsatz kommen, der für den 24/7-Betrieb geeignet ist. Von einer Nutzung von PCs oder Workstations ist natürlich absolut abzuraten, wegen der Verfügbarkeit habe ich diese Systeme aber als Demoumgebung genutzt.

    Wir geben Ihnen als Empfehlung zwei 10Gbit-Adapter mit jeweils zwei Ports vor, d.h. jeder Hyper-V Host ist mit 40 Gbit angebunden, hinzu kommen noch zwei oder mehr 1 Gbit-Adapter. Diese Anbindung könnte theoretisch noch erhöht werden auf sechs 10 Gbit-Adapter, prinzipiell spricht hier nichts gegen. Dies bewirkt eine Erhöhung der Gesamtbandbreite, ändert aber nichts an der Performance der einzelnen Adapter. Hier kommen RDMA bzw. SMB Direct-Karten ins Spiel. Mit Hilfe dieser Technik können Sie eine deutliche Steigerung der Performance bei sehr geringer Latenz erreichen. Wenn alle Netzwerk-Komponenten diese Technik beherrschen haben Sie eine enorm hohe Bandbreite zwischen Hyper-V Failover Cluster und Scale-Out File Server. Informationen zu dem Thema gibt es unter anderem im Hyper-V Podcast Folge 35 von meinem Kollegen Carsten Rachfahl.

    Wenn Sie nicht den Bedarf von 40 Gbit pro Knoten haben oder die Hardware bereits vorhanden ist, können Sie den Betrieb auch mit einer 10 Gbit DualPort-Karte realisieren. In diesem Fall wären die VMs mit zwei oder mehr 1 Gbit-Karten angebunden, die 20 Gbit ständen dann exklusiv für die Anbindung an den Storage zur Verfügung.

    Die Installation und Einrichtung des Betriebssystems

    Die Einrichtung beginnt mit einer frischen Installation eines Windows Server 2012 R2 in der Datacenter Edition auf beiden Hosts. Nach der Grundinstallation werden die Netzwerkkarten umbenannt und teilweise zu einem Team konfiguriert.

    image

    Beide 1Gbit-Adapter werden zu einem Team zusammengefasst, zusätzlich werden zwei 10Gbit-Adapter (jeweils auf einem der beiden Adapter) zu einem Team zusammengefasst. Das 2Gbit-Team wird als Management-Netzwerk genutzt, das 20Gbit-Team wird zur Anbindung der VMs an das Netzwerk genutzt. Insgesamt existieren vier Netzwerke, auf drei der Karten hat der Host eine eigene IP-Adresse. Das VM-Netzwerk wird exklusiv für die virtuellen Computer genutzt.

    image

    image

    image

    Die Konfiguration per PowerShell wäre wie folgt:

    New-NetLBFOTeam -Name "Management-Team" -TeamNICName "Management-Team" -TeamMembers 1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

    New-NetLBFOTeam -Name "VM-Team" -TeamNICName "VM-Team" -TeamMembers 10GBit#1, 10GBit#3 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

    Die Karte Management-Team wird mit einer IP-Adresse im Bereich 192.168.209.0/24 konfiguriert. In meinem Fall arbeite ich mit den Systemen Hyperv10 und Hyperv15, daher bekommt Hyperv10 die Adresse 192.168.209.10 und Hyperv15 die Adresse 192.168.209.15. Die Endadresse bleibt in allen Netzen gleich, so kann eine eindeutige Zuordnung erfolgen. Eine gleichmäßige Zuweisung von Adressen sowie eine durchgängige Benamung machen den Betrieb und die Administration an vielen Stellen einfacher. Die Karte VM-Team wird zu diesem Zeitpunkt nicht konfiguriert, sie wird später als Hyper-V Netzwerk genutzt. Bei der Wahl der Adapter wird jeweils ein Adapter pro Hardware-Karte gewählt, dies ermöglicht einen Betrieb auch dann, wenn einer der beiden Hardware-Karten ausfallen würde. Die Bindungen der Karte werden nicht geändert und sehen wie folgt aus:

    image

    Die beiden 10Gbit-Adapter, die nicht Mitglied des Teams sind, werden mit einer IP-Adresse aus den Storage-Bereichen versehen. Hierbei achten wir ebenfalls darauf, dass die End-Adresse jeweils identisch ist mit der Adresse im Management-Netz. Nach der korrekten Konfiguration sehen die Eigenschaften der Karten wie folgt aus:

    image

    image

     

     

     

     

     

    image

    image

     

     

     

     

     

     

     

     

     

     

     

    Unter IP-Einstellungen werden keine Änderungen vorgenommen, die Einstellungen der Karte 10GBit#2 (die zweite Storage-Karte) sind bis auf die IP-Adresse identisch.

    Die Konfiguration per PowerShell:

    Set-NetIPInterface -InterfaceAlias "10GBit#2" -dhcp Disabled -verbose
    New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#2" -IPAddress 192.168.208.10
    Set-DnsClientServerAddress -InterfaceAlias "10GBit#2" -ServerAddresses 192.168.209.1
    Set-NetAdapterBinding -Name "10GBit#2" -ComponentID ms_tcpip6 -Enabled $False

    Set-NetIPInterface -InterfaceAlias "10GBit#2" -dhcp Disabled -verbose
    New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#4" -IPAddress 192.168.207.10
    Set-DnsClientServerAddress -InterfaceAlias "10GBit#4" -ServerAddresses 192.168.209.1
    Set-NetAdapterBinding -Name "10GBit#2" -ComponentID ms_tcpip6 -Enabled $False

    Beide Server werden nun auf den aktuellen Patchlevel geupdatet.

    image

    Nach der Installation und dem anschließenden Neustart kann die Einrichtung mit der Installation der Hyper-V Rolle fortgesetzt werden.

    Über den Server-Manager oder per PowerShell kann nun die Hyper-V Rolle installiert werden. Bei der während der Installation durchgeführten Konfiguration wählen wir keine der Karten für das Hyper-V Netzwerk aus, dies wird im späteren Verlauf manuell konfiguriert. Die Livemigration wird nicht konfiguriert, bei der Wahl der Pfade wird ebenfalls an dieser Stelle keine Änderung vorgenommen. Das System startet nun zwei Mal durch und steht danach wieder zur Verfügung.

    image

    image

    imageimage

     Alternativ kann die Installation natürlich auch per PowerShell gemacht werden:

    Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart

    Wenn der Parameter –ComputerName noch mit angegeben wird können sogar alle Server fast gleichzeitig installiert werden:

    Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart -ComputerName Hyperv10

    Die Einrichtung von Hyper-V zur Vorbereitung auf den Betrieb als Failover Cluster-Knoten

    Nach der Installation von Hyper-V müssen noch ein paar lokale Einstellungen vorgenommen werden, bevor das Failover Cluster eingerichtet werden kann. Im Hyper-V-Manager werden auf beiden Systemen unter dem Manager für virtuelle Switches eine neue externe Switch erstellt und auf den VM-Team-Adapter gebunden. Achten Sie darauf, den korrekten Adapter auszuwählen.

    image

    Wie Sie die virtuelle Switch nennen ist Ihnen überlassen, wichtig ist das sie auf allen Hyper-V Hosts gleich heißt. Achten Sie zusätzlich unbedingt darauf, nicht die gemeinsame Verwendung zu aktivieren. Bei Nutzung der gemeinsamen Verwendung bekommt der Host eine weitere, virtuelle Netzwerkkarte, die nicht benötigt und nicht gewollt ist. Der PowerShell-Befehl hierzu ist:

    New-VMSwitch -Name "VM" -NetAdapterName VM -AllowManagementOS 0 -ComputerName Hyperv10

    Danach kann Hyperv10 durch den Namen des zweiten Knoten ersetzt werden.

    Die Installation und Einrichtung des Failover Cluster

    Nachdem nun die Vorbereitungen abgeschlossen sind können wir mit der Installation und Einrichtung des Failover Cluster beginnen.

    Die Installation der benötigten Features

    Für die Einrichtung eines Failover Cluster wird das Feature Failoverclustering benötigt

    image

    Wenn Sie das System lokal administrieren möchten oder müssen sollten Sie die Failovercluster-Verwaltungstools sowie das Failoverclustermodul für Windows PowerShell ebenfalls installieren

    image

    Per PowerShell:

    Install-WindowsFeature Failover-Clustering –IncludeAllSubFeature –IncludeManagementTools -ComputerName Hyperv10

    Die Einrichtung des Failover Cluster

    Nach der Installation öffnen Sie den Failovercluster-Manager und beginnen mit dem Menüpunkt Konfiguration überprüfen….

    image

    Im Assistenten fügen Sie die Server hinzu, die überprüft werden sollen (Tipp: das lokale System kann mit einem Punkt ( . ) oder “localhost” hinzugefügt werden)

    image

    Danach können Sie auswählen, welche Tests durchgeführt werden sollen. Falls dies der erste Durchlauf ist sollten Sie unbedingt alle Tests auswählen, falls Sie nur einen oder mehrere spezielle Tests durchführen möchten (z.B. bei einem erneuten Durchlauf) können Sie diese manuell auswählen.

    image

    Es werden nun alle Tests durchgeführt, dies dauert je nach Anzahl der Server.

    image

    Nach dem Durchlauf erhalten Sie eine Übersicht der Tests und haben die Möglichkeit, sich den kompletten Bericht anzeigen zu lassen.

    image

    Schauen Sie sich unbedingt die Warnungen und Fehler an. Je nach Art der Fehler können diese entweder ignoriert werden oder sie müssen aktiv korrigiert werden. In meinem Fall steckte ein Kabel in einem falschen VLAN, wodurch die folgende Meldung in dem Bericht auftaucht:

    image

    Solche Fehler werden meist durch den Assistenten erkannt und angemerkt, eine Behebung vor der Erstellung und Nutzung des Failover Cluster macht deutlich mehr Spaß als die nachträgliche Suche.

    Andere Warnungen können ggf. ignoriert werden, z.B. ein fehlender Datenträger oder eine permanente SCSI-3-Reservierung. Da wir mit SMB3-Shares arbeiten sind keine Datenträger im Failover Cluster vorhanden.

    image

    Wenn keine Fehler während der Überprüfung auftauchen aktiviert der Assistent direkt die Möglichkeit, den Failover Cluster mit den überprüften Knoten zu erstellen

    image

    Während der Erstellung werden wir nach dem Namen des Failover Cluster und der IP-Adresse gefragt, unter der eine Administration möglich ist. Die Frage nach dem Netzwerk erscheint nur, weil keine der Netzwerkkarten ein Gateway eingetragen hat. Sobald ein Gateway vorhanden ist wird automatisch dieses Netzwerk als Zugriffspunkt definiert.

    image

    Wir benötigen in unserem Fall eine IP-Adresse im Netzwerk 192.168.209.0/24 und einen eindeutigen Namen

    image

    Nach einem Klick auf Weiter wird überprüft, ob Name und IP-Adresse bereits vorhanden bzw. belegt sind, falls dies nicht der Fall ist erscheint eine Übersicht über die getätigten Einstellungen.

    image

    Die Option Der gesamte geeignete Speicher soll dem Cluster hinzugefügt werden bewirkt an dieser Stelle keine Änderung, da keine Datenträger hinzugefügt wurden. Wir haben uns angewöhnt diese Option grundsätzlich zu deaktivieren, da wir den Speicher manuell zuweisen wollen. Nach einem Klick auf Weiter wird der Cluster erstellt, danach verbindet sich der Failovercluster-Manager automatisch mit dem gerade erstellten Cluster. In der Zusammenfassung bekommen wir noch einen Hinweis angezeigt, dass kein geeigneter Datenträgerzeuge vorhanden ist. Um diese Einstellungen kümmern wir uns später.

    image

    Die Konfiguration des Netzwerks

    Die ersten Anpassungen im gerade erstellten Cluster werden im Netzwerk gemacht. Die Netze werden automatisch durchnummeriert, diese Namen ändern wir auf die Funktion des einzelnen Netzwerks.

    image

    Um welches Netz es sich handelt können Sie sehen, wenn Sie auf das Netzwerk klicken und im unteren Teil auf den Reiter Netzwerkverbindungen wechseln.

    image

    Das Ergebnis sind drei vollständig benannte Netzwerke. Die Eigenschaften der Karten sehen wie folgt aus:

    image

    image

    In den Einstellungen für Livemigration muss nun die Reihenfolge der Netzwerke definiert werden, über die eine Livemigration gemacht wird.

    image

    Hier werden die beiden Storage-Karten als primäre Karten definiert und in der Reihenfolge nach oben geschoben, falls dies nicht automatisch der Fall ist. Der Adapter Management bleibt ebenfalls aktiviert, wird aber ganz nach unten verschoben.

    image

    Als nächstes muss die Metrik der Netzwerke im Failover Cluster definiert werden. Die Metrik bestimmt, über welches Netzwerk die Daten während eines umgeleiteten Modus zwischen den einzelnen Knoten laufen. Diese Einstellung kann ausschließlich per PowerShell ausgelesen und gesetzt werden, eine Administration per GUI ist nicht möglich. Öffnen Sie eine administrative PowerShell oder die PowerShell ISE und nutzen Sie die folgenden Befehle zum Auslesen und manuellen Setzen der Werte.

    Get-ClusterNetwork | ft Name, Metric, AutoMetric

    image

    Je kleiner die Metrik, desto höher ist die Priorität. Standardmäßig wird in dem oberen Screenshot das Netzwerk Storage2 genutzt, da die Metrik 30240 die kleinste der drei ist. Grundsätzlich ist diese Reihenfolge (Erst Storage2, dann Storage1 und dann Management) in Ordnung, wir möchten aber gerne die Prioritäten manuell auf die folgenden Werte setzen:

    Storage1 100
    Storage2 101
    Management 110

    Die entsprechenden Befehle dazu sind

    (Get-ClusterNetwork "Storage1").Metric = 100
    (Get-ClusterNetwork "Storage2").Metric = 101
    (Get-ClusterNetwork "Management").Metric = 110

    Diese Einstellungen müssen nur auf einem der Knoten gemacht werden, da hier clusterweite Einstellungen verändert und konfiguriert werden.

    Die folgende Einstellung muss auf jedem Cluster-Knoten gesetzt werden, da es sich um eine lokale Einstellung handelt. Wechseln Sie in die Netzwerkverbindungen und wählen Sie in der Menüleiste (Falls nicht sichtbar “Alt” drücken) unter Erweitert die Option Erweiterte Einstellungen….

    image

    Schieben Sie dort den Adapter Management-Team ganz nach oben.

    image

    An dieser Stelle sind wir mit der Konfiguration des Netzwerks lokal und im Cluster fertig.

    Die Einrichtung des Datenträgerzeugen / Quorum

    Ganz wichtige Änderung unter Windows Server 2012 R2 in Bezug auf das Quorum: Erstellen Sie immer (egal welche Anzahl von Knoten und ob gerade oder ungerade) ein Quorum und weisen Sie dieses auch immer! zu. Das Failover Cluster verwendet dieses Quorum dynamisch, und zwar immer nur dann wenn es eins benötigt. Weitere Informationen und eine Bestätigung seitens Microsoft finden Sie im Technet: What’s New in Failover Clustering in Windows Server 2012 R2.

    Da wir bei der Nutzung eines Scale-Out File Server keine CSV-Datenträger in unserem Failover Cluster haben müssen wir eine Dateifreigabe verwenden. Es existieren zu diesem Zeitpunkt drei Freigaben auf dem Scale-Out File Server. Die Freigabe HVQuorum wird für den Hyper-V Failover Cluster genutzt.

    image

    Wechseln Sie im Hauptmenü des Failover Cluster unter Weitere Aktionen auf Clusterquorumeinstellungen konfigurieren….

    image

    Es öffnet sich ein Assistent, der Sie bei der Einrichtung unterstützt. Nach der Vorbemerkung werden Sie nach der Art der Einrichtung gefragt. Die erste Option Standardquorumkonfiguration verwenden ist in diesem Fall nicht möglich, dies führt dazu das kein Quorum verwendet wird. Wir nutzen daher die zweite Option Quorumzeugen auswählen.

    image

    Im nächsten Schritt werden Sie nach der Art des Quorum gefragt, hier wählen Sie die Option Dateifreigabezeuge konfigurieren.

    image

    Schreiben oder Kopieren Sie nun den Pfad der Freigabe in den Assistenten.

    image

    Bestätigen Sie die Einstellungen und schließen Sie den Assistenten ab.

    image

    Nachdem Sie die Einrichtung abgeschlossen haben können Sie sehen, dass an besagtem Ort nun ein Ordner erstellt wurde, in dem eine Textdatei liegt.

    image

    Kurze Zeit später erscheint eine zweite Datei

    image

    Die Konfiguration ist nun abgeschlossen.

    Die Einrichtung von Bandbreitenmanagement für SMB-Traffic

    Wenn, wie in unserem Fall, die Livemigration und der Storage-Traffic über eine Leitung laufen, könnte dies ungewünschte Folgen bei vielen gleichzeitigen Livemigrationen haben. Zusätzlich werden Daten zwischen den einzelnen Hosts ebenfalls über diese Netze gesendet (Metric-Konfiguration weiter oben, bei der Storage1 die geringste Metric besitzt. In solch einem Fall können wir ein Bandbreitenmanagement für SMB-Traffic einführen. Die Installation kann auf Wunsch per Server-Manager gemacht werden, die Konfiguration muss allerdings zwingend per PowerShell gemacht werden. Das Feature versteckt sich hinter dem Namen SMB Bandwidth Limit.

    image

    Die Installation per PowerShell erfolgt mit dem Befehl

    Add-WindowsFeature FS-SMBBW

    Nach der Installation erfolgt die Einrichtung per PowerShell. Um die Livemigration auf z.B. 8 Gbit/s zu begrenzen, kann der folgende Befehl angewendet werden

    Set-SmbBandwidthLimit -Category LiveMigration -BytesPerSecond 1000MB

    Als Kategorie steht neben LiveMigration noch VirtualMachine und Default zur Verfügung.

    image

    Die Nutzung von SMB Multi Channel

    Wir nutzen in unserem Fall mehrere Wege zu unserem Scale-Out File Server, daher haben wir beim Netzwerk-Design und bei der Einrichtung weiter oben zwei Storage-Karten konfiguriert. Grundsätzliches zum Thema SMB3 hat Carsten unter anderem in diesem Video gezeigt und erklärt: Hyper-V-Server.de: Videocast rund um Hyper-V auf SMB. Damit die Multi Channel-Funktionalität in einem Failover Cluster (egal ob Hyper-V oder Scale-Out File Server) greift, müssen sich die Storage-Karten in unterschiedlichen Subnetzen befinden. Multi Channel in einem Subnetz funktioniert nur bei Konfigurationen, in dem das Failover Cluster-Feature noch nicht installiert ist.

  • Die Installation und Einrichtung eines Scale-Out Fileserver unter Windows Server 2012 R2

    Dieser Gastbeitrag wurde uns von unserem Partner Rachfahl IT Solutions GmbH und Co. KG (Autor: Jan Kappen) zur Verfügung gestellt und erschien erstmals im Hyper-V Blog.

    Im zweiten Teil unserer Serie möchten wir den Aufbau und die Einrichtung eines Scale-Out File Server unter Windows Server 2012 R2 zeigen. Wir nutzen für diesen Aufbau zwei Server und ein JBOD, welches mit HDDs und SSDs bestückt ist. Die Server sind HP DL360 Gen8-Systeme und haben jeweils eine CPU, 20 GB RAM und zwei lokale Festplatten für das Betriebssystem. Die Anbindung an das JBOD erfolgt per SAS, hier kommt ein Adapter von LSI zum Einsatz. Jeder Server besitzt vier 1 Gbit-Karten und zwei 10 Gbit-Karten zur Anbindung der Systeme an das Netzwerk. Als Betriebssystem kommt ein Windows Server 2012 R2 Standard zum Einsatz.

    Falls Sie generell Interesse an diesem Thema haben, können wir Ihnen unseren Hyper-V PowerKurs empfehlen. Hier tauchen wir eine Woche in die Virtualisierung ein, der Aufbau und die Nutzung von SMB 3-Shares (sowohl Standalone als auch per Scale-Out File Server) spielen hier ebenfalls eine große Rolle. Mehr Informationen unter www.hyper-v-server.de/powerkurs .

    Weitere Informationen zur aufgeführten Hardware

    Zu der weiter oben schon kurz beschriebenen Hardware gibt es ein paar Dinge zu sagen. Zum einen möchte ich die Hardware näher und detaillierter auflisten, zum anderen ein paar Worte zu der Anzahl der jeweiligen Komponenten sagen. Das genutzte Equipment bietet zwar die Möglichkeit einen Scale-Out File Server aufzubauen, bietet aber an einigen Stellen keine Redundanz und daher nur eine bedingte Hochverfügbarkeit. Da uns momentan “nur” diese Hardware zu Demozwecken zur Verfügung steht können wir die Best-Practice-Vorgehensweise nur bedingt in Screenshots zeigen, die Beschreibung zeigt aber die optimale Einrichtung. Lesen Sie diesen Bereich unbedingt komplett, er enthält einige Informationen zu strategischen Entscheidungen und begründet einige der Best-Practice-Vorschläge.

    Die genutzte Hardware

    Als Hardware kommen die folgenden Komponenten zum Einsatz:

    HP DL360e Gen8

    DataOn DNS-1640 JBOD mit Platz für 24 2.5” HDDs

    Seagate 1200 SSD mit einer Kapazität von 200 GB

    Seagate Enterprise Capacity 2.5 HDD mit einer Kapazität von 1 TB

    Der optimale Aufbau

    Wie bereits erwähnt ist die Anzahl der einzelnen Komponenten für eine Hochverfügbarkeit sehr wichtig. Achten Sie unbedingt auf eine Zertifizierung der Hardware, eine Liste der von Microsoft zertifizierten Komponenten ist auf www.windowsservercatalog.com aufgeführt. Der hier beschriebene Scale-Out File Server ist die Basis für einen großen Teil Ihrer IT-Infrastruktur. Wackelt dieser Teil, wackelt auch alles oben drüber. Diese Zertifizierung ist kein “nice to have”, es ist absolute Pflicht!

    Die Anzahl der JBODs

    Die Anzahl der JBODs, die Sie einsetzen, steht im direkten Zusammenhang mit der Verfügbarkeit und dem Verhalten beim Ausfall solch eines Geräts. Um den kompletten Ausfall eines JBODs abfangen zu können benötigen Sie insgesamt drei Stück. Dies liegt daran, dass immer mehr als 50% aller Festplatten verfügbar sein müssen. Bei zwei JBODs mit gleicher Bestückung sind bei einem Ausfall eines Geräts genau die Hälfte aller Festplatten nicht mehr verfügbar, der Scale-Out File Server ist in diesem Moment nicht mehr funktionstüchtig. Sie könnten in eins der Gehäuse mehr Festplatten/SSDs stecken wie in das andere, aber wir kennen das Problem wahrscheinlich alle: Fällt in diesem Szenario etwas aus, ist es fast immer das Gehäuse mit der größeren Anzahl an Festplatten. Ihnen hilft zu einer echten Verfügbarkeit nur ein Betrieb eines dritten (oder noch mehr, dies geht natürlich auch) JBODs. Bei drei Gehäusen sollten Sie jeweils ein Drittel aller Festplatten und SSDs in einem der Gehäuse betreiben.

    Die Art des JBODs

    Achten Sie bei der Auswahl Ihrer JBODs auf eine Freigabe von Microsoft. Technisch werden JBODs mit den SCSI Enclosure Services (SES) benötigt, dies bedeutet das JBOD kann den Standort der Datenträger an den bzw. die Server melden. Nur diese Funktion ermöglicht eine Speicherung von Daten auf unterschiedlichen Datenträgern in unterschiedlichen JBODs. Weiß der Server nicht, wo welche Festplatte steckt, kann er hier keinen Schutz einbringen.

    Enclosure Awareness

    Damit Ihre Daten bei dem Betrieb von drei oder mehr JBODs vor einem Ausfall geschützt sind, müssen Sie eine Enclosure Awareness aktivieren. Dies bedeutet bei der Ablage von Daten auf Ihren Festplatten wird darauf geachtet, das die gespiegelten Daten nicht im gleichen JBOD gespeichert werden. Diese Funktion kann entweder für einen kompletten Storage Pool konfiguriert werden oder Sie setzen diese Eigenschaft bei der Erstellung Ihrer virtuellen Datenträger. Da diese Funktion nur per PowerShell aktiviert werden kann empfiehlt sich eine Erstellung von Datenträgern per PowerShell. Im späteren Verlauf des Artikels wird auf diesen Punkt erneut eingegangen. (TechNet Wiki: Enclosure Awareness Support – Tolerating an Entire Enclosure Failing)

    Die Verkabelung der JBODs

    Wir empfehlen eine direkte Verkabelung der JBODs pro Server, kein Schleifen der Verbindung (Chaining) über das vorherige JBOD. Technisch ist dies natürlich möglich, Sie bauen sich aber einen möglichen Engpass und eine potentielle Fehlerquelle ein. Binden Sie jedes JBOD direkt per SAS an. Wir selbst empfehlen und konfigurieren bei unseren Kunden die Systeme so, dass jedes JBOD doppelt an jeden Server angebunden ist.

    Im folgenden Bild ist ein Scale-Out File Server Knoten mit insgesamt drei Dual-Port SAS HBAs an drei JBODs angeschlossen. Mit diesem Aufbau könnte ein kompletter Controller, ein Kabel oder ein JBOD ausfallen, ohne dass die Kommunikation abbrechen würde. Der zweite Knoten wird auf die gleiche Weise verbunden. Bei Vier-Port SAS HBAs reduziert sich die Anzahl der Karten auf zwei, um alle sechs Verbindungen zu realisieren.

    23-04-2014 14-18-40

    Die Anzahl und Größe der Datenträger

    Achten Sie bei der Anzahl der Datenträger in Ihrem Failover Cluster darauf, dass Sie mindestens genau so viele Datenträger wie Knoten besitzen. Da seit Windows Server 2012 R2 eine Verbindung pro Share und nicht mehr pro Dateiserver aufgebaut wird können Sie so erreichen, dass alle Cluster-Knoten aktiv genutzt werden und nicht die gesamte Last über einen Knoten verarbeitet wird, während die anderen auf einen Ausfall warten, um übernehmen zu können. Positiv hinzu kommt, dass unter 2012 R2 eine automatische Verteilung der CSV-Datenträger im Failover Cluster passiert. Sie müssen sich nicht aktiv um die Verteilung kümmern, die Datenträger werden automatisch an unterschiedliche Knoten zugewiesen.

    Achten Sie bei der Größe der Datenträger darauf, dass Sie ausreichend freien Speicherplatz im Storage Pool lassen. Nur so erreichen Sie eine schnelle Wiederherstellung der Daten beim Ausfall eines Datenträgers. Mehr Informationen dazu und wie Sie den freien Speicherplatz berechnen können finden Sie ein paar Zeilen weiter unten.

    Hot-Spare-Datenträger vs. Automatische Wiederherstellung

    Oft wird beim Design von einem Scale-Out File Server mit Hot-Spare Festplatten kalkuliert. Diese sind beim Einsatz von Storage Spaces zwar möglich, seitens Microsoft aber nicht vorgesehen und nicht empfohlen (Microsoft TechNet: What’s New in Storage Spaces in Windows Server 2012 R2). Die empfohlene Variante ist die Nicht-Nutzung eines gewissen Prozenzsatzes des verfügbaren Speicherplatzes, was technisch auf ein ähnliches Resultat herausläuft, allerdings auf ein deutlich schnelleres. Ein kleines Rechenbeispiel:

    Sie nutzen in Ihrem Scale-Out File Server mehrere SSDs und HDDs, die HDDs haben eine Größe von 4 TB. Sie haben eine weitere 4 TB Festplatte als Hot-Spare Datenträger konfiguriert. Ihnen fällt nun eine 4 TB Festplatte aus und die Daten auf der ausgefallenen Festplatte müssen nun auf den Hot-Spare Datenträger übertragen werden, damit der Spiegel wieder intakt ist. Bei einer Transferrate von 100 MegaByte pro Sekunde haben Sie eine Wiederherstellungszeit von 40000 Sekunden bzw. 11,1 Stunden. Diese Zeit wird natürlich nur benötigt, wenn die kompletten 4 TB beschrieben sind, bei einer geringeren Datenmenge nimmt die Dauer ab.

    Microsoft hat bei Nutzung der Storage Spaces ein etwas anderes Verfahren genutzt, um die Daten beim Ausfall eines Datenträgers wiederherzustellen. Falls ausreichend Platz vorhanden ist werden die Daten, die auf der defekten Festplatte lagen, auf alle anderen verfügbaren Datenträger kopiert. Dies bedeutet es müssen nicht 4 TB auf eine Festplatte allein zurückgeschrieben werden, sondern eine gewisse Anzahl an Festplatten bekommt jeweils z.B. 100 GB. Da alle Festplatten gemeinsam “ihre” 100 GB speichern müssen ist der Gesamtzeitraum der Wiederherstellung deutlich geringer als bei der Wiederherstellung auf einer Festplatte.

    Bei der Berechnung des freien Speicherplatzes gehen wir davon aus, dass alle Festplatten und alle SSDs die gleiche Kapazität haben. Die Berechnung muss separat für HDDs und SSDs gemacht werden, jeder Speicher muss einen eigenen freien Speicherplatz haben. Den freien Speicherplatz errechnen Sie wie folgt:

    ((Gesamter Speicherplatz/Anzahl der Datenträger) + 8GB) * Anzahl der Enclosure

    Diesen freien Speicherplatz ziehen Sie von Ihrem Gesamt-Brutto-Speicherplatz ab. Im späteren Verlauf der Einrichtung sehen Sie, wie diese Formel bei der Berechnung des freien Speicherplatzes genutzt wird, um sowohl freien HDD- als auch freien SSD-Speicherplatz zu berechnen.

    Die Art der Spiegelung

    Sie können grundsätzlich zwischen drei Arten Datenträgern wählen: Simple, Mirror oder Parity. Simple ist eine einfache Speicherung der Daten ohne Schutz vor einem Ausfall, bei Mirror werden die Daten gespiegelt und bei Parity nutzen Sie eine Parität ähnlich einem RAID5, um die Daten bei einem Ausfall von einem Datenträger trotzdem noch lesen zu können. Bei der Nutzung von Storage Spaces inkl. Tiering (wird etwas weiter unten erklärt) können Sie nur Simple oder Mirror wählen, Parity ist hier nicht möglich. Da Simple in den wenigsten Fällen zum Einsatz kommen wird konzentrieren wir uns in unserem Fall ausschließlich auf Mirror. Seit dem Windows Server 2012 R2 können Sie neben einem Zwei-Wege-Spiegel (Ein Block wird auf einem Datenträger abgespeichert und gleichzeitig auf einen weiteren gespiegelt) auch einen Drei-Wege-Spiegel aufbauen. Hierbei wird ein Block auf einem Datenträger gespeichert und zusätzlich auf zwei weitere Datenträger gespiegelt.

    Nutzen Sie nach Möglichkeit immer einen Drei-Wege-Spiegel. Dies mag auf den ersten Blick als Verschwendung gelten, es gibt aber einen äußerst guten Grund für diese Art der Spiegelung: In einem Storage Space werden die Blöcke nicht wie bei einem RAID1 immer nur auf zwei Datenträgern abgespeichert, sondern die Daten liegen auf allen Festplatten verteilt. Dies führt dazu, dass im schlimmsten Fall in einem Zwei-Wege-Spiegel der Ausfall von zwei Datenträgern ausreicht, um einen Datenverlust zu erzeugen. Wird eine Enclosure Awareness genutzt können theoretisch alle Datenträger in einem JBOD ausfallen, danach aber kein weiterer mehr in einem der anderen JBODs. Wir empfehlen ausdrücklich die Einrichtung eines Drei-Wege-Spiegel, da hier zumindest zwei Festplatten ausfallen können, ohne das es zu Datenverlust kommt! (TechNet Wiki: What are the resiliency levels provided by Enclosure Awareness?)

    Die Blocksize / Interleave der virtuellen Datenträger

    Achten Sie bei der Erstellung und Formatierung der virtuellen Datenträger (bei der Nutzung als Ablage für Hyper-V VMs) darauf, dass Sie eine Blockgröße (im englischen Interleave genannt) von 64k verwenden. Dieser Wert ist optimal bei Nutzung als Ziel für Hyper-V VMs. Wie genau Sie diesen Wert konfigurieren zeigen wir Ihnen im späteren Verlauf bei der Konfiguration der virtuellen Datenträger.

    Die Anzahl der Columns / Spalten

    Die Anzahl der Colums bestimmt, über wie viele Datenträger die Daten gleichzeitig pro Verbindung weggeschrieben werden. Egal ob Sie nur HDDs, nur SSDs oder eine Mischung aus beidem haben, es gibt pro virtuellem Datenträger nur einen Column-Wert. Ein paar Beispiele:

    • Sie haben zwei Festplatten in einem Zwei-Wege-Spiegel und ein Interleave von 64KB. Sie haben einen Column-Wert von 1, d.h. Sie können pro Vorgang 64KB abspeichern (diese werden dann auf beide Festplatten geschrieben).
    • Sie haben vier Festplatten in einem Zwei-Wege-Spiegel und ein Interleave von 64KB. Sie haben somit einen Column-Wert von 2, d.h. Sie können pro Vorgang 2x 64KB abspeichern (zwei Festplatten nehmen jeweils 64KB an, zwei weitere speichern eine Kopie dieser Daten).
    • Sie haben 22 Festplatten und zwei SSDs in einem Zwei-Wege-Spiegel mit einem Interleave von 64KB. Sie haben in dieser Konfiguration einen Column-Wert von eins, da der kleinste Wert pro Datenträger-Typ diesen Wert bestimmt. Pro Vorgang können maximal 64KB abgespeichert werden.
    • Sie haben 18 Festplatten und sechs SSDs in einem Zwei-Wege-Spiegel mit einem Interleave von 64KB. Sie haben somit eine Column-Anzahl von 3 und können pro Vorgang 3x 64KB abspeichern.

    Diese Beispiele sollen Ihnen aufzeigen, dass nicht die Größe der SSDs bzw. HDDs ausschlaggebend sind, sondern die Anzahl. Teilweise sehen wir Konfigurationsvorschläge mit zwei 800 GB SSDs und vielen HDDs. Hier wären acht 200 GB SSDs deutlich besser. Die Column-Anzahl von eins bedeutet nicht, dass immer nur zwei Datenträger genutzt werden. Pro Vorgang werden zwei Datenträger genutzt, d.h. wenn Sie acht VMs betreiben kann jede auf jeweils zwei Datenträger schreiben (wenn der Spiegel mit kalkuliert wird, es können trotzdem nur 64KB geschrieben werden).

    Bei einem Drei-Wege-Spiegel ändert sich die Berechnung ein wenig, dies kommt daher das pro Interleave drei HDDs bzw. SSDs benötigt werden. Zwei weitere Beispiele:

    • Die haben neun HDDs und drei SSDs in einem Drei-Wege-Spiegel mit einem Interleave von 64KB. Sie haben eine Column-Anzahl von 1, da die drei SSDs diese Zahl erwirken. Gleichzeitig können 64KB verarbeitet werden pro Vorgang.
    • Sie haben 24 HDDs und 12 SSDs in einem Drei-Wege-Spiegel mit einem Interleave von 64KB. Mit diesem Aufbau erreichen Sie einen Column-Wert von 4, bedingt durch die geringere Anzahl an SSDs.

    Bei einer automatischen Erstellung der Datenträger ist die maximale Anzahl an Coloums der Wert 8, mehr werden nicht automatisch genommen. Bei der Erstellung der Datenträger per PowerShell können Sie auch einen höheren Wert auswählen. Sie müssen nicht grundsätzlich immer 8 oder mehr erreichen, Column-Werte ab 3 sind OK, falls möglich sollten Sie 4 erreichen. Alles über vier ist super, rechtfertigt aber meist nicht der erhöhten Preis für weitere SSDs (da diese in den meisten Fällen die geringe Anzahl in der Gesamtmenge ausmachen, aktuell noch bedingt durch den Preis).

    Auf den Seiten von Microsoft ist eine Grafik abgebildet, die den Performance-Unterschied zwischen 2 und 4 Columns zeigt:

    image

    Quelle: TechNet Wiki: Storage Spaces – Designing for Performance

    (TechNet Wiki: What are columns and how does Storage Spaces decide how many to use?)

    Die Nutzung von Tiering

    In der vorherigen Kapiteln wurde häufig von der Nutzung von HDDs und SSDs gleichzeitig gesprochen, hier folgt nun eine Erklärung dieser als Tiering bezeichneten Möglichkeit, die seit Windows Server 2012 R2 existiert.

    Ein Pool kann unter 2012 R2 aus zwei unterschiedlichen Arten von Datenträgern bestehen, HDDs und SSDs. Hierbei ist es egal wie schnell die Festplatten sind, alle SAS-Festplatten werden als HDD behandelt. Grundsätzlich macht nur der Betrieb von Festplatten der gleichen Geschwindigkeit Sinn (z.B. immer NearLine-SAS HDDs mit 7.2k rpm). Neben HDDs können noch SSDs eingebunden werden, hier funktionieren ebenfalls nur SAS-SSDs, keine Consumer-Produkte.

    Die Daten in den virtuellen Datenträgern werden vom Scale-Out File Server analysiert und je nach Nutzung entweder auf die SSDs verlagert (wenn festgestellt wird, dass die Daten häufig in Nutzung sind) oder auf den HDDs gespeichert (wenn festgestellt wird, dass die Daten nicht häufig benutzt werden). Das Betriebssystem arbeitet hier grundsätzlich mit 1 MB großen Blöcken, d.h. es werden nicht immer komplette Dateien verschoben, sondern nur 1 MB große Stücke der Datei.

    Standardmäßig werden die Daten nachts um ein Uhr umsortiert, Grund hierfür ist ein Task auf den Datei Server-Knoten:

    image

    Weitere Informationen über den technischen Hintergrund finden Sie in den folgenden Beiträgen:

    TechNet Blog: KeithMayer.com – Why R2? Step-by-Step: Automated Tiered Storage with Windows Server 2012 R2

    TechNet Blog: Ask Premier Field Engineering (PFE) – Storage Spaces: How to configure Storage Tiers with Windows Server 2012 R2

    Die Zusammenlegung von HDDs sowie SSDs führt zu der folgenden Situation: Mehrere große Festplatten, die nicht unbedingt schnell sind (z.B. 7.2k NL-SAS Festplatten mit 4 oder 6 TB) sorgen dafür, dass ausreichend Speicherplatz zur Verfügung steht. Mehrere SAS-SSDs sorgen dafür, dass der gesamte Pool ausreichend Performance bekommt.

    Weiterer Vorteil bei der Nutzung von SSDs: Sie können einen Teil der SSDs als Write-Back Cache nutzen, ähnlich dem Cache auf einem RAID-Controller. Standardmäßig wird bei einem Storage Pool mit SSDs 1 GB an Speicherplatz für diese Caching-Technik genutzt. Aidan Finn hat zu diesem Thema einen Benchmark gemacht und auf seinem Blog veröffentlicht:

    Aidan Finn – The Effects Of WS2012 R2 Storage Spaces Write-Back Cache

    Bessere Performance-Werte um den Faktor 11 in einer (laut seiner Aussage) recht schnell aufgebauten Demo-Umgebung zeigen den unglaublichen Performanceschub bei Nutzung dieser Technik.

    Lassen Sie den Standard-Wert von 1 GB auf diesem Wert stehen, dies ist laut Aussage der Produktgruppe ein optimaler Wert.

    Die Vorbereitung der Server

    Das Netzwerk

    Nach der Grundinstallation und einem Update auf den aktuellsten Patchlevel beginnt die Einrichtung mit der Konfiguration der Netzwerkkarten. Es werden insgesamt drei Netze genutzt:

    • Management – In diesem Netz befindet sich die Active Directory
    • Storage1 – Eines der beiden SMB-Netze
    • Storage2 – Das zweite SMB-Netz

    image

    In optimalen Fall besitzen die Server mindestens zwei Gbit-Adapter und vier 10 Gbit-Adapter. Dies ermöglicht die Nutzung von zwei Teams über beide 10 Gbit-Adapter. Dies ist notwendig, da SMB MultiChannel in einem Failover Cluster nur dann funktioniert, wenn sich alle Adapter in einem unterschiedlichen Subnetz befinden. Wenn wir davon ausgehen, dass die Hyper-V Hosts nur zwei Adapter im Storage-Netzwerk besitzen, können die SOFS-Knoten ebenfalls nur IP-Netze nutzen. Sollten die Hyper-V Hosts ebenfalls vier Adapter für SMB besitzen muss kein Team erstellt werden.

    Die einzelnen Adapter werden in der Systemsteuerung umbenannt, um hier eine bessere Übersicht zu haben. Das Resultat sieht wie folgt aus:

    image

    Falls Sie mehrere Server konfigurieren möchten lässt sich diese Benennung per PowerShell ein wenig automatisieren:

    Get-NetAdapter -InterfaceDescription "Intel(R) I350 Gigabit Network Connection" | Rename-NetAdapter -NewName 1GBit#1 –PassThru

    Das Management-Netzwerk wird über Gbit-Karten abgebildet. Zur Redundanz werden hier zwei der vier onboard-Adapter zu einem Team zusammengeschlossen und konfiguriert. Dies kann entweder per GUI oder per PowerShell erfolgen:

    New-NetLBFOTeam -Name "Management-Team" -TeamNICName "Management-Team" -TeamMembers 1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

    image

    Danach werden die Karten mit IP-Adressen versehen. Das Resultat sieht wie folgt aus:

    Management

    image

    image

    image

    Storage1

    image

    image

    image

    Storage2

    Diese Karte hat bis auf die IP-Adresse die exakt gleichen Einstellungen wie Storage1 bzw. 10GBit#1. Diese Karte enthält die folgende IP-Adresse

    image

    Die Storage-Karten werden übrigens nicht geteamt, SMB3 ermöglicht eine Nutzung beider Adapter gleichzeitig (SMB Multichannel).

    Die Konfiguration per PowerShell

    Die oben gezeigte Konfiguration lässt sich komplett per PowerShell realisieren.

    # Abfrage der IP-Adresse
    $IP = Read-Host "Geben Sie das letzte Oktett der IP-Adresse eine"

    # Team erstellen
    New-NetLBFOTeam -Name "Management-Team" -TeamNICName "Management-Team" -TeamMembers `
        1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

    # IP-Konfiguration
    Set-NetIPInterface -InterfaceAlias "Management-Team" -dhcp Disabled -verbose
    New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "Management-Team" `
        -IPAddress 192.168.209.$IP -verbose
    Set-DnsClientServerAddress -InterfaceAlias "Management-Team" -ServerAddresses 192.168.209.1

    Set-NetIPInterface -InterfaceAlias "10GBit#1" -dhcp Disabled -verbose
    New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#1" `
        -IPAddress 192.168.208.$IP -verbose
    Set-DnsClientServerAddress -InterfaceAlias "10GBit#1" -ServerAddresses 192.168.209.1
    Set-NetAdapterBinding -Name "10GBit#1" -ComponentID ms_tcpip6 -Enabled $False

    Set-NetIPInterface -InterfaceAlias "10GBit#2" -dhcp Disabled -verbose
    New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#2" `
        -IPAddress 192.168.207.$IP -verbose
    Set-DnsClientServerAddress -InterfaceAlias "10GBit#2" -ServerAddresses 192.168.209.1
    Set-NetAdapterBinding -Name "10GBit#2" -ComponentID ms_tcpip6 -Enabled $False

    Nehmen Sie die Systeme nun in die Active Directory auf und vergeben Sie einen aussagekräftigen Namen. In unserem Fall heißen die Systeme FSNode1 und FSNode2.

    Als letzten Punkt der Netzwerk-Konfiguration setzen wir auf den Systemen in den erweiterten Einstellungen innerhalb der Netzwerkverbindungen das Management-Team an die vorderste Stelle.

    image

    image

    Die Installation der benötigten Rollen und Features

    Auf den beiden Systemen werden die folgenden Rollen und Features benötigt

    image

    image

    Der Dateiserver wird benötigt, da dieser später als Rolle im Failover Cluster installiert und eingerichtet wird. Um eine Sicherung der VM-Daten machen zu können wird ebenfalls der VSS Agent Service benötigt. Einen Schritt weiter bei den Features wird das Failover Cluster-Feature inkl. den Verwaltungstools sowie MPIO (Multipfad E/A im deutschen) benötigt. Die Installation per PowerShell sieht wie folgt aus:

    Install-WindowsFeature -Name FS-Fileserver, FS-VSS-Agent, Failover-Clustering, `
        Multipath-IO -IncludeManagementTools

    image

    Wenn der Parameter –Computername noch mit angegeben wird kann die Installation auch remote durchgeführt werden.

    image

    Falls Sie noch weitere Rollen oder Features benötigen, hier ein Befehl zur Auflistung aller vorhandenen Rollen und Features:

    Get-WindowsFeature | Select-Object -ExpandProperty Name | Write-Host

    Die Einrichtung von MPIO

    Dieser Schritt muss nur gemacht werden, wenn HDDs bzw. SSDs in einem oder mehreren JBODs verwendet werden, die mit mehr als einem SAS-Kabel angeschlossen sind. In unserem Fall hat jeder Server zwei Verbindungen pro JBOD, daher muss auf unseren Servern MPIO aktiviert werden. Die Aktivierung kann entweder per GUI oder per PowerShell gemacht werden und bedingt einen Neustart, der nach der Bestätigung des Neustarts auch direkt gemacht wird.

    image

    Per PowerShell funktioniert es mit dem folgenden Befehl

    Enable-MSDSMAutomaticClaim -BusType SAS

    Ein Neustart wird an dieser Stelle nicht eingefordert, ist aber auf jeden Fall sinnvoll

    Restart-Computer

    Die Überprüfung der Disks

    Wenn Sie mehrere HDDs bzw. SSDs nutzen, kann es zu unterschiedlichen Performance-Werten bei eigentlich gleichen Datenträgern kommen. Bei einem Scale-Out File Server kann es zu sehr starken Einschränkungen bei der Gesamtperformance kommen, wenn ein oder mehrere Datenträger langsamer arbeiten wie andere. Aus diesem Grund sollten Sie vor der Nutzung Ihrer HDDs und SSDs einen Test machen, der Ihnen die Performance aller Datenträger ermittelt und aufführt. Sie benötigen ein PowerShell-Skript und die aktuellste Version des SQLIO-Tools:

    Technet Script Center: Storage Spaces Physical Disk Validation Script

    Microsoft Download Center: SQLIO Disk Subsystem Benchmark Tool

    Technet Script Center: Completely Clearing an Existing Storage Spaces Configuration

    Falls die HDDs oder SSDs bereits für etwas genutzt wurden benötigen Sie das unterste Skript zur kompletten Entfernung aller Informationen auf den Datenträgern. Achten Sie darauf, dass mit diesem Skript die Datenträger gelöscht werden. Falls Sie Daten auf den Disks noch benötigen, fertigen Sie ein Backup an!

    Führen Sie das Skript aus und warten Sie darauf, dass alle Datenträger gelöscht wurden

    image

    Installieren Sie SQLIO auf dem Server und kopieren Sie die sqlio.exe-Datei an den Standort, an dem das Validation-Skript liegt. Alternativ kopieren Sie das Skript in das Installationsverzeichnis.

    image

    Führen Sie den folgenden Befehl aus und überprüfen Sie, ob die korrekten Datenträger aufgeführt werden

    Get-PhysicalDisk |? {($_.CanPool) -and (!$_.IsPartial)}

    image

    Speichern Sie nun diese Datenträger in der Variablen $physicaldisks_to_pool mit dem Befehl

    $physicaldisks_to_pool = Get-PhysicalDisk |? {($_.CanPool) -and (!$_.IsPartial)}

    Starten Sie nun den Test mit dem folgenden Befehl

    .\Validate-StoragePool.ps1 -PhysicalDisks $physicaldisks_to_pool

    image

    Der Test beginnt und listet Ihnen auf, wie viele HDDs und SSDs vorhanden sind. In meinem Fall sind es fünf SSDs und 19 HDDs. Der Test läuft nun einige Stunden, daher empfiehlt es sich diesen zu einem Zeitpunkt zu starten, an dem noch andere Aufgaben erledigt werden müssen oder der Feierabend winkt.

    Als Ausgabe nach dem erfolgreichen Test erscheint der folgende Bericht

    image

    Schauen Sie sich die Warnungen und ggf. Fehler an, um potentiell schlechte Datenträger auszutauschen. In meinem Fall werden vier Datenträger bei der Leselatenz sowie drei Datenträger bei der Schreiblatenz angemerkt. Die ersten Werte liegen mit 830, 768, 776 und 801 ms nur wenig über dem Durchschnittswert von 620, bei den Schreiblatenzen könnte PhysikalDisk19 mit einer maximalen Latenz von knapp unter dem doppelten des Durchschnitts (1008 ms bei durchschnittlich 634 ms) evtl. getauscht werden. Führen Sie den Test evtl. ein zweites Mal durch und vergleichen Sie die Ergebnisse, um zufällige hohe Latenzen auszumerzen.

    Die Erstellung des Failover Cluster

    Wir sind nun an der Stelle angelangt, an dem das Failover Cluster erstellt und konfiguriert werden kann. Öffnen Sie dazu den Failover Cluster Manager und wählen Sie den Punkt Konfiguration überprüfen bzw. Validate Configuration….

    image

    Wählen Sie die beiden Server aus, die Mitglied des Failover Cluster werden sollen und führen Sie alle Tests aus.

    image

    Der Test versucht nun, alle Festplatten an allen Knoten zu erreichen. Sollte es hier zu Problemen kommen, wird Ihnen dies an dieser Stelle direkt angemerkt, nicht erst zu einem späteren Zeitpunkt während der Erstellung bzw. Konfiguration.

    image

    Sie können diesen Test natürlich auch per PowerShell starten, der Befehl hierzu lautet

    Test-Cluster -Node FSNode1,FSNode2

    Sie können jederzeit sehen, an welchem Punkt der Test sich gerade befindet

    image

    Nach Beendigung sehen Sie ein Ergebnis sowie den Pfad zu dem kompletten Bericht des Tests.

    image

    Schauen Sie sich diesen Test unbedingt an und korrigieren Sie potentielle Fehler. Sie können auch mit dem Parameter –ReportName einen Namen und einen Speicherort für den Bericht angeben, das macht die Suche einfacher.

    image

    Nachdem die Konfiguration nun überprüft wurde können Sie den Failover Cluster erstellen. Beenden Sie dazu den Überprüfungs-Assistenten und wechseln Sie in den Cluster erstellen-Assistenten. Fügen Sie die beiden Knoten hinzu

    image

    und wählen Sie einen Namen und eine IP-Adresse für das Failover Cluster. Da ich in meinem Fall kein Gateway gesetzt habe werde ich für alle Netze nach einer Adresse gefragt. An dieser Stelle deaktiviere ich alle Netze bis auf das Management-Netzwerk und setze nur in diesem Netzwerk eine IP-Adresse.

    image

    Achten Sie im nächsten Schritt unbedingt darauf, dass Sie den gesamten verfügbaren Speicher nicht automatisch hinzufügen lassen!

    image

    Nach einem Klick auf Weiter wird das Failover Cluster erstellt. Die Alternative per PowerShell wäre

    New-Cluster –Name FSCluster1 –Node FSNode1,FSNode2 –StaticAddress `
        192.168.209.110 -IgnoreNetwork 192.168.207.0/24,192.168.208.0/24 –NoStorage

    image

    Nach der Erstellung können Sie das Failover Cluster über den Failover Cluster Manager administrieren und benutzen.

    image

    Die Konfiguration des Failover Cluster zur Nutzung als Scale-Out File Server

    Nach der Erstellung müssen noch ein paar Einstellungen angepasst werden, bevor die Erstellung des hochverfügbaren Dateiservers beginnen kann.

    Das Netzwerk

    Die Netzwerke sind aktuell in einer recht unsagenden Reihenfolge benannt, dies möchten wir gerne ändern und sprechende Namen verwenden. Wechseln Sie im linken Menü auf Netzwerk und setzen Sie die Namen der Netzwerke so, wie sie auch auf den lokalen Hosts konfiguriert sind.

    image

    Per Hand geht dies über die Eigenschaften der einzelnen Netzwerke, per PowerShell mit den folgenden drei Zeilen

    (Get-ClusterNetwork | where-object {$_.Address -eq "192.168.209.0"}).Name = "Management"
    (Get-ClusterNetwork | where-object {$_.Address -eq "192.168.208.0"}).Name = "Storage1"
    (Get-ClusterNetwork | where-object {$_.Address -eq "192.168.207.0"}).Name = "Storage2"

    Nach der Umbenennung sehen die Netzwerke wie folgt aus

    image

    Neben dem Netzwerk sollte noch die Metrik der einzelnen Karten überprüft werden. Dies geht ausschließlich per PowerShell

    Get-ClusterNetwork | ft Name, Metric, AutoMetric -AutoSize

    image

    In meinem Fall hat Storage2 die kleinste Metric, dies bedeutet diese Karte hat im Failover Cluster die höchste Priorität (Je kleiner die Metric, desto höher die Priorität; allerdings immer abhängig von den anderen Karten). Die hier automatisch gesetzten Werte sind in Ordnung, falls diese geändert werden sollen geht dies mit den folgenden Befehlen

    (Get-ClusterNetwork "Management").Metric = 200
    (Get-ClusterNetwork "Storage1").Metric = 100
    (Get-ClusterNetwork "Storage2").Metric = 101

    In diesem Beispiel wird Storage1 die Karten mit der höchsten Priorität, gefolgt von Storage2.

    Ein Livemigration-Netzwerk müssen wir in dieser Art von Failover Cluster nicht aktiv konfigurieren, da keine VMs betrieben werden und somit auch kein RAM übertragen werden muss.

    Zur Nutzung der beiden Storage-Karten für den Dateiserver später muss die Nutzung im Cluster umgestellt werden. Aktuell stehen die Netzwerke auf “Cluster only”, dies muss korrigiert werden auf “Cluster and Client”, da sonst kein Zugriff auf die Freigaben über diese Karten möglich ist. Setzen Sie die Option über die Gui

    image

    oder per PowerShell:

    (Get-ClusterNetwork "Storage1").Role = 3

    (Get-ClusterNetwork "Storage2").Role = 3

    Die Rolle 1 bedeutet “Nur Cluster”, 3 bedeutet “Cluster und Client”.

    Der Datenträgerpool

    Um mit den Datenträgern in unserem JBOD arbeiten zu können wird ein Pool benötigt. Dieser Pool enthält alle HDDs und SSDs, die Erstellung kann per GUI oder per PowerShell vorgenommen werden.

    Im Failover Cluster Manager wechseln Sie unter Speicher auf Pools und erstellen mit dem Menüpunkt Neuer Storage Pool eine neue Ansammlung von Datenträgern.

    image

    Im nächsten Schritt können Sie die Datenträger wählen, die Mitglied des Pools werden sollen. Sie sehen hier bereits die Größe, den Steckplatz, den Typ und weitere Informationen.

    image

    Unter Zuordnung bzw. Allocation belassen Sie alle Datenträger auf Automatisch, außer Sie wollen an dieser Stelle eine oder mehrere HotSpare-Datenträger definieren. Nach einem Klick auf Weiter sehen Sie eine Zusammenfassung, danach kann die Erstellung beginnen.

    image

    Per PowerShell können Sie den Pool wie folgt einrichten:

    Suchen Sie im ersten Schritt nach allen verfügbaren Datenträgern

    Get-PhysicalDisk | ft FriendlyName, CanPool, PhysicalLocation –AutoSize

    Dieser Befehl listet Ihnen alle physischen Datenträger auf und zeigt Ihnen sowohl die Fähigkeit, einem Pool beizutreten als auch den Ort, an dem der Datenträger verbunden ist. In meinem Fall sehen wir auf dem System insgesamt 26 Datenträger, wovon 24 in meinem JBOD stecken

    image

    Datenträger 0 und 25 haben keine Informationen über den Aufenthaltsort, bei den anderen 24 Datenträgern erkennt man das JBOD. Mit der folgenden Zeile können Sie alle Festplatten zum Pool hinzufügen, achten Sie aber darauf die Seriennummer an Ihre eigene PhysicalLocation anzupassen.

    New-StoragePool -FriendlyName Pool01 -StorageSubSystemFriendlyName *Spaces* `
        -PhysicalDisks (Get-PhysicalDisk | where PhysicalLocation -like *500093D001CEC000*)

    Falls mehrere JBODs eingesetzt werden, sollte an dieser Stelle die Enclosure Awareness eingeschaltet werden. Dies geht ausschließlich per PowerShell und wird mit dem folgenden Befehl erreicht:

    Get-StoragePool -FriendlyName Pool01 | Set-StoragePool -EnclosureAwareDefault $true

    Überprüfen können Sie den Wert mit dem folgenden Befehl:

    Get-StoragePool -FriendlyName Pool01 | ft FriendlyName, EnclosureAwareDefault -AutoSize

    Nun haben wir einen Pool, der im nächsten Schritt als Grundlage für unsere virtuellen Datenträger genutzt werden kann.

    Die Erstellung der virtuellen Datenträger

    Bei der Erstellung der Datenträger sollten Sie (wie bereits in den Vorbemerkungen weiter oben angesprochen) darauf achten, dass Sie ausreichend Platz lassen, damit der Rebuild bei einem Ausfall schnell funktionieren kann. Ich nutze in diesem Aufbau insgesamt 24 Datenträger, wovon fünf SSDs mit jeweils 200 GB und 19 HDDs mit jeweils 1 TB Speicherplatz sind.

    image

    Rein theoretisch habe ich nun die folgenden Werte in meinem Scale-Out File Server:

    • Anzahl JBODs: 1
    • Coloums: 5, da insgesamt fünf SSDs vorhanden sind
    • Freier HDD-Speicherplatz: ((19TB/19+ 8GB) * 1 = 1,008 TB
    • Freier SSD-Speicherplatz: ((1000GB/5) + 8GB) * 1 = 208 GB

    Wir erinnern uns, die Formel zur Berechnung ist

    ((Freier Speicherplatz/Anzahl der Datenträger) + 8GB) * Anzahl der Enclosure

    Da wir ja alle seit der Erfindung von calc.exe eher weniger im Kopf rechnen möchten hier ein kleines Skript, welches die genaue Anzahl des freien Speicherplatz ausrechnet und in entsprechender Form ausgibt:

    # j.kappen@rachfahl.de, 23.04.2014, Kalkulation des freien Speicherplatzes in einem StoragePool
    # Ausgabe der vorhandenen Pools
    Get-StoragePool
    Write-Host ""
    Write-Host ""

    # Abfrage der Enclosure und des Pool-Namen
    $anzahlenclosure = Read-Host "Geben Sie die Anzahl der Enclosure an"
    $poolname = Read-Host "Geben Sie den Namen des Pools an, bei dem die Groessen berechnet werden sollen"

    # Berechnung des SSD-Speichers
    $disks = Get-StoragePool -FriendlyName $poolname | Get-PhysicalDisk | where MediaType -eq SSD
    $ssdSpace = 0
    $ssddiskCount = 0
    foreach ($disk in $disks)
    {
    if ($disk.MediaType -eq "SSD")
    {
    $ssdSpace += $disk.Size
    $ssddiskCount++
    }
    }

    # Berechnung des HDD-Speichers
    $disks = Get-StoragePool -FriendlyName $poolname | Get-PhysicalDisk | where MediaType -eq HDD
    $hddSpace = 0
    $hdddiskCount = 0
    foreach ($disk in $disks)
    {
    if ($disk.MediaType -eq "HDD")
    {
    $hddSpace += $disk.Size
    $hdddiskCount++
    }
    }

    #Berechnung
    $ssdSpaceinGB = $ssdSpace / 1024 / 1024 / 1024
    $hddSpaceinGB = $hddSpace / 1024 / 1024 / 1024
    $hddSpaceinTB = $hddSpace / 1024 / 1024 / 1024 / 1024
    # ((Freier Speicherplatz/Anzahl der Datenträger) + 8GB) * Anzahl der Enclosure
    $freessdspace = (($ssdSpaceinGB / $ssddiskCount) + 8) * $anzahlenclosure
    $freehddspace = (($hddSpaceinGB / $hdddiskCount) + 8) * $anzahlenclosure

    # Ausgabe der Ergebnisse
    Write-Host -ForegroundColor Green "Kalkulation der empfohlenen Groessen"
    Write-Host -ForegroundColor Green "————————————–"
    Write-Host -ForegroundColor Green "Anzahl der SSDs:" $ssddiskCount
    Write-Host -ForegroundColor Green "Gesamter SSD-Speicherplatz"
    Write-Host -ForegroundColor Green "————————————–"
    Write-Host -ForegroundColor Green $ssdSpace "Byte =>" $ssdSpaceinGB "GB"
    Write-Host ""
    Write-Host -ForegroundColor Green "————————————–"
    Write-Host -ForegroundColor Green "Freier benoetigter SSD-Speicherplatz"
    Write-Host -ForegroundColor Green $freessdspace "GB"
    Write-Host ""
    Write-Host ""
    Write-Host -ForegroundColor Green "————————————–"
    Write-Host -ForegroundColor Green "Anzahl der HDDs:" $hdddiskCount
    Write-Host -ForegroundColor Green "Gesamter HDD-Speicherplatz"
    Write-Host -ForegroundColor Green "————————————–"
    Write-Host -ForegroundColor Green $hddSpace "Byte =>" $hddSpaceinGB "GB =>" $hddSpaceinTB "TB"
    Write-Host ""
    Write-Host -ForegroundColor Green "————————————–"
    Write-Host -ForegroundColor Green "Freier benoetigter HDD-Speicherplatz"
    Write-Host -ForegroundColor Green $freehddspace "GB"

    Download: Berechnung_Freier_Speicherplatz_SOFS.txt

    Das Skript fragt die Anzahl der Enclosure und den Namen des Pools ab und errechnet danach sowohl für SSDs als auch für HDDs den freien Speicherplatz.

    image

    Da wir nun den Speicherplatz ausgerechnet haben können wir mit der Erstellung der Datenträger fortfahren. Dies geht entweder per Failover Cluster Manager oder per PowerShell. Die GUI erlaubt ziemlich wenig Anpassungen gegenüber den Standardwerten, der wichtigste Punkt ist die Konfiguration der Blockgröße / des Interleave. Aus diesem Grund nehme ich die komplette Erstellung innerhalb der PowerShell vor.

    Bei der Anzahl der Datenträger benötigen wir mindestens so viele Datenträger wie Cluster Knoten, in meinem Fall zwei. Zusätzlich kommt noch ein Quorum-Datenträger hinzu mit einer Größe von fünf GB. Dieser wird seit Server 2012 R2 immer benötigt, da immer ein Quorum zugewiesen wird und das Failover Cluster dynamisch mit dem Quorum arbeitet oder nicht, je nach Anzahl der Knoten. Da wir in diesem Aufbau zwei Server haben wir sowieso ein Quorum benötigt.

    Die Erstellung des Quorum

    Zur Erstellung des Quorum wird der folgende Befehl verwendet

    Get-StoragePool Pool01 | New-VirtualDisk -FriendlyName "FSQuorum" -ResiliencySettingName "Mirror" -NumberOfDataCopies 3 -Size 5GB -Interleave 64KB

    Dies bewirkt, dass im Storage Pool Pool01 ein neuer Datenträger mit dem Namen FSQuorum angelegt wird. Die Datensicherheit (Resiliency) ist ein Spiegel (Mirror), die Anzahl der Kopien sind 3 (d.h. es ist ein Drei-Wege-Spiegel). Die Größe wird mit 5 GB angegeben und die Interleave-Größe beträgt 64KB. Nach der Erstellung sieht der Datenträger im Failover Cluster Manager bzw. in der PowerShell wie folgt aus

    image

    image

    Man erkennt, dass der Datenträger 8 GB groß geworden ist, trotz dem Befehl mit 5 GB. Dies liegt vermutlich an der Aufteilung der Daten auf den unterschiedlichen Festplatten, 8 GB scheint in diesem Fall die kleinste Größe zu sein. Bei knapp 20 TB an Speicherplatz ist dies aber nicht weiter tragisch.

    Da ich bei der Erstellung nichts von einem Tiering angegeben habe, wurde dieser Datenträger komplett auf HDDs angelegt. Dies ist nicht weiter schlimm, auf dem Quorum-Datenträger wird sehr wenig geschrieben und gelesen, daher ist hier Tiering absolut nicht notwendig.

    Damit ich das Laufwerk nutzen kann muss es nun noch formatiert werden. Dies geht entweder manuell über den Failover Cluster Manager (und auch nur, wenn der Wartungsmodus für den Datenträger aktiviert ist) oder ebenfalls per PowerShell. Achten Sie bei der Formatierung per GUI darauf, dass der Datenträger auf dem Host liegt, auf dem Sie die Formatierung machen möchten. In meinem Fall ist dies FSNode1.

    # Datenträger auflisten
    Get-VirtualDisk
    Write-Host ""
    Write-Host -ForegroundColor Red "Achtung, diese Aktion formatiert einen oder mehrere Datenträger!"
    Write-Host ""
    # Name abfragen
    $vdName = Read-Host "Geben Sie einen Namen des Datenträger an, den Sie formatieren möchten"
    # Lokalen Computernamen herausfinden und speichern
    $ComputerName = $env:COMPUTERNAME
    # Neuen, verfügbaren Datenträger auf den lokalen Knoten verschieben
    Move-ClusterGroup “Available Storage” –Node $ComputerName
    # Cluster-Ressourcen auflisten und einlesen
    $clusterResource = Get-ClusterResource | where Name -like *$vdName*
    # Wartungsmodus aktivieren
    Suspend-ClusterResource $clusterResource
    # Datenträger formatieren
    Get-VirtualDisk $vdName | Get-Disk | New-Partition –UseMaximumSize | Format-Volume `
        –FileSystem NTFS –AllocationUnitSize 64KB –NewFileSystemLabel $vdName –Confirm:$false
    #unset VirtualDisk Maintance Mode
    Resume-ClusterResource $clusterResource

    Download: Formatierung_Datentraeger_FailoverCluster.txt

    image

    Nach der Formatierung sieht der Datenträger im Failover Cluster Manager wie folgt aus

    image

    Die Erstellung der weiteren CSV-Datenträger

    Im zweiten Schritt werden nun die CSV-Datenträger erstellt, in denen letztendlich die Daten der VMs gespeichert werden. Ich habe zwei Server, daher erstelle ich zwei virtuelle Datenträger. Um die korrekte Größe inkl. dem bereits erstellten Quorum zu setzen, hier ein weiteres Skript, welches auf die Daten aufbaut, die das vorherige Skript ausgeworfen hat.

    $gesamtHDDSpace = Read-Host "Geben sie die gesamte HDD-Größe in GB ein"
    $gesamtSSDSpace = Read-Host "Geben sie die gesamte SSD-Größe in GB ein"
    $freierHDDSpace = Read-Host "Geben sie Reserve-Speicherplatz der HDDs in GB ein"
    $freierSSDSpace = Read-Host "Geben sie Reserve-Speicherplatz der SSDs in GB ein"
    $mirrorlevel = Read-Host "Geben Sie den Spiegel an, den Sie nutzen möchten (2 oder 3)"
    $anzahlvdisks = Read-Host "Geben Sie die Anzahl der CSV-Datenträger ein"
    Write-Host ""
    $hddcsvsize = ($gesamtHDDSpace – $freierHDDSpace) / $mirrorlevel / $anzahlvdisks
    $ssdcsvsize = ($gesamtSSDSpace – $freierSSDSpace) / $mirrorlevel / $anzahlvdisks
    Write-Host -ForegroundColor Green "Größe des SSD-Speicherplatz:" $ssdcsvsize
    Write-Host -ForegroundColor Green "Größe des HDD-Speicherplatz:" $hddcsvsize

    image

    Zur Erstellung werden die folgenden Zeilen Code genutzt:

    # Storage-Tiers entfernen
    Get-StorageTier | Remove-StorageTier

    # Definiton
    $poolName = "Pool01"
    $ssdTierName = "SSD-Tier"+ $poolName
    $hddTierName = "HDD-Tier"+ $poolName
    $dataCopies = 3
    $columnCount = 1

    New-StorageTier -StoragePoolFriendlyName $poolName `
    -FriendlyName $ssdTierName -MediaType SSD
    New-StorageTier -StoragePoolFriendlyName $poolName `
    -FriendlyName $hddTierName -MediaType HDD

    $ssd_tier = Get-StorageTier | where FriendlyName -eq $ssdTierName
    $hdd_tier = Get-StorageTier | where FriendlyName -eq $hddTierName
    $ssdTierSize = 122GB
    $hddTierSize = 2791GB

    # Erstellung der Datenträger
    New-VirtualDisk -StoragePoolFriendlyName $poolName `
    -StorageTiers @($ssd_tier,$hdd_tier) `
    -StorageTierSizes $ssdTierSize,$hddTierSize `
    -ResiliencySettingName Mirror -NumberOfDataCopies $dataCopies `
    -NumberOfColumns $columnCount -ProvisioningType Fixed `
    -FriendlyName vDisk1 -Interleave 64KB -IsEnclosureAware:$true

    New-VirtualDisk -StoragePoolFriendlyName $poolName `
    -StorageTiers @($ssd_tier,$hdd_tier) `
    -StorageTierSizes @($ssdTierSize,$hddTierSize) `
    -ResiliencySettingName Mirror -NumberOfDataCopies $dataCopies `
    -NumberOfColumns $columnCount -ProvisioningType Fixed `
    -FriendlyName vDisk2 -Interleave 64KB -IsEnclosureAware:$true

    Auf Wunsch können diese Datenträger nun auch noch per PowerShell formatiert werden. Hierzu wird das gleiche Verfahren wie bei dem Quorum-Datenträger genutzt.

    # Datenträger auflisten
    Get-VirtualDisk
    Write-Host ""
    Write-Host -ForegroundColor Red "Achtung, diese Aktion formatiert einen oder mehrere Datenträger!"
    Write-Host ""
    # Name abfragen
    $vdName = Read-Host "Geben Sie einen Namen des Datenträger an, den Sie formatieren möchten"
    # Lokalen Computernamen herausfinden und speichern
    $ComputerName = $env:COMPUTERNAME
    # Neuen, verfügbaren Datenträger auf den lokalen Knoten verschieben
    Move-ClusterGroup “Available Storage” –Node $ComputerName
    # Cluster-Ressourcen auflisten und einlesen
    $clusterResource = Get-ClusterResource | where Name -like *$vdName*
    # Wartungsmodus aktivieren
    Suspend-ClusterResource $clusterResource
    # Datenträger formatieren
    Get-VirtualDisk $vdName | Get-Disk | New-Partition –UseMaximumSize | Format-Volume –FileSystem `
        NTFS –AllocationUnitSize 64KB –NewFileSystemLabel $vdName –Confirm:$false
    #unset VirtualDisk Maintance Mode
    Resume-ClusterResource $clusterResource

    image

    Nun sind zwei neue Datenträger vorhanden, jeweils mit einer Größe von 2,84 TB. Die Formatierung ist ebenfalls gemacht worden, die Blockgröße von 64KB wurde hierbei beachtet. In meinem Fall kann ich nur eine Coloum-Zahl von 1 verwenden, da fünf SSDs durch drei 1,66 sind. Alles nach dem Komma zählt nicht, die Coloum-Zahl beträgt 1. Um auf 2 zu kommen würde noch eine weitere SSD benötigt, für jede weitere Zahl drei weitere SSDs.

    image

    Damit diese Datenträger später als Speicher des Scale-Out File Server genutzt werden können müssen sie zu den Cluster Shared Volumes hinzugefügt werden. Dies geschieht entweder über den entsprechenden Punkt im Kontext-Menü oder per PowerShell:

    Get-VirtualDisk
    Write-Host ""
    $vdName = Read-Host "Geben Sie den Namen des Datenträgers ein, der als CSV-Datenträger konfiguriert werden soll"
    $clusterResource = Get-ClusterResource -Name "*$vdName*"
    Add-ClusterSharedVolume -InputObject $clusterResource

    image

    Die Konfiguration der Quorum-Einstellungen

    Als nächstes muss der 8 GB große Datenträger als Quorum-Datenträger konfiguriert werden. Dies geht über den Failover Cluster Manager über die erweiterten Befehle und dem Punkt Clusterquorumeinstellungen konfigurieren

    image

    image

    image

    image

    image

    Die Alternative per PowerShell:

    Set-ClusterQuorum -NodeAndDiskMajority "Cluster Virtual Disk (FSQuorum)"

    image

    Mit diesem Schritt ist die Konfiguration schon beendet.

    Die Erstellung und Konfiguration der Dateiserver-Rolle

    Im nächsten Schritt müssen wir die Dateiserver-Rolle installieren und einrichten. Per GUI wird dies über RollenRolle konfigurieren gemacht.

    image

    Wählen Sie den Dateiserver aus und bestätigen Sie die Auswahl mit Weiter.

    image

    Der nächste Schritt ist der wichtigste, an dieser Stelle wird die Art des Dateiserver ausgewählt. Der obere Punkt ist ein gewöhnlicher Dateiserver, der für die Ablage von Dateien genutzt werden kann. Dies wird in unserem Fall nicht benötigt, wir benötigen die untere Art von Dateiserver (im englischen als Scale-Out File Server bezeichnet, im deutschen als Dateiserver mit horizontaler Skalierung).

    image

    Unter Clientzugriffspunkt müssen Sie einen Namen für den Dateiserver eingeben. Unter diesem Namen ist der Server im Netzwerk erreichbar und ansprechbar. In meinem Fall nenne ich den Zugriffspunkt SOFS, d.h. mein Scale-Out File Server ist im Netzwerk unter \\SOFS\Share1 erreichbar.

    image

    Nach einer Überprüfung der AD auf ein evtl. schon vorhandenes Objekt mit diesem Namen bekommen Sie eine Zusammenfassung der Einstellungen, Sie sehen hier direkt die drei Subnetze, die von der Rolle genutzt werden.

    image

    Nach einem Klick auf Weiter beginnt die Erstellung der Rolle. Die Installation per PowerShell kann mit dem folgenden Befehl durchgeführt werden:

    Add-ClusterScaleOutFileServerRole -Name "SOFS"

    image

    image

    Als nächster Schritt kommt nun die Erstellung mehrerer Freigaben, auf die unsere Hyper-V Hosts zugreifen können. Wählen Sie im Kontextmenü der Dateiserver-Rolle den Punkt Freigabe hinzufügen.

    image

    Wenn Sie die folgende Meldung erhalten

    image

    haben Sie zwei Möglichkeiten. Entweder Sie holen sich jetzt einen Kaffee und versuchen es später erneut, oder Sie verschieben die Dateiserver-Rolle auf den Host, auf dem Sie gerade angemeldet sind. Falls dies immer noch nichts bringt und Ihr Failover Cluster-Manager Fehler bringt, die ein Berechtigungsproblem in Ihrem DNS anmerken (dies war bei mir der Fall, da die Objekte im DNS bereits vorhanden waren und nicht überschrieben werden konnten), gehen Sie wie folgt vor: Löschen Sie im DNS alle Einträge mit dem Namen des Scale-Out File Server. Erstellen Sie danach ein neues Objekt mit dem Namen und einer IP. Fügen Sie danach in den Sicherheitseinstellungen des DNS-Objekt das Computerobjekt hinzu und geben Sie ihm die Rechte zur Änderung des Eintrags:

    image

    Bestätigen Sie die Einstellungen und verschieben Sie die Dateiserver-Rolle erneut. Nun sollten keine Fehler mehr auftauchen und die Erstellung einer neuen Freigabe sollte ebenfalls funktionieren. Weiterhin werden alle IPs im DNS unter dem Namen der Rolle angelegt.

    Es öffnet sich ein Assistent, der Sie durch die Erstellung der Freigabe führt. Als erstes müssen Sie ein Profil auswählen, um welche Art von Freigabe es sich handelt. Da wir VMs speichern möchten sollte das Profil Anwendungen gewählt werden

    image

    Im nächsten Schritt können Sie den Server wählen, hier ist direkt unsere Dateiserver-Rolle angewählt. im mittleren Bereich können Sie sehen, dass Sie hier nur die beiden CSVs auswählen können, keinen lokalen Pfad. Wir beginnen mit Volume1 und fahren im Assistenten fort.

    image

    Vergeben Sie nun einen Namen für die Freigabe. Ich habe sie in meinem Fall Share1 genannt. Sie können erkennen, wie sich der Name im unteren Bereich einträgt. An dieser Stelle können Sie bereits den kompletten Pfad sehen, über den Sie später Ihre VMs speichern.

    image

    Nach einem Klick auf Weiter sehen Sie, dass die erhöhte Verfügbarkeit eingeschaltet ist und auch nicht entfernt werden kann. Diese Option ermöglicht einen nahtlosen Betrieb der VMs, auch bei einem Ausfall oder einem Neustart eines der Datei Server-Knoten

    image

    Nun kommen wir zu einer sehr wichtigen Stelle: Die Konfiguration der Berechtigungen für diese Freigabe

    image

    Passen Sie diese Einstellungen wie folgt an: Wählen Sie Berechtigungen anpassen im unteren Bereich und deaktivieren Sie als erstes die Vererbung. Danach entfernen Sie die Benutzer-Berechtigungen auf dieser Freigabe, Benutzer haben an dieser Stelle nichts zu suchen. Fügen Sie danach die Computerkonten aller Hyper-V Hosts hinzu, die auf diese Freigabe zugreifen sollen. Zusätzlich fügen Sie das bzw. die Cluster-Objekte hinzu der Hyper-V Failover Cluster (falls Sie einen oder mehrere Hyper-V Failover Cluster betreiben). Zuletzt geben Sie den AD-Admins noch eine Berechtigung auf diese Freigabe.

    image

    Das Ergebnis sieht wie folgt aus

    image

    image

    Nach einem Klick auf Weiter bekommen Sie eine kurze Zusammenfassung der Einstellungen, wenn diese korrekt sind können Sie die Freigabe erstellen.

    image

    Erstellen Sie eine zweite Freigabe, die auf dem Volume2 erstellt wird. Die Einstellungen bleiben die gleichen, nur der Name ändert sich. Das Resultat sieht wie folgt aus

    image

    Die Einrichtung per PowerShell sieht wie folgt aus:

    # Konfiguration_NTFS_Berechtigungen.ps1 – Jan Kappen – j.kappen@rachfahl.de
    # Erstellung einer neuen Freigabe für die SOFS-Rolle und Anpassung
    # der Rechte. Eine Anpassung ist notwendig an den markierten Stellen
    #
    # Konfiguration des Namen
    # Anpassung notwendig!
    $Sharename = "Share6"
    $Volumename = "Volume1"
    # Erstellen des neuen Ordners
    New-Item -Name $Sharename -ItemType Directory
    mkdir C:\ClusterStorage\$Volumename\Shares\$Sharename
    # Erstellung eines neuen Shares mit HA und ohne Caching
    #
    # Falls die Quorum-Freigabe erstellt werden soll, kann der Parameter
    # -ContiniousAvailable auf $false angepasst werden
    #
    New-SmbShare -Name $Sharename -Path C:\ClusterStorage\$Volumename\Shares\$Sharename `
    -CachingMode None -FullAccess "everyone" -ContinuouslyAvailable $true
    # Anzeige der Berechtigungen
    Get-Acl "C:\ClusterStorage\$Volumename\Shares\$Sharename" | fl
    # Benutzer aus den Rechten entfernen
    $colRights = [System.Security.AccessControl.FileSystemRights]"Read"
    $InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::None
    $PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None
    $objType =[System.Security.AccessControl.AccessControlType]::Allow
    $objUser = New-Object System.Security.Principal.NTAccount("BUILTIN\Users")
    $objACE = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType)
    $objACL = Get-ACL "C:\ClusterStorage\$Volumename\Shares\$Sharename"
    $objACL.RemoveAccessRuleAll($objACE)
    Set-ACL "C:\ClusterStorage\$Volumename\Shares\$Sharename" $objACL
    # Anzeige der Berechtigungen
    Get-Acl "C:\ClusterStorage\$Volumename\Shares\$Sharename" | fl
    # Besitzer konfigurieren
    $acl = Get-Acl "C:\ClusterStorage\$Volumename\Shares\$Sharename"
    $acl.SetOwner([System.Security.Principal.NTAccount] "Administrators")
    Set-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename $acl
    #
    $acl = Get-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename
    $acl.SetAccessRuleProtection($True, $False)
    #
    # Anpassung der Systemnamen sowie des Failover Cluster-Objekts notwendig!
    #
    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ("Powerkurs\Hyperv14$","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
    $acl.AddAccessRule($rule)
    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ("Powerkurs\Hyperv15$","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
    $acl.AddAccessRule($rule)
    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ("Powerkurs\powercluster1$","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
    $acl.AddAccessRule($rule)
    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ("Powerkurs\domain admins","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
    $acl.AddAccessRule($rule)
    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ("SYSTEM","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
    $acl.AddAccessRule($rule)
    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ("CREATOR OWNER","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
    $acl.AddAccessRule($rule)
    Set-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename $acl
    # Erneute Anzeige der Einstellungen
    Get-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename  | Format-List

    Download: PowerShell Skript: Konfiguration_NTFS_Berechtigungen

    image

    Die Erstellung einer Freigabe zur Nutzung als Quorum

    An dieser Stelle müssen wir noch eine weitere Freigabe erstellen, die als Quorum für unser Hyper-V Failover Cluster genutzt wird. Bei dieser Freigabe gibt es eine kleine Besonderheit: Sie sollte nicht dauerhaft zur Verfügung stehen, heißt wir konfigurieren diese Freigabe ein wenig anders. Diese Konfiguration kann allerdings erst nach der Erstellung gemacht werden, die Erstellung ist gleich wie bei den beiden Shares oben. In welchem Volume Sie die Freigabe erstellen ist grundsätzlich egal, ich lege sie in meinem Fall auf Volume1.

    Nach der Erstellung sehen Sie einen weiteren Share:

    image

    An dieser Stelle wechseln wir in die Eigenschaften von dieser Freigabe und konfigurieren in den Einstellungen die erhöhte Verfügbarkeit so, dass diese nicht markiert ist

    image

    Nun kann die Einstellung übernommen werden und die Freigabe ist korrekt konfiguriert.

    Quelle: Failover Clustering and Network Load Balancing Team Blog – Configuring a File Share Witness on a Scale-Out File Server

    Dieser Vorgang funktioniert auch mit dem oben verlinkten Skript, im oberen Teil bei der Erstellung der Freigabe müssen Sie eine Anpassung bei dem Parameter –ContiniouslyAvailable machen (weitere Infos im Skript), danach wird eine passende Freigabe erstellt.

    Nach dieser Anpassung ist der Aufbau im groben komplett. Sie können nun per \\sofs\Share1 oder \\sofs\Share2 auf die beiden Freigaben zugreifen, zusätzlich kann die dritte Freigabe als Quorum-Ablage genutzt werden.

    image

    Noch ein paar Worte zu Zugriffszeiten, Benchmarks usw…

    Wenn Sie das erste Mal auf die neu erstellten Freigaben zugreifen, kann es einige Zeit dauern, bis das Verzeichnis aufgerufen werden kann und Sie durch die Ordner navigieren können. Dies ist normal, es braucht einen kleinen Moment bis die Verzeichnisse erstmals aufgerufen werden können. Lassen Sie sich hier nicht beunruhigen. Wenn Sie während der Einrichtungs- bzw. Test-Phase das komplette Cluster herunterfahren oder alle Server gleichzeitig neustarten kann es nach dem Start ebenfalls einige Zeit dauern, bis alle Zugriffe wieder problemlos und ohne Verzögerung passieren. Planen Sie hier bitte ebenfalls ein paar Minuten ein, bis alles wieder flüssig und sauber läuft. Im Betrieb sind diese kompletten Ausschaltungen eher selten, daher passiert dies meist bei Simulationen von Problemen oder der kompletten Abschaltung des Dateiserver Cluster.

    Wenn Sie einen Performance-Test Ihres neu erstellten Scale-Out File Server machen möchten, fällt Ihnen wahrscheinlich als erstes die Kopie einer Datei auf einen der beiden Shares ein. Dies können Sie zwar machen, lassen Sie sich aber nicht von den Werten abschrecken, die sie während des Kopiervorgangs bekommen. Ein Scale-Out File Server speichert alle Blöcke ungepuffert. Dies wirkt sich bei Datei-Kopier-Operationen negativ aus, bei dem eigentlichen Betrieb des Speichers (der Ablage von VM-Daten) ist dies aber notwendig, damit alle Dateien und Blöcke immer definitiv auf den Platten landen, und nicht in irgendeinem Cache, der bei einem Stromausfall verfallen würde. Ein besserer Benchmark-Test wäre der Betrieb von einigen VMs, in denen mit Hilfe von Last- oder Benchmark-Tools I/O erzeugt wird. Selbst bei diesem Test gibt es wiederum einige Dinge, die beachtet werden sollten. Eine VM alleine reicht nicht, erst die Summe einiger VMs erzeugt (vielleicht) die Art von Last, die im späteren Betrieb auch auf dem System anliegt. Die Tiering-Funktion greift erst dann, wenn eine Umsortierung der Blöcke stattgefunden hat. Dies passiert, wie weiter oben erwähnt, standardmäßig täglich um 1:00 Uhr nachts. Eine Verbesserung der Benchmark-Werte (z.B. bei einem dauerhaften Benchmark) zeigt sich somit erst nach frühestens einem Tag.

    Die Nutzung eines Skripts zur kompletten Failover Cluster-Erstellung

    Die in diesem Beitrag genutzten Skripte sind fast alles Teilbereiche eines Skripts, welches mein Kollege Carsten Rachfahl bereits in einem Video genutzt und für unsere Zwecke angepasst hat. Das Skript kann ein komplettes Failover-Cluster inkl. Berechnung der Größen, Aufteilung und Erstellung der Datenträger usw. erstellen. Das Skript sowie das ziemlich sehenswerte Video finden Sie hier: Hyper-V-Server.de: Einen bestehenden Scale-Out Fileserver um SSDs erweitern

    An diese Stelle ist die Einrichtung im großen und ganzen abgeschlossen. Je nach Umgebung stehen nun noch weitere Schritte an, spontan fällt mir hier noch das Thema Backup ein.

  • TechNet Newsflash Ausgabe 13/2014

    Liebe Podcast-Zuhörer,

    der Podcast Ausgabe 13/2014 des TechNet Newsflash ist live.

    http://download.microsoft.com/download/B/5/6/B56DB709-07CA-4DE3-8F90-3CB99A2C01DD/TechNetFlash_13-2014.mp3

    Link zum TechNet Newsflash in Schriftform:

    http://www.microsoft.com/germany/technet/newsflash/aktuell.htm

    Link zum RSS Feed:

    http://www.microsoft.com/feeds/technet/de-de/newsflash/tn_flash_podcast_archiv.xml

    Wie immer: viel Freude beim Zuhören und späteren Durchstöbern der angekündigten Ressourcen!

    Euer TechNet-Team!

    ☁ Heike

  • SCADA-Systeme im Visier von kriminellen Profi-Hackern

    Eine neue Angriffswelle über mit Malware infizierte ICS (Industrielle Kontrollsysteme)/SCADA-Hersteller-Seiten haben Sicherheitsexperten von F-Secure entdeckt. Besonders Perfide: Für die im Stil einer so genannten Wasserloch-Attacke ausgeführten Angriffe haben die Kriminellen an sich legitime Downloads auf Webseiten von Herstellern aus dem ICS-Umfeld mit Trojanern infiziert. Ziel der Angriffe: Offenbar kommerzielle Spionage und die Übernahme von industriellen Kontrollsysteme.

    F-Secure hat nach eigenen Angaben seit einem Jahr eine Hackergruppe überwacht, die hinter der Havex-Malware-Familie steht. In der Vergangenheit wurde ein Remote-Access-Trojaner (RAT) dazu benutzt, um Energiefirmen ins Visier zu nehmen, wie die Experten von Crowdstrike berichten.

    In den letzten Monaten hat F-Secure 88 Havex-Varianten untersucht, sowie 146 C&C Server und 1500 IP-Addressen. Die Untersuchung hat ergeben, dass sich der Fokus der Hackergruppe zunehmend auf industrielle Kontrollsysteme richtet.

    Die Hacker verbreiteten Havex – wenig überraschend – über Spam-E-Mails und durch Exploit-Kits. Raffiniert ist jedoch der Missbrauch von Schwachstellen in der Web-Software, die die Hersteller von ICS-Komponenten zur Pflege der Webseiten verwenden. Denn auf diesem Weg konnten die Angreifer die Downloads mit den Trojanern verseuchen und so direkt auf die Rechner der Kunden des Herstellers schleusen.

    Von den drei infizierte Webseiten gehören zwei Anbietern von Remote-Management-Software für ICS-Systeme, die dritte gehört einem Anbieter von industriellen Kameras und der dazugehörigen Software.

    F-Secure gab an, bei der Untersuchung eine Komponente gefunden zu haben, die Daten von infizierten ICS/SCADA-Systemen sammelnn. F-Secure schließt daraus, dass die Hacker nicht nur in solchen Systeme eindringen, sondern auch die Kontrolle übernehmen wollen. Alle Opfer solcher Angriffe seien mit der Entwicklung und Anwendung von industriellen Anwendungen oder Maschinen beschäftigt. Hinter dem Hacker-Angriff könnte auch ein staatlicher Auftrag stecken, der Spionage betreibt, vermutet Sean Sullivan von F-Secure. Details zu der Quelle des Angriffs sind aber noch nicht bekannt.

    Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates. 

  • Goodbye Windows Server 2003! Besuchen Sie die kostenlose End-of-Support-Roadshow mit Microsoft MVPs

    Am 14. Juli 2015 endet der Support für Windows Server 2003 und Windows Server 2003 R2

    Dies bedeutet, dass nach dem 14.07.2015 keine automatischen Updates und Hotfixes für die dann mittlerweile zwölf Jahre alte Server-Generation mehr bereitgestellt werden. Beginnen Sie bereits jetzt mit der Upgrade-Planung und erfahren Sie, welche Optionen es für eine Modernisierung Ihrer Legacy-Serversysteme gibt und welche Unterstützungen Microsoft und Partner bereitstellen, damit Sie sich optimal vorbereiten können.

    In eintägigen, kostenlosen Veranstaltungen im Rahmen der End-of-Support-Roadshow erfahren Sie von Microsoft Most Valuable Professionals (MVPs), wie eine optimale Zielarchitektur aussehen kann und welche Wege es gibt, eine Migration möglichst effizient durchzuführen. Zusätzlich wird die sinnvolle Integration von Cloud Services beleuchtet, wie etwa Recovery-, Test- und Storage-Services mit Mirosoft Azure.

    Nutzen Sie die Roadshow auch, um sich über das breite Angebot von Microsoft Services in den typischen Projektphasen „Assessment“, „Planning“, „Migration“ und „Support“ zu informieren. Experten von Dell Software zeigen Ihnen zusätzlich softwaregestützte Optionen auf, wie Sie eine Migration kostengünstig, effizient und unter Einhaltung hoher Standards im Hinblick auf geschäftskritische Applikationen und Compliance durchführen können.

    Nutzen Sie die Chance sich umfassend zu informieren und melden Sie sich noch heute für die Roadshow an:

    22.07.2014

    Frankfurt

    Weitere Informationen und Anmeldung

    25.07.2014

    München / Unterschleißheim

    Weitere Informationen und Anmeldung

    26.08.2014

    Berlin

    Weitere Informationen und Anmeldung

    28.08.2014

    Hamburg

    Weitere Informationen und Anmeldung

    02.09.2014

    Köln

    Weitere Informationen und Anmeldung

    08.09.2014

    Frankfurt

    Weitere Informationen und Anmeldung

    24.09.2014

    München / Unterschleißheim

    Weitere Informationen und Anmeldung

    Es erwartet Sie eine informative und spannende Agenda, durch die Sie unsere technischen Experten führen werden:

    Agenda:

    08:30-09:00 Uhr Ankunft und Begrüßung
    09:00-10:00 Uhr Windows Server 2003 – Best Practices zum Upgrade
    10:00-11:00 Uhr IT-Architekturen im Jahr 2014 mit Windows Server / Microsoft Cloud OS Teil 1
    11:00-11:15 Uhr Pause
    11:15-12:45 Uhr Microsoft Cloud OS Teil 2: Virtualisierung, Management und der Weg dorthin
    12:45-13:45 Uhr Mittagspause und Networking
    13:45-14:30 Uhr Upgrade-Testing und Desaster-Recovery mit Microsoft Azure
    14:30-15:30 Uhr Software-gestützte Migration geschäftskritischer Applikationen (Gastvortrag DELL)
    15:30-15:45 Uhr Kaffeepause
    15:45-16:45 Uhr So unterstützt Microsoft Services in den einzelnen Projektphasen
    16:45-17:00 Uhr Feedback und Verabschiedung

    Wir freuen uns darauf, Sie zu einem der Termine begrüßen zu dürfen und Sie bei der Modernisierung Ihres Rechenzentrums zu unterstützen.

     

     

  • Interflow: Kostenloser Dienst liefert Threat-Informationen als Feed

    Microsoft macht die Sicherheits- und Threat-Plattform Interflow öffentlich zugänglich, wie meine US-Kollegen in einem Blogbeitrag schreiben (der Beitrag liefert noch mehr Hintergrundinformationen zu Interflow). Interflow ist gedacht für IT-Sicherheitsexperten und Analysten und will Organisationen helfen, sich gegen Cyberangriffe zu wehren. Die Plattform nutzt Industriestandards, um in Quasi-Echtzeit einen automatisierten, maschinenlesbaren Feed aus Bedrohungs- und Sicherheitsinformationen zu erzeugen. Letztendlich lassen sich auf Basis des Feeds die Kosten reduzieren, die durch die Abwehr von Angriffen und den Schutz von Kunden-Systemen entstehen.

    Es ist eine Binsenweisheit, dass sich Cyberangriffe ständig weiter entwickeln. Viele gängige Tools zur Abwehr von Attacken haben große Mühe, mit der hohen Geschwindigkeit der neuen Angriffsvarianten Schritt zu halten. Interflow will gezielt die Lücken schließen, die bislang noch offen stehen:

    • Interflow ist an die individuellen Bedürfnisse des Nutzers anpassbar. Nutzer können selbst entscheiden, welche Communities sie bilden wollen, welche Daten-Feeds sie ihren Communities zur Verfügung stellen wollen und mit wem sie Daten-Feeds teilen wollen.
    • Interflow arbeitet mit vorhandenen Operations- und Analysetools zusammen und hat kein verschlossenes, proprietäres Datenformat, das die Kosten für IT-Sicherheit in die Höhe treibt.
    • Interflow läuft selbständig. Der automatische Input von Daten reduziert die Zeit und beschleunigt den Prozess für Organisationen und Unternehmen, um Schwachstellen schnell zu finden.

    Interflow ist ein gutes Beispiel für unsere Motivation, unseren Kunden rund um Cybersecurity neue Ideen und Produkte zu bieten. Basierend auf Windows Azure ist Interflow auch ein gutes Beispiel für den kompromisslosen Einsatz der Cloud.  Nach dem Ende der Preview-Phase und mit der allgemeinen Verfügbarkeit wird die Interflow-Plattform kostenlos zugänglich sein. Microsoft wird der Interflow-Community die gleichen Threat-Daten zur Verfügung stellen, auf die wir zum Schutz unserer eigenen Dienste und Produkte bauen. Weitere Infos online unter www.microsoft.com/interflow.

    Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates. 

  • TechNet Newsflash Ausgabe 12/2014

    Liebe Podcast-Zuhörer,

    der Podcast Ausgabe 12/2014 des TechNet Newsflash ist live.

    http://download.microsoft.com/download/B/5/6/B56DB709-07CA-4DE3-8F90-3CB99A2C01DD/TechNetFlash_12-2014.mp3

    Link zum TechNet Newsflash in Schriftform:

    http://www.microsoft.com/germany/technet/newsflash/aktuell.htm

    Link zum RSS Feed:

    http://www.microsoft.com/feeds/technet/de-de/newsflash/tn_flash_podcast_archiv.xml

    Wie immer: viel Freude beim Zuhören und späteren Durchstöbern der angekündigten Ressourcen!

    Euer TechNet-Team!

    ☁ Heike

  • SCM (Security Compliance Manager) Baselines für Office 2013 verfügbar

    Wie das Windows Enterprise Client Customer Experience Team heute bekanntgegeben hat, stehe die SCM Baselines für Office 2013 zum Download bereit.

    Es gibt zwei Wege, um die entsprechenden Dateien zum SCM hinzufügen:

    1. Einfach das SCM-Tool öffnen und es wird automatisch anzeigen, dass neue Baselines verfügbar sind und sie importieren.
    2. Zum manuellen Download der CAB-Files per Browser gibt es die folgenden URLs:
      http://go.microsoft.com/fwlink/?LinkID=403023&clcid=0x409 (Baseline)
      http://go.microsoft.com/fwlink/?LinkID=403024&clcid=0x409 (Attachments)

    Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates. 

  • Sicherheitsbulletins maßgeschneidert dank neuem Online-Dienst

    Microsoft bietet seit kurzem mit myBulletins einen neuen Online-Sicherheits-Mitteilungsdienst, der sich den Wünschen der Kunden anpassen kann. Der Dienst lässt Anwender genau die Sicherheitsbulletins – also die Beschreibungen der monatlich veröffentlichten Sicherheitsupdates – auswählen, die für sie relevant sind. Der Online-Service bietet IT-Verantwortlichen eine personalisierbare Liste von Microsoft Sicherheitshinweisen, die für die jeweilige Organisation am wichtigsten sind.

    Der Zugang ist einfach: Auf der Webseite myBulletins mit einem Microsoft-Account einloggen, die gewünschten Microsoft-Produkte und Versionen auswählen und schon präsentiert der Dienst eine individuell erstellte Liste im Dashboard mit den wichtigsten Sicherheitshinweisen.

    Mit myBulletins wollen wir Security Bulletins leichter erreichbar und Informationen schneller auffindbar machen, damit unsere Kunden so schnelle(r) Entscheidungen treffen zu können. Der Dienst wurde auf den Wunsch zahlreicher Kunden hin entwickelt, rascher durch die Fülle an Informationen dringen zu können, die mit den monatlichen Sicherheitsupdates einhergeht.

    Die Sicherheitshinweise lassen sich nach Erscheinungsdatum, Wichtigkeit und Reboot-Notwendigkeit sortieren, um bei der Entscheidungsfindung zu helfen. Der Dienst gibt eine dynamische Liste mit Hinweisen aus, die vom Nutzer bearbeitet und in Excel übernommen werden kann.

    myBulletins ist unser Weg, um auftretende Security Updates so nahtlos wie möglich zu machen. Wir finden, dass Kunden am besten geschützt sind, wenn alle verfügbaren und vor allem benötigten Updates rasch installiert werden. Von daher meine Bitte: Legen Sie sich ein Profil bei myBulletins an, testen Sie den Dienst und lassen Sie uns wissen, wie Sie ihn finden.

    Gastbeitrag von Michael Kranawetter, Chief Security Advisor (CSA) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates.