Quantcast
Channel: server – Andy's Blog
Viewing all 346 articles
Browse latest View live

Schnell und einfach einen USB-Stick für die Windows Server 2019-Installation erstellen

$
0
0

Im Netz finden sich einige Anleitungen wie man mehr oder weniger aufwendig einen bootfähigen USB-Stick für die Installation von Windows Server 2019 erstellen kann.

Die meiner Meinung nach einfachste Variante stellt allerdings der Einsatz von Rufus dar.

  • Das Tool herunterladen und ausführen.
  • Die ISO-Datei auswählen und auf „START“ klicken.

An den Voreinstellungen habe ich nichts verändert. Der so erzeugte Stick wird just in diesem Moment für die Installation von Thomas Krenn Microserver verwendet.


pfSense: Wiederherstellung auf Hyper-V

$
0
0

Bei einem Kunden ist (natürlich) über Nacht der VPN-Router, eine pfSense, ausgefallen. Damit möglichst schnell und ohne Vor-Ort-Einsatz das VPN wieder läuft, wurde kurzerhand auf dem vorhandenen Hyper-V auf Basis eines Windows Server 2012 R2 eine virtuelle Maschine eingerichet.

Das Vorgehen ist hier beschrieben, mit dem Unterschied das mittlerweile die nativen virtuellen Netzwerkkarten des Hyper-V unterstützt werden. Man braucht also nicht mehr die „Älteren Netzwerkkarten“ und das Skript. Ferner läuft die pfSense dort nur als VPN-Server. Virtuelle Computer der „Generation 2“ funktionieren allerdings immer noch nicht.

Soweit so gut, die Installation lief reibunglos durch, der virtuelle Computer startete anschließend ohne Schwierigkeiten und die Netzwerkkarten und IP-Adresse konnten zugewiesen sowie das Web-Interface erreicht werden.

Beim Einspielen der Datensicherung allerdings wurde schon gar nicht nach der Neuzuordnung der Interfaces gefragt und das System startete neu. Eigentlich ist der Vorgang beim Wiederherstellen auf abweichende Hardware wie hier beschrieben. Nun blieb der virtuelle Computer bei

Hypervisor: Origin = "Microsoft Hv"

hängen. Selbst nach mehreren Minuten tat sich nichts.

Also das Ganze leider reproduzierbar wiederholt. Daraufhin den virtuellen Computer nochmals neu installiert und der Reihe nach folgende Teile aus der Datensicherung wiederhergestellt:

  • OpenVPN
  • Firewall Rules
  • System

Damit waren die OpenVPN-Instanzen, die Firewall-Regeln und die Benutzer sowie weitere System-relevante Einstellungen wiederhergestellt, aber es fehlten die Zertifikate. Kurz recherchiert zeigte schnell, das deren Wiederherstellung nicht ganz so schnell und einfach möglich ist, siehe beispielsweise hier:

netgate – Backup/restore How to restore Certificates only

Aus diesem nennen wir’s mal halb-nutzbaren Zustand dann nochmals eine Wiederherstellung von „All“ durchgeführt und siehe da man wird nach dem Zuordnung der Interfaces gefragt. Beim anschließenden Neustart dauerte es zwar ebenfalls einen Moment bis

Hypervisor: Origin = "Microsoft Hv"

übersprungen war, aber es läuft.

Igel Thin Client: Bildschirm geht ständig an und aus

$
0
0

Seit kurzem zeigt sich bei einem Kunden das Phänomen, das die Displays ständig an und aus gehen, grob beschrieben wirkt das wie ein Flackern.

Geändert hat sich nichts, es wurden keine Updates, neue Firmware o.ä. eingespielt, auch die Konfiguration ist seit längerem die Gleiche. Vermutlich liegt’s an Bauteilalterung o.ä. Als Displays kommen LG 27MP55, diese sind bereits fünf Jahre alt, zum Einsatz. Diese sind per DVI-VGA-Adapter mittels VGA-Kabel verbunden. Ein Wechsel zu einem DVI-auf-HDMI-Kabel half direkt auf Anhieb nicht.

Eine Reduktion der Bildwiederholrate von 60 auf 56 Hz scheint aktuell das Problem zu lösen:

Mal sehen, ob’s dabei bleibt oder dann doch langsam ein Austausch der Geräte in Betracht gezogen wird.

Windows Server 2012 R2: WSUS auf einen anderen Server umziehen

$
0
0

Bei einem Kunden sollte eine bestehende WSUS-Installation auf einen anderen Server umgezogen werden. Da auf beiden Seiten, also Quell- sowie Zielserver, Windows Server 2012 R2 Standard ausgeführt wird lässt sich dies recht einfach bewerkstelligen.

