> For the complete documentation index, see [llms.txt](https://msdocs.aohwv.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://msdocs.aohwv.com/quick-start/step-1-event-hub-setup.md).

# Step 1 - Event Hub Setup

The Event Hub is the pickup point your SIEM reads Microsoft logs from. Microsoft sources send their logs here, and your SIEM collects them. You only need to set this up once.

{% hint style="info" %}
**Time:** about 15 minutes
{% endhint %}

### Before you start

* **Owner** (or Contributor) on the Azure subscription where the Event Hub will live
* Your SIEM vendor's guide for the **Azure Event Hub** connector. Check whether it requires specific event hub names, consumer groups or partition counts
* If you use **LogRhythm** or another SIEM that tracks its progress in Azure storage, permission to create a **storage account** (see the LogRhythm note near the end of this page)

### 1. Create the namespace

The namespace is the container that holds your event hubs.

1. Sign in to the [Azure portal](https://portal.azure.com).
2. Search for **Event Hubs** and select **Create**.
3. Fill in the form:
   * **Subscription:** the subscription you use for security or shared services
   * **Resource group:** create one such as `rg-siem-logging`, or use an existing security resource group
   * **Namespace name:** for example, `evhns-siem-<companyname>`
   * **Location:** any region, ideally close to your SIEM
   * **Pricing tier:** **Standard**
   * **Throughput units:** **2**, with **Enable Auto-Inflate** checked and a maximum of **10**
4. Select **Review + create**, then **Create**.

{% hint style="info" %}
Auto-inflate adds capacity automatically when log volume spikes, for example during a busy Monday morning or a security incident, so no logs are dropped.
{% endhint %}

### 2. Create the event hubs

Create one event hub for each Microsoft source. Keeping sources separate makes it easier for your SIEM to sort and parse the data.

1. Open your new namespace.
2. Select **Event Hubs** → **+ Event Hub**.
3. Create each of the following:

| Event hub name   | Receives logs from          |
| ---------------- | --------------------------- |
| `entra-logs`     | Entra ID (Step 2)           |
| `defender-xdr`   | Defender XDR (Step 3)       |
| `defender-cloud` | Defender for Cloud (Step 7) |
| `activity-logs`  | Azure Activity Log (Step 7) |
| `intune-logs`    | Intune (Step 8, optional)   |

For each one, use these settings:

* **Partition count:** **4** (or what your SIEM vendor recommends). This can't be changed later.
* **Retention time:** **168 hours** (7 days), so logs are kept if your SIEM connection goes down temporarily.
* **Capture:** leave **off** unless you want a separate long-term copy in a storage account.

{% hint style="info" %}
**Microsoft 365, Copilot and Purview don't use the Event Hub.** Your SIEM collects those directly from Microsoft. They're covered in their own steps.
{% endhint %}

### 3. Create a consumer group for your SIEM

A consumer group gives your SIEM its own reading position in each event hub, so it doesn't conflict with anything else reading the same data.

For **each** event hub:

1. Open the event hub → **Consumer groups** → **+ Consumer group**.
2. Name it after your SIEM, for example `siem`.
3. Select **Create**.

### 4. Create read-only access for your SIEM

1. Go back to the **namespace**. Some SIEMs, such as LogRhythm, need a policy on **each event hub** instead. See the LogRhythm note near the end of this page.
2. Select **Shared access policies** → **+ Add**.
3. Name it `siem-listen` and check **Listen** only.
4. Select **Create**.
5. Open the new policy and copy the **Connection string–primary key**.

{% hint style="danger" %}
**Treat the connection string like a password.** Store it in Azure Key Vault or your password manager. Never paste it into email, tickets or documents.
{% endhint %}

### 5. Give your SIEM the connection details

Enter the following in your SIEM's Azure Event Hub connector:

| Detail            | Value                                   |
| ----------------- | --------------------------------------- |
| Namespace         | The namespace name from part 1          |
| Event hub names   | The names from part 2                   |
| Consumer group    | `siem` (or the name you chose)          |
| Connection string | From the `siem-listen` policy in part 4 |

{% hint style="info" %}
**Using LogRhythm?** The LogRhythm **Azure Event Hub Beat** (Open Collector) works with the one-hub-per-source setup above, with a few differences:

* Create a **Listen** shared access policy on **each event hub** (not just the namespace), so each connection string ends with **EntityPath=** and the hub name
* Create a **storage account** (StorageV2, default settings) so the beat can track what it has already collected
* Allow outbound traffic on ports **5671** and **443** from the collector

See LogRhythm's guide: [Configure Azure Event Hubs Using Connection Strings](https://docs.logrhythm.com/OCbeats/docs/configure-azure-event-hubs-using-connection-strings)
{% endhint %}

### Verify

1. In the Azure portal, open the namespace and confirm all event hubs are listed.
2. Confirm your SIEM shows the connector as **connected** with no authentication errors.

There won't be any data yet. Logs start flowing once you complete the next steps.

## Related

* [Prerequisites](/quick-start/prerequisites.md) — Roles and licenses you'll need
* [Step 2 — Entra ID](/quick-start/step-2-entra-id.md) — Send sign-in and directory logs to your new Event Hub


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://msdocs.aohwv.com/quick-start/step-1-event-hub-setup.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.