Azure VPN-Verbindung (S2S) über den Azure Resource Manager und Windows Server 2012 R2

Fangen wir mal an

Auch für kleine Firmen kann die Nutzung von Diensten aus der Cloud sinnvoll sein, lässt sich damit doch der eine oder andere Test oder die Beschaffung zusätzlicher Server-Hardware umgehen.

Neben einer Vielzahl von Diensten (Azure-Backup), welche einfach über die Ports 80 oder 443 genutzt werden, kann es dennoch notwendig sein, eine VPN Verbindung nach Azure zu bauen (also das lokale Netzwerk mit Azure zu koppeln, was man auch Site-2-Site-VPN/S2S-VPN nennt). Um es gleich vorne weg zu sagen, in Azure kocht man auch nur mit Wasser … oder anders rum, mit Virtuellen Maschinen (VM), was bedeutet das ein VPN-Gateway in Azure nichts anderes ist, als ein Windows Server (Stand heute 2012R2). Zwar gibt es bei Microsoft Azure eine Liste von Routern und Beschreibungen wie diese für eine VPN-Verbindung mit Azure konfiguriert werden müssen, für kleine Firmen tut es aber auch ein Windows Server und genau diese Konfiguration soll hier beschrieben werden.

Um z.B. eine FRITZ!Box mit Azure zu verbinden gibt es eine Reihe von Anleitungen, dass Problem mit den FRITZ!Boxen ist aktuell, dass diese keinen IKEv2 support liefern und deshalb die Verbindung nach Azure über den ARM (Azure Resource Manager) nicht ganz so einfach zu konfigureren ist.

Microsoft hat in Azure zwei Möglichkeiten um Ressourcen zu verwalten:

  • ASM = Azure Service Manager (alt und nicht mehr auf Höhe der Zeit, der ASM wird nur noch aus Gründen der Kompatibilität bereit gestellt)
  • ARM = Azure Resource Manager (aktuell und die empfohlene Lösung)

Ich habe z.B. festgestellt, dass sich Azure GPU VMs (N-series) nur über den ARM bereitstellen lassen und auch nur auf ARM Ressourcen zurückgreifen können. Ich hatte die Situation, dass ich es nicht hinbekommen habe auf eine VPN Verbindung zwischen meiner FRITZ!Box und meinem lokalen Netzwerk (ASM basierend) mit einer N-Series VM zu zugreifen. Vielleicht saß das Problem auch vor dem Rechner, zumindest war eine einfache Lösung nicht möglich (ein VNet-Peering oder VNet-Routing wollte ich nicht konfigurieren).

Voraussetzungen

Damit nun eine VPN-Verbindung zwischen Azure und einem lokalen Netzwerk mit einem Windows Server konfiguriert werden kann, müssen wir uns, über ein paar Dinge klar werden:

  1. IPv4-Adressbereiche in Azure
  2. Lokale IP-Adressbereich(e) und die externe IP des Routers
  3. Auf welchem Server installieren wir RRAS (Remote Routing and Access)?

Gleich mal zu Punkt 3 … auf einem Windows Server mit geladener Essentials Role würde ich von einer Konfiguration von RRAS absehen … Da ich inzwischen die Standard Edition von Windows Server verwende und die seit geraumer Zeit den Betrieb von 2 VMs möglich macht, gehe ich von der folgenden Konfiguration aus:

  • Host mit Hyper-V
  • VM 1, Windows Server mit installierter Essentials Role
  • VM 2, Windows Server mit RRAS und weiteren Diensten

Die folgenden Screenshots wurden auf einem Windows Server 2012 R2 (Englisch) gemacht und auch die Menübeschreibungen des Server beziehen sich auf die Englische Version …

Punkt 2 beschreibt alle lokalen Adressbereiche welche verwendet werden, und darüber hinaus brauchen wir die externe IP des Routers. Diese ist bei mir statisch, oder sagen wir mal so gut wie statisch. Bisher hat bei UnityMedia (meinem Provider) die IP höchstes 1x im Jahr gewechselt.

Meine lokalen Adressbereiche sehen wie folgt aus:

  • 192.168.2.0/24, Gateway ist immer die .1 und der DNS läuft unter 192.168.2.17
  • 192.168.12.0/24, Gateway ist immer die .1

Die externe IP ist 38.210.102.188, bzw. ein verwendeter DynDns-Name wie z.B. azuretest.remotewebaccess.com

Damit kommen wir zum letzten Punkt, was soll eigentlich in Azure gebaut werden? Meine Absicht ist es ein Subnetz für VMs zu erstellen und dieses über ein VPN Gateway mit dem Netzwerk zuhause zu koppeln. Im ARM müssen dazu 2 Netzwerke definiert werden. Ein Netzwerk, oder genauer gesagt Subnetz für die VMs und ein weiteres für das Gateway.

