Autostart Services Not Running / Shell Hardware Detection

Regelmäßig, nach einem Neustart “meiner” SBE 2012 R2 Server erscheint folgende Fehlermeldung im Health Report.

image

Der Shell Hardware Detection Service steht im Service Status: Stopped

Der Statup type des Services steht dagegen auf Automatic und damit muss der Service laufen. Das übliche Vorgehen den Service im Falle eines Fehlers einfach automatisch nochmals zu starten funktioniert interessanter Weise hier nicht.

image

Der Grund wieso dieser Service gestoppet wird ist nämlich kein Fehler sondern ein Verhalten, welches diesem Service immanent ist. Der Shell Hardware Detection Service wird nur ausgeführt, wenn ein Benutzer am Server direkt angemeldet ist (über die Console, oder über RDP). Daher tritt das Problem auch nur auf, wenn der Server nach einem Update neu gestartet wurde, bei einem laufenden Service und getrennter RDP Session bleibt er aktiv.

Nun stellt sich die Frage, wie man mit diesem Fehler am sinnvollsten umgeht – von Maßnahmen wie “diesen Fehler kann man ignorieren” halte ich nicht viel (auch wenn sie manchmal unumgänglich sind), es gibt keine guten und bösen Fehler – Fehler sind Fehler!

Der Health Report des SBE übernimmt diesen Fehler vom Server Manager, daher habe ich mich entschlossen die Überwachung dieses Services zu deaktivieren.

Dazu sind die folgenden Schritte notwendig:

Server Manager / Dashboard / Local Server / Services

image

Hier im Local Server – Services Detail View den Haken bei Shell Hardware Detection raus nehmen, damit wird die Anzeige des Status im Server Manager deaktiviert und es erfolgt auch keine Anzeige mehr im Health Report. Fehler des Services selbst werden auch weiterhin im Eventlog protokolliert.

image

Enjoy it, b!

WSUS und Windows 10

Damit der Windows Update Service Windows 10 Clients korrekt anzeigt, hat Microsoft ein Update mit den KB3095113 bereit gestellt. Damit lässt sich für den in Windows Server 2012 und auch R2 enthaltenen WSUS die Anzeige von Windows 10 Clients korrigieren. Ich habe in diesem Beitrag schon darüber geschrieben.

Leider gibt es für Windows Server 2008 R2 dieses Update nicht. Da aber Windows Server 2008 R2 die Grundlage des Windows Small Business Essentials Server 2011 ist, habe ich das Problem recherchiert und bin dabei auf folgendes SQL-Script gestoßen, welche die Korrektur für den WSUS 3.2 erledigt.

UPDATE [SUSDB].[dbo].[tbComputerTargetDetail]
SET [OSDescription] = 'Windows 10'
WHERE [OSMajorVersion] = '10'
AND [OSMinorVersion] = '0'
AND [OldProductType] = '1'
AND ([OSDescription] <> 'Windows 10' or [OSDescription] IS NULL)

Das Script kann über das SQL Server Management Studio als Query für die SUSDB ausgeführt werden.

image

Der auf dem Windows Server 2008 R2 betriebene WSUS hat die Version 3.2.7600.226 und damit das aktuellste Update des SP2 aus dem KB2938066. Dieses Update würde ich auf jeden Fall, falls nicht vorhanden, installieren.

Nach dem Ausführen des Scripts genügt ein Refresh in der WSUS MMC und die Clients werden korrekt dargestellt.

image

Enjoy it, b!

Windows 10 Upgrade in einer SBE Domain

Erfolgt ein Upgrade auf Windows 10 und ist der Client in einer Windows Server 2012 R2 Small Business Essentials Domain Mitglied, so gibt es ein paar Kleinigkeiten welche im Anschluss korrigiert werden müssen.

  1. Ist ein WSUS im Einsatz, dann erkennt dieser den Client als Windows Vista (und das wollen wir unserem Windows 10 ja gewiss nicht antun)

    image

  2. Der Connector funktioniert nicht mehr und im Dashboard des SBE erscheint der Windows 10 Client als Offline.

Punkt 1 wird über einen Hotfix für den WSUS auf Windows Server 2012 und R2 gelöst. Dazu existiert KB3095113 mit dem entsprechenden Hotfix.

image

