CAPI2 Fehler während VSS Backup

Seit geraumer Zeit sichere ich unsere wichtigsten Daten - nebst doppelter Datenhaltung Vorort - mittels Livedrive  in die Cloud. Die zugehörige Software besteht aus einem Desktop-Programm und dem "Livedrive VSS Service". Seit einiger Zeit tauchten bei jedem Backup im Eventlog Einträge folgender Art auf:

20151128_capi2.jpg

 

Die darauf folgende Google-Recherche brachte folgendes als Ursache zum Vorschein:

During backup a VSS process running under NETWORK_SERVICE account calls cryptcatsvc!CSystemWriter::AddLegacyDriverFiles(), which enumerates all the drivers records in Service Control Manager database and tries opening each one of them. , The function fails on MSLLDP record with "Access Denied" error.

Turned out it fails because MSLLDP driver's security permissions do not allow NETWORK_SERVICE to access the driver record.

In meinem Fall ging es zwar nicht um den Account "NETWORK_SERVICE", aber das Problem war ansonsten identisch. Wer sich den Security Descriptor ansehen will, kann dies mit dem Sysinternals-Tool AccessChk bewerkstelligen und somit leicht feststellen, welcher Eintrag im Security Descriptor fehlt oder falsch ist (sprich der jeweilige Service Account unter dem das Service läuft).

accesschk.exe -c mslldp

Mittels System-Tool "sc" kann der Security Descriptor vom MSLLDP Treiber neu geschrieben werden (Achtung: der unten angegebene String muss nicht für jeden Fall ident sein, also vorsicht damit, eventuell den original Security Descriptor vorher sichern mittels "SC sdshow MSLLDP"):

sc sdset MSLLDP D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)

Schaut wild aus, ist es auch ;-).

Wenn es geklappt hat sollte "sc" wie im Screenshot ersichtlich mit "[SC] SetServiceObjectSecurity SUCCESS" reagieren:

20151128_mslldp-sc.jpg

AccessChk liefert nun folgendes:

C:\WINDOWS\system32>accesschk.exe -c mslldp

Accesschk v6.0 - Reports effective permissions for securable objects
Copyright (C) 2006-2015 Mark Russinovich
Sysinternals - www.sysinternals.com

mslldp
RW NT AUTHORITY\SYSTEM
RW BUILTIN\Administrators
RW S-1-5-32-549
R NT SERVICE\NlaSvc
R NT AUTHORITY\SERVICE

Inzwischen ist bereits ein weiteres Backup gelaufen und es wurde kein neues CAPI2 Event erzeugt.

(RaiZl)

Curl testet Microsoft Exchange

Wer Microsoft Exchange betreiben muss, sieht sich schnell mit der Frage konfrontiert, wie man selbiges überwachen kann, ohne Unsummen von Geld in die Hand nehmen zu müssen. Im Windows-Umfeld gibt es unzählige Möglichkeiten, will man das von Linux aus bewerkstelligen, muss man mittels curl nur die entsprechenden Requests absetzen.

ActiveSync

curl -v -k -u domain\\username:password -H "Host:your.fully.qualified.hostname" --request OPTIONS https://ipaddress/Microsoft-Server-ActiveSync
20151021_curl_activesync.JPG Der retournierte Antwort-String auf den OPTIONS-Befehl muss wie im Screenshot  aussehen (siehe Markierung). Kommt eine davon abweichende Antwort ist davon auszugehen dass ein Problem vorliegt.

Outlook Anywhere (RPC over HTTP)

curl -v -k --request RPC_IN_DATA -A MSRPC -u domain\\username:password -H "Host:your.fully.qualified.hostname" http://ipaddress/rpc/rpcproxy.dll?your.fully.qualified.hostname:6001
20151021_curl_outlookanywhere.JPG In diesem Fall kann auf die Antwort "200 Success" geprüft werden, liefert der Server ein andere Code/Return-String Kombination, dann liegt vermutlich ein Fehler vor.

Outlook Web App

