none
[Exchange 2010; DAG] Event IDs 507, 118, 531, 245, 915 RRS feed

  • Frage

  • HI Community,

    seit letzter Woche verdichten sich die Hinweise, dass auf einem unserer DAG Knoten etwas mit den Datenbanken nicht mehr stimmt. Es gab letzte Woche einen Vorfall mit dem Storage, welches eine so große Latenz ausgelöst hat, dass die Datenbanken auf einem anderen Knoten aktiviert wurden, ich habe diesbzgl. aber keine Bestätigung auf dem ESX oder anderen virtuellen Servern auf dem Host gefunden.

    Seitdem bekomme ich einmal täglich die Events 507, 118 und 531 zur selben Zeit, nur für eine oder zwei Datenbanken, gestern war es eine andere Datenbank, morgen erwarte ich wieder andere Datenbanken wie heute. Der Vorfall ereignet sich nicht zu Zeiten eines Wartungszyclus, Backups oder Virenscans. Heute zB um 09:30 Uhr:

    ---snip---

    Protokollname: Application
    Quelle:        ESE
    Datum:         23.01.2019 09:27:52
    Ereignis-ID:   507
    Aufgabenkategorie:Leistung
    Ebene:         Warnung
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      UNIVERSE-4.DOMAIN.local
    Beschreibung:
    Information Store (4180) VWL1: Eine Anforderung für das Lesen aus der Datei "d:\VWL1\vwl1.edb" bei Offset 36497588224 (0x000000087f6d0000) für 262144 (0x00040000) Bytes war erfolgreich, aber die Bearbeitung durch das Betriebssystem dauerte sehr lange (54 Sekunden). Dieses Problem wurde wahrscheinlich durch fehlerhafte Hardware verursacht. Wenden Sie sich an den Hardwarehersteller, um Hilfe bei der Problemdiagnose zu erhalten.

    ---snap---

    Wie gesagt, auf ein Hardwareproblem deutet auf dem Host selber nichts hin.

    ---snip---

    Protokollname: Application
    Quelle:        ExchangeStoreDB
    Datum:         23.01.2019 09:27:54
    Ereignis-ID:   118
    Aufgabenkategorie:Database recovery
    Ebene:         Fehler
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      UNIVERSE-4.DOMAIN.local
    Beschreibung:
    '23.01.2019 09:27:52': Die Kopie der Datenbank 'VWL1' auf diesem Server weist anscheinend Leistungsprobleme auf, die möglicherweise auf einen Speicherfehler zurückzuführen sind. Überprüfen Sie das Ereignisprotokoll auf dem Server hinsichtlich anderer Speicher- und "ExchangeStoreDb"-Ereignisse, um detailliertere Informationen zu dem Fehler zu erhalten. Die Wiederherstellung wurde nicht ausgeführt.
    ---snap---

    ---snip---

    Protokollname: Application
    Quelle:        ESE
    Datum:         23.01.2019 09:28:15
    Ereignis-ID:   531
    Aufgabenkategorie:Datenbankbeschädigung
    Ebene:         Warnung
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      UNIVERSE-4.DOMAIN.local
    Beschreibung:
    Information Store (4180) Das Datenbankmodul hat versucht, einen bereinigenden Schreibvorgang für die Seite 1113817 der Datenbank 'd:\VWL1\vwl1.edb' auszuführen. Auf diese Weise sollte ein vorheriges Problem behoben werden, das beim Lesen der Seite aufgetreten ist.

    ---snap---

    Diese Meldung taucht dann öfter hintereinander auf.

    Soweit so gut, was jedoch nicht ganz ins Bild passt, ist die Tatsache, dass weitere Meldungen darauf hindeuten, dass alles in bester Ordnung ist:

    ---snip---

    Protokollname: Application
    Quelle:        MSExchangeRepl
    Datum:         23.01.2019 10:10:15
    Ereignis-ID:   4114
    Aufgabenkategorie:(1)
    Ebene:         Informationen
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      UNIVERSE-4.DOMAIN.local
    Beschreibung:
    Die Systemdiagnose im Hinblick auf die Datenbankredundanz war erfolgreich.
    Datenbankkopie: VWL1
    Redundanzanzahl: 2

    Fehler:


    ================
     Summary Status
    ================


    Name                 Status RealCopyQueu InspectorQue  ReplayQueue      CIState
                                           e           ue                          
    ----                 ------ ------------ ------------  -----------      -------
    VWL1\UNIVERSE       Mounted            0            0            0      Healthy
    -4                                                                             
    VWL1\UNIVERSE       Healthy            0            0            0      Healthy
    -3


    ===============
     Full Status
    ===============



    Identity                         : VWL1\UNIVERSE-4
    Name                             : VWL1\UNIVERSE-4
    DatabaseName                     : VWL1
    Status                           : Mounted
    MailboxServer                    : UNIVERSE-4
    ActiveDatabaseCopy               : universe-4
    ActivationSuspended              : False
    ActionInitiator                  : Administrator
    ErrorMessage                     :
    ErrorEventId                     :
    ExtendedErrorInfo                :
    SuspendComment                   :
    SinglePageRestore                : 0
    ContentIndexState                : Healthy
    ContentIndexErrorMessage         :
    CopyQueueLength                  : 0
    ReplayQueueLength                : 0
    LatestAvailableLogTime           :
    LastCopyNotificationedLogTime    :
    LastCopiedLogTime                :
    LastInspectedLogTime             :
    LastReplayedLogTime              :
    LastLogGenerated                 : 0
    LastLogCopyNotified              : 0
    LastLogCopied                    : 0
    LastLogInspected                 : 0
    LastLogReplayed                  : 0
    LogsReplayedSinceInstanceStart   : 0
    LogsCopiedSinceInstanceStart     : 0
    LatestFullBackupTime             : 21.01.2019 21:02:09
    LatestIncrementalBackupTime      :
    LatestDifferentialBackupTime     :
    LatestCopyBackupTime             :
    SnapshotBackup                   : True
    SnapshotLatestFullBackup         : True
    SnapshotLatestIncrementalBackup  :
    SnapshotLatestDifferentialBackup :
    SnapshotLatestCopyBackup         :
    LogReplayQueueIncreasing         : False
    LogCopyQueueIncreasing           : False
    OutstandingDumpsterRequests      : {}
    OutgoingConnections              :
    IncomingLogCopyingNetwork        :
    SeedingNetwork                   :
    ActiveCopy                       : True

    Identity                         : VWL1\UNIVERSE-3
    Name                             : VWL1\UNIVERSE-3
    DatabaseName                     : VWL1
    Status                           : Healthy
    MailboxServer                    : UNIVERSE-3
    ActiveDatabaseCopy               : universe-4
    ActivationSuspended              : False
    ActionInitiator                  : Service
    ErrorMessage                     :
    ErrorEventId                     :
    ExtendedErrorInfo                :
    SuspendComment                   :
    SinglePageRestore                : 0
    ContentIndexState                : Healthy
    ContentIndexErrorMessage         :
    CopyQueueLength                  : 0
    ReplayQueueLength                : 0
    LatestAvailableLogTime           : 23.01.2019 10:09:42
    LastCopyNotificationedLogTime    : 23.01.2019 10:09:42
    LastCopiedLogTime                : 23.01.2019 10:06:01
    LastInspectedLogTime             : 23.01.2019 10:06:01
    LastReplayedLogTime              : 23.01.2019 10:06:01
    LastLogGenerated                 : 670484
    LastLogCopyNotified              : 670484
    LastLogCopied                    : 670484
    LastLogInspected                 : 670484
    LastLogReplayed                  : 670484
    LogsReplayedSinceInstanceStart   : 180
    LogsCopiedSinceInstanceStart     : 174
    LatestFullBackupTime             : 22.01.2019 21:02:46
    LatestIncrementalBackupTime      :
    LatestDifferentialBackupTime     :
    LatestCopyBackupTime             :
    SnapshotBackup                   : True
    SnapshotLatestFullBackup         : True
    SnapshotLatestIncrementalBackup  :
    SnapshotLatestDifferentialBackup :
    SnapshotLatestCopyBackup         :
    LogReplayQueueIncreasing         : False
    LogCopyQueueIncreasing           : False
    OutstandingDumpsterRequests      : {}
    OutgoingConnections              :
    IncomingLogCopyingNetwork        :
    SeedingNetwork                   :
    ActiveCopy                       : False
    ---snap---

    Diese Meldung kommt für jede Datenbank _nach_ den oben gezeigten Fehlermeldungen und Warnungen.Im BlockReplication Logfile habe ich noch Warnungen stehen, die im Zusammenhang mit einer Mitteilung über vermisste Transaction Logs stehen könnte:

    ---snip---

    Protokollname: Microsoft-Exchange-HighAvailability/BlockReplication
    Quelle:        Microsoft-Exchange-HighAvailability
    Datum:         21.01.2019 14:01:03
    Ereignis-ID:   245
    Aufgabenkategorie:BlockReplication
    Ebene:         Warnung
    Schlüsselwörter:
    Benutzer:      SYSTEM
    Computer:      UNIVERSE-4.DOMAIN.local
    Beschreibung:
    Block-mode replication for database copy 'RED1\UNIVERSE-4' released a range of complete but unfinalized logs from generation 0x76375 to 0x76377. The data is identical to the active copy but the file timestamps may differ by a small value.
    ---snap---

    ---snip---

    Protokollname: Application
    Quelle:        ESE BACKUP
    Datum:         22.01.2019 09:04:07
    Ereignis-ID:   915
    Aufgabenkategorie:General
    Ebene:         Warnung
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      UNIVERSE-4.DOMAIN.local
    Beschreibung:
    Information Store (4180) Es wurden 2776 Protokolldateien im Protokollbereich (d:\DTP1\E04000A55C3.log - d:\DTP1\E04000A609A.log) nicht gefunden, für die ein Abschneideversuch unternommen wurde.
    ---snap---

    Diese Meldung haben wir für alle Datenbanken und sehr viele Logdateien erhalten. Ein Backup machen wir aber auch eigentlich nur auf dem anderen, inaktiven Knoten.

    Ein Integrity Check einer Testdatenbank brachte jedoch auch nicht beunruhigendes zu Tage:

    ---snip---

    [PS] C:\Windows\system32>eseutil.exe /mh "C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\TEST\test.edb"

    Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
    Version 14.03
    Copyright (C) Microsoft Corporation. All Rights Reserved.

    Initiating FILE DUMP mode...
             Database: C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\TEST\test.edb


    DATABASE HEADER:
    Checksum Information:
    Expected Checksum: 0x15a17dee
      Actual Checksum: 0x15a17dee

    Fields:
            File Type: Database
             Checksum: 0x15a17dee
       Format ulMagic: 0x89abcdef
       Engine ulMagic: 0x89abcdef
     Format ulVersion: 0x620,17
     Engine ulVersion: 0x620,17
    Created ulVersion: 0x620,17
         DB Signature: Create time:09/20/2016 13:37:14 Rand:3623090 Computer:
             cbDbPage: 32768
               dbtime: 27316056 (0x1a0cf58)
                State: Clean Shutdown
         Log Required: 0-0 (0x0-0x0)
        Log Committed: 0-0 (0x0-0x0)
       Log Recovering: 0 (0x0)
      GenMax Creation: 00/00/1900 00:00:00
             Shadowed: Yes
           Last Objid: 1909
         Scrub Dbtime: 0 (0x0)
           Scrub Date: 00/00/1900 00:00:00
         Repair Count: 0
          Repair Date: 00/00/1900 00:00:00
     Old Repair Count: 0
      Last Consistent: (0xFED4,48,11A)  01/23/2019 09:11:00
          Last Attach: (0xFE86,9,86)  01/22/2019 08:57:22
          Last Detach: (0xFED4,48,11A)  01/23/2019 09:11:00
                 Dbid: 1
        Log Signature: Create time:09/20/2016 13:37:14 Rand:3620083 Computer:
           OS Version: (6.1.7601 SP 1 NLS ffffffff.ffffffff)
         Reseed Count: 1
          Reseed Date: 01/15/2019 17:05:55
     Old Reseed Count: 0
          Patch Count: 2
           Patch Date: 01/15/2019 17:05:55
      Old Patch Count: 0

    Previous Full Backup:
            Log Gen: 65181-65186 (0xfe9d-0xfea2) - OSSnapshot
               Mark: (0xFEA3,9,A8)
               Mark: 01/22/2019 22:02:46

    Previous Incremental Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Previous Copy Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Previous Differential Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Current Full Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Current Shadow copy backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

         cpgUpgrade55Format: 0
        cpgUpgradeFreePages: 0
    cpgUpgradeSpaceMapPages: 0

           ECC Fix Success Count: none
       Old ECC Fix Success Count: none
             ECC Fix Error Count: none
         Old ECC Fix Error Count: none
        Bad Checksum Error Count: none
    Old bad Checksum Error Count: none

      Last checksum finish Date: 01/21/2019 19:16:56
    Current checksum start Date: 00/00/1900 00:00:00
          Current checksum page: 0


    Operation completed successfully in 0.94 seconds.

    ---snap---

    So jetzt stellen sich die Fragen, was ist passiert, was ist kaputt und wie bekomme ich das am besten repariert?

    Vielen Dank fürs Lesen bis hierher

    Bye Tom


    Mittwoch, 23. Januar 2019 11:17