Diese Netze nennen wir wie folgt und verwenden die folgenden Adressbereiche:

  • SBSland-Azure-CR-Network-000, 10.1.0.0/16
  • Subnetz 1: VM-Network-250, 10.1.250.0/24
  • Subnetz 2: GatewaySubnet, 10.1.249.0/28

Darüber hinaus müssen wir im ARM eine Gruppe für diese Ressourcen anlegen:

  • SBSland-Azure-Core-RG-1

Zum Abschluss, also bevor wir die Sache angehen können brauchen wir noch einen PreShared-Key welcher im Gegensatz zu früher (im ASM) selbst erstellt werden muss. Ich mache das immer mit KeePass.

  • f75bb948e79e072503af6cf93b154321cdf88e1c00964da4569e9123456789a8

Da wir zwischen dem lokalen Netzwerk und Azure routen, dürfen sich KEINE der Adressebereiche überlappen.

Konfiguration in Azure Remote Manager (ARM)

Nach der Anmeldung in Azure, muss möglicher Weise in das neue Portal gewechselt werden … was dann so aussieht.

image

Nun erfolgt im ersten Schritt das Erstellen der Ressourcengruppe

  1. Dazu wählen wir Ressourcengruppe / Hinzufügen und geben hier den Ressourcengruppenname (SBSland-Azure-Core-RG-1) ein

    image

    An dieser Stelle wird auch ausgewählt in welcher Azure Region wir den Service laufen lassen, Westeurope = Amsterdam (stand heute)

  2. Ein Klick auf Erstellen erzeugt die Gruppe

    image

  3. Nun legen wir die Netzwerke an. + / Netzwerk / Virtual Network

    image

    Welche wie folgt benannt werden, SBSland-Azure-CR-Network-000 und darüber hinaus geben wir noch den von uns gewählten IP-Adressbereich für das VM-Subnetz 10.1.0.0/16 und das erste Subnetz VM-Network-250, 10.1.250.0/24 an.

    image

    Dazu nicht vergessen, die vorhin erstelle Ressourcengruppe aus zu wählen und natürlich mit Erstellen das virtuelle Netzwerk erzeugen zu lassen. Damit ist das erste Subnetz für die VMs angelegt

  4. Als nächstes muss das Gatewaysubnetz konfiguriert werden, dazu einfach + Gatewaysubnetz (blau markiert) auswählen und den IP-Adressbereich 10.1.249.0/28 einfügen.

    image

    Nach Auswahl der + Gatewaysubnetz Option erscheint der Dialog zur Anöage

    image

    Der Name GatewaySubnet ist vorgegeben, daher kann nur der IP-Adressbereich in CIDR Form eingegeben werden

    image

    In den nächsten Schritten wird nun das Azure Gateway und das Lokale Gateway angelegt. Beginnen wir mit dem Azure Gateway …

  5. Um das Azure Gateway an zu legen, muss + / Netzwerk / Virtuelles Netzwerkgateway ausgewählt werden

    image

    Das Gateway nennen wir SBSland-Azure-AZ-Gateway, darüber hinaus wird das angelegte Netzwerk (SBSland-Azure-CR-Network-000) ausgewählt und eine öffentliche IP erstellt

    image

    Kleiner Hinweis an dieser Stelle … hinter SKU steckt die Größe, bzw. die Leistungsfähigkeit des Gateways und damit im Prinzip nur eine größere oder kleiner VM Winking smile 

    Als Gatewaytyp lassen wir VPN, eine Expressroute haben wir ja nicht und als VPN-Typ verwenden wir Routenbasiert.

    Routenbasiert, unterstützt dynmische routen und mehrere VPN-Verbindungen basierend auf IKEv2
    Richtlinienbasiert, unterstützt statische Routen, eine single VPN-Verbindung und IKEv1

    Für die FRITZ!Boxler unter uns, wäre das eine Möglichkeit ein Richtlinienbasiertes VPN zu bauen, da hier IKEv1 verwendet wird… was ich mir aber bisher noch nicht angeschaut habe.

    Die Erstellung dauert übrigens seine Zeit, be patient … Kaffeepause …

  6. Nach dem das Azure Gateway erstellt wurde, brauchen wir das “lokale” Gegenstück, ein lokales Netzwerk Gateway, welches im Wesentlichen die externe IP des Routers repräsentiert, hier also die 38.210.102.188

    + / Netzwerk / Lokales Netzwerkgateway öffnet den Dialog zur Konfiguration

    image

    Das Netzwerk nennen wir SBSland-Azure-LN-Gateway, als öffentliche IP geben wir die externe IP des Routers ein und konfigurieren zusätzlich die IP-Subnetze welche wir lokal verwenden. In kleinen Umgebungen ist es nur eines, bei mir sind es zwei 192.168.2.0/24 und 192.168.12.0/24

    image

    Nachdem nun fast alle Ressourcen in Azure angelegt sind, fehlt noch die VPN-Verbindung und damit sind wir im ARM auch schon fertig.
    Noch ein Hinweis zu den lokalen Subnetzen, diese können natürlich im Anschluss noch erweitert werden, falls die lokale Infrasturktur zu wachsen beginnt

  7. Zum Einrichten der VPN-Verbindung wählen wir das erstellte Lokale Netzwerkgateway (SBSland-Azure-LN-Gateway) aus und klicken dort auf Verbindungen

    image

    Nach der Auswahl von Verbindungen erfolgt das Hinzufügen einer VPN-Verbindung durch + Hinzufügen rechts oben. Die Verbindung nennen wir SBSland-Azure-Local-VPN und fügen als Gateway für virtuelle Netzwerke das erstellte SBSland-Azure-AZ-Gateway hinzu und den selbst erstellten PSK-Key

    image