curl -v -k -u domain\\username:password -H "Host:your.fully.qualified.hostname" http://ipaddress/owa/auth/logon.aspx?url=https://your.fully.qualified.hostname/owa/&reason=0
20151021_curl_outlookanywhere.JPG In diesem Fall kann auf die Antwort SetCookie "OutlookSession=" geprüft werden. Kommt vom Exchange Server eine andere Meldung retour, sprich es kann keine Outlook Session gestartet werden, dann liegt ein Fehler vor.

Die oben angeführten Curl-Statements können relativ einfach in Scripts eingebaut werden, die im Fehlerfall entsprechend Alarm schlagen (e-Mail, etc.).

(RaiZl)

Exchange Server 2016 Koexistenz

Anfang Oktober hat Microsoft die neueste Version von Exchange Server veröffentlicht (Released To Manufacturing). On-premises Installationen sind nach wie vor möglich (dass es  Exchange irgendwann nur mehr in der Cloud geben soll kann und will ich nicht glauben). Als Betriebssystem ist aktuell nur Windows Server 2012 R2 unterstützt. Die Active Directory Domain muss mindestens auf Windows Server 2008 R2 laufen.

Eines der ersten Themen mit dem man sich auseinander setzen muss, wenn es um den Einsatz neuer Exchange Versionen geht, ist die Koexistent mit der/den Vorgänger-Versionen(en). Im Zuge der Migration wird ein neues System eingerichtet und die Funktionen und Daten nach und nach von alt nach neu übersiedelt.

Folgende Exchange Versionen können mit Exchange 2016 im Zuge einer Migration ko-existieren:

  • Exchange 2010 SP3 Update Rollup 11
  • Exchange 2013 Cululative Update 11

Beide der o.a. Versionen sind bis dato noch nicht veröffentlicht worden, daher ist vorerst eine Migration noch nicht möglich.

Wer eine High Availibility Installation im Einsatz hat (Database Availibility Group) sollte besonders vorsichtig sein: Mit Exchange 2016 RTM ist es möglich, DAGs mit gemischten Exchange Versionen zu erstellen (sowohl übers GUI, als auch über die Powershell). Dieses Szenario ist aber absolut un-supported und würde in weiterer Folge vermutlich zu wilden Fehlern führen! Ein Bug, der in einer RTM-Version definitiv nicht enthalten sein sollte!

(RaiZl)

RDP und Copy und Paste

Sollte einmal im RDP Copy/Paste von/zum remote Computer nicht funktionieren, dann im Taskmanager prüfen ob ein Prozess "rdpclip.exe" (im Kontext des angemeldeten Users) vorhanden ist. Wenn dem nicht der Fall ist, wird Copy/Paste auch nicht funktionieren. Dann am remote Computer einfach Start/Ausführen und dort rdpclip.exe und Return und alles wird gut :-)

(RaiZl)

Windows 8 Language Packs installieren

Dieser Blog-Eintrag ist quasi als Notiz an mich selbst zu verstehen. Ich suche immer verzweifelt wie man unter Windows 8/8.1 Enterpise ein Language Pack installiert. Daher habe ich es jetzt einmal schriftlich festgehalten.

Auf folgender Website findet man eine Liste von Direktlinks zu den gängigsten Sprachpaketen: http://winaero.com/blog/download-official-mui-language-packs-for-windows-8-1-windows-8-and-windows-7/ für Windows 7 und Windows 8 bzw. Windows 8.1. Oder Google befragen, die wissen in der Regel auch wo die Language Packs zu finden sind ;-).

Das gewünschte Paket herunter laden (die haben so sprechende namen wie "lp_8fa033dd9ab61a528192eaa696088d582f112e68.cab"). Danach das Language Pack Setup (via "lpksetup.exe") starten:

Language Pack Setup starten

Setup Wizard

Mit dem Wizard dann einfach das vorher herunter geladene CAB-File installieren und alles wird gut.Folgende Anmerkung sei mir noch gestattet: falls ich das nächste Mal wieder suche wie ich zu dem Wizard komme, dann hab ich vermutlich vergessen, dass ich dazu einen Blog-Eintrag erstellt habe... ;-)

(RaiZl)