Letztlich kommt im wesentlichen nur copy & paste zum Einsatz, denn es wird auf dem Zielserver die WSUS-Rolle installiert und so konfiguriert wie auf dem Quellserver und dann die Daten vom Quellserver kopiert. Nachfolgend die einzelnen Schritte:

  • Auf dem Zielserver die WSUS-Rolle installieren und identische zum Quellserver konfigurieren.
  • Nach der ersten Synchronisation folgende Dienste beenden:
    – Interne Windows-Datenbank (MSSQL$MICROSOFT##WID)
    – WSUS-Dienst (WsusService)
    – WWW-Publishingdienst (W3SVC)
  • Auf dem Quellserver die gleichen Dienste beenden.
  • Den Inhalt von „C:\WSUS“ vom Quell- auf den Zielserver kopieren.
  • Aus „C:\Windows\WID\Data“ die Dateien
    – SUSDB.mdf und
    – SUSDB_log.mdf
    auf den Zielserver kopieren.
  • Auf die Dateien und Ordner muss manuell die Berechtigung für das Dienstkonto „NT SERVICE\MSSQL$MICROSOFT##WID“ wiederhergetellt werden.
    In den Eigenschaften auf der Registerkarte „Sicherheit“ auf „Bearbeiten – Hinzufügen“ klicken,
    unter „Pfade“ den lokalen Server auswählen und
    im Feld „NT SERVICE\MSSQL$MICROSOFT##WID“ einfügen.
    Auf „Namen überprüfen“ klicken und mit „OK“ bestätigen.
  • Die Dienste auf dem Zielserver wieder starten und prüfen, ob man die WSUS-Konsole öffnen kann.
  • Die Client-Konfiguration (GPO, Registry) anpassen, so das Diese auf den Zielserver zeigt.

Windows: Hohe CPU-Auslastung durch WmiPrvSE.exe

$
0
0

Gleich auf mehreren unterschiedlichen Systemen fiel unangenehm auf, das diese sporadisch und mal mehr oder weniger lange Stocken. Ein Blick in den Task-Manager zeigte, das der Prozess „WmiPrvSE.exe“ sehr viel Leistung des Prozessor in Anspruch nimmt.

Workarounds für auf die Schnelle

Wenn nicht zeitnah geklärt werden kann was die Ursache ist, kann man den Prozess beenden, mitunter hilft das bereits. Als weiteres, damit die Störung nicht mehr ganz so gravierend ins Gewicht fällt, kann man die Priorität des Prozesses auf „Niedrig“ setzen. Zu guterletzt kann man den Dienst „Windows-Verwaltungsinstrumentation“ (Dienstname: Winmgmt) beenden und deaktivieren.

Fehler- bzw. Ursachensuche

Um der Quelle des Übels auf die Schliche zu kommen hilft ein Blick ins Ereignisprotokoll unter

Anwendungs- und Dienstprotokolle - Microsoft - Windows - WMI-Activity

In diesem Szenario findet sich beispielsweise folgendes:

Protokollname: Microsoft-Windows-WMI-Activity/Operational
Quelle:        Microsoft-Windows-WMI-Activity
Datum:         19.11.2019 07:42:20
Ereignis-ID:   5858
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      srv01
Beschreibung:
ID: {7F417761-7F2A-0003-0392-427F2A7FD501}; Clientcomputer: SRV01; Benutzer: NT-AUTORITÄT\SYSTEM; Clientprozess-ID: 1736; Komponente: Unknown; Vorgang: Start IWbemServices::ExecQuery - root\cimv2 : SELECT * FROM Win32_Process WHERE CommandLine='C:\Windows\sysWOW64\wbem\wmiprvse.exe -secured -Embedding'; Ergebniscode: 0x80041017; mögliche Ursache: Unknown

Im vorliegenden Fall finden sich pro Minute 20 solcher Meldungen und diese über den ganzen Tag verteilt. Ob das die Ursache für die hohe CPU-Auslastung ist, ist zumindest fraglich, da das Problem ja, so die Annahme, ganztätig vorhanden sein müssten und nicht nur sporadisch.

Mittels der „Clientprozess-ID“ kann man über den Task-Manager ermitteln um welchen Prozess es sich handelt. Hier ist es „PSANHost.exe“, dieser gehört zu Panda Adaptive Defense 360. Der Support ist informiert und wir warten auf Antwort.

Auf der Microsoft Support-Seite findet sich zusätzlich folgendes:

Hohe CPU-Auslastung durch WMIPRVSE.EXE-Prozess in regelmäßigen Abständen unter Windows

Mit Hilfe des dieses Befehls, ausgeführt in einer Eingabeaufforderung mit erhöhten Rechten, lassen sich weitere Informationen sammeln:

tasklist /m wmiperfclass.dll

Bislang hatten wir damit leider keinen Erfolg. Allerdings handelt es sich bei den uns bekannten betroffenen Systemn um Windows Server 2012 R2 Standard. Unbekannt scheinen solche Schwierigkeiten nicht zu sein, wie man beispielsweise im TechNet Forum nachlesen kann:

windows 2012 R2 wmiprvse.exe high CPU usage — URGENT

Windows Server: Beim Domänencontroller vor dem Herunterstufen prüfen, ob noch Zugriffe stattfinden

$
0
0

Bei einem Kunden muss ein betagter und zudem angeknackster Domänencontroller auf Basis von Windows Server 2012 R2 heruntergestuft werden. Weitere Domänencontroller existieren und die FSMO-Rollen wurden bereits vor mehreren Tagen verschoben.

Da dies der erste Domänencontroller in diesem Netzwerk war und zudem der Kunde selbst noch mehr oder weniger wahllos Systeme ans Netz bringt, war nicht ganz klar, ob nicht doch noch irgendein Gerät auf diesen Server zugreift.

Die via DHCP verteilten DNS-Server wurden bereits ebenfalls vor mehreren Tagen aktualisiert, so dass das Risiko relativ gering sein sollte, das noch irgendein Gerät ausgerechnet diesen Server kontaktiert.

Um auf Nummer sicher zu gehen wollte ich dennoch mal nachschauen, was denn noch so alles passiert.

LDAP-Zugriffe mit Ausnahme der anderen Domänencontroller konnten ausgeschlossen werden, da außer Active Directory sonst nichts beim Kunden LDAP verwendet. Die Freigaben waren bereits umgezogen, so das eigentlich nur noch DNS übrig blieb.

Bevor man nun groß das DNS-Logging aktiviert schien es mir einfacher, einen Tag lang SmartSniff laufen zu lassen. Um gezielt nur die DNS-Zugriffe zu sehen stellt man unter

Options - Capture Filter

folgendes ein:

include:both:udp:53

Startet man nun den Mitschnitt werden nur DNS-Abfragen, sowohl ein- als auch ausgehend, erfasst:

Links:

Microsoft Docs – DNS Logging and Diagnostics

Windows-Remotedesktopverbindung, Linux und Reiner SCT-Kartenleser

$
0
0

Beim Einsatz von Windows-Terminalservern oder auch bei Einzel-PCs die im RZ stehen ist es einfach möglich einen Smartcard-Leser wie die Geräte von Reiner SCT weiterzuleiten und somit beispielweise für Anmeldungen oder Online-Banking zu verwenden.

Aktuell wegen dem nahenden Lebensende von Windows 7 kommt teilweise zum Tragen, das ältere PCs die nicht Windows 10 kompatibel sind abgelöst oder uminstalliert werden sollen. In Terminalserverumgebung macht ein Wechsel zu Thin Clients Sinn. So unterstützt z.B. Igel die Kartenleser von Reiner SCT.

Hat man keinen kompatiblen Thin Cient zur Hand oder möchte man selbst (ältere) PCs auf Linux umstellen und dann als Terminalserver-Client verwenden, so geht dies natürlich auch. Der Hersteller unterstützt diverse Distributionen wie OpenSuse, SuSe, Ubuntu, Centos und Debian. Auf die jeweilige Version muss ggf. geachtet werden!

Am Beispiel von Debian 9 Stretch in Verbindung mit Remmina ist das Ganze sehr einfach:

  • Aus den Paketquellen „libifd-cyberjack6“ installieren, dabei handelt es sich um den notwendigen Treiber.
  • In Remmina die RDP-Verbindung bearbeiten, auf die Registerkarte „Erweitert“ wechseln, den Haken setzen bei „Smartcard teilen“ und die Änderung speichern.
  • Ab dem nächsten Verbindungsaufbau wird der Reiner SCT-Kartenleser in die RDP-Sitzung umgeleitet und kann dort verwendet werden.

Vmtl. funktioniert es auch mit Debian 10 Buster, in den dortigen Paketquellen ist das Paket ebenfalls enthalten.

Kommt kein Remmina zum Einsatz, so lässt sich via Befehl und FreeRDP ebenfalls der Kartenleser verwenden:

xfreerdp /v:<IP-oder-Hostname> /u:<Benutzername> /d:<Domäne-oder-Zielcomputername> /smartcard

Den Reiner SCT Gerätemanager scheint es indes leider nicht für Linux zu geben. Darüberhinaus ist zu Beachten, das es für dieses Konstrukt relativ wenig Support und Service gibt! Wer also eine dauerhaft funktionierende Lösung und Unterstützung im Fehlerfall benötigt ist mitunter mit entsprechenden Herstellern und Lösungen besser beraten.

OPNsense als OpenVPN-Server verwenden

$
0
0

Als Pendant zum Beitrag pfSense als OpenVPN-Server verwenden folgt nun die Variante für OPNsense.

Im Grunde ist die Handhabung die Gleiche, selbst die Umgebungen ähneln sich. Diesmal geht es allerdings um eine virtualisierte OPNsense-Installation auf einem Hyper-V Server auf Basis von Windows Server 2019 Standard.

Apropos Hyper-V: Als Generation 2 habe ich OPNsense nicht zum Laufen bekommen, daher bleibt’s bei Generation 1.

Die OPNsense in diesem Projekt soll lediglich als OpenVPN-Server dienen, d.h. sie ist nicht für den Internetzugang zuständig.

  • Man legt eine virtuelle Maschine an und weisst Dieser zwei virtuelle Netzwerkkarten zu.
  • Die erste Netzwerkkarte ist lediglich ein Dummy, also ein virtueller privater Switch, an dem nichts weiter außer die OPNsense mit ihrem WAN-Interface hängt. Bei der Installation der OPNsense richtet man das erste Interface als WAN ein und weisst diesem irgendeine IP-Adresse, z.B. 192.168.100.1, zu. Diese Maßnahme dient lediglich dazu, den Bootvorgang zu beschleunigen, damit das System nicht darauf wartet eine IP-Adresse via DHCP zu erhalten.
  • Die zweite Netzwerkkarte hängt man ins LAN.
  • Nach erfolgter Installation zunächst den Ersteinrichtungsassistenten durchlaufen lassen.

Nun folgt die Anpassung der Netzwerkkonfiguration, damit die OPNsense z.B. nach Updates suchen und die Zeit synchronisieren kann. Da sie direkt nach der Installation bzw. Einrichtung davon ausgeht, das über das WAN-Interface das Internet erreichbar ist, muss sowohl das Standard-Gateway als auch der abzufragende DNS-Server umgestellt werden:

Default-Route / Standard-Gateway ändern

Unter

System - Gateways - Single

den Eintrag „GW_WAN“ bearbeiten und die IP-Adresse des eigentlichen Routers eintragen.

Unter

Interfaces - LAN

bei „IPv4 Upstream Gateway“ von „Auto-detect“ auf „GW_WAN – <IP>“  wechseln.

DNS-Server ändern

Unter

System - Settings - General

bei „DNS servers“ den richtigen DNS-Server eintragen.

Nun sollte es möglich sein, die aktuellen Updates zu suchen und zu installieren. Falls es dennoch nicht funktioniert, dann mit Ping und DNS Lookup unter

Interfaces - Diagnostics

die Konnektivität prüfen.

OpenVPN-Server einrichten

Unter

VPN - OpenVPN - Server

kann mittels des Assistenten ein neuer OpenVPN-Server angelegt werden. Bei der Auswahl des Interfaces muss darauf geachtet werden, das statt „WAN“ „LAN“ ausgewählt wird.


DVBViewer Pro Client und Media Server

$
0
0

Zwei oder mehr DVBViewer Pro in Verbindung einem Media Server-Erweiterung (bei einem der Pros) bietet die bequeme Möglichkeit beispielsweise die Senderlisten zentral zu verwalten und das EPG nur einmal updaten zu lassen. Selbstverständlich funktioniert dann auch das Streamen über das Heimnetz und mehr.

In diesem Beitrag geht es um die Client-Anbindung, also wie man ein DVBViewer Pro an einen anderen DVBViewer Pro mit Media Server-Erweiterung anbindet. Vorausgesetzt wird, das die Server-Seite bereits läuft.

Zunächst installiert und aktiviert man DVBViewer Pro. Anschließend erfolgt die Konfiguration unter „Einstellungen – Optionen“:

Unter „Hardware“ auf „Geräte suchen“ klicken. Es sollte mindestens der Media Server und, sofern vorhanden, andere SAT>IP-Geräte gefunden werden. Sobald diese hinzugefügt sind,

Tipp: Um ggf. Schwierigkeiten mit geplanten Aufnahme am Media Server zu vermeiden, die SAT>IP-Geräte wieder entfernen.

Nun unter „DVBViewer Media Server“ den Haken setzen bei „Unterstützung für den DVBViewer Media Server aktivieren“. Anschließend bei „Media Server wählen“  den Server auswählen und bei „Adresse und Port“ die IP-Adresse samt Port eintragen.

Tipp: Die Haken setzen bei „EPG vom Server abrufen“, „Lokale Aufnahemliste ignorieren“, „Senderliste beim Start abrufen“ und „Senderlogos vom Server beziehen“.

Bemerkung: Ein Klick auf „Sender jetzt abrufen“ klappte bei mir nicht, nach einem Programmneustart waren die vorhandenen Sender vom Media Server synchronisiert.

Gut zu Wissen: In der Demo-Version wird der Media Server nicht unterstützt, ergo kann man die Funktionalität an dieser Stelle nicht testen.

Client per App steuern

Mit der lizenzierten Version klappt’s dann auch mit der Android-App DVBViewer Controller den Client zu steuern:

Windows: Fehler 4012 DFSR bei nur einem Domänencontroller

$
0
0

In einem Kunden-Netz mit nur einem Domänencontroller fanden sich im Ereignisprotokoll folgende Meldungen:

Protokollname: DFS Replication
Quelle: DFSR
Datum: 21.01.2020 13:04:27
Ereignis-ID: 4012
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: srv02.domain.local
Beschreibung:
Der DFS-Replikationsdienst hat die Replikation für den Ordner unter dem folgenden lokalen Pfad "C:\Windows\SYSVOL\domain" beendet. Dieser Server wurde von anderen Partnern für 63 Tage getrennt. Dadurch wird die im Parameter "MaxOfflineTimeInDays" zulässige Dauer überschritten (60). Aus diesem Grund geht der DFS-Replikationsdienst davon aus, dass diese Daten veraltet sind, und dieser Ordner wird vom Server erst nach Korrektur dieses Fehlers wieder repliziert. 

Verwenden Sie zum Fortsetzen der Replikation dieses Ordners das DFS-Verwaltungs-Snap-Ins zum Entfernen dieses Servers aus der Replikationsgruppe, und fügen Sie ihn dann der Gruppe erneut zu. Dadurch führt der Server einen ersten Synchronisierungstask aus, wodurch die veralteten Daten durch aktuelle Daten der Mitglieder der Replikationsgruppe ersetzt werden. 

Weitere Informationen: 
Fehler: 9061 (Der replizierte Ordner war zu lange offline.) 
Name des replizierten Ordners: SYSVOL Share 
ID des replizierten Ordners: <ID> 
Replikationsgruppenname: Domain System Volume 
ID der Replikationsgruppe: <ID> 
Mitglieds-ID: <ID>

Fakt ist vor ein paar Monaten gab es noch einen zweiten DC, dieser wurde ordentlich heruntergestuft und etwaige Reste entfernt, dennoch kam es zu diesem Fehler.

Der erste Suchmaschinen-Treffer gilt für Umgebungen mit mehr als einem Domänencontroller, der Zweite ist dann passender (Siehe Quellen). Hier nun meine Kurzfassung:

  • „adsiedit.msc“ öffnen und eine Verbindung herstellen (Details samt Screenshots siehe Quellen – John Lose…)
  • Zu
    DC=Domain/DC=TLD/OU=Domain Controllers/CN=ErsterDomänencontrollername/CN=DFSR-LocalSettings/CN=Domain System Volume/CN=SYSVOL Subscription

    wechseln und folgende Werte setzen bzw. ändern:

    msDFSR-Enabled=Falsch
    msDFSR-options=1

    Den „ADSI-Editor“ offen lassen (wird gegen Ende nochmal benötigt).

  • In einer Eingabeauffoderung mit erhöhten Rechten folgende Befehle ausführen:
    repadmin.exe /syncall
    dfsrdiag pollad

    Hinweis: Sollte der Befehl „dfsrdiag“ nicht gefunden werden, dann über den Server-Manager die „DFS-Replikation“ nachinstallieren.

  • Den Dienst „DFS-Replikation“ neu starten.
  • Im ADSI-Editor den Wert von „msDFSR-Enabled“ wieder auf „Wahr“ setzen.

Quellen:

John Lose – #DFSR, Fehler 4012 auf #SYSVOL DFS-Replikation in Windows Server 2012 / DC

Administrator.de – Ereignis ID 4012, DFSR – bei nur einem DC (Server 2012R2)

So wird aus einem altem Askozia 19″ Telephony Server ein HTPC

$
0
0

So langsam nahmen die Probleme mit unserem Intel DN2820FYK (NUC) als HTPC im Wohnzimmer immer mehr zu. Erst neulich die Sache mit dem WLAN, dann kamen jetzt noch häufiger Abstürze des Bluetooth-Stacks hinzu, was bedeutet in Folge kein Audio mehr und ein erzwungener Neustart und zuletzt noch Performance-Engpässe.

Klar, die Hardware war und ist nie besonders schnell gewesen, hat aber bis jetzt ausgereicht. Interessanterweise klappte mit dem DVBViewer soweit alles in Sachen Live-TV und aufgenommene Sendungen bzw. Filme anschauen. Hauptsächlich beim Streamen von Netflix und noch schlimmer von Amazon Prime gab es ständig Hänger und Aussetzer.

Bei der Beobachtung mit dem Task-Manager konnte man deutlich die CPU-Auslastung und eben die Spitzen passend zu den Aussetzern beobachten. Also musste etwas schnelleres her.

Da ich grundsätzlich für Wiederverwertung bzw. Wiederverwendung bin, kam an einem Samstag einem zugute, das man das eine oder andere ausgeschlachtete System im Keller liegen hat. So auch ein Mainboard eines ehemaligen Askozia 19″ Telephony Server. Dabei handelt es sich um ein MiTAC PD10BI, ein embedded Mini-ITX Board mit verlöteter passiv-gekühlter Intel Bay Trail-D J1900-(Celeron)-CPU, 2 GB RAM DDR3L SO-DIMM (2 Slots, max. 8 GB sind möglich).

Die damaligen SSDs der Askozia gab’s nicht mehr, daher kam erstmal eine gebrauchte 2.5″ 120 GB Samsung 840 EVO zum Einsatz. Das Netzteil wurde wegen Start-Schwierigkeiten entsorgt, stattdessen kommt ein 12 V / 3 A-Netzteil mit Hohlstecker zum Einsatz (das Mainboard bietet zwei Anschlussmöglichkeiten, 1x Onboard und 1x per Hohlstecker), dieses stammt ebenfalls aus dem Keller-Fundus von einem Wortmann Terra-Display.

Bluetooth und Infrarot für die Fernbedienung sowie WLAN, übrigens der gleiche Stick wie beim NUC, wurden per jeweilige USB-Adapter nachgerüstet. So ist es zwar auf der Rückseite gleich mal voll, dafür alles vorhandene Teile und läuft.

Schnell Windows 10 installiert und den DVBViewer umgezogen. Soweit, sogut. Netflix wird aktuell mit der entsprechenden App aus dem Microsoft Store geschaut, keine Probleme, tut wie es soll. Amazon Prime (Video) haben wir noch nicht getestet. Der DVBViewer läuft sowieso.

So sah’s provisorisch aus. Nicht hübsch, dafür selten:

Damit das Ganze wieder eher etwas für’s Auge ist, wurde kurzerhand ein günstiges Mini-ITX-Gehäuse bestellt. Die Wahl fiel auf ein M200, gekauft bei CarTFT. Darüber hinaus folgte noch eine mSATA-SSD von Transcend, diese wurde direkt auf das genannte Mainboard montiert und spart so Kabel und Platz. So sieht’s im Moment im Gehäuse aus:

Einschalten und Steuern per Fernbedienung

Um mehr Wohnzimmer-tauglichen Komfort (als zuvor) zu haben wurde zudem noch in Sachen Infrarot-Empfänger mit Einschaltmöglichkeit nach- bzw. umgerüstet. Details dazu in meinem Beitrag

HTPC per Fernbedienung einschalten und steuern

Troubleshooting

Na gut, ein wenig Troubleshooting gab es dann doch noch. Von Zeit zu Zeit setzte der Ton aus, dieser wird mittels Bluetooth übertragen. So richtig einen Reim darauf machen konnte ich nicht, scheinbar hat die Kombi aus folgenden beiden Maßnahmen geholfen:

Ursprünglich steckte der Bluetooth-Stick unterhalb des WLAN-Sticks. Das war etwas knapp. Nachdem ein USB-Anschluss nach dem Umrüsten auf den Atric IR-WakeupUSB eco frei geworden war, wurde der Bluetooth-Stick umgesteckt. Im Moment sieht die Verteilung auf der Rückseite so aus:

Als weitere Maßnahme, da ja auch diese „Kiste“ nicht so wahnsinnig leistungsfähig ist, bestand darin, den Windows 10-eigenen Virenschutz Defender nicht nur zu deaktiviereren, sondern auch dessen Dienste still zu legen:

Windows 10: Defender samt seiner Dienste deaktivieren

Fazit

Vorteil dieser Lösung, neben dem weitgehendem Wiederverwenden von vorhandenen Komponenten ist, das im Gegensatz zum NUC-Format nun eher mal das Innenleben ausgetauscht werden kann. Sollte das MiTAC-Board nicht mehr ausreichen, kann auf eine andere Kombi aus Mainboard und CPU zurückgegriffen werden.

Die Neuerung mit dem Einschalten per Fernbedienung ist zudem weitaus bequemer und die Bedienung insgesamt familienfreundlicher als zuvor.

DVBViewer Pro: Kein Bild im anderen Subnetz

$
0
0

Betreibt man den DVBViewer Pro als Client/Server im Netzwerk und hat zudem mehrere unterschiedliche Netze wie z.B. LAN und WLAN mit jeweils eigenen IP-Bereichen, so blickt man wortwörtlich ins Schwarze.

Während im LAN alles läuft, kann es im WLAN schon ganz anders aussehen. Man erhält zwar die ggf. die Kanalliste und das EPG vom Media Server, aber kein TV- bzw. Video-Bild. Die Sache ist einfach zu lösen und hängt schlicht an einer Firewall-Regel. In Windows muss die Regel „DVBViewer Pro LAN/WLAN“ geändert werden. Per Vorgabe lässt diese nur Zugriffe aus dem gleichem Subnetz zu. Entweder man fügt die weiteren Subnetze hinzu oder man ändert diese Regel dahingehend ab, das Zugriffe aus allen Subnetzen zugelassen sind:

Als weiteres sollte man prüfen, ob die Netzwerkkategorie stimmt.

WSUS: Computer wird nach Upgrade mit falschem Betriebssystem angezeigt

$
0
0

Wird ein Computer nach einem Upgrade, beispielsweise von Windows 7 auf Windows 10, im WSUS mit dem alten oder vorigen Betriebssystem angezeigt, liegt das meist daran, das bereits vorher oder spätestens nach dem Upgrade etwas mit der Registrierung am Update-Dienst nicht stimmt.

Die Lösung ist einfach und findet sich hier:

spiceworks – WSUS shows wrong Client OS

Einfach folgendes Skript auf dem betroffenen Computer als Administrator bzw. in einer Eingabeaufforderung mit erhöhten Rechten ausführen:

@echo off

net stop bits
net stop wuauserv
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f
rd /s /q "C:\WINDOWS\SoftwareDistribution"
net start bits
net start wuauserv
wuauclt /resetauthorization /detectnow
PowerShell.exe (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()

pause

Auf einem fehlerhaften Computer sah die Ausgabe so aus:

Intelligenter Hintergrundübertragungsdienst ist nicht gestartet.

Sie erhalten weitere Hilfe, wenn Sie NET HELPMSG 3521 eingeben.

Windows Update wird beendet.
Windows Update wurde erfolgreich beendet.

FEHLER: Der angegebene Registrierungsschlüssel bzw. Wert wurde nicht gefunden.
FEHLER: Der angegebene Registrierungsschlüssel bzw. Wert wurde nicht gefunden.
Der Vorgang wurde erfolgreich beendet.
Der Vorgang wurde erfolgreich beendet.
Intelligenter Hintergrundübertragungsdienst wird gestartet.
Intelligenter Hintergrundübertragungsdienst wurde erfolgreich gestartet.

Windows Update wird gestartet.
Windows Update wurde erfolgreich gestartet.

Drücken Sie eine beliebige Taste . . .

Wie man anhand der Fehler-Meldungen sieht, fehlten bereits die ersten beiden Registry-Werte.

Nachdem das Skript ausgeführt wurde, sollte der betroffene Computer relativ schnell richtig im WSUS angezeigt werden.

MDaemon: Liste der ActiveSync-Nutzer abrufen

$
0
0

Verwendet man beim MDaemon Messaging Server die ActiveSync-Erweiterung und existieren mehrere Anwender, die diese nutzen dürfen sowie etliche Anwender die dieses nicht nutzen (dürfen), so kann es schnell unübersichtlich werden.

In der MDaemon-Verwaltungskonsole kann man über

Einstellungen - ActiveSync - Benutzerverwaltung

auf einen Blick sehen, welche Benutzer zur Nutzung von ActiveSync berechtigt sind.

Interessant bzw. relevant ist an dieser Stelle der Haken bei

"Benutzerkonten beim ersten Zugriff über ActiveSync Berechtigung zur Nutzung erteilen"

Dieser ist ab Werk gesetzt, erlaubt allerdings mitunter nicht berechtigten Anwendern den Zugriff über dieses Protokoll. Wichtig ist das vor allem wenn man eine unterschiedliche Anzahl an MDaemon-Connector und ActiveSync-Lizenzen hat.

Benötigt man eine Liste der ActiveSync-Anwender beispielsweise zu Dokumentationszwecken, so lassen sich die aktuell berechtigten Nutzer in folgender Datei auslesen:

C:\MDaemon\Data\AirSyncUsers.dat

Windows Server 2016: Get-WindowsUpdateLog funktioniert nicht, wenn der Defender entfernt wurde

$
0
0

Sucht man Fehler im Bezug zu den Windows Updates hilft ein Blick ins Protokoll.

In früheren Windows-Versionen war dies eine einfache Text-Datei Namens „WindowsUpdate.log“ unter „C:\Windows“. Mittlerweile geht das nicht mehr ganz so einfach. Ein Protokoll kann man durch den Powershell-Befehl „Get-WindowsUpdateLog“ erzeugen lassen.

Zumindest unter Windows Server 2016 kommt es allerdings zu einem Fehler, wenn der Defender deinstalliert wurde:

C:\Users\Administrator>powershell Get-WindowsUpdateLog
Copy-Item : Der Pfad "C:\Program Files\Windows Defender\SymSrv.dll" kann nicht gefunden werden, da er nicht vorhanden
ist.
In C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:56 Zeichen:5
+ Copy-Item -Path $SYMSRV_DLL_PATH -Destination $WORKDIR -Force -Er ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\Program File...nder\SymSrv.dll:String) [Copy-Item], ItemNotFoundExce
ption
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.CopyItemCommand

Lösen lässt sich das, wenn man die Datei

C:\Windows\System32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1

editiert und die Zeile 56 auskommentiert:

# Copy-Item -Path $SYMSRV_DLL_PATH -Destination $WORKDIR -Force -ErrorAction Stop

denn die dortige Variable verweisst auf den Defender, siehe Zeile 21:

$SYMSRV_DLL_PATH = "$env:ProgramFiles\Windows Defender\SymSrv.dll"

Damit man die Änderung speichern kann, muss man den Besitz an der Datei übernehmen!


Windows: Mit VeloRAM oder VeloFull das System beschleunigen (oder auch nicht)

$
0
0

Freud und Leid liegen oft nah beieinander, wie dieser Test zeigt. Nun erstmal hübsch der Reihe nach.

Möchte oder muss man mehr Performance aus seinem System herausholen gibt es dazu gleich mehrere Möglichkeiten. Um beispielsweise den Zugriff auf den Speicherplatz in Form von HDD oder SSD zu beschleunigen bieten sich neben RAID, entsprechende Controller mit Cache und Software-definied-Storage (SDS) Lösungen wie Storage Spaces, StarWind VirtualSAN oder DataCore

Für Bestandssystems, Windows Client-Betriebssystems oder um beispielsweise nur eine Festplatte zu tunen sind diese allerdings zu viel des guten. Abhilfe können spezialisierte Cache-Programme bieten. Der Vorteil von diesen liegt im Idealfall darin, das diese günstig sind, keine spezielle Hardware und keine komplexe Administration benötigen.

Einer dieser Lösungen bzw. gleich eine ganze Palette bietet EliteBytes an. Von Vorteil ist eine übersichtliche Lizenzierung, die gestaffelt nach zu beschleunigten Volumes, max. Speicherplatz und maximaler Cache-Größe ist. Zudem handelt es sich um Lifetime-Lizenzen und die kleinste Staffelung beinhaltet gleich zwei Geräte, also z.B. PC und Notebook oder Host und virtuelle Maschine.

Die Homepage des Anbieters ist recht „Oldschool“ gehalten, man findet sich zurecht.

Baselining

Soviel zum Vorwort und wie es sein könnte. Schreitet man zur Tat gilt es erstmal Baselining zu betreiben. Also wie schnell sind denn die Bestandslaufwerke. Hier mal die Messungen mit CrystalDiskMark von einer 1 TB HDD und einer 240 GB SSD, damit man Vergleichswerte hat:

Nebenbei erwähnt: Das Testsystem ist ein frisch installierter Windows Server 2019 Standard auf einem Supermicro-Server. Es werden die Onboard-SATA-Schnittstellen verwendet (Intel, AHCI-Modus, kein RAID).

VeloRAM

Den Einstieg in die „Velo-Welt“ macht dabei VeloRAM, eine Software zum Anlegen eines L1 Cache im RAM, der das ausgewählte Laufwerk beschleunigt. Setup und Konfiguration sind einfach: Das Programm installieren, ggf. das System neustarten, das zu beschleuningte Volume bzw. Laufwerk auswählen, angeben wie groß der Cache sein soll und schon läufts:

Dann gleich mal gemessen und das Ganze sieht so aus:

Auch innerhalb einer VM unter Hyper-V läuft’s gut:

Aber dann…

Nach dem Entfernen des Caches und/oder (ja, bei beiden) der Deinstallation von VeloRAM benötigte der Host drei Neustarts um wieder erfolgreich hochzukommen. Die ersten Beiden scheiterten mit einem Bluescreen der Marke „DRIVER POWER STATE FAILURE“. Nicht schön.

Coming up next

Ganz den Vogel ähm das System abgeschossen hat dann VeloFull, die Kombi aus VeloRAM, VeloSSD bzw. MaxVeloSSD. Nach dessen Installation startete der Server nicht mehr, es endete immer an einem BSOD (Bluescreen), dessen Hintergrund es war, das die Treibersignatur nicht überprüft werden konnte. Ignoriert man das und startete das System ohne diese Prüfung lief es zwar, aber ein Dauerzustand kann und soll das nicht sein. Bei VeloRAM kam es übrigens zu keinem Problem bei der Treibersignaturprüfung.

Jedefalls wurde VeloFull deinstalliert und danach startete der Server überhaupt nicht mehr. Diesmal lautete die Bluescreen-Fehlermeldung „INACCESSIBLE BOOT DEVICE“. Alle Reparaturversuche scheiterten, zum Glück handelte es sich nur um ein Test-System. Einen unguten Eindruck hinterlässt das Ganze allerdings schon. Schade.

Grundsätzlich glaube ich an solche Lösungen und das es auch anders laufen kann beweissen neben den Eingangs erwähnten größen Lösungen Programme wie PrimoCache von Romex. Dazu ein andermal mehr.

MDaemon: ClamAV deaktivieren

$
0
0

Der Open Source Virenscanner ClamAV ist in jeder MDaemon Messaging Server-Installation, unabhängig vom SecurityPlus Addon, enthalten und per Voreinstellung aktiv.

Wer einen leistungsfähigeren Virenschutz beispielsweise in Form einer UTM oder anderer Security-Gateways vor dem MDaemon-Server betreibt oder der Mailserver in Sachen Arbeitsspeicher etwas schwach ausgestattet ist, der kann den ClamAV deaktivieren:

  • Die MDaemon-Verwaltungskonsole starten.
  • Zu „Sicherheit – AntiVirus“ wechseln.
  • Bei „AntiVirus – Virenprüfung“ in „Module für die Virenprüfung“ den Haken entfernen bei „Nachrichten mit Hilfe des Moduls ClamAV prüfen“.


Die Änderung greift ohne Neustart sofort, an Arbeitsspeicher wird ca. 1 GB freigegeben.

MDaemon: An Webmail per URL anmelden

$
0
0

Möchte man den Zugriff auf MDaemon’s Webmail bsplw. mittels Link, Einbettung, etc. von einem anderen Web-Portal aus Integrieren, bietet sich an, die Anmeldedaten (Benutzername, Passwort) in der URL mitzugeben.

Auf diese Weise entfällt ein ggf. mehrfaches Anmelden an verschiedenen Seiten. Die notwendigen Angaben beschreibt der Hersteller hier:

(FAQ) How can I pass logon details to WorldClient from another page?

Kurzum sieht die notwendige Adresse so aus:

https://<FQDN-oder-IP>/worldclient.dll?View=Main&User=<Benutzername>&Password=<Passwort>

Der Benutzername entspricht im Regelfall der E-Mail-Adresse, außer man hat etwas anderes konfiguriert.

Wie der Hersteller richtig zu bedenken gibt, sollte diese Art der Anmeldung nur an vertrauenswürdigen, nicht-öffentlichen Computern verwendet werden und ggf. nach deren Nutzung der Browserverlauf gelöscht und der Browser geschlossen werden.

Nextcloud: ONLYOFFICE mit integriertem Community Document Server nutzen

$
0
0

Eine wesentliche Neuerung in Nextcloud 18.x (Hub) ist die native Integration von ONLYOFFICE bzw. genauer ausgedrückt des Community Document Server.

Im Gegensatz zu früheren Versionen wird nicht zwingend ein eigener Server oder Docker-Container benötigt, was den Einstieg erheblich erleichtert.

Zu beachten neben dem höheren Ressourcenverbauch ist, das der Community Document Server nur für x86_64 Linux zur Verfügung steht. Damit ist es nicht möglich, die Kombi z.B. auf einem Raspberry Pi (ARM) zu nutzen.

Nachfolgend wird die Einrichtung auf einer bestehenden Nextcloud-Installation beschrieben. Bei Neuinstallationen sind die Apps bereits enthalten.

Da es zunächst Unklarheiten darüber gab, was man genau benötigt vorab eine kurze Aufklärung:

  • Die App ONLYOFFICE ist „nur“ ein Connector zum (Community) Document Server.
  • Der (Community) Document Server stellt die eigentliche Funktionalität dar.

Beides wird zwingend benötigt!

Installation

  • Zuerst installiert man unter „Administrator – Apps – Büro & Text“ den „Community Document Server“. Dieser bedarf keiner weiteren Konfiguration. Das Paket ist relativ umfangreich, je nach Performance des Servers und der Internetverbindung dauert die Einrichtung ein paar Minuten.
  • Als nächstes installiert man über „Administrator – Apps – Büro & Text“ dann „ONLYOFFICE“.

Konfiguration

Damit ONLYOFFICE genutzt werden kann muss ggf. noch eine kleine Konfiguration erfolgen. Die Einstellungen finden sich unter

Administrator - Einstellungen - ONLYOFFICE

Wird Nextcloud hinter einem Reverse Proxy verwendet müssen zwingend die Server-Adressen angepasst werden, andernfalls wird die IP-Adresse und ggf. ein nicht-vertrauenswürdiges oder gar kein Zertifikat verwendet, was zu Fehlern führt (von der Sicherheit ganz zu Schweigen).

Das Feld „Geheimer Schlüssel“ muss leer bleiben. Da sowohl ONLYOFFICE als auch der Community Document Server sich auf dem selben System befinden und letzterer nicht konfiguriert werden kann entfällt dies.

Das Feld „Serviceadresse der Dokumentbearbeitung für interne Anforderungen vom Server“ kann ebenfalls leer bleiben.

Nutzung

ONLYOFFICE zusammen mit dem Community Document Server steht direkt zur Verfügung. Möchte man beispielsweise eine *.odt-Datei ansehen oder ändern, kann diese direkt im Browser in der Nextcloud-Oberfläche angeklickt werden. Daraufhin öffnet sich ONYLOFFICE:

Anmerkungen

In der Voreinstellungen ist in ONLYOFFICE das automatische Speichern aktiv. Ferner ist das Wörterbuch „English (United States)“ ausgewählt. Änderungen an diesen beiden Punkten merkt das das System allem Anschein nach nicht unbedingt. Zu erstem kann helfen die Einstellungen unter „Datei – Erweiterte Einstellungen…“ zu ändern. Zum Wörterbuch kann helfen die Dokumentsprache („Statusleiste – Sprache des Dokuments festlegen“) zu ändern.

Über das Kontextmenü in „Dateien“ kann schnell eine *.odt- oder *.ods-Datei in das entsprechende Microsoft-Office-Format (*.docx, *.xlsx) umgewandelt werden:

Leider wird dies nicht auch in die anderen Richtung angeboten.

Quellen:

BITblokes – Nextcloud Hub (18) mit integriertem ONLYOFFICE ist verfügbar (theoretisch)

Nextcloud – OnlyOffice native in NextCloud 18 einbinden

Windows: Die SYSVOL-Replikation scheitert mit Verweis auf „FrsErrorMismatchedJournalId“

$
0
0

In einem Domänennetzwerk mit zwei DCs klappte die SYSVOL-Replikation auf einem der beiden Server nicht mehr.

Die entsprechende Ereignisprotokollmeldungen sehen so aus:

Protokollname: File Replication Service
Quelle:        NtFrs
Datum:         13.03.2020 07:08:20
Ereignis-ID:   13552
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      srv01.domain.local
Beschreibung:
Der Dateireplikationsdienst kann diesen Computer dem folgenden Replikatsatz nicht hinzufügen: 
    "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 
 
Mögliche Ursachen sind: 
  --  ein ungültiger Stammpfad, 
  --  ein fehlendes Verzeichnis, 
  --  ein fehlender Datenträger oder 
  --  ein Dateisystem auf dem Datenträger, das NTFS 5.0 nicht unterstützt. 
 
Die folgenden Informationen können bei der Problembehebung hilfreich sein: 
DNS-Name des Computers: "srv01.domain.local" 
Mitgliedname des Replikatsatzes: "SRV01" 
Stammpfad des Replikatsatzes: "c:\windows\sysvol\domain" 
Replikatstagingverzeichnis: "c:\windows\sysvol\staging\domain" 
Pfad des Replikatarbeitsverzeichnisses: "c:\windows\ntfrs\jet" 
Windows-Fehlerstatuscode: "" 
Fehlerstatuscode des Replikationsdienstes: "FrsErrorMismatchedJournalId" 

 

Protokollname: File Replication Service
Quelle:        NtFrs
Datum:         13.03.2020 07:08:20
Ereignis-ID:   13555
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      srv01.domain.local
Beschreibung:
Der Dateireplikationsdienst befindet sich im Fehlerzustand. Dateien werden nicht von oder zu einem oder allen Replikatsätzen auf diesem Computer repliziert, bevor nicht die folgenden Wiederherstellungsmaßnahmen durchgeführt wurden: 
 
 Wiederherstellungsmaßnahmen: 
 
 [1] Der Fehlerzustand löst sich möglicherweise von selbst, wenn der Dienst angehalten und neu gestartet wird. Führen Sie Folgendes an der Befehlszeile aus: 
 
    net stop ntfrs 
    net start ntfrs 
 
Falls dies nicht zum Erfolg führt, sollten Sie wie folgt fortfahren: 
 
 [2] Active Directory-Domänencontroller, die keine DFS-Alternativen oder andere Replikatsätze mit aktivierter Replikation hosten: 
 
Falls mindestens ein weiterer Domänencontroller in der Domäne vorhanden ist, dann stellen Sie den "Systemzustand" von dem Domänencontroller von dessen Sicherungskopie wieder her (unter Verwendung von "ntbackup" oder einem anderen Sicherungswiederherstellungs-Hilfsprogramm) und kennzeichnen Sie ihn nicht- autorisierend. 
 
Falls es keine weiteren Domänencontroller in der Domäne gibt, dann stellen Sie den "Systemzustand" von dem Domänencontroller von dessen Sicherungskopie wieder her (unter Verwendung von "ntbackup" oder einem anderen Sicherungs- wiederherstellungs-Hilfsprogramm) und wählen Sie die erweiterten Optionen, sodass die Systemvolumes als primär gekennzeichnet werden. 
 
Falls es andere Domänencontroller in dieser Domäne gibt, aber ALLE diese Nachricht im Ereignisprotokoll enthalten, dann müssen Sie einen von ihnen als primären Domänencontroller wiederherstellen (dessen Daten überall hin repliziert  werden) und alle anderen als nicht-autorisierend. 
 
 
 [3] Active Directory-Domänencontroller, die DFS-Alternativen oder andere Replikatsätze mit aktivierter Replikation hosten: 
 
 (3-a) Falls die DFS-Alternativen auf diesem Domänencontroller über keine anderen Replikationspartner verfügen, dann müssen Sie die Daten auf der DFS- Freigage an eine sichere Stelle kopieren.  
 (3-b) Falls dieser Server der einzige Active Directory-Domänencontroller in der Domäne ist, dann müssen Sie, bevor Sie mit (3-c) fortfahren, sicher- stellen, dass der Server keine eingehenden oder ausgehenden Verbindungen zu anderen, ehemaligen Domänencontrollern, die keine Netzwerkverbindung mehr haben (und nie wieder haben werden) oder die neu, ohne Heraufstufung installiert sind, aufweist. Verwenden Sie das Snap-In "Standorte und Dienste", um Verbindungen zu löschen, und suchen Sie nach 
Standorte->NAME_DES_STANDORTS->Server->NAME_DES_SERVERS-> NTDS-Einstellungen->VERBINDUNGEN. 
 (3-c) Stellen Sie den "Systemzustand" von dem Domänencontroller von der  Sicherungskopie (unter Verwendung von "ntbackup" oder einem anderen Sicherungs- wiederherstellungs-Hilfsprogramm) wieder her, und kennzeichnen Sie ihn als nicht- autorisierend. 
 (3-d) Kopieren Sie die Daten von (3-a) zurück in das ursprüngliche Verzeichnis, nachdem die Systemvolumefreigabe veröffentlicht worden ist. 
 
 
 [4] Andere Windows-Server: 
 
 (4-a)  Falls eine der von diesem Server gehostete DFS-Alternativen oder anderen Replikatsätze über keine anderen Replikationspartner verfügt, dann müssen Sie die Daten unter der Freigabe oder des Replikationsstrukturstammes an eine sichere Stelle kopieren. 
 (4-b)  net stop ntfrs 
 (4-c)  rd /s /q  c:\windows\ntfrs\jet 
 (4-d)  net start ntfrs 
 (4-e)  Kopieren Sie die Daten von (4-a) zurück in das ursprüngliche Ver- zeichnis, nachdem der Dienst gestartet wurde (warten Sie vorsichtshalber 5 Minuten). 
 
Hinweis: Falls diese Fehlermeldung im Ereignisprotokoll aller Mitglieder eines bestimmten Replikatsatzes angezeigt wird, dürfen Sie die Schritte (4-a) bis (4-e) nur auf einem der Mitglieder ausführen.

Dem Fehler vorausgegangen war ein nahezu volles Laufwerk C: (ca. 10 GB frei, nicht ganz so dramatisch), allerdings war der Server sehr träge und musste neu gestartet werden und eine Erweiterung der virtuellen Festplatte (damit wieder genug Platz vorhanden ist). Darüber hinaus fand chkdsk Fehler die behoben wurden und Defragmentiert wurde ebenfalls.

Die Lösung dieses Fehler auf dem betroffenen Server ist simple:

  • Den „Dateireplikationsdienst“ (Dienstname: Ntfrs, z.B. via „net stop ntfrs“) stoppen.
  • Via Regedit den Wert von
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup\BurFlag

    auf „D2“ setzen.

  • Den „Dateireplikationsdienst“ wieder starten.

Im Ereignisprotokoll die Meldungen beobachten. Die Replikation sollte wieder erfolgreich sein. Je nach Umfang kann es eine Weile dauern, bis das man entsprechende Einträge sieht.

Quellen:

Alant – Dateireplikationsdienst-Fehler

Microsoft Support – Ereignis-IDs 13552 und 13555 im Dateireplikationsdienst auf einem Windows-basierten Domänencontroller protokolliert

Viewing all 346 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>