Tracking 2016

Diese Seite ist eigentlich entstanden, weil ich ermitteln musste, welche Clients per SMTP anonym Mails einliefern. Heraus gekommen ist dann aber doch eine etwas umfangreichere Analyse des Exchange 2016 Tracking Logs.

Tracking von verschiedenen Quellen

Ich habe daher erst mal einen Test gemacht, wie die Mails eingeliefert werden und folgende fünf Fälle betrachtet:

  • Authentifizierter Versand per Outlook über MAPI/HTTP
  • Authentifizierter Versand per Outlook Web App
  • Authentifizierter Versand per ActiveSync
  • Authentifizierter Versand per SMTP
  • Anonymer Versand per SMTP

Das entsprechende Messagetracking ergibt:

[PS] C:\>Get-MessageTrackingLog | sort timestamp| ft messagesubject,source,eventid,originalclientip,clientip,kmessageinfo

MessageSubject Source      EventId      OriginalClientIp ClientIp                     MessageInfo
-------------- ------      -------      ---------------- --------                     -----------
EAS            STOREDRIVER RECEIVE                       fe80::c576:b2c3:f631:f737    04I:
EAS            SMTP        RECEIVE      192.168.100.33   192.168.100.33               0cI:
EAS            STOREDRIVER SUBMIT                        fe80::c576:b2c3:f631:f737%12 2018-02-05T12:56:41.168Z;LSRV=NAWEX16.neta...
EAS            AGENT       AGENTINFO    192.168.100.33
EAS            ROUTING     TRANSFER
EAS            SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T12:56:41.168Z;SRV=NAWEX16.netat...
OWA            STOREDRIVER RECEIVE      192.168.100.5    fe80::c576:b2c3:f631:f737    04I:
OWA            SMTP        RECEIVE      192.168.100.5    192.168.100.33               0cI:
OWA            STOREDRIVER SUBMIT       192.168.100.5    fe80::c576:b2c3:f631:f737%12 2018-02-05T12:58:12.622Z;LSRV=NAWEX16.neta...
OWA            AGENT       AGENTINFO    192.168.100.5
OWA            ROUTING     TRANSFER
OWA            SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T12:58:12.622Z;SRV=NAWEX16.netat...
Outlook        STOREDRIVER RECEIVE      192.168.103.56   fe80::c576:b2c3:f631:f737    04I:
Outlook        SMTP        RECEIVE      192.168.103.56   192.168.100.33               0cI:
Outlook        STOREDRIVER SUBMIT       192.168.103.56   fe80::c576:b2c3:f631:f737%12 2018-02-05T12:59:27.467Z;LSRV=NAWEX16.neta...
Outlook        AGENT       AGENTINFO    192.168.103.56
Outlook        ROUTING     TRANSFER
Outlook        SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T12:59:27.467Z;SRV=NAWEX16.netat...
SMTP Auth      SMTP        RECEIVE      192.168.103.56   192.168.100.33               07I:
SMTP Auth      AGENT       AGENTINFO    192.168.103.56
SMTP Auth      SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T13:07:41.772Z;SRV=NAWEX16.netat...
smtpanon       SMTP        RECEIVE      192.168.103.56   192.168.100.33               0cA:
smtpanon       AGENT       AGENTINFO    192.168.103.56
smtpanon       SMTP        SEND                          192.168.100.33               2018-02-05T13:09:07.107Z;LSRV=NAWEX16.neta...
smtpanon       STOREDRIVER DELIVER      192.168.103.56                                2018-02-05T13:09:07.107Z;SRV=NAWEX16.netat...
EWSTest        STOREDRIVER RECEIVE      192.168.103.56   fe80::c576:b2c3:f631:f737    04I:
EWSTest        SMTP        RECEIVE      192.168.103.56   192.168.100.33               0cI:
EWSTest        STOREDRIVER SUBMIT       192.168.103.56   fe80::c576:b2c3:f631:f737%12 2018-02-05T13:27:12.152Z;LSRV=NAWEX16.neta...
EWSTest        AGENT       AGENTINFO    192.168.103.56
EWSTest        ROUTING     TRANSFER
EWSTest        SMTP        SENDEXTERNAL                  192.168.100.33               2018-02-05T13:27:12.152Z;SRV=NAWEX16.netat...