So, in Azure (ARM) sind wir nun erst einmal fertig, nun muss noch der Windows Server mit RRAS konfiguriert werden.

Konfiguration des Windows Servers (RRAS)

Die Installation von Routing und Remote Access erfolgt am einfachsten über PowerShell.

Install-WindowsFeature Routing -IncludeManagementTools

 

  1. Unter Routing and Remote Access / Network Interfaces fügen wir nun ein New Demand-dial Interface.. hinzu, damit das funktioniert muss der Server von Local area network (LAN) routing only auf LAN and demand-dial routing umgestellt werden.

    image

    Nun kann das neue Interface erstellt werden …

    image

    Das Demand-Dial Interface nennen wir SBSland-Local-Azure-VPN und wählen im Anschluss Connect using virutal private networking (VPN) aus

    image

  2. darauf hin als VPN Type , IKEv2 auswählen

    image

  3. In der Zusammenfassung des von uns konfigurierten Azure Gateways (SBSland-Azure-AZ-Gateway) finden wir die öffentliche Azure-IP-Adresse …

    image

    … die als Destination Address eingetragen wird

    image

    … und die Sicherheitseinstellungen belassen wir so, wie sie sind …

    image

    … und fügen eine statische Route (Static Route) in unser Azure Netzwerk (VM-Network-250) hinzu

    image

    Wenn mehr als ein Netzwerk in Azure vorhanden ist (das GatewaySubnet zählt nicht), dann hier entsprechend diese Netze ebenfalls hinzufügen.

  4. Den Dialog mit den Credentials zur Einwahl können wir dahingehend ignorieren, dass wir nur einen Benutzer eintragen (SBSland) was dem Wizard ausreicht …

    image

    … mit Finish schließen wir den Dialog und bestätigen die Konfiguration

  5. Damit die VPN-Verbindung funktioniert, muss nun die Verwendung von IKEv2 konfiguriert werden. Das erfolgt in den Eigenschaften des Interfaces unter der Option Security

    image

    Hier wird der gleiche PSK-Key eingetragen, wie schon oben bei der Konfiguration der Verbindung in Azure.

  6. Nun ist die Verbindung erstellt und wir können mit der rechten Maustaste eine Verbindung (Connect) initiieren.
  7. Das manuelle initiieren der Verbindung ist OK, aber nicht das was wir haben wollen, da immer nach einem Server-Neustart die Verbindung manuell getriggert werden muss. Daher ändern wir die Einstellungen der Verbindung wie folgt:
    Routing an Remote Access / <Servername> / Network Interfaces / SBSland-Local-Azure-VPN, rechte Maustaste und Properties / Options auswählen, hier den Haken bei Persistent Connection setzen

    image

    Damit baut der Server nach einem Neustart die Verbindng von selbst auf

Zurück in Azure

In Azure wählen wir nun das Gateway für virtuelle Netzwerke (SBSland-Azure-AZ-Gateway), mit dem Punkt Verbinden aus.

image

So, nun sind wir eigentlich fertig hier noch ein Bild mit den Objekten welche wir konfiguriert haben.

image

The End

Wenn wir aber nicht auf allen VMs im lokalen Netz eine Route nach Azure definieren wollen, ist es sinnvoll dem Router eine entsprechende Route hinzu zu fügen, um eine automatische Weiterleitung aller Paket in das Netzwerk 10.1.250.0/24 zu gewährleisten.

image

Damit sind wir nun wirklich fertig.

Enjoy it, b!

Ausführen von PowerShell über eine Batch

