Windows Store-Apps gehen nicht auf, Ereignis 5973 im Eventlog

Problem

Auf einem Windows 8/8.1/10 öffnen sich nicht (mehr) alle Windows Store Apps. Zudem wird (in etwa) dieser Fehler im Eventlog („Anwendung“) protokolliert:

Quelle: Microsoft-Windows-Power-Shell  (Oder unter Windows 10: Apps)
Ereignis-ID: 5973
Aufgabenkategorie: (5973)
Ebene: Fehler
Beschreibung
Fehler bei der Aktivierung der app AppID : Diese Anwendung unterstützt den angegebenen Vertrag nicht oder ist nicht installiert.
Weitere Informationen finden Sie im Protokoll „Microsoft-Windows-TWinUI/Betriebsbereit“.

Lösung

Spontanes Herunterfahren kann den Appcache in C:\Users\ < Benutzername > \AppData\Local\Packages beschädigen. Meistens hilft es, ein neues Benutzerkonto zu estellen und alle Daten zu migrieren. Den doofen Appcache kann man (unseres Wissens nach) leider nicht leeren ohne ihn zu zerstören.

  1. Neues Benutzerkonto (1) anlegen
  2. Neues Benutzerkonto (2) anlegen
  3. Windows NEU STARTEN (!) und mit (1) anmelden.
  4. Windows NEU STARTEN (!) und mit (2) anmelden.
  5. Alle Dateien aus dem alten (kaputten) Profilverzeichnis in das neue (1) kopieren (ausser NTUser.*)
  6. Neu starten und mit (1) anmelden und testen.

Meistens klappt dann schon wieder alles. Eventuell fehlen ein paar Einstellungen und Registry-Kram, aber die apps klappen wieder.

Windows Server 2012/2012R2 Windows Internal Database (WID) mit dem SQL Management Studio nutzen

Die Windows Internal Database (WID) ist ein ganz normaler SQL-Server (Express Edition), der sehr verschlossen konfiguriert ist. In der Regel benötigt man auch keinen direkten Zugriff darauf, außer es treten Fehler wie zum Beispiel der WSUS „Serverknoten zurücksetzen“ Effekt auf.

Es auch weiterhin möglich, sich mit dem SQL Management Studio (ab SMSS 2012 aufwärts) oder einer anderen SQL-Konsole der Wahl mit der WID-Instanz zu verbinden. Es gibt keinen TCP/IP listern mehr, daher man muß sich auf die entsprechende WID-Instanz mit dem passenden Memory-Pipe Verbindungsalias (Connection String) verbinden.

Die aktuellen Connectionstrings für WID

  • Windows Server 2008 und höher
    \\.\pipe\mssql$Microsoft##SSEE\sql\query
  • Windows Server 2012 und höher
    \\.\pipe\Microsoft##WID\tsql\query

Diesen KB Titel einmal genau lesen … das erklärt einiges


„A list of Microsoft Knowledge Base articles is available to help troubleshoot error messages that you may receive when you upgrade from Windows Vista to Windows“

Übersetzungsfehler, Tippfehler oder Absicht. Mehr Ursachen können wir uns für diesen schönen Satz kaum vorstellen 🙂

vSphere Webclient „Erste Schritte“ ausblenden

Der „Erste Schritte“ Tab im vSphere Webclient nimmt unglaublich viel Platz und Performance. Hilfreich sind die Inhalte wie „Was ist eine virtuelle Maschine“ für den tagtäglichen Einsatz nun beim besten Willen auch nicht.

„Erste Schritte“ Tab entfernen

  • Oben rechts im Webclient auf den Link „Hilfe“
  • Darunter „Alle Erste-Schritte-Seiten ausblenden“ wählen

CertificateServicesClient-AutoEnrollment Event 6, CertificateServicesClient-CertEnroll Event 13 und CertificateServicesClient-CertEnroll Event 82

Problem

Auf Domänencontrollern gibt es in regelmäßigen Abständen im Eriegnisprotokoll diese Fehlermeldungen:

Quelle: CertificateServicesClient-CertEnroll
Event-ID: 82
Fehler bei der Zertifikatregistrierung für Lokales System bei der Authentifizierung für alle URLs für den
Registrierungsserver, der folgender Richtlinien-ID zugeordnet ist: {1874501F-FFFF-AFFE-BBD5-F3B749CBCF4A}
(Der RPC-Server ist nicht verfügbar. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)).
Fehler bei der Registrierung für Vorlage: DomainController

Dicht gefolgt von

Die Zertifikatregistrierung für Lokales System konnte sich nicht für ein Zertifikat DomainController mit der Anforderungs-ID N/A von serverwitten.DrSpangGmbH.local\Dr. Spang GmbH (Der RPC-Server ist nicht verfügbar. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)) registrieren.

Quelle: CertificateServicesClient-CertEnroll
Event-ID: 13
Die Zertifikatregistrierung für Lokales System konnte sich nicht für ein Zertifikat DomainController mit der
Anforderungs-ID N/A von SERVERNAME.DPOMAIN.TLD\OLD-CA-NAME (Der RPC-Server ist nicht verfügbar.
0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)) registrieren.

Und dann bestätigt von:

Bei der automatischen Zertifikatregistrierung für lokales System ist ein Fehler aufgetreten (0x800706ba) Der RPC-Server ist nicht verfügbar. .

Quelle: CertificateServicesClient-AutoEnrollment
Event-ID: 6
Meldung:
Bei der automatischen Zertifikatregistrierung für lokales System ist ein Fehler aufgetreten (0x800706ba)
Der RPC-Server ist nicht verfügbar.
.