Punkt 2 lässt sich durch die Installation des Connectors für Windows 10 lösen, dazu existiert KB2790621 mit dem entsprechenden Update. Nach der Installation des Connectors auf dem Windows 10 Client muss dieser konfiguriert und Windows 10 nochmals mit dem SBE verbunden werden, danach ist der PC wieder Online im SBE Dashboard dargestellt.

Darüber hinaus sollten die Gruppenrichtlinien für Windows 10 aktualisiert werden, was ich in diesem Blogbeitrag beschrieben habe und zum Abschluss ist noch eine Anpassung des WSE Group Policy WMI Filters sinnvoll, damit die Umleitung von Ordnern mit Windows 10 wieder korrekt funktioniert.

image

In diesem WMI Filter muss die Query (Abfrage) wie im Folgenden dargestellt geändert werden:

/* Alt (bis einschließlich Windows 8.1 */

select * from Win32_OperatingSystem where (Version >= "6.1%") and ProductType= "1"

/* Neu (bis einschließlich Windows 10 */

select * from Win32_OperatingSystem where Version like "10.%" or Version >="6.1"

Enjoy it, b!

Acer 8572G und Windows 10

Ich habe immer noch das Acer 8572G rum liegen, 8GB und Core i7 sind nicht schlecht und irgendwie möchte ich das Ding schon auf Windows 10 haben. Also habe ich mir das Teil nochmals angeschaut. Im BIOS des Rechners gibt es die Möglichkeit den Grafikadapter auf Switchable Graphics: [Discrete Mode] ein zu stellen (eigentlich für Linux und Windows XP!), damit wird die Intel Grafik deaktiviert und Windows 10 ist in der Lage einen NVIDIA GeForce GT 330M Chip zu erkennen und den richtigen Treiber zu laden.

image

Der in diesem Beitrag beschriebene Microsoft Basic Display Adapter ist nun nicht mehr vorhanden und es ist möglich auf die volle Beschleunigungsleistung des NVIDIA Chips zurück zu greifen! Allerdings nur bei einer Auflösung von 1366×768 Punkten, will man mehr – also die alte Auflösung von 1920×1080 muss man im NVIDIA Setup eine Benutzerspezifische Auflösung von 1920×1080/60Hz konfigurieren, welche zwar funktioniert, aber nicht die Schärfe und Klarheit der 1366 Punkte erziehlt.

image

Nach der Windows Installation sind noch zwei unbekannte Geräte im Device-Manager zu finden, eines läßt sich über Windows Update aktualisieren (Intel) und das zweite Gerät stellt den Fingerprint-Reader dar, welche problemlos mit dem Windows 7 Treiber läuft den Acer wenigstens zur Verfügung stellt.

Dazu gibt es auch einen inzwischen prähistorischen Blog (wer wollte eigentlich jemals Windows 8.1 auf dem Notebook haben … Winking smile )

https://sbsland.wordpress.com/2013/12/29/acer-travelmate-8572g-und-windows-8-1/

Enjoy it, b!

“Log on as a service” Trouble bei der Migration

Das Recht sich als Service an einem Domain Controller anmelden zu können, spielt eine wichtige Rolle bei der Migration auf den Windows Server 2012 R2 Small Business Essentials (SBE). Hier ist bei meiner letzten Migration irgendetwas schief gelaufen – die Berechtigung hier war nicht ausreichend gesetzt.

Zwar referenziert die Phase 1 der SBE Migration auf eine Löschunt der “Logon as a service” Einstellungen, aber explizit nur für eine Migration von Windows Server 2003!

image

Die Einstellung ist in der Default Domain Controller Policy unter Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Logon as a service zu finden und wird damit lediglich auf Domain Controller angewendet – was aber ein einer SBE Umgebung OK ist, wir haben in der Regel nur diesen einen Server. Auf Member-Servern in der Domain wird die Berechtigung in der lokalen Policy konfiguriert.

Ich habe diese Einstellung bei der letzten Migration nicht geändert … was zu folgenden Problem führte.

  1. Nach der Installation der Essentials Role muss ein Post-Deployment Task ausgeführt werden, welcher das Dashboard startet und damit den Wizard zur Einrichtung des SBE. Das ging erstmal schief und zu diesem Zeitpunkt dachte ich noch nicht an die fehlende Konfiguration der Logon as a service Richtlinie.
  2. Folgende Dienste (Services) wollten nach einem Reboot des Servers nicht mehr starten:
    1. Windows Server Essentials Media Streaming Service
      (Log on as: sbsland.local\MediaAdmin$)
    2. WSUS Service
    3. SQL Server (MSSQLSERVER)
      (Log on as: NT Service\MSSQLServer)