Alle Antworten

  • ich kenne nun Dein System zu wenig aber ich vermute Festplattenprobleme infolgedessen die Festplatten Bloecke neu sortieren und diesse dazu fuehrt dass es sehr grosse Latenzen gibt. 

    ggf. ist es sinnvoll sich die SMART Values der Festplatten anzusehen und nach Schreib- Lesefehlern zu suchen. Wenn dieser erhoeht sind, wuerde ich dringend die betroffenen Festplatten tauschen.

    Leider beschreibst du nicht deinen "Vorfall mit dem Storage" und was du gemacht hast. Wenn also noch alte Platten in deiner DB Replikation vohanden sind, wuerde ich diese ebenfalls auf Fehler hin untersuchen und ggf. tauschen.

    um Fehler ins. Inkonsistenzen zu beseitigen dienst das Programm eseutil mit diesem koennen die Fehler bereinigt werden.


    regards Thomas Paetzold visit my blog on: http://sus42.wordpress.com

    Donnerstag, 24. Januar 2019 16:26
  • Servus Thomas,

    >ggf. ist es sinnvoll sich die SMART Values der Festplatten anzusehen und nach Schreib- Lesefehlern zu suchen.

    Die SMART Daten auf dem Host sind alle mit Status ok aber wir haben in dmesg eine Fülle von Daten, von denen wir noch nicht wissen, was sie konkret bedeuten, die aber durchaus auf ein Problem mit dem Storage hindeuten:

    ---snip---

    Controller Daten und Disk Daten soweit in Ordnung, jedoch immer wieder folgende Meldungen im Kernel Log des Hosts:

    2019-01-25T08:44:39.379Z cpu12:8204)NMP: nmp_ThrottleLogForDevice:2346: Cmd 0x85 (0x412440406dc0, 19629095) to dev "naa.600508b1001c9f001e77aaf9538be863" on path "vmhba1:C0:T0:L2" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0. Act:NONE
    2019-01-25T08:44:39.389Z cpu12:8204)ScsiDeviceIO: 2358: Cmd(0x412440406dc0) 0x4d, CmdSN 0x17905 from world 19629095 to dev "naa.600508b1001c9f001e77aaf9538be863" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0.
    2019-01-25T08:44:39.389Z cpu12:8204)ScsiDeviceIO: 2358: Cmd(0x412440406dc0) 0x1a, CmdSN 0x17906 from world 19629095 to dev "naa.600508b1001c9f001e77aaf9538be863" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.
    2019-01-25T08:44:39.474Z cpu12:8204)NMP: nmp_ThrottleLogForDevice:2346: Cmd 0x85 (0x412441db95c0, 19629097) to dev "naa.600508b1001c99963b8f8fe230231d66" on path "vmhba1:C0:T0:L1" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0. Act:NONE
    2019-01-25T08:44:39.484Z cpu12:8204)ScsiDeviceIO: 2358: Cmd(0x412441db95c0) 0x4d, CmdSN 0x17908 from world 19629097 to dev "naa.600508b1001c99963b8f8fe230231d66" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0.
    2019-01-25T08:44:39.484Z cpu12:8204)ScsiDeviceIO: 2358: Cmd(0x412441db95c0) 0x1a, CmdSN 0x17909 from world 19629097 to dev "naa.600508b1001c99963b8f8fe230231d66" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.
    2019-01-25T08:47:38.603Z cpu0:19628910)User: 2744: wantCoreDump : sfcb-smx -enabled : 0


    Hier nochmal etwas was auch sehr nach Storage Hardware aussieht:

    2019-01-17T02:55:38.945Z cpu14:8368)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-17T02:55:38.945Z cpu14:8368)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-17T02:55:38.945Z cpu14:8368)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-17T02:55:40.947Z cpu14:8368)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-17T02:55:40.947Z cpu14:8368)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-17T02:55:40.947Z cpu14:8368)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-17T02:55:42.949Z cpu14:8368)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1


    2019-01-24T13:58:42.139Z cpu4:15443)VSCSI: 2386: handle 8193(vscsi0:1):Reset request on FSS handle 179459 (1 outstanding commands) from (vmm0:UNIVERSE-4)
    2019-01-24T13:58:42.139Z cpu10:8314)VSCSI: 2665: handle 8193(vscsi0:1):Reset [Retries: 0/0] from (vmm0:UNIVERSE-4)
    2019-01-24T13:58:42.139Z cpu10:8314)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-24T13:58:42.139Z cpu10:8314)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-24T13:58:42.139Z cpu10:8314)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-24T13:58:42.139Z cpu10:8314)WARNING: VSCSIFs: 295: handle 8193(vscsi0:1):Failed reset of virtual target 179459, (initiator 0x4100156a3480, 0): Failure
    2019-01-24T13:58:45.194Z cpu4:15443)WARNING: VSCSI: 3493: handle 8193(vscsi0:1):WaitForCIF: Issuing reset;  number of CIF:2
    2019-01-24T13:58:45.194Z cpu4:15443)WARNING: VSCSI: 2428: handle 8193(vscsi0:1):Ignoring double reset
    2019-01-24T13:59:12.774Z cpu10:8314)VSCSI: 2665: handle 8193(vscsi0:1):Reset [Retries: 1/0] from (vmm0:UNIVERSE-4)
    2019-01-24T13:59:12.774Z cpu10:8314)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-24T13:59:12.774Z cpu10:8314)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-24T13:59:12.774Z cpu10:8314)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver hpsa, for vmhba1
    2019-01-24T13:59:12.774Z cpu10:8314)WARNING: VSCSIFs: 295: handle 8193(vscsi0:1):Failed reset of virtual target 179459, (initiator 0x4100156a3480, 0): Failure
    2019-01-24T13:59:17.366Z cpu10:8314)VSCSI: 2462: handle 8193(vscsi0:1):Completing reset (0 outstanding commands)
    ---snap---

    Die Mewldungen gehen Monate zurück, warum das die VMware-Serveranwendung nicht mitbekommt, wissen wir derzeit noch nicht.

    >Leider beschreibst du nicht deinen "Vorfall mit dem Storage" und was du gemacht hast.

    Dieser konkrete Vorfall war nur aufgrund der Daten aus dem Windows Logfile gemeint. Zu diesem Zeitpunkt hatte ich auf dem Host nur die Logfiles im Frontend überprüft, die nicht auf ein Problem mit dem Host hindeuteten.

    >Wenn also noch alte Platten in deiner DB Replikation vohanden sind, wuerde ich diese ebenfalls auf Fehler hin untersuchen und ggf. tauschen.

    Wenn es nicht der Controller ist...

    >um Fehler ins. Inkonsistenzen zu beseitigen dienst das Programm eseutil mit diesem koennen die Fehler bereinigt werden.

    Es wird wohl darauf hinauslaufen, dass wir den betroffenen Host evakuieren müssen und den Exchange auf einen anderen Host verlegen. Spricht etwas bei vorliegendem Fehlerbild gegen einen Neustart? Wir würden dann den Exchange offline synchronisieren.

    Hier mal noch eine Grafik über den zeitlichen Ablauf des Problem, wenn die Datenbanken geschwenkt werden:

    Wie würde es weitergehen, wenn der Exchange auf einem sicheren Host verschoben wurde?

    Thx & Bye Tom

    Freitag, 25. Januar 2019 09:17
  • Servus Thomas,

    also wir haben am Wochenende die VM des betroffenen Servers auf einen anderen Host migriert, nachdem wir im Host-Logfiles Fehler gefunden haben, die mit dem Storage zusammenhingen. Die Datenbanken scheinen sich aber soweit selber gemanaget zu haben, da wir bislang keinerlei Warnungen oder Fehler mehr bekommen haben, die auf Probleme mit der Konsistenz der Datenbanken in Zusammenhang stehen.

    Wir vermuten, dass das Storage keine fehlerhaften Blöcke hatte, sondern aus irgendeinem Grund die Latenz soweit gestiegen ist, dass die DAG in einen Failover Modus gegangen ist. Das Fehlen von Hinweisen auf defekte Blöcke in den SMART Daten der betroffenen Festplatten stützt diese These.

    Puh, die Ereignisanzeigen der betroffenen Server sehen zwar noch aus wie ein Trümmerfeld nach einem Bombenangriff aber das sortiert sich in der Übersicht dann schon langsam aus. Aber so insgesamt scheint das Konstrukt der Exchange Datenbanken eine relativ robuste Angelegenheit zu sein, hoffentlich bleibt das bei Exchange 2016 auch so, dahin migrieren wir nämlich die nächsten Monate...

    Thx & Bye Tom

    Dienstag, 29. Januar 2019 11:44
  • na das hoert sich doch gut an. Wir setzen bereits Exchange 2016 seit 2017 ein. Bisher ohne Probleme toi toi toi.

    viele Gruesse

     Thomas 


    regards Thomas Paetzold visit my blog on: http://sus42.wordpress.com

    Montag, 4. Februar 2019 10:07