Windows Server 2016 SBE und DFSR 4012

Zum Problem

Eine vor gut 2 Monaten stattgefundene Migration von SBE 2011 auf Windows Server 2016 SBE hat wohl zu Problemen bei der Replikation geführt. Zumindest meldete rund 71 Tage danach der Zielserver das er ein Problem mit der Replikation hätte.

image

Analog dazu sieht die Meldung im Eventlog wie folgt aus.

image

Nachdem nun bekannt ist, dass ein Problem existiert, sollten wir das auch lösen können, irgendwie halt 🙂

Ein paar Hintergrund Informationen

Typischer Weise hat eine Domain im Small Business Umfeld nur einen Domain Controller, so auch diese Domain. Darüber hinaus wird die Art der Sysvol-Replikation (FRS oder DFSR) durch die Migration bestimmt. FRS ist für Windows server 2016 als deprecated gekennzeichnet, wird also nicht mehr wirklich unterstützt und damit sollte spätestens nach einer Migration (besser davor) die Replikation auf DFSR umgestellt werden.

https://blog.friedlandreas.net/2014/12/sysvol-migration-von-frs-auf-dfsr/

Die Lösung

Die Lösung des Problems liegt darin, dass man einen “D4” auf dem Domain Controller machen muss.

https://blogs.technet.microsoft.com/janelewis/2006/09/18/d2-and-d4-what-is-it-for/

Ich habe dazu die folgenden Schritte durch geführt um das Problem zu lösen.

Aus der Expertem GUI (cmd.exe als Admin gestartet) starten wir die adsiedit.msc und arbeiten uns dort durch den folgenden Pfad zum CN=SYSVOL Subscription.

image

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

Dort öffnen wir den CN=SYSVOL Subscription mit einem Doppelklick (Grüner Kasten im Screenshot oben).

Hier finden wir die beiden Einträge msDFSR-Enabled und msDFSR-Options, welche wir von …

image

auf …

msDFSR-Enabled=FALSE
msDFSR-options=1

… ändern und hier bei der Änderung mit Apply und OK bestätigen. Da wir hier nur einen Domain Controller haben, brauchen wir hier keine weiteren Änderungen mehr in ADSIEDIT machen (es gibt ja keine weiteren DCs)!

Nur zur Vollständigkeit, läuft in der Domain (was auch bei Small Business Essentials) möglich wäre ein weiterer DC, dann müssen auf diesem die folgenden Einstellungen über ADSIEDIT gesetzt werden.

msDFSR-Enabled=FALSE

Danach starten wir die Active Directory Replikation, wieder aus unserem Experten GUI:

repadmin /syncall /AdeP

Im Eventlog finden wir danach die ID 4114, optional kann auf dem DC einfach den Service File Replication (FRS) bzw. DFS Replication (DFSR) neu gestartet werden.

image

Nochmals der Hinweis an dieser Stelle, FRS wird in Windows Server 2016 nicht mehr unterstützt und die Replikation sollte daher dringend auf DFSR umgestellt werden.

http://patrickvandenborn.blogspot.de/2017/06/windows-server-2016-frs-deprecated-how.html

Damit haben wir die Grundlage die Replikation wieder neu auf zu bauen. Dazu setzen wir wieder auf unseren (einzigen, und daher ersten DC) msDFSR-Enable auf True.

msDFSR-Enabled=TRUE

und erzwingen erneut eine AD-Replikation

repadmin /syncall /AdeP

Funktioniert dieser Call, dann meldet repadmin insgesamt 5x die Meldung SyncAll terminated with no errors.

image

Danach führe wir noch den Befehl DFSRDIAG mit der Option POLLAD aus.

DFSRDIAG POLLAD

Wenn alles gut geht, bekommen wir die Meldung Operation Successful zurück und dazu noch das Event 4602 im Eventlog.

image

So, jetzt haben wir unseren “D4” durch und alles ist wieder gut.

Enjoy it, b!

Windows 7 installiert nicht mehr alle Updates