Fehler 1 – The Post-Deployment Configuration task may fail after you install the Windows Server Essentials Experience role on Windows Server 2012 R2

Fehler 1 ist inzwischen bei Microsoft in einem KB-Artikel KB2914651 dokumentiert. Hier fehlt den Accounts ServerAdmin$ und MediaAdmin$ das Recht sich als Service an zu melden (Logon as a service). Nachdem die beiden Accounts, wie im Artikel beschrieben in der Default Domain Controller Policy konfiguriert wurden und ein GPUPDATE das dem Server mitgeteilt hat, konnten der Post-Deployment Task zur Einrichtung des SBE ohne Fehlermeldung starten.

Fehler 2 – die oben genannten Services starten nicht (mehr)

Bis zum Zeitpunkt des Neustarts war der WSUS aktiv und hatte schon gute 2 Wochen lang die Clients mit Updates versorgt. Eine Kontrolle der Default Domain Controller Policy zeigte, dass der Service Account des SQL Servers (NT Service\MSSQLServer) ebenfalls nicht berechtigt war.

Der folgende Screenshot zeigt die korrekt berechtigten Service Accounts in der GPO:

image

Nach dem auch dieser Account eingetragen war, startete der SQL Server ohne Probleme und damit lief auch mein WSUS wieder, welcher diesen zur Ablage der SUSDB (WSUS Datenbank) verwendet.

Der Windows Server Essentials Media Streaming Service war zwar richtig berechtigt, stand aber, aus welchen Gründen auch immer, auf deaktiviert (disabled). Hier habe ich die Service Startart auf Automatisch (automatic) gestellt, danach lief auch dieser Service ohne Probleme.

Enjoy it, b!

Server hängt beim herunterfahren

Nach der Installation einer großen Anzahl von Updates wollten einige Server nicht mehr sauber herunter fahren, bzw. neu starten.

Gut 20min musste ich mir den folgenden Bildschirm anschauen.

image

Dabei habe ich mir die Frage gestellt – was tun? Gut, eine VM kann ich über das Hyper-V Management einfach ausschalten, einen Hyper-V Host oder anderen physikalischen Server kann ich über das ILO-Board ausschalten. Die Konsequenzen sind aber nicht immer absehbar.

Die Ursache des Problems war bei allen Systemen (3x virtuell und 1x Hyper-V Host), dass sich ein Services nicht korrekt beenden wollte.

Eine Abfrage der Services …

sc \\server queryex >c:\temp\process.txt

… welche remote noch möglich war lieferte folgendes Ergebnis.

SERVICE_NAME: TrkWks
DISPLAY_NAME: Distributed Link Tracking Client
        TYPE               : 20  WIN32_SHARE_PROCESS  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 12
        FLAGS              : 

