UT-IT

Damit meinte ich es kann nicht wirklich was damit zu tun haben, weil ich es schon geprüft hatte.

Ach Du meinst das Windows-Benutzerprofil? Das kann ja nicht wirklich was damit zu tun haben, ich habe das ganze schon relativ früh auf einem anderen Rechner getestet. Und wie gesagt, Migration in einen vollkommen anderen Benutzer ändert leider nichts am Verhalten.

Ich habe einen neuen Benutzer angelegt und die vorhandenen Mails per pst Ex-/Import migriert, ohne dass eine Änderung eingetreten ist.

Oder was meinst Du genau mit neuem Benutzerprofil?

Also nach kurzer Recherche (https://docs.microsoft.com/de-de/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019) sollte Exchange 2013 mit Office 365 ProPlus kompatibel sein.

Da wir viele Postfächer in der genannten Größe und mit komplexen Ordnerstrukturen haben, das Problem aber nur bei einem Nutzer auftritt, mag ich nicht so recht an ein generelles Problem glauben.

Office 2013 müsste ich in einer VM installieren, aber würde mir nicht wirklich bei der Problemlösung helfen. Ich kann dem User ja nicht wieder Office 2013 installieren.

Gruß,

UT-IT

Hallo,

das ist der "Exchange Cache Modus", den ich meinte. Auch wenn dieser auf "alle" steht, werden nicht annähernd alle Mails synchronisiert.

Gruß,

UT-IT

Hallo zusammen,

wir haben ein sehr seltsames Problem. Wir haben einen Exchange Server 2013 mit dem aktuellen CU23 und den aktuellen Sicherheitsupdates. Als Clients setzen wir Office365 Click-to-Run ein, aktuelle Version 2002 (Build 12527.20278).

Nun haben wir einen Benutzer, dessen Postfach sich nicht vollständig in Outlook synchronisiert. Das Postfach ist ca. 6GB groß. Auf dem Rechner des Benutzers wurde ein neues Mailprofil erzeugt und in diesem das Postfach synchronisiert. Outlook meldet, alle Ordner seien auf dem neusten Stand. Es fehlen aber sehr viele Unterordner und Mails. Wenn das Postfach per Outlook Web Access geöffnet wird, sind alle Mails vorhanden. Wenn das Postfach per ActiveSync unter Android abgerufen wird, sind alle Mails vorhanden. Ein Anpassen des "Exchange Cache Modus" auf "alle Mails herunterladen" ändert nichts an der Situation.

Die lokale ost-Datei auf dem Client ist lediglich rund 100MB groß. Ein Löschen der lokalen ost-Datei führt zum gleichen Verhalten. Auf einem anderen Rechner wurde für den Benutzer testweise ein weiteres Mail-Profil erzeugt mit dem gleichen Verhalten. Das Postfach des Benutzers wurde per "New-MailboxRepairRequest" serverseitig repariert, ohne dass sich etwas verändert hätte. Das Postfach wurde per "New-MailboxExportRequest" in eine pst-Datei exportiert. Wenn diese in Outlook eingebunden wird, sind alle Mails vorhanden. Es wurde ein neuer AD-Benutzer erzeugt und in dessen Mailbox die exportierte pst-Datei per "New-MailboxImportRequest" importiert. Das Verhalten in Outlook ist für den neuen Benutzer absolut identisch: viele Ordner und Mails fehlen, die lokale ost-Datei ist sehr klein.

Langsam aber sicher gehen mir die Ideen aus. Hat jemand eventuell so ein seltsames Verhalten schon einmal gesehen und eine mögliche Erklärung dafür?

Gruß,

UT-IT

Das denke ich auch, dass es nicht an den eigentlichen Makros im Dokument liegt. Vielen Dank für den Link, Google hatte ich auch gewälzt, dieses Ergebnis habe ich aber anscheinend übersehen. Die VBUSC.exe hatten wir schon an anderer Stelle gefunden (der Microsoft-Link geht ins Leere), bekamen aber die Fehlermeldung, dass Visual Basic nicht erkannt wurde. In Deinem Link sind aber weitergehende Schritte, die wir noch ausführen können

Hallo Jan,

vielen Dank für Deine Antwort. Wir haben nur Click&Run-Installationen von Office365 im Umlauf.

Debuggen können wir an der Stelle nichts, die Fehlermeldung kommt bei jeder Prozedur schon bevor die erste Zeile Code ausgeführt wird, die Prozedurdefinition selbst wird dann gelb markiert.

Viele Grüße

Dennis

Private Sub Workbook_BeforeClose(Cancel As Boolean)
    
    With Application
        .CommandBars(1).Controls("Konvertierung").Delete
    End With
    
End Sub

Private Sub Workbook_Open()
    
    Dim HelpMenu As CommandBarControl
    Dim NewMenu As CommandBarPopup
    Dim NewMenuItem As CommandBarButton
    
    With Application
        On Error Resume Next
        'Ein bestehendes Menü mit dem gleichen Namen löschen
        .CommandBars(1).Controls("Konvertierung").Delete
        'Hilfe Menü finden und Position für neuen Eintrag bestimmen
        Set HelpMenu = .CommandBars(1).FindControl(ID:=30010)
        If HelpMenu Is Nothing Then
            Set NewMenu = .CommandBars(1).Controls.Add(msoControlPopup, Temporary:=True)
        Else
            Set NewMenu = .CommandBars(1).Controls.Add(msoControlPopup, Before:=HelpMenu.Index, Temporary:=True)
        End If
        'Menu benennen
        NewMenu.Caption = "Konvertierung"
        'Eintrag anlegen
        Set NewMenuItem = NewMenu.Controls.Add(msoControlButton)
        With NewMenuItem
            .Caption = "Starten"
            .OnAction = "DieseArbeitsmappe.Konvertierung"
        End With
    End With
    
End Sub

Private Sub Konvertierung()
    
    'Tabelle vorbesetzen
    Set Tabelle = DieseArbeitsmappe.Application.ActiveSheet

    frmBearbeiten.Show

End Sub

Daran solls nicht scheitern ;)