PowerShell Skripte oder CmdLets lassen sich auch über eine Batchdatei (.cmd / .bat) ausführen. Das geht recht einfach und sogar Parameter können mit angegeben werden. Es muss lediglich auf korrekte gesetzte Quoten (Anführungszeichen) geachtet werden.

:: Variables
set log="%temp%\Expand-Raw.log"

:: Header
echo Expand-Raw ...
echo Expand-Raw ... >%log%
echo.

for /f "tokens=*" %%a in ('dir RAW*.zip /b') do (

	rem  PowerShell -NoExit "&" ""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'"
	PowerShell ""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'"
	echo [RC=%ERRORLEVEL%], PowerShell -NoExit "&" ""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'" >>%log%

)

:_End

Schauen wir uns das PowerShell-Skript genauer an, dann sehen wir das insgesamt 4 Parameter übergeben werden:

  • -Action und die entsprechende Aktion, also –Action dis
  • -File und Dateiname, also –File ‘RAW 2017-01-08-01, Huskies auf der Alb.zip’

Der Aufruf unter PowerShell (also nicht über eine Batch sieht wie folgt aus):

.\Distribute-Pictures.ps1 -Action dis -File 'RAW 2017-01-08-01, Huskies auf der Alb.zip'

Die Batch Datei, welche nun drum herum abläuft, soll das PowerShell-Skript einfach mehrfach für eine Reihe von Dateien im gleichen Verzeichnis ausführen. Darum erfolgt ein Aufruf von PowerShell.exe mit dem Script und den Parametern aus der Batch heraus.

PowerShell ""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'"

PowerShell ruft die PowerShell.exe auf, danach wird der vollständige Aufruf für PowerShell in normale Anführungszeichen gesetzt.

""P:\Code\Distribute-Pictures.ps1" -Action dis -File '.\%%a'"

Innerhalb dieser Anführungszeichnen (“) steht dann das PowerShell-Script in weiteren Anführungszeichen, gefolgt von den Parametern. Der letzte Parameter, welcher den Dateinamen darstellt, wird in einfache Anführungszeichen (‘) gesetzt, da ihn PowerShell dann literal behandelt.

Enjoy it, b!

Lenovo L460 und Windows 10

Ich finde, dass Lenovo L460 hat ein recht gutes Preis-/Leistungsverhältnis und daher kommt es häufig bei meinen Kunden zum Einsatz. Mit einer Windows 7 / Windows 10 Lizenz ausgestattet, hat man die Wahl zwischen den beiden Betriebssystemen. Aktuell installiert Lenovo immer noch Windows 7 und damit ist man, wenn Windows 10 zum Einsatz kommen soll, vor die Wahl gestellt, entweder ein Upgrade zu machen oder eine Neuinstallation in Betracht zu ziehen. Ich glaube ich hatte schon geschrieben, dass ich kein großer Freund von Upgrades bin – zumindest wenn es nichts zu upgraden gibt. Sprich die Lenovo Apps bekommen wir hinterher problemlos wieder drauf.

Eine Neuinstallation läuft bei Lenovo vollkommen schmerzfrei ab:

  1. USB Stick mit Windows 10 einstecken
  2. PC einschalten und die ENTER-Taste (Return) drücken und im Anschluss mit F12 den Dialog für die Bootlaufwerke auswählen
  3. Den USB-Stick als Boot Device auswählen und alle vorhanden Partitionen löschen
  4. Windows 10 installieren und fertig
  5. Erst nach erfolgter Installation das LAN-Kabel einstecken oder sich mit dem WLAN verbinden, damit kann man während des Setups problemlos einen Admin-Acrrount anlegen
  6. Den USB-Stick lassen wir übrigens stecken, auch wenn die Windows Installation fertig ist

Ja, geht so einfach … und nach der Anmeldung einfach das Notebook eine Zeit lang (20min) mit einer Verbindung ins Internet stehen lassen. Bei geöffnetem Geräte-Manager, kann man WIndows 10 dabei zuschauen, wie es alle Treiber aus dem Internet über Windows Update herunter lädt. Danach sieht der Geräte-Manager wie folgt aus:

image

Nun installiere ich über Windows Update alle noch ausstehenden Updates und starte das System danach neu. Der HUAWEI GNSS Sensor lässt sich zu diesem Zeitpunkt noch mit keinem anderen Treiber versehen, bzw. meldet das die Treibersoftware auf dem neusten Stand ist.

image

Ab jetzt ist dann die Suche auf der Lenovo Homepage angesagt.

http://pcsupport.lenovo.com/de/de/

Die Lenovo Support Bridge benötigt das .Net Framework 3.5.1 welches üblicher Weise aus dem Internet geladen wird, was aber relativ lange dauert. Daher ist es sinnvoll das .Net Framework einfach davor zu installieren und zwar vom USB-Stick (Windows 10 Medium) mit dem folgenden Kommando:

