Microsoft SharePoint Server ULS Trace Log

Quick Start

uv tool install eventum-generator
git clone https://github.com/eventum-generator/content-packs.git
cd content-packs
eventum generate \
  --path generators/application-sharepoint-server-uls/generator.yml \
  --id sharepoint-uls \
  --live-mode true

Event Types

Realism Features

• A browser request writes nasq, xmnv Name=Request, avwhz, agb9s, xmnv Site=, an optional aoxsq redirect and b4ly, in the order of a published SharePoint Server 2019 trace; the first request of about 70% of sessions is an anonymous NTLM challenge (agb9s with IsAuthenticated=False, af32k, b6p2). A job-workflow timer run writes nasq, xmnv, one ahk8y, b6p4, tzkv triple per workflow instance it processes, and b4ly.
• About 11,800 rows per hour in weekday office hours (08:00-18:00 UTC), 4,900 in the shoulder hours (07:00-08:00, 18:00-20:00) and 1,600 at night and all weekend. About 205 accounts make requests in a weekday office hour, 95 in a shoulder hour and 16 in a night hour; the search crawl account and the timer job add a flat 1,100 rows per hour. A site owner makes about 80 to 115 requests on a weekday, most other accounts 20 to 85, in sessions of a few requests about 40 s apart.
• Requests cover site home pages (26%), document downloads (22%), search crawl (16%), library views (14%), NTLM challenges (10%), uploads (7%), site-root redirects (5%) and access-denied pages (1%). Sessions tend to stay on one site; a request to a site the account cannot open gets a 302 to AccessDenied.aspx and is retried up to three more times within minutes, after which most users go back to a site they can open.
• Site owners open the permissions page, grant permissions from the share dialog (about 47 a weekday) and plan a removal for 75% of grants: 40% are quick reverts with a 15-minute median delay, the rest follow after a median of three hours, and 45% of removals come right after one to six downloads of that site. An owner who granted access and then downloaded three or more documents of the site within the hour opens the permissions page instead of removing the grant (3 to 13 times a weekday). Uploads to the six workflow sites start instances that the five-minute timer job processes one to three times.
• event.original holds all nine ULS columns, repeated one to one in sharepoint.uls.*; @timestamp keeps the native 10 ms resolution with the farm in UTC, and the nasq row that opens a request has an empty Correlation column. user.name, url.*, http.request.method and sharepoint.site.url are copied to every row of a correlation ID, as a SIEM pipeline would join them; they are not ULS columns.
• The rows of one request are about 1.4 s apart in the median (99% within 16 s, wider at night) instead of milliseconds, while b4ly still states a duration of tens to hundreds of milliseconds; rows of different requests do not interleave. Line shapes come from published Microsoft examples (the Tx sample, a SharePoint Server 2019 Q&A trace and the workflow timer-job article), not a format specification; the timer-job b4ly text follows the 2019 request form. Only a filtered subset of tags is emitted, rows are unpadded, correlation IDs follow the shape of the samples and aoxsq appears only for 302 responses.
• Volumes, the hour curve, session behaviour, the crawl rate and the timer schedule are synthetic, with no holidays and the same shape every week; compatibility with the KUMA SharePoint Server 2016 normalizer is not established. ULS carries no permission delta: the granted or removed principal is only in the SharePoint audit log, so the chain is a hunting lead, not proof. In ordinary traffic a removal that would complete the chain within the hour shows as a permission-page view; with anomaly_mode on, counts of grants, owner downloads and removals are about one episode's worth higher.

Sample Output

{
  "@timestamp": "2026-09-21T17:38:22.970Z",
  "ecs": {
    "version": "8.17.0"
  },
  "event": {
    "action": "correlation-data",
    "category": [
      "web"
    ],
    "code": "xmnv",
    "dataset": "sharepoint.uls",
    "kind": "event",
    "module": "sharepoint",
    "original": "09/21/2026 17:38:22.97\tw3wp.exe (0x83E4)\t0x0FA8\tSharePoint Foundation\tLogging Correlation Data\txmnv\tMedium\tName=Request (POST:https://portal.contoso.test:443/sites/it/_layouts/15/aclinv.aspx)\t90874d28-8cb3-06e6-d2a6-418013147e49",
    "type": [
      "info"
    ]
  },
  "host": {
    "name": "sp-wfe-02"
  },
  "http": {
    "request": {
      "method": "POST"
    }
  },
  "log": {
    "level": "medium"
  },
  "message": "Name=Request (POST:https://portal.contoso.test:443/sites/it/_layouts/15/aclinv.aspx)",
  "process": {
    "name": "w3wp.exe",
    "pid": 33764,
    "thread": {
      "id": 4008
    }
  },
  "related": {
    "hosts": [
      "sp-wfe-02"
    ],
    "user": [
      "a.smirnov"
    ]
  },
  "service": {
    "name": "SharePoint Server",
    "version": "16.0.10390.20000"
  },
  "sharepoint": {
    "site": {
      "url": "/sites/it"
    },
    "uls": {
      "area": "SharePoint Foundation",
      "category": "Logging Correlation Data",
      "correlation_id": "90874d28-8cb3-06e6-d2a6-418013147e49",
      "event_id": "xmnv",
      "level": "Medium",
      "message": "Name=Request (POST:https://portal.contoso.test:443/sites/it/_layouts/15/aclinv.aspx)",
      "process": "w3wp.exe (0x83E4)",
      "thread_id": "0x0FA8",
      "timestamp_local": "09/21/2026 17:38:22.97"
    }
  },
  "url": {
    "domain": "portal.contoso.test",
    "original": "https://portal.contoso.test:443/sites/it/_layouts/15/aclinv.aspx",
    "path": "/sites/it/_layouts/15/aclinv.aspx",
    "port": 443,
    "scheme": "https"
  },
  "user": {
    "domain": "contoso",
    "name": "a.smirnov"
  }
}

Parameters