Manchmal reicht es schon, wenn man sich ein Problem genau anschaut. Neulich hatte ich einen Windows 7 Client welcher partout keine Updates mehr installieren wollte. Der Versuch einzelne Updates zu installieren klappte, oder auch nicht und nach einer Installation wurde beim nächsten Neustart das System einfach wieder zurückgerollt.

Die Liste der zu installierenden Updates sah wie folgt aus:

image

Wenn wir uns die Liste genau anschauen, dann ist zu sehen das die Updates für das .Net Framework seit April ausstehen, Windows Updates hingegen (zumindest überwiegend) installiert wurden.

Mein erster Schritt in diesem Fall war eine Reparatur des .Net Frameworks, für die Microsoft das folgende Tool anbietet.

https://www.microsoft.com/en-us/download/details.aspx?id=30135

Nach der Reparatur konnten alle ausstehenden Updates ohne Probleme installiert werden,

Enjoy it, b!

Windows 10 Fall Creators Update 1709 und der Windows Server Essentials Connector …

… bekommt keine Verbindung mehr zum Server. Das passiert manchmal, also nicht bei jedem Upgrade. Eine Logik konnte ich dahinter noch nicht erkennen. Leider gibt es keinen Event dazu, sprich der Windows Client zeigt den Connector lediglich als Grau anstatt Grün an.

image

Aktuell gibt es für das Problem, keine Lösung außer dem Workaround einfach den Connector nochmals zu installieren, falls dieser nach dem Upgrade auf Build 1709 keine Verbindung mehr zum WSE bekommt.

http://wse/connect

Update: 2018-01-15

Im Rahmen der Installation des Build 1709 (Windows 10 Fall Creator Update 1709) und der anschließenden Installation des Januar 2018-01 Updates, habe ich festgestellt das der Connector bei allen neun PCs problemlos funktioniert hat. Möglicher Weise hat hier Microsoft Abhilfe geschaffen.

https://www.catalog.update.microsoft.com/Search.aspx?q=2018-01

Update 2: 2018-01-22

Im Blog von Susan Bradley habe ich den Hinweis gefunden, dass nach 3x Reboot der Connector ebenfalls wieder funktionieren sollte.

https://blogs.msmvps.com/bradley/2017/12/31/1709-and-essentials-2012-r2/

Enjoy it, b!

Hyper-V und der Saved-State einer VM

Neulich bekam ich eine VM auf einem Hyper-V Host (Windows Server 2012R2) in die Finger, welche sich aus dem Save-State partout nicht mehr starten lies.

image

Es erschien immer die folgende Fehlermeldung.

image

Nach ein wenig Social-Engineering, habe ich herausgefunden das am Wochenende ein BIOS-Update auf dem Hyper-V Host eingespielt wurde. BIOS Updates auf Servern können manchmal gravierende Änderungen mit sich bringen. Hier war es so, dass der Host gegenüber den Betriebssystem Veränderungen an der CPU bereitstellte und diese für alle gesicherten (Saved-State) VMs den Start verhinderten, die VMs welche hingegen sauber heruntergefahren wurden, starteten im Anschluss wieder ohne Probleme.

Daher, sollte mal das BIOS des Hyper-V Hosts aktualisiert werden, darauf achten das alle VMs sauber heruntergefahren wurden und sich nicht in einem Saved-State verharren. In diesem ist es nämlich nicht möglich, Änderungen an der Konfiguration der VM wie z.B. dem Prozessor Kompatibilitätsmodus einzustellen.

Natürlich, die Lösung …. war das Löschen des Saved-States!

image

Glücklicher Weise wurde die VM erst am Wochenende in diesen Zustand gebracht und so gingen keine noch nicht geschriebenen Daten verloren. Alternativ hätte man auch den Versuch unternehmen können, nochmals das alte BIOS (falls vorhanden) zu flashen, was ich mir aber vom Hersteller des Servers bestätigen lassen würde. Diese Vorgehensweise ist nämlich nicht immer supported.

Enjoy it, b!

Application ESENT 490 Error, Remote Desktop Gateway #2

