Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into us416874-freshness-update-ts

Author: asudbring

.openpublishing.redirection.json

@@ -6739,6 +6739,11 @@
       "redirect_url": "/dotnet/maui/data-cloud/push-notifications",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/work-with-styx-objects-and-indicators.md",
+      "redirect_url": "/azure/sentinel/work-with-styx-objects-indicators",
+      "redirect_document_id": false
+    },
     {
       "source_path": "articles/storage/files/geo-redundant-storage-for-large-file-shares.md",
       "redirect_url": "/azure/storage/files/files-redundancy",

articles/healthcare-apis/dicom/update-files.md

@@ -19,7 +19,10 @@ Beyond the efficiency gains, the bulk update capability preserves a record of th
 There are a few limitations when you use the bulk update operation:
 
 - A maximum of 50 studies can be updated in a single operation.
-- Only one bulk update operation can be performed at a time.
+- Only one bulk update operation can be performed at a time for a given study.
+- For updates involving UID changes, only one study can be updated in a single operation.
+- Only Study Instance UID and Series Instance UID can be updated as part of UID update. SOP Instance UID cannot be updated for an instance.
+- UID update operation would fail when the target UIDs (`studyInstanceUID`, `seriesInstanceUid` and `sopInstanceUId`) already exists.
 - You can't delete only the latest version of a study, or revert back to the original version. 
 - You can't update any field from non-null to a null value.
 
@@ -64,6 +67,41 @@ The request body contains the specification for studies to update. Both the `stu
 }
 ```
 
+For updating the UIDs, new UIDs have to be provided in the change dataset as follows. The `seriesInstanceUid` is an optional field.
+
+1. Use the request in the format below to update the `studyInstanceUid` for all instances within a study.
+
+```
+{
+    "studyInstanceUids": ["1.2.3.4"],
+    "changeDataset": { 
+        "0020000D": { 
+            "vr": "UI", 
+            "Value": ["1.2.3.5"]
+        } 
+    }
+}
+```
+
+2. Use the request in the format below to update the `studyInstanceUid` and the `seriesInstanceUid` for all instances within a series. Note that only one study can be updated at a time, and if a series-level update is performed, the entire hierarchy must be included. For series-level update, both the new `studyInstanceUid` and `seriesInstanceUid` have to be provided in the `changeDataset`.
+
+```
+{
+    "studyInstanceUids": ["1.2.3.4"],
+    "seriesInstanceUid": "5.6.7.8",
+    "changeDataset": { 
+        "0020000D": { 
+            "vr": "UI", 
+            "Value": ["1.2.3.5"]
+        },
+        "0020000E": { 
+            "vr": "UI", 
+            "Value": ["5.6.7.9"]
+        } 
+    }
+}
+```
+
 #### Responses
 When a bulk update operation starts successfully, the API returns a `202` status code. The body of the response contains a reference to the operation.
 
@@ -140,7 +178,7 @@ GET {dicom-service-url}/{version}/operations/{operationId}
 | 404 (Not Found) |           | Operation not found |
 
 ## Retrieving study versions
-The [Retrieve (WADO-RS)](dicom-services-conformance-statement-v2.md#retrieve-wado-rs) transaction allows you to retrieve both the original and latest version of a study, series, or instance. By default, the latest version of a study, series, or instance is returned. The original version is returned by setting the `msdicom-request-original` header to `true`. An example request follows.
+The [Retrieve (WADO-RS)](dicom-services-conformance-statement-v2.md#retrieve-wado-rs) transaction allows you to retrieve both the original and latest version of a study, series, or instance. By default, the latest version of a study, series, or instance is returned. The original version is returned by setting the `msdicom-request-original` header to `true`. For bulk updates involving UID update, the original and latest version can be retrieved using the newer UIDs only. An example request follows.
 
 ```http 
 GET {dicom-service-url}/{version}/studies/{study}/series/{series}/instances/{instance}
@@ -149,11 +187,13 @@ msdicom-request-original: true
 Content-Type: application/dicom
  ```
 
+For bulk updates involving UID update, the original and latest version can be retrieved using the newer UIDs only.
+
 ## Delete
 The [delete](dicom-services-conformance-statement-v2.md#delete) method deletes both the original and latest version of a study, series, or instance.
 
 ## Change feed
-The [change feed](change-feed-overview.md) records update actions in the same manner as create and delete actions. 
+The [change feed](change-feed-overview.md) records update actions in the same manner as create and delete actions. For UID updates, change feed entries for the older UIDs will not be updated. The update action would be present only for the new UIDs. 
 
 ## Supported DICOM modules
 Any attributes in the [Patient Identification Module](https://dicom.nema.org/dicom/2013/output/chtml/part03/sect_C.2.html#table_C.2-2) and [Patient Demographic Module](https://dicom.nema.org/dicom/2013/output/chtml/part03/sect_C.2.html#table_C.2-3) that aren't sequences can be updated using the bulk update operation. Supported attributes are called out in the tables.
@@ -213,6 +253,8 @@ The UID `1.3.6.1.4.1.311.129` is a registered under [Microsoft OID arc](https://
 #### General study module
 | Attribute Name   | Tag           | Description           |
 | ---------------- | --------------| --------------------- |
+| Study Instance UID | (0020,000D) | Unique identifier for the Study |
+| Series Instance UID | (0020,000E) | Unique identifier for the Series |
 | Referring Physician's Name | (0008,0090) | Name of the patient's referring physician |
 | Accession Number | (0008,0050) | A RIS generated number that identifies the order for the Study |
 | Study Description | (0008,1030) | Institution-generated description or classification of the Study (component) performed |

articles/sentinel/TOC.yml

@@ -802,6 +802,8 @@
     href: use-threat-indicators-in-analytics-rules.md
   - name: Use matching analytics to detect threats
     href: use-matching-analytics-to-detect-threats.md
+  - name: Work with STIX objects and indicators
+    href: work-with-styx-objects-indicators.md
 - name: Detect threats and analyze data
   items:
   - name: Monitor and visualize data

articles/sentinel/understand-threat-intelligence.md

@@ -2,10 +2,11 @@
 title: Threat intelligence
 titleSuffix: Microsoft Sentinel
 description: Understand threat intelligence and how it integrates with features in Microsoft Sentinel to analyze data, detect threats, and enrich alerts.
-author: austinmccollum
+author: guywi-ms
 ms.topic: concept-article
 ms.date: 02/27/2025
-ms.author: austinmc
+ms.author: guywild
+ms.reviewer: alsheheb
 appliesto:
     - Microsoft Sentinel in the Azure portal
     - Microsoft Sentinel in the Microsoft Defender portal
@@ -203,23 +204,28 @@ For more information, see [Work with threat intelligence in Microsoft Sentinel](
 
 ## View your threat intelligence
 
-View your threat intelligence from the management interface or using queries. From the management interface, use advanced search to sort and filter your threat intelligence objects without even writing a Log Analytics query.
+View your threat intelligence from the management interface or using queries: 
 
-:::image type="content" source="media/understand-threat-intelligence/advanced-search.png" alt-text="Screenshot that shows an advanced search interface with source and confidence conditions selected." lightbox="media/understand-threat-intelligence/advanced-search.png":::
+- From the management interface, use advanced search to sort and filter your threat intelligence objects without even writing a Log Analytics query.
 
-Use queries to view threat intelligence from **Logs** or **Advanced hunting**. Either way, the `ThreatIntelligenceIndicator` table under the **Microsoft Sentinel** schema is where all your Microsoft Sentinel threat indicators are stored. This table is the basis for threat intelligence queries performed by other Microsoft Sentinel features, such as analytics, hunting queries, and workbooks.
+    :::image type="content" source="media/understand-threat-intelligence/advanced-search.png" alt-text="Screenshot that shows an advanced search interface with source and confidence conditions selected." lightbox="media/understand-threat-intelligence/advanced-search.png":::
+
+- Use queries to view threat intelligence from **Logs** in the Azure portal or **Advanced hunting** in the Defender portal. 
+
+    Either way, the `ThreatIntelligenceIndicator` table under the **Microsoft Sentinel** schema is where all your Microsoft Sentinel threat indicators are stored. This table is the basis for threat intelligence queries performed by other Microsoft Sentinel features, such as analytics, hunting queries, and workbooks.
 
 >[!IMPORTANT]
->Tables supporting the new STIX object schema aren't available publicly. In order to view the STIX objects in queries and unlock the hunting model that uses them, request to opt in with [this form](https://forms.office.com/r/903VU5x3hz?origin=lprLink). Ingest your threat intelligence into the new tables, `ThreatIntelIndicator` and `ThreatIntelObjects`, alongside or instead of the current table, `ThreatIntelligenceIndicator`, with this opt-in process.
->
+> On April 3, 2025, we publicly previewed two new tables to support STIX indicator and object schemas: `ThreatIntelIndicator` and `ThreatIntelObjects`. Microsoft Sentinel will ingest all threat intelligence into these new tables, while continuing to ingest the same data into the legacy `ThreatIntelligenceIndicator` table until July 31, 2025. 
+>**Be sure to update your custom queries, analytics and detection rules, workbooks, and automation to use the new tables by July 31, 2025.** After this date, Microsoft Sentinel will stop ingesting data to the legacy `ThreatIntelligenceIndicator` table. We're updating all out-of-the-box threat intelligence solutions in Content hub to leverage the new tables. For more information about the new table schemas, see [ThreatIntelIndicator](/azure/azure-monitor/reference/tables/threatintelligenceindicator) and [ThreatIntelObjects](/azure/azure-monitor/reference/tables/threatintelobjects).
+> For information on using and migrating to the new tables, see (Work with STIX objects to enhance threat intelligence and threat hunting in Microsoft Sentinel (Preview))[work-with-styx-objects-and-indicators.md]. 
 
-For more information, see [Work with threat intelligence in Microsoft Sentinel](work-with-threat-indicators.md#find-and-view-threat-intelligence-with-queries).
+### Threat intelligence lifecycle
 
-### Threat intelligence life cycle
+Microsoft Sentinel ingests threat intelligence indicators into the threat intelligence tables in your Log Analytics workspace. For more information on Microsoft Sentinel's threat intelligence tables, see [View your threat intelligence](#view-your-threat-intelligence).
 
-Threat intelligence indicators are ingested into the `ThreatIntelligenceIndicator` table of your Log Analytics workspace as read-only. Whenever an indicator is updated, a new entry in the `ThreatIntelligenceIndicator` table is created. Only the most current indicator appears on the management interface. Microsoft Sentinel deduplicates indicators based on the `IndicatorId` and `SourceSystem` properties and chooses the indicator with the newest `TimeGenerated[UTC]`.
+Whenever an indicator is created, updated, or deleted, Microsoft Sentinel creates a new entry in the tables. Only the most current indicator appears on the management interface. Microsoft Sentinel deduplicates indicators based on the `Id` property (the `IndicatorId` property in the legacy `ThreatIntelligenceIndicator`) and chooses the indicator with the newest `TimeGenerated[UTC]`.
 
-The `IndicatorId` property is generated using the STIX indicator ID. When indicators are imported or created from non-STIX sources, `IndicatorId` is generated using both the source and pattern of the indicator.
+The `Id` property is a concatenation of the base64-encoded `SourceSystem` value, `---` (three dashes), and the `stixId` (which is the `Data.Id` value).
 
 ### View your GeoLocation and WhoIs data enrichments (public preview)