Jump to content

Dirk-HH-83

Members
  • Gesamte Inhalte

    613
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Dirk-HH-83

  1. Hallo, 

     

    es ist eine Server/Client Software die ohne Datenbanksystem sondern dateibasiert arbeitet. 

    Hier sind mehrere Ordner / Dateien aus zwei benachbarten Über-Ordnern verschwunden.  (es sind ca. 2,5 GB)

     

    Die NTFS Ordnerüberwachtung (siehe Eigenschaften/Sicherheit) ist nicht aktiv. Schattenkopien auch nicht.

     

    Ich habe bei Kroll Ontrack gefragt, die Diagnose einer HyperVM soll 1000 € kosten, statt wie bei normalen SATA Festplatten mit einem kostenlosen KVA.

     

    Eine teure Angelegenheit ist sowas immer, keine Frage.

     

    Es gibt noch einen neueren HyperV Snapshot, habe dazu gerade im Virtualisierungsforum gepostet. (betreff:  30 Dateien...aus Snapshot)

     

    Fakt ist, dass nicht RANDOM - >  sondern gezielt wichtige Datenordner fehlen. Das läßt einerseits auf ein Softwarebug und andererseits auf Absicht deuten.

    Es handelt sich um ein Share bei dem sich die User üblicherweise nicht bewegen welches unglücklicherweise aber zuviele Rechte hatte.

     

    Sehe ich genauso, normalerweise verschiebt jemand automatisch.

     

  2. Hallo, 

     

    bei dem HyperV Windows 2012 läuft eine größere VM.    (*.vhdx)

    (sie hat ein HyperV Prüfpunkt/Snapshot vom 5. April)  

     

    Das Backup ist blöderweise zuletzt am 26. März gelaufen.   

    Gibt es ein Weg den Snapshot zu mounten um von aus Ordner XY 30 Dateien zu holen?

     

    Schätze es gibt nur diesen Weg:   VM von heute beenden, sichern/klonen.   
    Snapshot laden+Dateien holen,  Snapshot beenden und wieder die VM von heute starten.

     

    Danke, Gruß Dirk

  3. Hallo, 

     

    die Volumen Office 2010 Standard Aktivierung meldet wie folgt. 

    Telefonisch mit dem Microsoft Aktivierungshotline (nicht der Telefoncomputer) hat die Aktivierung dann funktioniert.

    Kann man diesen Counter um z.B. 20 Aktivierungen zurückstellen lassen?

     

    Your Installation cannot be activated because you have activated up to the limit your Multiple Activation Key. Consult you Administrator for further Help.

     


    Danke, Gruß

    Dirk

     

  4. Hi, 

     

    am DC in der Domänen GPO Verwaltung und im ADS User Objekt d.h. im Register Remotedesktopdienste-Benutzerprofil (User Profile) und / oder die Remotedesktopdienste-Basisordner (Home Folder) steht leider nix (mehr) drinne.  

     

    Beim WTS wurde eigentlich nur zu neues .NET 4.6-4.7 deinstalliert und danach Windows GUI reaktiviert.

     

    Danke, Gruß

    Dirk

  5. Hallo, 

     

    bei Terminalservern (Win2012 R2)    (z.B. mit Verbindungs-Broker)  gibt es doch manchmal ein gespiegeltes Laufwerk C: bzw. wenn ich richtig erinnere ist es nur eine Spiegelung vom %userprofile%

     

    Wo schaltet man das nochmal ein? (bzw. wo wird das geregelt?)

     

    Manche Menschen nennen es Homedirectory W:\ genannt.  (damit meine kein leeres Shares was auf dem Server für die Benutzer angelegt ist)

     

    Vielen Dank vorab, gruß

  6. Hallo, 

     

    • bei einem Win2012 R2 HyperV Host funktioniert VSS nicht.
    • die HyperV integrationsdienste lassen sich bei den VMs nicht richtig installieren/updaten
    • Windows Updates lassen nicht nicht sauber automatisch installieren
    • das hat sich dadurch bemerkbar gemacht, dass Veeam Backup viele VSS Fehler auswirft.  (und nicht mehr funktioniert, es lief bereits länger)
    • (sowohl wenn es auf einer separaten Win7 VM installiert ist als auch wenn Veeam direkt auf dem HyperV Host installiert ist)
    • die ungenannten vssadmin befehlen melden wie folgt, wobei zwei davon kein Ergebnis auswerfen.
    • Neustart vom Volumenschattenkopie-Dienst funktioniert nicht, muss dann über Taskmgr gekillt werden.  (neustart vom HyperV Host hilft nicht)
    • es hat sich an dem HyperV Host im Grunde nichts geändert in den letzten Wochen...

     

     

    Frage: Sehe ich es richtig, dass Neuinstallation vom HyperV Host die beste Variante ist?   Reparatur-Installation bietet sich ggf. auch an.

     

    danke, gruß Dirk

     

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

     

    Microsoft Windows [Version 6.3.9600]

    (c) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

     

    C:\Windows\System32>vssadmin list volumes

    vssadmin 1.1 - Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienstes

     

    nichts passiert

     

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

     

    (C) Copyright 2001-2013 Microsoft Corp.

     

    C:\Windows\System32>vssadmin list shadows

    vssadmin 1.1 - Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienstes

     

    (C) Copyright 2001-2013 Microsoft Corp.

     

    nichts passiert

     

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

     

    C:\Windows\System32>vssadmin list writers

    vssadmin 1.1 - Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienst

     

    (C) Copyright 2001-2013 Microsoft Corp.

     

    Verfassername: "Task Scheduler Writer"

       Verfasserkennung: {d61d61c8-d73a-4eee-8cdd-f6f9786b7124}

       Verfasserinstanzkennung: {1bddd48e-5052-49db-9b07-b96f96727e6b}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "VSS Metadata Store Writer"

       Verfasserkennung: {75dfb225-e2e4-4d39-9ac9-ffaff65ddf06}

       Verfasserinstanzkennung: {088e7a7d-09a8-4cc6-a609-ad90e75ddc93}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "Performance Counters Writer"

       Verfasserkennung: {0bada1de-01a9-4625-8278-69e735f39dd2}

       Verfasserinstanzkennung: {f0086dda-9efc-47c5-8eb6-a944c3d09381}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "System Writer"

       Verfasserkennung: {e8132975-6f93-4464-a53e-1050253ae220}

       Verfasserinstanzkennung: {5816e3aa-7a69-4c55-bf2e-abbd6827219a}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "SqlServerWriter"

       Verfasserkennung: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}

       Verfasserinstanzkennung: {039e53aa-ec6a-444a-8ee6-f785fffcbd3d}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "Microsoft Hyper-V VSS Writer"

       Verfasserkennung: {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}

       Verfasserinstanzkennung: {aa8745ef-27e3-41af-b3c1-d8e1fcd8fd82}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "ASR Writer"

       Verfasserkennung: {be000cbe-11fe-4426-9c58-531aa6355fc4}

       Verfasserinstanzkennung: {cf7da136-8eeb-4f21-8826-844c79724790}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "Registry Writer"

       Verfasserkennung: {afbab4a2-367d-4d15-a586-71dbb18f8485}

       Verfasserinstanzkennung: {ceab02a9-ed11-498d-8678-8e1ac9541af1}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "Shadow Copy Optimization Writer"

       Verfasserkennung: {4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f}

       Verfasserinstanzkennung: {cef15ec7-8878-4ece-9862-60cce5d5fdff}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "WMI Writer"

       Verfasserkennung: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}

       Verfasserinstanzkennung: {427de135-0bf7-45e5-889a-27e54a0017a8}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

    Verfassername: "COM+ REGDB Writer"

       Verfasserkennung: {542da469-d3e1-473c-9f4f-7847f01fc64f}

       Verfasserinstanzkennung: {fe8c3457-ee0e-46d9-80d1-a9d8fa61e27d}

       Status: [1] Stabil

       Letzter Fehler: Kein Fehler

     

     

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

     

     

    vssadmin list providers

     

    vssadmin 1.1 - Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienstes

     

    (C) Copyright 2001-2013 Microsoft Corp.

     

    Anbietername: "Microsoft File Share Shadow Copy provider"

       Anbietertyp: Dateifreigabe

       Anbieterkennung: {89300202-3cec-4981-9171-19f59559e0f2}

       Version: 1.0.0.1

     

    Anbietername: "Microsoft Software Shadow Copy provider 1.0"

       Anbietertyp: System

       Anbieterkennung: {b5946137-7b9f-4925-af80-51abd60b20d5}

       Version: 1.0.0.7

     

     

     

    ....zwei Meldungen aus dem Hyper-V-VMMS Eventlog:

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

     

    Protokollname: Microsoft-Windows-Hyper-V-VMMS-Admin
    Quelle:        Microsoft-Windows-Hyper-V-VMMS
    Datum:         28.03.2018 09:10:33
    Ereignis-ID:   19510
    Aufgabenkategorie:Keine
    Ebene:         Fehler
    Schlüsselwörter:
    Benutzer:      SYSTEM
    Computer:      HVHOST
    Beschreibung:
    Die Beschreibung für die Ereignis-ID "19510" aus der Quelle "Microsoft-Windows-Hyper-V-VMMS" wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, nicht auf dem lokalen Computer installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren.

    Falls das Ereignis auf einem anderen Computer aufgetreten ist, mussten die Anzeigeinformationen mit dem Ereignis gespeichert werden.

    Die folgenden Informationen wurden mit dem Ereignis gespeichert: 

    %%2147942480
    0x80070050

    Die gebietsschemaspezifische Ressource für die gewünschte Meldung ist nicht vorhanden

    Ereignis-XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Hyper-V-VMMS" Guid="{6066F867-7CA1-4418-85FD-36E3F9C0600C}" />
        <EventID>19510</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-03-28T07:10:33.066632700Z" />
        <EventRecordID>57453</EventRecordID>
        <Correlation />
        <Execution ProcessID="4036" ThreadID="1240" />
        <Channel>Microsoft-Windows-Hyper-V-VMMS-Admin</Channel>
        <Computer>HOST</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <UserData>
        <VmlEventLog xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events" xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
          <ErrorMessage>%%2147942480</ErrorMessage>
          <ErrorCode>0x80070050</ErrorCode>
        </VmlEventLog>
      </UserData>
    </Event>

     

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

     

     

    Protokollname: Microsoft-Windows-Hyper-V-VMMS-Admin
    Quelle:        Microsoft-Windows-Hyper-V-VMMS
    Datum:         28.03.2018 09:07:53
    Ereignis-ID:   14090
    Aufgabenkategorie:Keine
    Ebene:         Warnung
    Schlüsselwörter:
    Benutzer:      SYSTEM
    Computer:      HVHOST
    Beschreibung:
    Der Verwaltungsdienst für virtuelle Computer wird heruntergefahren, während einige virtuelle Computer gestartet werden. Alle derzeit ausgeführten virtuellen Computer werden weiterhin ausgeführt, verfügen jedoch nicht über Verwaltungszugriff.
    Ereignis-XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Hyper-V-VMMS" Guid="{6066F867-7CA1-4418-85FD-36E3F9C0600C}" />
        <EventID>14090</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-03-28T07:07:53.895269000Z" />
        <EventRecordID>57440</EventRecordID>
        <Correlation />
        <Execution ProcessID="3008" ThreadID="7064" />
        <Channel>Microsoft-Windows-Hyper-V-VMMS-Admin</Channel>
        <Computer>HVHOST</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <UserData>
        <VmlEventLog xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events" xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
        </VmlEventLog>
      </UserData>
    </Event>

     

     

     

     

    Protokollname: Microsoft-Windows-Hyper-V-Integration-Admin
    Quelle:        Microsoft-Windows-Hyper-V-Integration-KvpExchange
    Datum:         29.03.2018 08:42:07
    Ereignis-ID:   4010
    Aufgabenkategorie:Keine
    Ebene:         Warnung
    Schlüsselwörter:
    Benutzer:      NT VIRTUAL MACHINE\664DD81A-AF4E-4E3C-901E-B01051096F0E
    Computer:      HVHOST
    Beschreibung:
    Der Hyper-V-Datenaustauschdienst ist mit dem virtuellen Computer "WIN7" verbunden, die Version entspricht aber nicht der von Hyper-V erwarteten Version (ID des virtuellen Computers: 664DD81A-AF4E-4E3C-901E-B01051096F0E). Frameworkversion: Negotiated (3.0) - Expected (3.0), Meldungsversion: Negotiated (3.0) - Expected (5.0). Es handelt sich um eine nicht unterstützte Konfiguration. Dies bedeutet, dass bis zur Behebung des Problems kein technischer Support zur Verfügung gestellt wird. Aktualisieren Sie die Integrationsdienste, um das Problem zu beheben. Stellen Sie zum Durchführen des Upgrades eine Verbindung mit dem virtuellen Computer her, und wählen Sie im Menü "Aktion" die Option "Installationsdatenträger für Integrationsdienste einlegen" aus.
    Ereignis-XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Hyper-V-Integration-KvpExchange" Guid="{82D60869-5ADA-4D49-B76A-309B09666584}" />
        <EventID>4010</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-03-29T06:42:07.581923300Z" />
        <EventRecordID>2657</EventRecordID>
        <Correlation />
        <Execution ProcessID="8016" ThreadID="2812" />
        <Channel>Microsoft-Windows-Hyper-V-Integration-Admin</Channel>
        <Computer>HVHOST</Computer>
        <Security UserID="S-1-5-83-1-1716377626-1312599886-279977616-242157905" />
      </System>
      <UserData>
        <VmlEventLog xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events" xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
          <VmName>WIN7</VmName>
          <VmId>664DD81A-AF4E-4E3C-901E-B01051096F0E</VmId>
          <Param1>Negotiated (3.0) - Expected (3.0)</Param1>
          <Param2>Negotiated (3.0) - Expected (5.0)</Param2>
          <Param3>
          </Param3>
        </VmlEventLog>
      </UserData>
    </Event>

     

     

     

    Protokollname: Microsoft-Windows-Hyper-V-Integration-Admin
    Quelle:        Microsoft-Windows-Hyper-V-Integration-VSS
    Datum:         29.03.2018 08:42:05
    Ereignis-ID:   4000
    Aufgabenkategorie:Keine
    Ebene:         Fehler
    Schlüsselwörter:
    Benutzer:      NT VIRTUAL MACHINE\664DD81A-AF4E-4E3C-901E-B01051096F0E
    Computer:      HVHOST
    Beschreibung:
    Der Hyper-V-Volumeschattenkopie-Anforderer konnte keine Verbindung mit dem virtuellen Computer "WIN7" herstellen, weil die Version nicht der von Hyper-V erwarteten Version entspricht (ID des virtuellen Computers: 664DD81A-AF4E-4E3C-901E-B01051096F0E). Frameworkversion: Negotiated (0.0) - Expected (3.0), Meldungsversion: Negotiated (0.0) - Expected (5.0). Aktualisieren Sie die Integrationsdienste, um das Problem zu beheben. Stellen Sie zum Durchführen des Upgrades eine Verbindung mit dem virtuellen Computer her, und wählen Sie im Menü "Aktion" die Option "Installationsdatenträger für Integrationsdienste einlegen" aus.
    Ereignis-XML:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Hyper-V-Integration-VSS" Guid="{67E605EE-A4D8-4C46-AE50-893F31E13963}" />
        <EventID>4000</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-03-29T06:42:05.081923700Z" />
        <EventRecordID>2656</EventRecordID>
        <Correlation />
        <Execution ProcessID="8016" ThreadID="5800" />
        <Channel>Microsoft-Windows-Hyper-V-Integration-Admin</Channel>
        <Computer>HVHOST</Computer>
        <Security UserID="S-1-5-83-1-1716377626-1312599886-279977616-242157905" />
      </System>
      <UserData>
        <VmlEventLog xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events" xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
          <VmName>WIN7</VmName>
          <VmId>664DD81A-AF4E-4E3C-901E-B01051096F0E</VmId>
          <Param1>Negotiated (0.0) - Expected (3.0)</Param1>
          <Param2>Negotiated (0.0) - Expected (5.0)</Param2>
          <Param3>
          </Param3>
        </VmlEventLog>
      </UserData>
    </Event>

  7. Hallo, 

     

    habe den aktuellen stand bzgl. bEA Postfach abgefragt. Siehe nächster Post.

    In der Email von der Rechtsanwalt-Kammer  stand folgender Satz.

    Habe mich damit zu wenig beschäftigt,   die im Folgenden genannte Lücke soll offen für einen externen Angriff sein?  der beA Client ist ein eigener Webserver der angreifbar ist?

    Laut BRAK kann die gegenwärtig bei den Anwältinnen und Anwälten installierte Client Security, unabhängig von dem am 22. Dezember 2017 verbreiteten Zertifikat, eine Lücke für einen externen Angriff bieten od


    Die BRAK empfiehlt deshalb allen Anwältinnen und Anwälten, ihre bisherige Client Security zu deaktivieren!

    Details und weitere Informationen finden Sie in einer Pressemitteilung der BRAK hier: http://www.brak.de/fuer-journalisten/pressemitteilungen-archiv/2018/presseerklaerung-04-2018/ 

     

    danke, gruß

    dirk


     

  8. vor 9 Stunden schrieb djmaker:

    GGF. auch eine Inkonsistenz im RAID. Das bekommt man meist nur sehr schwer heraus und ist ziemlich fies. Das Problem sollte im LOG der RAID-MGMT-SW auftauchen bzw. man findet sowas auch mit einem (cold?) - Backup auf Sectorebene.

    Hallo, 

     

    Info:   der Exchange 2013  (ist eine HyperV VM Gen2 mit virutellem SCSI Ctrl) (win2012 r2)

    der HyperV Host ist ebenfalls win2012r2

     

    Gruß
    Dirk

     

  9. Hallo, 

     

    ich wollte nur mal kurz ansprechen,  wodurch korrupte Exchangedatenbanken entstehen könnten, weil ich diesbzgl. nicht auf dem neusten Stand bin.

     

    • 4 Poweruser haben eine 220 GB Exchange 2013 Datenbank. (läuft auf HyperV) (alle haben Vollzugriff auf alle 10 Postfächer und sind immer im Büro und nicht mit Notebooks unterwegs)
    • ist es wegen der Exchange Datenbank Gesundheit wichtig, ob für das eigene Postfach und die freigegebenen Postfächer der Cache Modus an oder aus ist?
    • Ich befürchte das jeder eine lokale 220 GB OST Datei bekommt.  (je nach Einstellung, ob Outlook 2016 nur die letzten 3 Monate oder ALLES anzeigen soll)
    • mit Cachemodus sollte Outlook 2016 etwas schneller sein und bei einer Exchange Offline Situation sieht man zumindest die alten Mails soweit ich weiß.

       

     

    • habe gerade ein langes Wochenende wegen einer nicht entdeckten korrupten Datenbank. Es wurde sogar Outlook upgedated von 2010 auf 2016 wegen der merkwürdigen Langsamkeit im Outlook.
    • gestern mit eseutil /p  + einfügen der fehlenden Umlaufprotokollierungs-Logs und diesem Befehl wird nun alles in eine neue Datenbank verschoben:
    • Zitat

      foreach($mailbox in Get-MailboxStatistics -Database RDB) { New-MailboxRestoreRequest -SourceDatabase RDB -SourceStoreMailbox $mailbox.DisplayName -TargetMailbox $mailbox.DisplayName -baditemlimit unlimited -AcceptLargeDataLoss }

       

    • Die korrupte Datenbank hatte repaircount = 0, allerdings war die Backupsoftware falsch konfiguriert und hatte die alten Umlaufprotokollierungs Logs nicht bereinigt wodurch in der Vergangenheit 2-3x die Datenbank dismounted war wegen voller Festplatte.
    • ferner gab es auch mal einen Datenbankwechsel auf Dateiebene (aus dem Backup) wegen mißglückter Zertifikatserneuerung.  (powershell+owa lief nicht)
    • das ESET Mail Security die Datenbank korrumpiert hat schätze ich als eher unwahrscheinlich ein.
    • Stromausfälle und Bluescreens hatte der Exchange Server nicht nicht.

     

    Vermute das die Frage ob Outlook Cachemodus an/aus absolut egal ist.

    Sehe ich ich folgendes Fazit richtig?  Die EDB Datenbankgesundheit wird durch die ..

    -Größe der EDB (max.200GB)  bzw. der Postfächer (wohl max. 2 GB am besten) , bzw. der Anzahl Emails je Ordner beeinflusst
    -die ordnungsgemäße Online-Defragmentierung

    -genaue Beobachtung des Anwendungslogs (gibt es noch spezielle Logordner die mit der Datenbankgesundheit im Zusammenhang stehen?)

    -Bereinigung der Umlaufprotokollierungs Logs müsste egal sein? Es ist nur Platzverschwendung und 200000 Dateien stören das System...die Datebank braucht nur die aktuellen Logs von heute?

    -jegliche 3rd Party Anwendungen auf dem Exchange Server

    -Emailarchivierung beeinflusst...

    ....

     

    danke, gruß dirk

     

     

     

     

  10. Hallo, 

     

    es wurde Windows 2016 Std. installiert.

    Ob OEM oder OPEN VOLUME ist unklar / unbekannt / kann man nicht nachgucken meines Wissens nach.

    Der nun gekaufte OPEN VOLUME Key meldet:    Diese Edition kann nicht aktualisiert werden.

    Werde bei Microsoft jetzt anrufen.

    Woher das WIn2016 SETUP gekommen ist weiß ich nicht.

    Werde auch fragen ob man die Win2016 Eval´s  mit OPEN Keys aktivieren aktivieren.

     

    Ist das weiterhin so?  Bei Office natürlich auch so.

     

    Beste Grüße

    Dirk

     

     

  11. @Dr Melzer - es gab keine neuartige Lösung  / eure Klarstellung /Erkenntnis das es "Limitiations by design"   hat dazu beigetragen, dass die "Exchange-Anforderung geändert wurde"   Sorry habe mich schlecht ausgedrückt.

     

     

     

    Hi,

     

    sowas will man, wie auch Pop Konnektoren, eigentlich unbedingt vermeiden. Du musst die akzeptierte Domäne als "Internes Relay" konfigurieren. Dann gehen allerdings auch nur Mails an den Smart-Host, die der Exchange nicht kennt. Wenn die Mailbox bzw. Mailadresse auf dem Exchange liegt, geht die natürlich nicht über den SmartHost.

     

    Gruß

    Jan

     

     

    dies war 100% die Lösung

    Unter NachrichtenFluss/Akzeptierte Domänen....per Default steht es ja auf Autoritativ: E-Mail wird nur an gültige Empfänger in dieser Exchange-Organisation zugestellt. Alle E-Mails an unbekannte Empfänger werden zurückgewiesen.

  12. Hallo, 

     

    1. Exchange Server 2013 CU11  15. Dezember 2015 sendet über Smarthost   und es ist eine Mail von intern nach extern nicht angekommen und der NDR liegt nicht vor  / unbekannt.
    2. Das der Smarthost externer SMTP Provider bei sich prüfen kann/muss ist klar...allerdings wollte ich fragen ob Exchange 2013 hinsichtlich Beweisführung SMTP Versand tatsächlich so unhandlich ist.
    3. Unter Start/Programme/ Exchange Toolbox habe ich die "Wizards bzgl. Versandprobleme suchen" noch nicht probiert, weil aus Erfahrung nur in folgenden Logs die Wahrheit steht
    4. Default Speicherort der LOGS:

      C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend
      C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceiv
       
    5. Wenn ich nach der Empfängerdomäne in den heutigen smtp log files gucke ist nix zu finden.
    6. Im ECP unter Sendeconntector wurde auf "Protokollierung ausführlich" geändert / Transportdienst neugestartet und erneute Testmail gesendet  > Empfänger Domäne dennoch nicht zu finden in den smtp txt logfiles.
    7. Die Auswertung bei FrankysWeb Message Tracking GUI DE  ist ziemlich kryptisch, ich werde daraus nicht schlau.    RTFM nehme ich an.

    Frage:   Es scheint nicht möglich zu sein, das man in diesen SMTP Log die SMTP Kommunikation deutlich / sofort sieht?

    (bei Mailversand von intern nach extern über Smarthost oder direkt ohne Smarthost)

    (auch nach einiger Zeit nicht nachdem die Mail versendet wurde) 

     

    Danke, Gruß

    Dirk

  13. Hallo Jan,

     

    es wird mit einer einzigen Email Domäne gearbeitet.

     

    Alle  Postfächer / User im Exchange / die der Exchange intern kennt -> müssten leider alle einmal über extern smarthost gehen.  (derzeit nur 20 Stück) (im Enddefekt geht es ggf. nur um 5 besondere  Postfächer)

     

    Das interne Mails / MFP Scans uvm.  länger dauern kann ist klar.

     

    Wie ginge das?

×
×
  • Neu erstellen...