Beim Öffnen der Mappe passiert eigentlich noch nicht viel außer dem Anlegen eines Menüeintrags. Auf den beiden Systemen ist es aber egal, welchen Code aus welchen Modul ich ausführen will, diese Lizenzmeldung kommt immer.

Ich hatte die Vermutung, dass irgendein Control nicht gefunden wird, aber ich kenne das so, dass man das dann im Visual Basic Editor unter "Verweise" als missing drinstehen hat

Der ist schon länger nicht mehr im Unternehmen

Ehrlich gesagt glaube ich auch eigentlich nicht, dass der Fehler irgendwo im Code liegt, der wurde nur hier und da mal auf andere Anforderungen bezüglich der Ausgabedateien hin angepasst, läuft aber so schon ne Weile. Und dann sollten die anderen Kollegen mit Office365 doch auch Probleme haben, oder?

Ich fürchte, dass es an irgendeiner Konstellation auf den Systemen liegt. Nur spricht dagegen, dass es auf 2 verschiedenen Betriebssystemen passiert....Wie Du siehst, bin ich recht ratlos, was ich noch testen kann...irgendwie klingt jede Überlegung unlogisch

Hallo,

wir haben schon seit etlichen Jahren eine Excel-Datei im Einsatz, die über Makros eine Quelldatei einliest und die Informationen dann in andere Dateien unterschiedlichen Formats exportiert.

Bei 2 Kollegen kommt seit der Installation von Office365 die folgende Fehlermeldung: (siehe Anhang)

"Lizensierungsinformationen für diese Komponente nicht gefunden. Sie verfügen nicht über die erforderliche Lizenz, um dieses Funktionsmerkmal in der Entwurfsumgebung nutzen zu können"

Die beiden Kollegen haben unterschiedliche Betriebssysteme, einmal Windows 7 und einmal Windows 10 Version 1803, beide weitesgehend gepatcht. Bei anderen Kollegen funktioniert die Datei noch ohne Probleme, auch auf meinem Rechner (Windows 10 Version 1803, gleicher Patchstand) kommt nur die Sicherheitswarnung wegen dem Makro, ich kann die Datei danach aber normal nutzen.

Wir haben bei Office 365 schon beide Reparaturfunktionen (schnelle und Onlinereparatur) ausgeführt, es wurden laut Zeitstempel auch DLLs und OCXen ausgetauscht, ohne Erfolg. Das .NET Framework 3.5 ist auch schon nachträglich aktiviert.

Wir haben auch einen uralten Fix ausgeführt, der als 1. Symptom unsere Fehlermeldung hatte, auch dies ohne Erfolg. (http://www.c-bit.org/kb/194751/EN-US/)

Hat vielleicht noch jemand eine Idee, was ich auf den betroffenen Systemen noch prüfen könnte, um dem Fehler auf die Spur zu kommen?

Besten Dank!

Dennis