Genau genommen fehlt hier natürlich noch die RESTAPI. Der Fall "SMTP-Anon" ist ein Sonderfall, da ich hier die Mail lokal zustellen musste (Mein Exchange ist kein Anonymes offenes Relay)

Der Weg zum Postfach auf einem einzelnen Server

Ich habe mir die sechs Wege durch den Exchange Server erst einmal skizziert. Das ist gar nicht so einfach, wenn auf einem Server alle Funktionen sehr schnell ablaufen und die Protokollierung im Messagetracking nicht in der zeitlich korrekten Abfolge geschrieben wird.

Es ist gut zu sehen, dass "SMTP/RECEIVE" also auch "AGENT/AGENTINFO" von allen Mails durchlaufen wird. Sie sehen hier auch gut den "Sonderfall SMTP Anonym" und die letzten beiden Stationen sind natürlich auch für eine Einlieferung über die anderen Fälle gültig. Der "STORE/SUBMIT" zeigt auch, wann die Mail in "Gesendete Objekte erscheint".

Der Weg durch mehrere Server

Interessant wird es, wenn Sie nun zwei oder mehr Server haben. Hier werden die Mails ggfls. über unterschiedliche Transport-Systeme übertragen und auch der ShadowCache sorgt für zusätzliche Events. Zudem scheint es Events zu geben, die auf einem Single-Server nicht erscheinen, z.B. MAPI/NOTIFY. Hier einfach mal eine Mail von zwei internen Postfächern. Die Events sind von zwei Servern und aufgrund der engen Zeitstempel bin ich nicht sicher, ob die Reihenfolge so passt.

Timestamp           Source      EventId    MessageInfo
---------           ------      -------    -----------
13.04.2017 17:15:29 STOREDRIVER RECEIVE    04I:
13.04.2017 17:15:29 SMTP        RECEIVE    0cI:
13.04.2017 17:15:29 SMTP        HAREDIRECT
13.04.2017 17:15:29 SMTP        HARECEIVE
13.04.2017 17:15:29 STOREDRIVER SUBMIT     2018-02-01T16
13.04.2017 17:15:29 AGENT       AGENTINFO
13.04.2017 17:15:29 STOREDRIVER DELIVER    2018-02-01T16
13.04.2017 17:15:30 SMTP        SEND       2018-02-01T16
13.04.2017 17:15:31 SMTP        HADISCARD

Der Weg durch die Server ist erst mal identisch aber hinzu kommen hier die Kopien auf eigenem anderen Server für die Hochverfügbarkeit:

Wenn ich in dem Fall ein "Anonymes Relay nacherfolge, dann sehe ich:

Timestamp           Source EventId    MessageInfo
---------           ------ -------    -----------
13.04.2017 16:52:02 SMTP   RECEIVE    0cA:
13.04.2017 16:52:02 SMTP   HAREDIRECT
13.04.2017 16:52:02 AGENT  AGENTINFO
13.04.2017 16:52:02 SMTP   SEND       2018-02-01T1
13.04.2017 16:52:02 SMTP   HARECEIVE
13.04.2017 16:52:56 SMTP   HADISCARD
13.04.2017 16:53:15 SMTP   HADISCARD
13.04.2017 16:53:36 SMTP   HARECEIVE
13.04.2017 16:53:36 SMTP   HAREDIRECT
13.04.2017 16:53:36 SMTP   RECEIVE    0cA:
13.04.2017 16:53:36 AGENT  AGENTINFO
13.04.2017 16:53:37 SMTP   SEND       2018-02-01T1
13.04.2017 16:54:04 SMTP   HADISCARD
13.04.2017 16:54:51 SMTP   HADISCARD

So genau habe ich aber diesen Durchlauf nun auch nicht mehr verstanden. Der Hauptweg der Mail ist verständlich und sie sehen auch, dass hier anscheinend die Agenten zweimal aktiv werden und ganz viele Einträge der Hochverfügbarkeit des Transport geschuldet sind.

Der erste Aufschlag: Feld: OriginalClientIP

Mein Ziel war es zu erkunden, wie die ersten Einträge im Tracking bezüglich EventID, OriginalClientIP und ClientIP aussieht. Schaut man sich das Tracking nun genauer an, dann findet man pro Weg unterschiedliche erste "Treffer". Zusätzlich habe ich mir die erste "ReceivedBy"-Zeile in der empfangenen Mail angeschaut, auch wenn diese im Messagetracking nicht aber auf dem Client meist sichtbar ist.