In meinem vorherigen Blog hatte ich beschrieben wie sich der Fehler im Application Log 490 für den SQL Server beheben läßt. Nun hatte ich das gleiche Problem, allerdings mit dem SvcHost (6480).

svchost (6480) An attempt to open the file "C:\Windows\system32\LogFiles\Sum\Api.chk" for read / write access failed with system error 5 (0x00000005): "Access is denied. ".  The open file operation will fail with error -1032 (0xfffffbf8).

Im ersten Schritt ging es darum, zu analysieren welcher Prozess oder vielleicht auch Service sich hinter der PID 6480 versteckt. Dazu gibt es mehrere Möglichkeiten, die einfachste dürfte hier wohl der Process Explorer aus der Sysinternals Suite sein.

Einmal als Admin gestartet braucht man lediglich den Pen Prozess mit der ID 6480 suchen und bekommt in dessen Eigenschaften den eigentlichen Service Namen geliefert.

image

In diesem Fall ist es das Remote Desktop Gateway (tsgateway), welches wiederum die entsprechenden Berechtigungen auf den Sum Ordner benötigt.

image

"C:\Windows\System32\LogFiles\Sum"

Das Remote Desktop Gateway läuft unter dem Network Service, welcher damit auf den Ordner Sum entsprechend berechtigt werden muss (Modify sollte genügen).

image

Im Gegensatz zu einem Virtual Account finden wir den Network Service in der Domain, also im AD.

image

Am Ende sehen die Berechtigungen wie folgt aus …

image

… und auch dieser Fehler ist aus dem Application Log verschwunden.

Enjoy it, b!

Application ESENT 490 Error, SQL Server 2016

Auf einem Windows Server Essentials mit installierten SQL Server 2016 Express hatte ich im Eventlog den folgenden Fehler gefunden.

image

svchost (7204) An attempt to open the file "C:\Windows\system32\LogFiles\Sum\Api.log" for read / write access failed with system error 5 (0x00000005): "Access is denied. ".  The open file operation will fail with error -1032 (0xfffffbf8).

Der Microsoft KB-Artikel 2811556 beschreibt hier als Lösung, dass Hinzufügen des SQL Server Service Accounts (Dienstkonto unter dem der SQL Server läuft) mit entsprechenden Berechtigungen auf das Verzeichnis Sum.

"C:\Windows\System32\LogFiles\Sum"

Der Service Account ist in diesem Fall ein sogenannter Virtual Account (NT Service\MSSQLSERVER) welcher nicht im Active Directory, sondern in der lokalen Benutzer-Datenbank des Servers zu finden ist.

image

Um diesen Account hinzu fügen zu können, muss darauf geachtet werden, dass in der Location nicht die Domain, sondern der Name des Servers selbst ausgewählt wurde, dann kann im Feld weiter unten NT Service\MSSQLSERVER eingetragen werden, was automatisch in MSSQLSERVER expandiert wird.

image

Auf das Verzeichnis Sum habe ich dann Modify als Berechtigung vergeben und nach unten vererbt.

image

Im Anschluss war ein Start des SQL Servers ohne die Fehlermeldung möglich.

An dieser Stelle möchte ich noch Euch allen ein Gutes Neues Jahr wünschen!

Enjoy it, b!

Diskpart und das RO-Flag

Sollte für eine Disk in Windows das RO-Flag (Read-Only) Flag gesetzt haben, ist eine Einrichtung nicht möglich. Dazu muss das RO-Flag zurück gesetzt werden, was mit DISKPART einfach geht.

Zuerst schauen wir, ob die Disk auch unter DISKPART angezeigt wird (in diesem Fall ist es Disk 1)

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          256 GB  1024 KB
  Disk 1    Online          512GB   512 GB

Danach wählen wir die Disk aus:

DISKPART> select disk 1

Um mit dem folgenden Befehl das RO-Flag zurück zu setzen.

attributes disk clear readonly

So, fertig und eigentlich kein großes Ding.

Bildergebnis für Frohe Weihnachten