Dism /online /enable-feature /featurename:NetFX3 /All /Source:D:\sources\sxs /LimitAccess

Deshalb haben wir ihn ja auch im Notebook stecken lassen Smile

image

Es reicht genau 1x auf Detect my Serial Number zu klicken, der Buton wird dann grau und im Hintergrund (nicht sichtbar) läuft der Download und wenn dieser erfolgt ist, einfach das Setup starten.

Danach erkennt die Support-Webseite das Lenovo Notebook und bietet uns nach erfolgter Installation des Lenovo System Updates die noch ausstehenden Treiber, Utilities und Anwendungen an. Wichtig dabei ist, dass generell der Internet-Explorer oder auch Google-Chrome verwendet werden, mit dem Edge-Browser steht der Scan-Dialog bei 10% … stunden lang!

Nach erfolgreichem Scan können nun die noch fehlenden Treiber, etc. installiert werden.

image

So, das war’s mal wieder, bis auf den Treiber für das HUAWEI Modem, diesen müssen wir explizit auswählen.

image

Nun sind wir aber wirklich fertig.

Enjoy it, b!

Neuinstallation Lenovo P50 Workstation

Lenovo liefert die P50 häufig mit einer Windows 7 / Windows 10 “Lizenz” aus, sprich der Kunde hat die Möglichkeit das Teil entweder mit Windows 7 oder mit Windows 10 zu betreiben. Da der Windows Lizenzkey im Notebook steckt genügt es Windows zu installieren und danach das Teil ins Internet zu verbinden. Die Aktivierung erfolgt dabei automatisch.

Für mich ungeschickt ist die Tatsache, das Windows 7 der Preload ist, soll also Windows 10 auf das Notebook, ist eine Neuinstallation angesagt (ok, Upgrade wäre möglich – aber da bin ich kein Freund von, zumal ohnehin noch keine Anwendungen mit Ausnahme der Lenovo Apps vorhanden sind).

Nachdem nun auf dem Teil eine Neuinstallation durchgeführt wurde, zeigt sich der Gerätemanager in einer erstaunlich kompletten Ansicht.

image

Lediglich die beiden Grafikkarten sind zwar installiert, können aber erst nach einem Neustart korrekt verwendet werden. Das ist schon mal spitze Smile

Nun müssen eigentlich nur noch die Lenovo Apps und Treiber (und davon nicht alle!) drauf. Hierzu bietet Lenovo neuerdings einen Service zur Erkennung des Gerätes an.

image

Nach einem Klick auf Detect my Serial Number, öffnet sich der Dialog zur Installation der Lenovo Service Bridge.Die Lenovo Service Bridge benötigt das .Net Framework 3.5.1 welches in diesem Zuge gleich mit installiert wird. Nach erfolgter Installation erscheint das Notebook auf der Support-Webseite von Lenovo mit dem entsprechenden Angeboten an Treiber und Hilfsprogrammen.

image

Nach der Auswahl von Treiber & Software, kann ein Start Scan erfolgen um alle notwendigen Updates zu identifizieren.

image

Im Rahmen des Scans wird das Lenovo System Update installiert, welches sich dann auch manuell aus dem Startmenü heraus starten lässt. Die Lenovo Service Bridge stellt lediglich eine Verbindung zwischen dem Notebook und dem darauf installiertem System Update und der Supportwebseite von Lenovo her.

image

Noch eine Anmerkung zur Verwendung des “richtigen” Browsers, in Edge blieb bei mir das System Update bei 10% stehen, im Internet Explorer hingegen lief es durch.

image

Damit wäre auch dieses Gerät mit Windows 10 installiert.

Enjoy it, b!

Installation von KB2919355 auf Windows Server 2012 R2 schlägt fehl …

Wenn sich das Update Windows8.1-KB2919355-x64.msu nicht auf einem Windows Server 2012 R2 installieren lässt, ist es sinnvoll die Anwesenheit von KB2919442 zu prüfen, welches die Voraussetzung für die Installation von KB2919355 ist.

image

Leider geht dieser Hinweis auf der Supportseite von Microsoft ein wenig unter, oder wird gerne mal überlesen. Mein Problem konkret war, dass der WSUS oder auch Microsoft Update mir dieses Paket NICHT angeboten hat und die Installation des KB2919355 fehl schlug, mit der Meldung das dieses Update nicht für mein System geeignet wäre.

Aber nun wissen wir ja wie es geht Smile

Enjoy it, b!

Windows 10 File History

Mit Windows 10 hat Microsoft die Möglichkeit eingeführt, Dateien im Hintergrund in die File History (Dateiversionsverlauf) zu sichern. Ich mag dieses Feature, zumal es mich selbst auch schon gerettet hat.