Protokoll Source und Event MessageInfo OriginalClientIP ClientIP ReceivedBy:  with...

EAS

STORE RECEIVE
STORE RECEIVE

04I:
0cI:

Leer
Exchange FE IPv4

Exchange FE IPv6
Exchange FE IPv4

mapi

OWA

STORE RECEIVE
STORE RECEIVE

04I:
0cI:

Client oder Proxy
Client oder Proxy

Exchange FE IPv6
Exchange FE IPv4

mapi

Outlook

STORE RECEIVE
STORE RECEIVE

04I:
0cI:

Client oder Proxy
Client oder Proxy

Exchange FE IPv6
Exchange FE IPv4

mapi

SMTP Auth

SMTP RECEIVE

07I:

Client IP

Exchange FE IPv4

Microsoft SMTP Server

SMTP Anonym

SMTP RECEIVE

0cA:

Client IP

Exchange FE IPv4

Microsoft SMTP Server

EWS

STORE RECEIVE
STORE RECEIVE

04I:
0cI:

Client IP
Client IP

Exchange FE IPv6
Exchange FE IPv4

mapi

Sie sehen hier schon gut, dass das Feld "OriginalClientIP" bis auf den Sonderfall ActiveSync immer die IP-Adresse des einliefernden Clients enthält, Diese Feld wird sogar in der Folge weiter mitgeführt, d.h. selbst beim finalen Zustellen in eine Mailbox mit "STOREDRIVER:DELIVER" oder dem Versand nach extern mittels "SMTP:SEND" die der Inhalt von "OriginalClientIP" vorhanden und erlaubt eine schnelle Analyse von wo nach wo die Mail geroutet wurde.

Hier interessieren mich einige Fehler für die spätere Auswertung:

  • ClientIP
    Es ist gut zu sehen, dass mit Ausnahme von SMTP-Einlieferungen die "ClientIP" immer die Exchange interne IPv6-Adresse ist. Dieses Feld ist für eine Auswertung nach der Quelle nicht geeignet
  • OriginalClientIP
    Daher wird Microsoft auch dieses Feld eingeführt haben, damit man zumindest halbwegs erkennen kann, welcher Client hier verbunden war. Interessanterweise liefert ActiveSync hier keine Information mit.
  • Source und Event
    Nur SMTP umgeht den Store. Alle anderen Protokolle legen ihre Mails quasi im Postausgang des Anwenders ab und werden dort abgeholt.
  • MessageInfo
    Dieses Feld habe ich lange nicht weiter betrachtet. Aber es ist wichtig um mehr Details zur Einlieferung zu erhalten

Bei der Betrachtung der ersten Einträge je nach Protokoll fällt auf, dass jede Mail eine "SMTP-RECEIVE"-Zeile hat. Das ist ja auch verständlich, da jede Mail durch den SMTP-Tramsport durch geroutet wird. Wer allerdinge mehrere Server hat und eine Mail mehrere Stationen durchläuft, wird entsprechend mehrere Einträge finden. Auch wenn mehrere Empfänger zu adressieren sind und die Mail vielleicht noch aufgesplittet wird (Bifurcation), wird mehrere dieser Einträge finden. für eine "Zählung" müssen Sie also noch etwas genauer hinschauen. Aber auch der Eintrag "AGENT/AGENTINFO" kann für eine Mail mehrfach auftreten. Ich habe aber zwei solcher Einträge verglichen und sie sind identisch. Für eine Zählung der Mails alleine aber auch kein 100% zuverlässiger Event. Dubletten und damit Falschzählungen sind möglich.

Feld Messageinfo

Auf der Suche nach einer verlässlichen Quelle zur Erkennung von "anonymen Mails" habe ich die beiden Logs zu "SMTP Auth" und "SMTP Anonym" verglichen und abgesehen von dem Timestamp und dem Betreff hat sich nur noch das Feld "MessageInfo" unterschieden: . Also habe ich mir mal genauer angeschaut, welche Events es bei mir gibt. Das Feld hat manchmal eine dreistellige Kombination aber später enthält es viel mehr Daten. Hier mal ein Auszug einer Mail:

