Kategoriearchiv: Microsoft

Volume Shadow Copy Fehler: Unexpected error calling routine ConvertStringSidToSid. hr = 0x80070539

Veröffentlicht am von — Keine Kommentare ↓

Problem

Es treten verschiedene VSS-Fehler auf. Einige Volumenschattenkopien sind nicht verfügbar, P2P-Operationen mit dem vmware Converter schlagen fehl oder eine Datenträgersicherung bricht ab.

Die Fehlermeldung im Ereignisprotokoll:

Log Name:      Anwendung
Source:        VSS 
Event ID:      8193 
Beschreibung: 
Volume Shadow Copy Service error: Unexpected error calling routine ConvertStringSidToSid. 
hr = 0x80070539.

Operation: 
   OnIdentify event 
   Gathering Writer Data

Context: 
   Execution Context: Shadow Copy Optimization Writer 
~snip~

Lösung

Uns sind hier zwei verschiedene Ursachen begegnet. Die erste wesentlich häufiger als die zweite.

  1. Der betroffene Computer hat nicht auflösbare SIDs in der lokalen Administratorengruppe. Diese einfach aus der Gruppe entfernen und den Anmeldedienst neu starten. Schon geht wieder alles.
  2. Im Registry-Schlüssel HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList gibt es noch eine oder mehrere Kopien von Registry-Benutzerprofilen (<SID>.bak). Diese rückstandsfrei löschen.

Nach der Fehlerbehebung klappt auch der VSS-Dienst wieder fehlerfrei.

SQL Management Studio „Die Agent XPs-Komponente ist im Rahmen der Sicherheitskonfiguration für diesen Server deaktiviert.“

Veröffentlicht am von — 1 Kommentar ↓

Die Agent XPs-Komponente ist im Rahmen der Sicherheitskonfiguration für diesen Server deaktiviert. Ein Systemadministrator kann die Verwendung von "Agent XPs" mithilfe von "sp_configure" aktivieren. Weitere Informationen zum Aktivieren von "Agent XPs" finden Sie unter "Oberflächenkonfiguration" in der SQL Server-Onlinedokumentation. (Microsoft.SqlServer.Management.MaintenancePlanWizard)Beim Einrichten eines Wartungsplanes, eines Dumps oder anderer Konfigurationseigenschaften erhält man diese Fehlermeldung:

„Die Agent XPs-Komponente ist im Rahmen der Sicherheitskonfiguration für diesen Server deaktiviert. Ein Systemadministrator kann die Verwendung von „Agent XPs“ mithilfe von „sp_configure“ aktivieren. Weitere Informationen zum Aktivieren von „Agent XPs“ finden Sie unter „Oberflächenkonfiguration“ in der SQL Server-Onlinedokumentation. (Microsoft.SqlServer.Management.MaintenancePlanWizard)“

Lösung

Neue SQL-Abfrage ausführen:

sp_configure 'show advanced options',1;
GO
RECONFIGURE;
GO
sp_configure 'Agent XPs',1;
GO
RECONFIGURE
GO

Mithilfe der Agent XPs kann man die erweiterten gespeicherten Prozeduren des SQL Server-Agenten auf dem SQL-Server aktivieren. Wenn diese SQL-Option nicht aktiviert ist, treten diese Fehler im Zusammenhang mit dem Agenten auf und der SQL Server-Agent-Knoten im Objekt-Explorer vom SQL-SMSS ist nicht verfügbar.

Mehr zum Thema:https://msdn.microsoft.com/de-de/library/ms178127.aspx

 

E-Mails die in Outlook von einem gemeinsamen Postfach aus versendet werden, landen nicht im gemeinsamen „Gesendete Objekte“ Ordner

Veröffentlicht am von — Keine Kommentare ↓

Seit Office 2010 ist die Standardeinstellung von Outlook-Ablageobjekten nicht immer optimal. Neue Nachrichten, die von einem gemeinsamen (ob fremdgeöffnet oder als shared Mailbox angelegt ist egal) Postfach gesendet werden, werden nicht im Ordner „Gesendete Objekte“ des freigegebenen Postfachs abgelegt, sondern im Postfach des absendenden Benutzers. Das sorgt oft für Verwirrung.

Das liegt daran, das in Exchange 2010+ und Office 365 freigegebene Postfächer keine Lizenz mehr benötigen und man Outlook nicht mehr als „unabhängiges“ Postfach verbinden kann. In so einem Fall meldet man sich konsequenterweise aber beim eigenen Postfach an und öffnen das freigegebene Postfach zusätzlich. Beim Senden nimmt Outlook dann standartmäßig das Konto des Absenders. Daher werden Nachrichten – im Prinzip folgerichtig – auch immer im Ordner „Gesendete Objekte“ das Postfach des Absenders (also angemeldeten Nutzers) gespeichert.

Dieses Verhalten ist reine Outlook-Sache (nicht Exchange) und lässt sich schnell in der Registry anpassen:

HKCU\Software\Microsoft\Office\<VERSION>\Outlook\Preferences
DWORD: DelegateSentItemsStyle
Wert: 1 (für Ablage in geöffnetem Postfach)
Wert: 0 (für Ablage in eigenem Postfach, Standard)

Outlook / Office 365 „Ihr Postfach wurde temporär auf den Microsoft Exchange-Server verschoben. Ein temporäres Postfach ist zwar vorhanden …“

Veröffentlicht am von — Keine Kommentare ↓

Problem

Outlook 2013/2016 startet nur noch mit dieser Fehlermeldung. Gesehen haben wir den fehler bei On-Premise Serverinstallationen und Office 365. Der Fehler selber liegt in der Art, wie Outlook Cache-Daten interpretiert.

Das Postfach wurde temporär auf den Microsoft Exchange-Server verschoben. Ein temporäres Postfach ist zwar vorhanden, aber enthält möglicherweise nicht alle vorherigen Daten.„Ihr Postfach wurde temporär auf den Microsoft Exchange-Server verschoben. Ein temporäres Postfach ist zwar vorhanden, aber enthält möglicherweise nicht alle vorherigen Daten. Sie können eine Verbindung zum temporären Postfach herstellen oder offline mit allen alten Daten arbeiten. Wenn Sie mit den alten Daten arbeiten möchten, können Sie keine E-Mail-Nachrichten senden oder empfangen.“

An sich funktioniert Outlook aber problemlos.

Lösung

Die Ursache ist ein Fehler in Outlook, unser Case-Manager sagt ein Fix sei „in Arbeit“. Mal sehen wann das passiert, die Meldung ist von 2014 … 🙂

SICHERE Lösung, die immer funktioniert:

  1. Neues Outlook-Profil im Onlinemodus (!!) erstellen. Ja, komplett ohne Cachemode.
  2. Das betroffene alte Profil entfernen
  3. Outlook starten und Erstsynchronisation abwarten (~20 Sekunden)
  4. Outlook schliessen
  5. Cachemode wieder einschalten (wenn gewünscht), Outlook neu starten, fertig.

Es gibt auch Fälle, in denen hat es schon geholfen, die bestehende OST-Datei (%LOCALAPPDATA%\Microsoft\Outlook) zu löschen und durch einen Outlook Neustart erneut zu synchronisieren.

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

Veröffentlicht am von — Keine Kommentare ↓

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: