Merge pull request #25973 from microsoftgraph/repo_sync_working_branch

jasonjoh · web-flow · commit 33a70dc7ea3c · 2025-02-11T10:53:43.000-05:00
Confirm merge from repo_sync_working_branch to main to sync with https://github.com/microsoftgraph/microsoft-graph-docs-contrib (branch main)
diff --git a/api-reference/beta/api/authorizationpolicy-update.md b/api-reference/beta/api/authorizationpolicy-update.md
@@ -335,7 +335,7 @@ The following example shows the response.
 HTTP/1.1 204 No Content
 ```
 
-### Example 5: Enable default user role to use Self-Serve Password Reset feature
+### Example 5: Enable administrators to use the self-serve password reset feature
 
 #### Request
 
diff --git a/api-reference/beta/api/profilephoto-delete.md b/api-reference/beta/api/profilephoto-delete.md
@@ -43,7 +43,7 @@ The following tables show the least privileged permission or permissions require
 |Application      |    ProfilePhoto.ReadWrite.All           | Group.ReadWrite.All |
 
 > [!NOTE]
-> - Global and user admins can delete the photo of any user in the organization using delegated permissions. This operation also supports application permissions. Deleting the photo of any user in the organization requires *ProfilePhoto.ReadWrite.All* or *User.ReadWrite.All* permissions. Deleting the photo of the signed-in user only requires *User.ReadWrite* permissions.
+> - Global admins, User admins, and People admins can delete the photo of any user in the organization using delegated permissions. This operation also supports application permissions. Deleting the photo of any user in the organization requires *ProfilePhoto.ReadWrite.All* or *User.ReadWrite.All* permissions. Deleting the photo of the signed-in user only requires *User.ReadWrite* permissions.
 
 ## HTTP request
 
diff --git a/api-reference/beta/api/profilephoto-update.md b/api-reference/beta/api/profilephoto-update.md
@@ -61,7 +61,7 @@ You can use either PATCH or PUT for this operation.
 > [!NOTE]
 >
 > - Permissions marked with * are supported only for backward compatibility. Please update your solutions to use an alternative permission and avoid using these permissions going forward.
-> - Users with admin roles such as User admins can update the photo of any user in the organization by using delegated permissions. This operation is also supported with application permissions. Updating the photo of any user in the organization requires *ProfilePhoto.ReadWrite.All* or *User.ReadWrite.All* permission. Updating the photo of the signed-in user only requires *User.ReadWrite* permission.
+> - Users with admin roles such as User admins, Global admins, or People admins can update the photo of any user in the organization by using delegated permissions. This operation is also supported with application permissions. Updating the photo of any user in the organization requires *ProfilePhoto.ReadWrite.All* or *User.ReadWrite.All* permission. Updating the photo of the signed-in user only requires *User.ReadWrite* permission.
 > - Updating a user's photo using the Microsoft Graph API is currently not supported in Azure AD B2C tenants.
 
 ## HTTP request
diff --git a/api-reference/beta/resources/device.md b/api-reference/beta/resources/device.md
@@ -97,7 +97,7 @@ This resource supports:
 |registrationDateTime|DateTimeOffset|Date and time of when the device was registered. The timestamp type represents date and time information using ISO 8601 format and is always in UTC time. For example, midnight UTC on Jan 1, 2014 is `2014-01-01T00:00:00Z`. Read-only.|
 |status | String| Device is `online` or `offline`. Only returned if user signs in with a Microsoft account as part of Project Rome. |
 |systemLabels|String collection| List of labels applied to the device by the system. Supports `$filter` (`/$count eq 0`, `/$count ne 0`). |
-|trustType|String| Type of trust for the joined device. Read-only. Possible values: `Workplace` (indicates *bring your own personal devices*), `AzureAd` (Cloud only joined devices), `ServerAd` (on-premises domain joined devices joined to Microsoft Entra ID). For more information, see [Introduction to device management in Microsoft Entra ID](/azure/active-directory/device-management-introduction). |
+|trustType|String| Type of trust for the joined device. Read-only. Possible values: `Workplace` (indicates *bring your own personal devices*), `AzureAd` (Cloud only joined devices), `ServerAd` (on-premises domain joined devices joined to Microsoft Entra ID). For more information, see [Introduction to device management in Microsoft Entra ID](/azure/active-directory/device-management-introduction). Supports `$filter` (`eq`, `ne`, `not`, `in`).|
 
 ## Relationships
 | Relationship | Type    |Description|
diff --git a/api-reference/v1.0/api/authorizationpolicy-update.md b/api-reference/v1.0/api/authorizationpolicy-update.md
@@ -264,7 +264,7 @@ The following example shows the response.
 HTTP/1.1 204 No Content
 ```
 
-### Example 4: Enable default user role to use Self-Serve Password Reset feature
+### Example 4: Enable administrators to use the self-serve password reset feature
 
 #### Request
 
diff --git a/api-reference/v1.0/api/event-delta.md b/api-reference/v1.0/api/event-delta.md
@@ -70,7 +70,7 @@ If successful, this method returns a `200 OK` response code and [event](../resou
 
 Within a round of **delta** function calls bound by the date range of a **calendarView**, you may find a **delta** call returning two types of events under `@removed` with the reason `deleted`: 
 - Events that are within the date range and that have been deleted since the previous **delta** call.
-- Events that are _outside_ the date range and that have been added, deleted, or updated since the the previous **delta** call.
+- Events that are _outside_ the date range and that have been added, deleted, or updated since the previous **delta** call.
 
 Filter the events under `@removed` for the date range that your scenario requires.
 
diff --git a/api-reference/v1.0/api/profilephoto-delete.md b/api-reference/v1.0/api/profilephoto-delete.md
@@ -44,7 +44,7 @@ The following tables show the least privileged permission or permissions require
 |Application      |    ProfilePhoto.ReadWrite.All           | Group.ReadWrite.All |
 
 > [!NOTE]
-> - Global and user admins can delete the photo of any user in the organization using delegated permissions. This operation also supports application permissions. Deleting the photo of any user in the organization requires *ProfilePhoto.ReadWrite.All* or *User.ReadWrite.All* permissions. Deleting the photo of the signed-in user only requires *User.ReadWrite* permissions.
+> - Global admins, User admins, and People admins can delete the photo of any user in the organization using delegated permissions. This operation also supports application permissions. Deleting the photo of any user in the organization requires *ProfilePhoto.ReadWrite.All* or *User.ReadWrite.All* permissions. Deleting the photo of the signed-in user only requires *User.ReadWrite* permissions.
 
 ## HTTP request
 
diff --git a/api-reference/v1.0/api/profilephoto-get.md b/api-reference/v1.0/api/profilephoto-get.md
@@ -66,6 +66,7 @@ The following tables show the least privileged permission or permissions require
 > [!NOTE]
 > 
 > - Retrieving a user's photo using the Microsoft Graph API is currently not supported in Azure AD B2C tenants.
+> - Guest users can view profile photos of users, even when the **Guest user access** settings are configured to the **most restrictive** option in Azure Active Directory External Identities settings.
 
 ## HTTP request
 
diff --git a/api-reference/v1.0/api/profilephoto-update.md b/api-reference/v1.0/api/profilephoto-update.md
@@ -60,7 +60,7 @@ The following tables show the least privileged permission or permissions require
 
 > [!NOTE]
 >
-> - Users with admin roles such as User admins can update the photo of any user in the organization by using delegated permissions. This operation is also supported with application permissions. Updating the photo of any user in the organization requires *ProfilePhoto.ReadWrite.All* or *User.ReadWrite.All* permission. Updating the photo of the signed-in user only requires *User.ReadWrite* permission.
+> - Users with admin roles such as User admins, Global admins, or People admins can update the photo of any user in the organization by using delegated permissions. This operation is also supported with application permissions. Updating the photo of any user in the organization requires *ProfilePhoto.ReadWrite.All* or *User.ReadWrite.All* permission. Updating the photo of the signed-in user only requires *User.ReadWrite* permission.
 > - Updating a user's photo using the Microsoft Graph API is currently not supported in Azure AD B2C tenants.
 
 ## HTTP request
diff --git a/api-reference/v1.0/api/unifiedrolemanagementpolicyassignment-get.md b/api-reference/v1.0/api/unifiedrolemanagementpolicyassignment-get.md
@@ -66,9 +66,9 @@ If successful, this method returns a `200 OK` response code and an [unifiedRoleM
 
 ## Examples
 
-<a name='example-1-rretrieve-the-details-of-a-policy-assignment-for-pim-for-azure-ad-roles'></a>
+<a name='example-1-retrieve-the-details-of-a-policy-assignment-for-pim-for-azure-ad-roles'></a>
 
-### Example 1: RRetrieve the details of a policy assignment for PIM for Microsoft Entra roles
+### Example 1: Retrieve the details of a policy assignment for PIM for Microsoft Entra roles
 
 #### Request
 
diff --git a/api-reference/v1.0/resources/device.md b/api-reference/v1.0/resources/device.md
@@ -80,7 +80,7 @@ This resource supports:
 |profileType|deviceProfileType|The profile type of the device. Possible values: `RegisteredDevice` (default), `SecureVM`, `Printer`, `Shared`, `IoT`.|
 |registrationDateTime|DateTimeOffset|Date and time of when the device was registered. The timestamp type represents date and time information using ISO 8601 format and is always in UTC time. For example, midnight UTC on Jan 1, 2014 is `2014-01-01T00:00:00Z`. Read-only.|
 |systemLabels|String collection| List of labels applied to the device by the system. Supports `$filter` (`/$count eq 0`, `/$count ne 0`). |
-|trustType|String| Type of trust for the joined device. Read-only. Possible values:  `Workplace` (indicates *bring your own personal devices*), `AzureAd` (Cloud-only joined devices), `ServerAd` (on-premises domain joined devices joined to Microsoft Entra ID). For more information, see [Introduction to device management in Microsoft Entra ID](/azure/active-directory/device-management-introduction). |
+|trustType|String| Type of trust for the joined device. Read-only. Possible values:  `Workplace` (indicates *bring your own personal devices*), `AzureAd` (Cloud-only joined devices), `ServerAd` (on-premises domain joined devices joined to Microsoft Entra ID). For more information, see [Introduction to device management in Microsoft Entra ID](/azure/active-directory/device-management-introduction). Supports `$filter` (`eq`, `ne`, `not`, `in`).|
 
 ## Relationships
 | Relationship | Type    |Description|
diff --git a/concepts/auth-limit-mailbox-access.md b/concepts/auth-limit-mailbox-access.md
@@ -27,7 +27,7 @@ Some apps call Microsoft Graph using their own identity and not on behalf of a u
 
 There are scenarios where administrators might want to limit an app to only specific mailboxes and _not all_ Exchange Online mailboxes in the organization. Administrators can identify the set of mailboxes to permit access by putting them in a mail-enabled security group. Administrators can then limit third-party app access to only that set of  mailboxes by creating an application access policy for access to that group.
 
-As further described in the [Supported permissions and other resources](#supported-permissions-and-additional-resources) section, application access policy restricts mailbox access for apps that are granted any of the Microsoft Graph or Exchange Web Services permission scopes that the policy supports.
+As further described in the [Supported permissions and other resources](#supported-permissions-and-other-resources) section, application access policy restricts mailbox access for apps that are granted any of the Microsoft Graph or Exchange Web Services permission scopes that the policy supports.
 
 ## Configure ApplicationAccessPolicy
 
diff --git a/concepts/auth-register-app-v2.md b/concepts/auth-register-app-v2.md
@@ -8,7 +8,7 @@ ms.topic: quickstart
 ms.localizationpriority: high
 ms.subservice: entra-applications
 ms.custom: graphiamtop20
-ms.date: 01/11/2024
+ms.date: 01/27/2024
 #customer intent: As a developer, I want to register an application with the Microsoft identity platform, so that I can use it to access data in the Microsoft cloud.
 ---
 
diff --git a/concepts/authenticationmethods-get-started.md b/concepts/authenticationmethods-get-started.md
@@ -6,7 +6,7 @@ ms.author: ombongifaith
 ms.reviewer: jpeterre
 ms.localizationpriority: high
 ms.subservice: entra-sign-in
-ms.date: 01/18/2024
+ms.date: 01/27/2025
 ms.topic: concept-article
 #customer intent: As a developer, I want to understand what user authentication options are available for Microsoft Entra ID through Microsoft Graph, and how I can integrate them into my applications.
 ---
diff --git a/concepts/backup-storage-error-codes.md b/concepts/backup-storage-error-codes.md
@@ -58,7 +58,6 @@ The following table lists the possible error and response codes that can be retu
 
 | HTTP status code| Error code| Error message | Description|
 |:------------------|:--------------|:--------------|:--------------|
-|200|ProtectionUnitAlreadyExists|This is a delta patch ProtectionUnit level error returned when the request has duplicate Protection Unit in the list that is already present in the service.|ProtectionUnit level error: ProtectionUnit already exists.|
 |200|ProtectionUnitNotFound|This is a delta patch ProtectionUnit level error returned when the user requests to remove Protection Unit, which isn't present in the service.|ProtectionUnit level error: ProtectionUnit doesn't exist.|
 |400|DuplicateProtectionUnitInList|This is a Protection Unit level error returned when the request has duplicate artifacts in the list.|Protection Unit level error: Duplicate Protection Unit in list.|
 |400|ProtectionUnitActionNotAllowed|The artifact with the given protection unit ID can't be removed as it's protected by a dynamic rule.| Protection units protected via dynamic rules can't be removed manually.|
diff --git a/concepts/data-connect-troubleshooting.md b/concepts/data-connect-troubleshooting.md
@@ -153,6 +153,10 @@ The following error message indicates that a **Microsoft.GraphServices** type re
 
 ![Screenshot that shows an error for the already existent billing resource.](images/app-registration-already-premium-usage.png)
 
+### Developer email missing
+
+When creating a new registration, it may appear successful, but you receive a "Developer email not found" error. This happens when the registration is created with a guest user; use a non-guest user to successfully complete the registration.
+
 ## Related content
 
 - [Data Connect overview](data-connect-concept-overview.md)
diff --git a/concepts/delta-query-overview.md b/concepts/delta-query-overview.md
@@ -26,8 +26,8 @@ The typical call pattern is as follows:
 
 1. The application makes a GET request with the **delta** function on the desired resource. For example, `GET https://graph.microsoft.com/v1.0/users/delta`.
 
-    > [!TIP]
-    > `/delta` is a shortcut for the fully qualified name `/microsoft.graph.delta`. Requests generated by Microsoft Graph SDKs use the fully qualified name.
+  > [!TIP]
+  > `/delta` is a shortcut for the fully qualified name `/microsoft.graph.delta`.
 
 2. Microsoft Graph responds with the requested resource and a [state token](#state-tokens).
 
diff --git a/concepts/permissions-overview.md b/concepts/permissions-overview.md
@@ -112,11 +112,12 @@ Container objects such as groups support members of various types, for example u
 
 This principle is applied to all relationships that are of [directoryObject](/graph/api/resources/directoryobject) type. Examples include `/groups/{id}/members`, `/users/{id}/memberOf`, and `me/ownedObjects`.
 
-For example, a group can have users, groups, applications, service principals, devices, and contacts as members. An app is granted the *GroupMember.Read.All* least privileged permission to [List group members](/graph/api/group-list-members). In the response object, only the **id** and **@odata.type** properties are populated for all the members that are returned. The other properties are indicated as `null`. For this API:
-- To read the basic properties of a group's members that are users, the app needs at least the *User.ReadBasic.All* permission.
-- To read the basic properties of a group's members that are groups, the app needs at least the *GroupMember.Read.All* permission.
-- To read the basic properties of a group's members that are devices, the app needs at least the *Device.Read.All* permission, and so on.
-- However, as an alternative to the individual resource-level permissions, the app can be assigned at least the *Directory.Read.All* permission to read *all properties for all member types*.
+For example, a group can have users, groups, applications, service principals, devices, and contacts as members. An app is granted the *GroupMember.Read.All* least privileged permission to [List group members](/graph/api/group-list-members). In the response object, only the **id** and **@odata.type** properties are populated for all the members that are returned. The other properties are indicated as `null`. For this API, and to return more information for the group's members, the app needs the following additional permissions:
+- To read the basic properties of a group's members that are users, *User.ReadBasic.All* is the least privileged permission.
+- To read the basic properties of a group's members that are groups, *GroupMember.Read.All* is the least privileged permission.
+- To read the basic properties of a group's members that are devices, *Device.Read.All* is the least privileged permission.
+- To read the basic properties of a group's members that are service principals, *Application.Read.All* is the least privileged permission.
+- As per the principle of least privilege, you should prefer using the preceding permissions as appropriate for your application. However, as an alternative to the individual resource-level permissions, the app can be assigned the *Directory.Read.All* permission to read *all properties for all member types*.
 
 ### Example
 
diff --git a/concepts/profilephoto-configure-settings.md b/concepts/profilephoto-configure-settings.md
@@ -49,7 +49,7 @@ Content-Type: application/json
 
 {
     "source": "cloud",
-    "allowedRoles": {}
+    "allowedRoles": []
 }
 ```
 
@@ -111,15 +111,15 @@ Content-Type: application/json
 ```
 ### Configure adminstrator support for profile photo updates
 
-The following example shows how to configure the Global Administrator and User Administrator roles to change profile photo update settings in your organization.
+The following example shows how to configure the Global Administrator, User Administrator, and People Administrator roles to change profile photo update settings in your organization.
 
 ```http
 PATCH https://graph.microsoft.com/beta/admin/people/photoupdatesettings
 Content-Type: application/json
 
 {
     "source": "cloud",
-    "allowedRoles": ["62e90394-69f5-4237-9190-012177145e10", "fe930be7-5e62-47db-91af-98c3a49a38b1"]
+    "allowedRoles": ["62e90394-69f5-4237-9190-012177145e10", "fe930be7-5e62-47db-91af-98c3a49a38b1", "024906de-61e5-49c8-8572-40335f1e0e10"]
 }
 ```
 
diff --git a/concepts/sdks/sdks-overview.md b/concepts/sdks/sdks-overview.md
@@ -10,7 +10,7 @@ ms.date: 11/07/2024
 
 The Microsoft Graph software development kits (SDKs) are designed to simplify building high-quality, efficient, resilient applications that access Microsoft Graph. The SDKs include two components: a service library and a core library.
 
-The *service library* contains models and request builders generated from Microsoft Graph metadata. The service library provides a rich, strongly-typed, and discoverable experience when working with the many datasets available in Microsoft Graph.
+The *service library* contains models and request builders generated from Microsoft Graph metadata. The service library provides a rich, strongly typed, and discoverable experience when working with the many datasets available in Microsoft Graph.
 
 The *core library* provides features that enhance working with all the Microsoft Graph services. Embedded support for retry handling, secure redirects, transparent authentication, and payload compression improve the quality of your application's interactions with Microsoft Graph with no added complexity while leaving you entirely in control. The core library also supports everyday tasks such as paging through collections and creating batch requests.
 
@@ -39,6 +39,11 @@ A release of an SDK in *GA* status can use the Microsoft Graph API v1.0 endpoint
 
 In some cases, it's beneficial to use a Kiota-generated client instead of a Microsoft Graph SDK. For example, a developer that only uses a small subset of the Microsoft Graph APIs and wants to minimize the overall install size of their app can use Kiota to generate a smaller client library. For details, see [Generate Microsoft Graph client libraries with Kiota](generate-with-kiota.md).
 
+## SDKs supportability
+
+Microsoft Graph SDKs are open-source GitHub projects so if you have an issue with the SDK, submit it with all the needed information on the "issues" page. SDK authors and contributors should look into the issue and release a fix accordingly.
+Microsoft CSS doesn't officially, support SDKs but Microsoft supports the HTTP request of the Microsoft Graph API call you're making.
+
 ## Related content
 
 - Learn more about the features and capabilities of the SDK in the [design requirements documentation](https://github.com/microsoftgraph/msgraph-sdk-design).

Original file line number	Diff line number	Diff line change
`@@ -61,7 +61,7 @@ You can use either PATCH or PUT for this operation.`
`61`	`61`	`> [!NOTE]`
`62`	`62`	`>`
`63`	`63`	`> - Permissions marked with * are supported only for backward compatibility. Please update your solutions to use an alternative permission and avoid using these permissions going forward.`
`64`		`-> - Users with admin roles such as User admins can update the photo of any user in the organization by using delegated permissions. This operation is also supported with application permissions. Updating the photo of any user in the organization requires ProfilePhoto.ReadWrite.All or User.ReadWrite.All permission. Updating the photo of the signed-in user only requires User.ReadWrite permission.`
	`64`	`+> - Users with admin roles such as User admins, Global admins, or People admins can update the photo of any user in the organization by using delegated permissions. This operation is also supported with application permissions. Updating the photo of any user in the organization requires ProfilePhoto.ReadWrite.All or User.ReadWrite.All permission. Updating the photo of the signed-in user only requires User.ReadWrite permission.`
`65`	`65`	`> - Updating a user's photo using the Microsoft Graph API is currently not supported in Azure AD B2C tenants.`
`66`	`66`
`67`	`67`	`## HTTP request`
Original file line number	Diff line number	Diff line change
`@@ -66,6 +66,7 @@ The following tables show the least privileged permission or permissions require`
`66`	`66`	`> [!NOTE]`
`67`	`67`	`>`
`68`	`68`	`> - Retrieving a user's photo using the Microsoft Graph API is currently not supported in Azure AD B2C tenants.`
	`69`	`+> - Guest users can view profile photos of users, even when the Guest user access settings are configured to the most restrictive option in Azure Active Directory External Identities settings.`
`69`	`70`
`70`	`71`	`## HTTP request`
`71`	`72`
Original file line number	Diff line number	Diff line change
`@@ -60,7 +60,7 @@ The following tables show the least privileged permission or permissions require`
`60`	`60`
`61`	`61`	`> [!NOTE]`
`62`	`62`	`>`
`63`		`-> - Users with admin roles such as User admins can update the photo of any user in the organization by using delegated permissions. This operation is also supported with application permissions. Updating the photo of any user in the organization requires ProfilePhoto.ReadWrite.All or User.ReadWrite.All permission. Updating the photo of the signed-in user only requires User.ReadWrite permission.`
	`63`	`+> - Users with admin roles such as User admins, Global admins, or People admins can update the photo of any user in the organization by using delegated permissions. This operation is also supported with application permissions. Updating the photo of any user in the organization requires ProfilePhoto.ReadWrite.All or User.ReadWrite.All permission. Updating the photo of the signed-in user only requires User.ReadWrite permission.`
`64`	`64`	`> - Updating a user's photo using the Microsoft Graph API is currently not supported in Azure AD B2C tenants.`
`65`	`65`
`66`	`66`	`## HTTP request`