Autoren-Archiv: admin

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.

VMware ESX5.1/5.5 Warnung: „Systemprotokolle auf dem host foo.bar werden in einem nicht beständigen Speicher gespeichert“ [update]

Veröffentlicht am von — 15 Kommentare ↓

Frische Neuinstallationen des ESXi 5.1/5.5 auf einem USB-Stick oder einer SD-Karte behaupten gerne mal „Systemprotokolle auf dem host foo.bar werden in einem nicht beständigen Speicher gespeichert„. Das ist auch fast korrekt – USB-Speicher und Sd-Karten sind nach VMWare-denke „volatil“. Nur Festplatten (respektive Datastores) sind beständig.

Lösungsmöglichkeit 1 (EMPFOHLEN, BRAUCHT NEUSTART)

Einen Speicherort für die Scratch-Files für jeden betroffenen ESX(i)-Host auf einem Datastore erstellen. Das geht direkt im vSphere Client und im laufenden Betrieb – die Änderung wird nur erst bei einem Neustart des Hosts aktiv.

  1. Auf dem jeweiligen ESX(i)-Host unter Konfiguration/Speicher den passenden Datastore Durchsuchen und einen Ordner erstellen. VMWare schlägt einen Namen wie .locker-ESXHOSTNAME vor, denn Ordner die mit einem „.“ beginnen werden im Browser nicht angezeigt. Jeder Host braucht einen eigenen Scratch-Ordner.
  2. Diesen neuen Ort dann in die ESX(i) Konfiguration der Hosts eintragen: Unter Konfiguration -> Software -> Erweiterte Einstellungen -> ScratchConfig -> ScratchConfig.ConfiguredScratchLocation auf den neuen Pfad setzen, z.B. /vmfs/volumes/DATASTORENAME/.locker-ESXHOSTNAME

Der Defaultwert ist /tmp/scratch, was in einer Standardinstallation auf der Ramdisk liegt. Eine Möglichkeit diese Warnung ohne die solche Anpassung des Setups auszuschalten ist (mir) nicht bekannt.

Lösungsmöglichkeit 2 (OHNE NEUSTART)

  1. Auf dem jeweiligen Host auf dem Tab „Konfiguration“ > unter „Software“ auf „Erweiterte Einstellungen“
  2. In der Baumstruktur links „Syslog“ aufwählen
  3. In dem Feld „Syslog.global.loghost“ die Adresse des vCenter-Servers eintragen
    1. Das Format lautet: udp://<IP-VCENTER-SERVER>:514