SERVICE_NAME: TrustedInstaller
DISPLAY_NAME: Windows Modules Installer
        TYPE               : 10  WIN32_OWN_PROCESS  
        STATE              : 3  STOP_PENDING 
                                (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x2
        WAIT_HINT          : 0x36ee80
        PID                : 4124
        FLAGS              : 

SERVICE_NAME: UmRdpService
DISPLAY_NAME: Remote Desktop Services UserMode Port Redirector
        TYPE               : 20  WIN32_SHARE_PROCESS  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0

Da die Ausgabe in eine Textdatei erfolgte konnte ich hier einfach eine Suche durchführen und bin dabei mehrfach auf den TrustedInstaller Service gestoßen welcher mit STOP_PENDING das Herunterfahren, bzw. den Neustart des Servers verhinderte.

Ein Beenden des Prozesses mit taskkill half sofort und das Problem war gelöst.

taskkill /S server /PID 4124

Nach dem Neustart wurden nochmals wenige ausstehende Updates installiert und der Server läuft wieder ohne Probleme.

Auf einem Hyper-V Host hatte ich das gleiche Problem, hier wollte eine VM sich nicht beenden und nach über 1h Warten habe ich mich entschlossen den Prozess der VM zu beenden.

SERVICE_NAME: vds
DISPLAY_NAME: Virtual Disk
        TYPE               : 10  WIN32_OWN_PROCESS  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 1076
        FLAGS              : 

SERVICE_NAME: vmms
DISPLAY_NAME: Hyper-V Virtual Machine Management
        TYPE               : 10  WIN32_OWN_PROCESS  
        STATE              : 3  STOP_PENDING 
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_PRESHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0xdcb
        WAIT_HINT          : 0x7d0
        PID                : 1112
        FLAGS              : 

SERVICE_NAME: W32Time
DISPLAY_NAME: Windows Time
        TYPE               : 20  WIN32_SHARE_PROCESS  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 844
        FLAGS              : 

Das Beenden erfolgt wiederum über taskkill.exe und der entsprechenden Prozess-ID (1112).

Nach dem Neustart des Hyper-V Hosts hat lediglich die VM einen “unexpected shutdown” gemeldet, alle anderen VMs waren davon nicht betroffen.

Generell erscheint mir diese Vorgehensweise (auch bei Hyper-V Hosts) die deutlich sinnvollere als einfach den Server aus zu schalten. Ein Power-Reset betrifft gleich immer alle darauf laufenden Systeme was auch mal einige VMs beschädigen kann.

Enjoy it, b!

WISO EÜR & Kasse 2016 – msvcr120.dll

Es gibt Programme die haben immer mal wieder besondere Eigenarten an sich. Die Produkte von Buhl gehören dazu. Nachdem sich WISO EüR & Kasse 2016 problemlos installieren ließ wurde ich mit folgender Meldung beim Programmstart begrüßt.

image

Das Fehlen der msvcr120.dll, bzw. der msvcrXXX.dll deutet meistens darauf hin, dass die Runtime auf dem System nicht vorhanden ist. Bei mir handelt es sich um Windows 10, welches diese Runtime eigentlich von Haus an Bord hat. Eine Suche nach der DLL lieferte multiple Ergebnisse.

How ever – die Lösung des Problems lag in der Installation der Visual Studio 2013 Runtime, in der x86 Version (das Programm ist x86 und dafür brauchen wir die richtige DLL – das OS ist x64). Danach war ein Programmstart ohne Probleme möglich.

image

Enjoy it, b!

Troubleshooting Azure Backup

Dieser Beitrag behandelt gleich zwei Probleme welche ich mit dem Azure Backup Client auf Windows Server 2008 R2 hatte.

„Unable to execute the embedded application“ …

… error when you try to install the Microsoft Azure backup agent

Dafür liefert Microsoft sogar einen KB, wichtig ist hier das genau die im Artikel referenzierte VC Komponente verwendet wird und nicht etwa ein Update davon.

https://support.microsoft.com/en-us/kb/2934202

Danach klappt’s auch hier mit dem Backup. Interessanter ist jedoch das folgende Problem – und dessen Lösung.

ID: 100050 – Verbindung zu Microsoft Azure Backup

Nach der Installation des Azure Backup Clients ist unter Verwendung korrekter Tresoranmelde-Daten (Vault Credentials) keine Verbindung zu Azure Backup möglich. Die Netzwerkeinstellungen sind aber OK, der Server ist mit dem Internet verbunden!

image

Wenn die obigen Vorraussetzungen zutreffen, sollten einmal die Internet-Einstellungen des System-Accounts geprüft werden! Der Azure Backup Service läuft nämlich unter Local System und hat damit eigene Proxy-Einstellungen, welche möglicher Weise verändert wurden:

image

An diese gelangt man durch einen Aufruf des Internet Explorers durch psexec im Kontext von Local System.

psexec -i -s "C:\Program Files\Internet Explorer\iexplore.exe"

In dem nun gestartetem Internet Explorer kommt man über Extras / Internet Optionen / Verbindungen / LAN-Einstellungen zum Proxyserver welcher in diesem Fall konfiguriert war!

image

Hier alle Einstellungen raus nehmen und schon klappt es mit der Registrierung des Servers.

Update:
Optional kann man auch die Liste erweitern für die kein Proxyserver verwendet wird.

image

Hierzu die folgenden Einträge hinzufügen:

https://*.windows.net;https://*.windowsazure.com

Enjoy it, b!