MessageSubject Source      EventId      MessageInfo
-------------- ------      -------      -----------
Outlook        STOREDRIVER RECEIVE      04I:
Outlook        SMTP        RECEIVE      0cI:
Outlook        STOREDRIVER SUBMIT       2018-02-05T12:59:27.467Z;LSRV=EX16.msxfaq.de:TOTAL-SUB=0.328|SA=0.078|MTSS=0.253(M...
Outlook        AGENT       AGENTINFO
Outlook        ROUTING     TRANSFER
Outlook        SMTP        SENDEXTERNAL 2018-02-05T12:59:27.467Z;SRV=EX16.msxfaq.de:TOTAL-SUB=0.203|SA=0.078|MTSS-PEN=0.12...

Einige Events sind leer und einige andere Events enthalten umfangreiche Verarbeitungsinformationen. Das Feld gibt es wohl seit Exchange 2007 und die Bedeutung is wie folgt umschrieben

The message origination date-time in UTC for DELIVER and SEND events. The origination date-time is the time when the message first entered the Exchange organization. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, T indicates the beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC.
Authentication errors. For example, you may see the value 11a and the type of authentication that was used when the authentication error occurred.
Message tracking
https://technet.microsoft.com/en-us/library/bb124375(v=exchg.160).aspx

Leider gibt es keine Auflistung für die "Authentication Errors". Also habe ich die obige Liste genommen und versucht zu ermitteln, welche Events damit verbunden sind. Ich war natürlich neugierig, welche Events dahinter verborgen waren. Ich habe ein paar Versuche gebraucht um zu erkennen, dass bei den kurzen Einträgen ein "Leerzeichen" hinter dem Doppelpunkt steht. So sah dann die Verteilung bei mir aus:

Get-MessageTrackingLog `
   -Start (get-date).adddays(-10) `
   -ResultSize unlimited `
| ?{$_.messageinfo -like "*: "} `
| group messageinfo `
   -NoElement

Folgende Einträge habe ich mit der angegebenen Häufigkeit und den verbundenen Events gefunden und aus verschiedenen anderen Quellen zusammengesucht:

Code Häufigkeit Events Connector Beschreibung

0cI:

7044

SMTP/RECEIVE

Default Receive Connector

Interne Absender, vermutlich authentifiziert

07I:

7486

SMTP/RECEIVE

Client Receive Connector

Über den Port 465 angenommene

0cA:

13678

SMTP/RECEIVE

Default Receive Connector

Die Absenderadresse ist extern.

0cI:

 

SMTP/RECEIVE

Default Receive Connector

Die Absenderadresse ist intern

05I:

1

AGENT/RECEIVE

 

Bei mir war das eine Mail des Malware Agent

03I:

465

MAILBOXRULE/RECEIVE
STOREDRIVER//RECEIVE

$null

Automatische Antworten, Weiterleitungen
Angeblich auch ein Hinweis auf MAPI ohne RPC-Encryption

04I:

5762

STOREDRIVER/RECEIVE

$null

Von Anwendern zum Versand übergebene Nachrichten. Darunter fallen auch HealthMailboxen.
Andere Quellen MAPI beschreiben diese als Zugriffe per RPC Verschlüsselung

00a:

0

?

?

Angeblich Keine Verschlüsselung, Anonym per SMTP empfangen

0aI:

0

?

?

Authentifiziertes SMTP empfangen

Wenn Sie weitere Events finden und zuordnen können, dann bin ich für Hinweise dankbar.

Feld Directionality

Im Messagetracking habe ich noch ein Feld "Directionality" entdeckt. Auch hier habe erst etwas Hoffnung gehabt aber eine schnelle Auswertung hat gezeigt, dass diese Angabe der Richtung wenig beitragen kann

Get-TransportService | Get-MessageTrackingLog -ResultSize 1000 | group Directionality 

Count Name
----- ----
11165 Originating
9569 Incoming
1124

Bei der Analyse, welche Event mit welchen Einträgen vorkommen, können Sie schon selbst erkennen, dass man hier wohl nicht weiter kommt.

directionality Source/Event

Incoming

STOREDRIVER/DELIVER
STOREDRIVER/DUPLICATEDELIVER

Originating

STOREDRIVER: DELIVER
STOREDRIVER: RECEIVE
STOREDRIVER: DUPLICATEDELIVER
STOREDRIVER: SUBMIT
STOREDRIVER: THROTTLE
MAILBOXRULE: RECEIVE

Irgendwie logisch, dass ein "Deliver" bei "Incoming auftaucht". Aber ich habe keinen einzigen Event von SMTP oder AGENT gefunden, der das Feld "Directioality" gesetzt hätte. Als Kriterium für die "Richtung" ist das Feld damit wohl schon ziemlich überflüssig.

Feld: MessageID u.a.

Wenn Sie sich bei SMTP/RECEIVE mal so einen Header anschauen, dann fallen ihnen gleich mehrere Felder auf, die etwas mit einer MessageID zu tun haben. Die werden gerne als primärer Schlüssel für die Suche von zusammen gehörenden Mails genutzt. Das ist aber nicht immer so einfach

RunspaceId              : 0f13ec85-1234-1234-1234-67d8cc282755
Timestamp               : 2/09/2018 11:28:01 AM
ClientIp                : 192.168.1.26
ClientHostname          : EX2016B.msxfaq.net
ServerIp                : 192.168.1.16
ServerHostname          : EX2016A
SourceContext           : 08D572C8F08A428A;2018-02-09T10:27:48.749Z;9
ConnectorId             : EX201A\Default EX201A
Source                  : SMTP
EventId                 : RECEIVE
InternalMessageId       : 468967479081
MessageId               : <2127232375.466@ex2016A.msxfaq.net>
NetworkMessageId        : 5e630e82-bf20-5678-5678-08d572cc7562
Recipients              : {user2@msxfaq.com}
RecipientStatus         : {}
TotalBytes              : 3636
RecipientCount          : 1
RelatedRecipientAddress :
Reference               :
MessageSubject          : TestMessage
Sender                  : user1@msxfaq.de
ReturnPath              : user1@msxfaq.de
Directionality          : Incoming
TenantId                :
OriginalClientIp        : 80.66.20.20
MessageInfo             : 0cA:
MessageLatency          :
MessageLatencyType      : None
EventData               : {[ProxyHop1, EX2016A.com.msxfaq.net(192.168.1.26)], [MessageValue, MediumHigh], [Replication, EX2016B], [FirstForestHop,
                          EX2016C.com.msxfaq.net], [FromEntity, Internet], [ProxiedClientIPAddress, 80.66.20.20], [ProxiedClientHostname,
                          EX2016EDGE.dmz.msxfaq.net], [DeliveryPriority, Normal], [OriginalFromAddress, user1@msxfaq.net],
                          [AccountForest, msxfaq.net]}
TransportTrafficType    : Email
SchemaVersion           : 15.01.1261.035

Interessant sind natürlich Felder, die über mehrere Stationen unverändert bleiben und einmalig sind. Es ist sonst gar nicht so einfach zu ermitteln, ob mehrere Events nun die gleiche Mail auf mehreren Zwischenstationen darstellen oder ob eine Mail an mehrere Empfänger entsprechende Events erzeugt. Meine Erkenntnisse sind soweit:

  • MessageID
    Durch den Absender vorgegeben aber wird von Exchange addiert, wenn sie fehlt. sie sollte pro gesendeter Mail eindeutig sein. Wird die gleiche Mail zugleich an mehrere Empfänger gesendet, (CC, BCC), dann gibt es mehrere Mails mit der gleichen MessageID
  • InternalMessageId
    Diese ID scheint Exchange selbst zu generieren. Allerdings habe ich schon zwei komplett unterschiedliche Mails mit der gleichen "InternalMessageId" gefunden. Richtig brauchbar ist das Feld daher nicht
  • NetworkMessageId
    Dieses Feld wird auch von Exchange vergeben und ist wohl innerhalb der Organisation einmalig und beständig. Es eignet sich vortrefflich, um z.B. mehrfache Events zusammen zu fassen.

Sprechend ist von den drei Feldern natürlich die MessageID. Aus Datenschutzgründen könnte es aber nicht gewünscht sein, den Inhalt dieses Felds zu verwenden. Dann ist NetworkMessageID ein gleichwertiges Feld. Nur dem Inhalt von InternalMessageID vertraue ich nicht.

Anonyme Einlieferer erkennen

Wenn ich die ganze Beschreibung nun Revue passieren lasse, dann gibt es mit Exchange 2016 aktuell nur einen Weg, die anonyme Zustellung an Exchange zu erfassen. Man sammelt alle SMTP/RECEIVE-Events, bei denen die MessageInfo den Wert "0cA: " hat. Zumindest ist die aktuell aus meiner Sicht für Exchange 2016 CU7 zutreffend.

Einfacher haben es natürlich die Administratoren, die eine anonyme Zustellung per Default gar nicht erlauben, wie es bei Exchange 2007/2010 noch Default war, und daher einen eigenen SMTP-Receive Connector für die Annahme ohne Authentifizierung angelegt haben. Idealerweise legt man gleich zwei Connector an, um interne Einlieferer von den extern empfangenden Mails zu trennen. Dann können Sie auf dem internen Receive-Connector u.a. die IP-Adressliste getrennt verwalten und über das Messagetracking genau die Quellen anhand des Feldes "ConnectorID" filtern.

Hier der erste "Check", ob es denn solche Mails gibt.

Get-transportservice `
| get-messagetrackinglog `
   -source SMTP `
   -eventid receive `
   -start (get-date).adddays(-1) `
   -resultsize 1000 `
| ?($_.MessageInfo -eq "0cA: ")

Eine erste Sichtprobe hat mir gezeigt, dass diese Annahme wohl gültig sein könnte. Also habe ich das Skript etwas aufgebohrt, um mehrere Server abzufragen und dann die Daten gleich zu verarbeiten. Wenn Sie zu viele PowerShell-Pipelines verbinden, dann zickt Exchange und PowerShell manchmal etwas. Daher lege ich eine For-Schleife drum herum. Sie können beim "Get-TransportService" natürlich noch eine Beschränkung auf die aktiven Transportdienste einbauen oder Edge-Server ausschließen. Um die Datenmenge klein zu halten, kann ich auch die Clients und Subnetze filtern, die mich nicht interessieren um die Datenmenge zu reduzieren. Das sieht dann in etwa so aus:

$serverlist = Get-transportservice
foreach ($Server in $serverlist) {
   write-host "Processing Server $server";
   get-messagetrackinglog `
      -server $server `
      -source SMTP `
      -eventid receive `
      -start (get-date).adddays(-1) `
      -resultsize unlimited `
   | ?{ (  ($_.MessageInfo -eq "0cA: ") `
      -and ($_.OriginalClientIp -ne "192.168.100.4") `
      -and ($_.OriginalClientIp -notlike "192.168.105.*") `
      ) `
   } `
   | select Timestamp,OriginalClientIp,Sender,Messagesubject,{[string]$_.Recipients} `
   | export-csv `
      -path anonsmtpsender.csv `
      -encoding unicode `
      -NoTypeInformation `
      -append
}

Die resultierende Datenmenge ist natürlich je nach Größe ihrer Umgebung nicht zu unterschätzen. Ich habe hier auch schon mal mehrere hundert Megabyte CSV-Dateien generiert. In dem Fall musste ich dann aber noch den Faktor Zeit mit einbauen und habe pro Tag eine eigene CSV-Datei erstellt. Das ist in dem Codebeispiel nicht enthalten. Aber PowerShell hat trotz Pipeline sonst das Problem, dass der Hauptspeicher stark belastet wird.

Das gilt natürlich auch, wenn man hinterher versucht die CSV-Dateien mit Powershell zu lesen und z.B. mit "Group-Objekt" zusammenfassen will. Selbst mit der Angabe von "-NoElement" ist mir regelmäßig der Speicher ausgegangen.

Hier bin ich dann auf Power BI umgestiegen, mit dem ich auf dem Desktop auch viele CSV-Dateien einlesen und auswerten kann.

Leider ist so eine Auswertung mit "Testdaten" nicht wirklich beeindruckend. Wenn Sie aber bei Kunden mehrere hundert Megabyte CSV-Daten mal eben schnell in Power BI grafisch und vor allem interaktiv auswerten, dann bekommen die meisten Kunden schon Appetit auf mehr und denken sogar daran die Daten in eine Datenbank on Office 365 zu laden und mit Power BI online auszuwerten.

Weitere Links