Ich nutze diese Funktion für alle Windows 10 Geräte bei mir im Haushalt und habe zu diesem Zweck einen File Share auf dem NAS oder auch auf einem Windows Server angelegt. Sind der PC oder das Notebook und der Server in der gleichen Domäne reicht es lediglich den Share (die Freigabe) entsprechend unter Windows 10 zu konfigurieren.

\\ncore.home.local\filehistory

Sind das Windows 10 Gerät und der Server (oder meistens das NAS) nicht in der gleichen Domäne, sondern in einer Arbeitsgruppe (Workgroup) ist darauf zu achten, dass die Anmeldung funktioniert. Am einfachsten geht das, wenn auf das NAS der gleiche Benutzer / Passwort verwendet wird.

In einem Windows in englischer Sprache ist diese Einstellung unter

Settings / Update & Security / Backup / Backup Up using File History / more Options zu finden.

analog dazu in einem Windows in deutscher Sprache:

Einstellungen / Update und SIcherheit / Sicherung / Mit Dateiversionsverlauf sichern / weitere Einstellungen

Dort muss vor der ersten Verwendung diese Funktion erst einmal eingeschaltet und dann der Share entsprechend hinterlegt werden, was dann am Ende so aussieht.

image

Diese Einstellung ist Benutzer bezogen, daher wird dort erst einmal für jeden Benutzer ein Verzeichnis eingerichtet und darunter wiederum für jedes Gerät auf dem die File History für den jeweiligen Benutzer aktiv ist ein weiterer Ordner. Was wie folgt aussieht.

image

Um den blauen Pfad kurz zu erläutern, hier die Syntax:

<UNC Pfad Server>\<Share mit der File Historie>\<Benutzername>\<Gerät>\Data\<Pfad ins Benutzerprofil>

Grün markiert sehen wir dann die Ordner des Profils, welche dann in der File History landen, und dort ist auch z.B. das OneDrive vorhanden womit (zumindest die Ordner welche für eine lokale Synchronisation ausgewählt wurden) auch ein Backup besitzen, welches lokal ist.

Zerschießt man also die lokale Ordnerstruktur seines OneDrives kann diese basierend auf der letzten in der File Historie vorhandenen Daten wieder hergestellt werden.

image image

Die wiederherstellte Ordnerstruktur, oder auch einzelne Dateien werden dann wieder über alle Geräte hinweg synchronisiert …. was abhängig von Menge und Bandbreite ein wenig dauern kann.

Die Standardkonfiguration sichert die Ordner im Benutzer Profil, es können aber auch noch zusätzliche Ordner hinzugefügt werden.

image

Was sinnvoll ist, wenn unter C:\Users\Public … irgendwelche Dokumente, etc. abgelegt werden.

Enjoy it, b!

Konvertierung von m4a Dateien nach mp3

Leider können nicht alle Car-Audio Systeme M4A-Dateien abspielen. Darum bin ich gelegentlich mit der Aufgabe konfrontiert M4A-Dateien nach MP3 zu konvertieren, was mit ffmpeg.exe und einem kleinen Script an der Eingabeaufforderung ohne große Probleme funktioniert.

Dazu habe ich den aktuellsten Windows-Build von ffmpeg herunter geladen und in ein Verzeichnis auf meinem Server (SBS) entpackt.

https://ffmpeg.zeranoe.com/builds/

Danach in das Verzeichnis mit den M4A-Dateien gewechselt und folgenden Aufruf ausgeführt:

for /f "tokens=1,2 delims=." %a in ('dir *.m4a /b') do \\sbs\xapps\ffmpeg\bin\ffmpeg.exe -i "%a.%b" -b:a 256K -vn "%a.mp3"
  • dir *.m4a /b liefert mir alle M4A-Dateien zurück
  • for /f …. zerlegt die Dateien in den eigentlichen Dateinamen und die Endung (welche nach der Konvertierung .mp3 sein soll)
  • ffmpeg.exe erstellt die entsprechende mp3 Datei mit einer Sampling-Rate von 256Kbit/s

That’s it … ging recht einfach Smile Die M4A-Dateien habe ich dann noch im Anschluss gelöscht.

Enjoy it, b!

Verknüpfung von Outlook.com mit Outlook 2013

Wird Outlook 2013 zum Abruf von Mails aus Outlook.com oder Outlook.de verwendet, kann es zu Problemen bei der Verknüpfung des Accounts kommen. Diese Mail haben wohl einige von uns erhalten …

image

… und auch versucht die im folgenden KB-Artikel empfohlene Vorgehensweise zum Verknüpfen von Outlook.com und Outlook 2013 versucht nach zu vollziehen.

Das hat bei mir leider nicht funktioniert, Outlook 2013 war nicht in der Lage heraus zu finden wie das Konto von Outlook.com konfiguriert werden sollte.