Das passiert in der Regel, wenn es „irgendwann“ mal eine CA in dieser Domäne gab und der Servers nicht mehr exisitert. Hinweise auf so eine Situation können Zitate sein wie „Den Servernamen kenne ich, aber den gibt es schon lange nicht mehr. Wir haben auch keine eigene CA“. Das passiert auch gene mal, wenn uralte Exchange-Server deinstalliert werden die Self-Signed Zertifikate über sich selber genutzt haben.

Wichtig: Der Name der CA (aus den Ereignismeldungen) muss exakt stimmen.

Lösung

Die ehemalige CA und deren Zertifikatsvorlagen (Templates) müssen sauber aus dem Active Directory entfernt werden. Der Name der CA ist ja aus den Meldunge bekannt.

  1. „Active-Directory Standorte und Dienste“ öffnen und unter Ansicht > „Dienstknoten anzeigen“ einschalten
  2. Öfnen von „Services“ > „Public Key Service“ > „AIA“ > in der rechten Hälfte hier die falsche/tote CA (Hier steht der CA Name, NICHT der Servername)  löschen
  3. Öffnen von „Services“ > „Public Key Service“ > „Enrollment Services“ > und auch hier die falsche CA löschen

Die folgenden beiden Schritte nur durchführen, wenn es KEINE NEUE CA in dieser Domäne gibt. Wenn es eine CA in der Domain gibt, diese Schritte überspringen.

  1. Die alten Zertifikatsvorlagen aus dem AD entfernen: Öffne „Public Key Service“ > „Certificate Templates“ und lösche alle LDAP-Vorlagen hier drin
  2. Unter „Public Key Services“ das Objekt „NTAuthCertificates“ löschen

Konfiguration im AD aktualisieren

An der Shell (CMD oder Powershell) die DC-Informationen aufräumen und aktualisieren:

C:\> certutil -dcinfo deleteBad

Nach ein paar Minuten (Default: 5) die RSOP-Daten des/der DCs aktualisieren:

C:\> gpupdate /force

Das passiert zwar auch automatisch (auch auf allen DCs), aber wenn man das manuell anstößt kann man den Erfolg praktisch sofort in der Ereignisanzeige nachvollziehen:

 

 

Windows Server 2012R2 verliert sporadisch Netzwerkverbindung „Die IP-Adresse für die Isatap-Schnittstelle LAN-Verbindungwurde nicht aktualisiert.“

Ein sehr seltsames Problem, aber eine einfache Lösung.

Wir haben einen Windows Server 2012 R2 (Domain Controller), der früher auf einem vSphere 5.5 lief. Später wurde der darunterliegende ESXi auf ein vSphere 6 aktualisiert. Sporadischen („random“) traten unter beiden ESX-Versionen Ausfälle bei ebendiesem DC auf; die Netzwerkkarte war plötzlich nicht mehr erreichbar.

Die Netzwerkkarte war im Fehlerfall tot, sprich von außen nicht mehr pingbar. Mann konnte sich auf der Konsole des Servers problemlos einloggen und die Karte sehen, aber keine Pakete wurden mehr verschickt oder empfangen. Nach einem Reboot klappte wieder alles einwandfrei, mal für ein paar Stunden, mal für ein paar Tage.

Im Ereignisprotokoll war nichts zu finden (wenn doch nur alle Logs so sauber wären …), außer:

Log Name:      System
Source:        Microsoft-Windows-Iphlpsvc
Date:          2/1/2017 5:01:51 PM
Event ID:      4202
Task Category: None
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      MYSERVER.MYDOMAIN
Description:
Unable to update the IP address on Isatap interface isatap.{<SID>}. Update Type: 0. Error Code: 0x57.

und

 Log Name: System
 Source: Microsoft-Windows-Iphlpsvc
 Date: 2/1/2017 4:49:33 PM
 Event ID: 4202
 Task Category: None
 Level: Error
 Keywords:
 User: SYSTEM
 Computer: MYSERVER.MYDOMAIN
 Description:
 Unable to update the IP address on Isatap interface isatap.{<SID>}. Update Type: 1. Error Code: 0x490.

Lösung

Die Netzwerkkarte in dem System war eine vmware INTEL E1000. Diese durch einen VMXNET-Adapter (idealerweise VMXNET3) austauschen und der Fehler ist verschwunden.

 

VMware Tools Tray-Icon auf RDS- oder Terminalservern via GPO ausblenden

In einer RDS/View/Desktop Umgebung wird das niedliche VMware Tools Icon ständig und bei allen Benutzer im Tray angezeigt. Der Benutzer hat zwar keine Möglichkeit den Prozess zu mißbrauchen, trotzdem frißt der VMwareTray.exe-Prozess lockere 3Megaby RAM (pro Nutzer) und hat keinen sinnvollen Nutzen.

Der Schlüssel für die dauerhafte Ausblendung des vmware Tray-Prozesses lautet:

[HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Tools]
"ShowTray"=dword:00000000

Der DWORD(32)-Wert „ShowSystray“=0 bedeutet dass das Icon nicht angezeigt wird, mit dem Wert 1 ist es wieder sichtbar

Daß der Prozess überhaupt gestartet wird, ist im RUN Schlüssel des Systems abgelegt. Daher kann auch dieser entfernt werden. Beide Einstellungen sind natürlich auch über Group Policy Preferences konfigurierbar.