Die Lösung war die “Manuelle” Konfiguration in Outlook 2013 unter Auswahl der 2ten Option (Outlook.com or Exchange ActiveSync compatible service / Outlook.com oder Exchange ActiveSync kompatibler Service). Hier muss dann aber ein Mail-Server mit angegeben werden. Hier hat in meinem Fall immer die folgende Adresse funktioniert.

s.outlook.com

Alternativ kann auch der folgende Alias probiert werden.

m.hotmail.com

Damit war Outlook 2013 problemlos in der Lage das Outlook.de Konto zu konfigurieren.

Enjoy it, b!

NTDS Backup Error 1168 (1032)

Manche Fehler sind schon fieß! Auf einem Windows Server 2012 R2 DC (Windows Server 2012 R2 mit installierter Small Business Essential Rolle) hatte ein Kunde seit einiger Zeit den folgenden Fehler im Health Report des Servers.

image

Analog dazu die entsprechende Meldung im Ereignisprotokoll (der Health Report holt diese auch nur dort heraus).

image

Um diesen Fehler zu reparieren gibt es hinreichend viele Links, Artikel und Blogs im Web:

https://support.microsoft.com/de-de/kb/280364

https://social.technet.microsoft.com/Forums/windowsserver/en-US/1a0d9633-c497-4cab-bbff-053e2a056f6d/event-id-1168-active-directory?forum=winserverDS

Welche aber alle nicht funktionieren (zumindest in diesem Fall hat das nicht geklappt). Im Application Eventlog habe ich dann immer die folgenden Einträge gefunden…

image

… die auf ein Problem mit dem VSS Writer hindeuten.

image

Eine Abfrage der Registry ergab aber, dass die Einstellungen passen müssten.

C:\Temp>reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Para
meters

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
    Src Srv objectGuid    REG_BINARY    08E518AF5742FA48ACCAFDAD6F518DE4
    System Schema Version    REG_DWORD    0x45
    Root Domain    REG_SZ    DC=xxx,DC=local
    Configuration NC    REG_SZ    CN=Configuration,DC=xxx,DC=local
    Machine DN Name    REG_SZ    CN=NTDS Settings,CN=WP-SBS-1,CN=Servers,CN=Stan
dardname-des-ersten-Standorts,CN=Sites,CN=Configuration,DC=xxx,DC=local
    Src Root Domain Srv    REG_SZ    WP-SBS-2.xxx.local
    DsaOptions    REG_SZ    1
    IsClone    REG_DWORD    0x0
    ServiceDll    REG_EXPAND_SZ    %systemroot%\system32\ntdsa.dll
    DSA Working Directory    REG_SZ    C:\Windows\NTDS
    DSA Database file    REG_SZ    C:\Windows\NTDS\ntds.dit
    Database backup path    REG_SZ    C:\Windows\NTDS\dsadata.bak
    Database log files path    REG_SZ    C:\Windows\NTDS
    Hierarchy Table Recalculation interval (minutes)    REG_DWORD    0x2d0
    Database logging/recovery    REG_SZ    ON
    DS Drive Mappings    REG_MULTI_SZ    c:\=\\?\Volume{ca08668b-ea69-4e87-a59a-
c848a2f1fea5}\
    DSA Database Epoch    REG_DWORD    0x2ba5
    Strict Replication Consistency    REG_DWORD    0x1
    Schema Version    REG_DWORD    0x45
    ldapserverintegrity    REG_DWORD    0x1
    Global Catalog Promotion Complete    REG_DWORD    0x1

Das Volume für das DS Drive ist korrekt und die anderen Einträge stimmen auch, allerdings hatte der VSS Writer ein Problem …

c:\temp> vssadmin list writers
...

Writer name: 'NTDS'
   Writer Id: {b2014c9e-8711-4c5c-a5a9-3cf384484757}
   Writer Instance Id: {f86a8c78-c7e5-4f16-b1fd-09abd7eaff32}
   State: [11] Failed
   Last error: Non-retryable error

...

… das sich auch nicht durch einen Neustart beheben ließ. Daraufhin habe ich die VM auf dem Hyper-V Host exportiert und in meiner Testumgebung wieder importiert und gestartet … der Fehler war weg! Ein Vergleich der beiden Hosts / VMs ergab, dass auf dem Host welcher die VM mit dem Fehler bereit stellt die Hyper-V Replikation aktiv war. Per se, ist das kein Problem da auch im Testlab eine Replika am Laufen war – nur eben mit einer anderen Einstellung!

image image
Fehler 1168 im Eventlog vorhanden KEIN Fehler im Eventlog vorhanden

Nachdem auf dem produktiven Hyper-V Host die Replikation entsprechend angepasst wurde, war dort der Fehler verschwunden.

Enjoy it und noch ein gutes Neues Jahr 2017, b!

Routing auf einem Hyper-V Server 2016

Mit ein paar Handgriffen kann ein Hyper-V Server zum Routen von IP bewegt werden.

Ausgangslage

  • Server mit 2 Netzwerkkarten (172.16.16.253 und 192.168.120.1)
  • Fritz!BOX für den Internet-Zugang
  • Netzwerk an der Fritz!Box ist 172.16.19.0/24, das Gateway ist immer die 1 (also die Fritz!BOX selbst)

Der Server soll IP-Pakete vom Subnetz 192.168.120.0/24 ins 172er Netzwerk übertragen, und umgekehrt sollen Datenpakete aus dem 172er Netzwerk in das 192er Netzwerk geroutet werden. Alle Hosts im 172er Netzwerk haben die Fritz!BOX selbst als Gateway eingetragen. Daher muss dieser gesagt werden, wohin Pakete mit 192.168.120.0 geroutet werden sollen, nämlich auf die IP-Adresse 172.16.16.253 welches den ersten Adapter des Servers darstellt.

Konfiguration Fritz!BOX

Dazu wird folgende Route in der Fritz!BOX eingetragen:image

Die Konfiguration erfolgt über innerhalb der Fritz!BOX:

Heimnetz / Heimnetzübersicht / Netzwerkeinstellungen / Statische Routingtabelle

Konfiguration des Hyper-V Servers mit PowerShell

Auf dem Hyper-V Server sind die beiden Netzwerk-Adapter wie folgt konfiguriert:

Ethernet 2 172.16.16.253/24 Gateway 172.16.16.1
Ethernet 4 192.168.120.1/24 Gateway 192.168.120.1

Mit PowerShell ist die Konfiguration einfach.

Im ersten Schritt schauen wir uns an, ob und welche IP-Adressen schon vergeben sind.

PS C:\Temp> Get-NetIPAddress |ft

ifIndex IPAddress                                       PrefixLength PrefixOrigin SuffixOrigin AddressState PolicyStore
------- ---------                                       ------------ ------------ ------------ ------------ -----------
6       192.168.110.1                                             24 Manual       Manual       Preferred    ActiveStore
3       172.16.16.253                                             24 Manual       Manual       Preferred    ActiveStore
4       169.254.19.2                                              16 WellKnown    Link         Preferred    ActiveStore
1       127.0.0.1                                                  8 WellKnown    WellKnown    Preferred    ActiveStore

Wir sehen, der Adapter mit dem Interface-Index 3 (ifIndex) hat eine Adresse aus dem 172er Netzwerk. Der Adapter mit dem ifIndex 4 hat noch eine APIPA-Adresse aus dem 169er Netzwerk und soll nun die IP aus dem 192er Netzwerk bekommen.

Der Name des Adapters lässt sich übrigens mit Get-NetAdapter ermitteln

PS C:\Temp> Get-NetAdapter

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
Ethernet 2                Microsoft Hyper-V Network Adapter #2          3 Up           00-15-5D-10-DB-00         2 Gbps
Ethernet 3                Microsoft Hyper-V Network Adapter #3          6 Up           00-15-5D-10-DB-01        10 Gbps
Ethernet                  Microsoft Hyper-V Network Adapter             4 Up           00-15-5D-10-DB-02        10 Gbps

Nun konfigurieren wir mit PowerShell die IP-Adresse aus dem 192.168.120.0 Netzwerk.

PS C:\Temp> New-NetIPAddress -InterfaceIndex 4 -IPAddress 192.168.120.1 -PrefixLength 24 -DefaultGateway 192.168.120.1


IPAddress         : 192.168.120.1
InterfaceIndex    : 4
InterfaceAlias    : Ethernet
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Manual
SuffixOrigin      : Manual
AddressState      : Tentative
ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource      : False
PolicyStore       : ActiveStore

IPAddress         : 192.168.120.1
InterfaceIndex    : 4
InterfaceAlias    : Ethernet
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Manual
SuffixOrigin      : Manual
AddressState      : Invalid
ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource      : False
PolicyStore       : PersistentStore

Abschließend müssen wir noch die Weiterleitung von IP-Paketen aktivieren (IP-Forwarding).

PS C:\Temp> Set-NetIPInterface -InterfaceIndex 4 -Forwarding Enabled

Ich habe das auf einem relativ neuem Microsoft Hyper-V Server 2016 durchgeführt, sollte aber auch auf dem Hyper-V Server 2012 R2 und jedem anderen Windows Server funktionieren, welcher die PowerShell-Befehle unterstützt. Ansonsten ist Netsh.exe unser Freund.

Enjoy it, b!