User Profile
sansbacher
Brass Contributor
Joined 3 years ago
User Widgets
Recent Discussions
Re: Blocked from Migrating Entra App from Personal to Org Tenant (Production Use, Partner Account)
Sorry, no. If it used to be possible but no longer is: I can only suggest finding the right person in Microsoft who can bend the rules, reinstate the policy, or at least explain why it's no longer possible. Perhaps JillArmourMicrosoft can find someone? Otherwise, as noted: having to do create a new App and transition customers over. I only deal with "internal" Customers (our CSP clients) so I don't have any suggestions unfortunately. (in my situation I'd just create a new App [with a similar but different name] and write a script leveraging the original App to deploy the new one and then use the new to remove the old. All my stuff is entirely hands-off for the client once GDAP has been granted). Perhaps you have an account manager who can pull some strings?Re: Partner Center API: Getting subscription usage count
tl-jacob, It's been a while since I tried to do something along those lines, and it may have been pre-NCE. But I recall having to use "Offers" to link up Subscriptions and Licenses, finding the same disconnect you did. I got SubscribedSkus as you did, plus: https://learn.microsoft.com/en-us/partner-center/developer/get-all-of-a-customer-s-subscriptions To get all their Subscriptions, but Orders as you're doing probably works as well. And was able to link them using Offers: https://learn.microsoft.com/en-us/rest/api/partner-center/manage-orders/get-a-list-of-offers-for-a-market Things may have changed since I last tried, but see if you can use a known Customer's SKUs, Subscriptions, various IDs and compare with Offers - I'm sure I found OfferID matched ProductID or something. Microsoft has Products which are made up of Product SKUs, the product catalogue lists Offers of how these Products are sold. Customers get Subscriptions to Offers, and can have multiple Offers all for the same underlying License. (Again, fuzzy memory for all this, but it wasn't a straight line between SKU and Subscription, since from a License perspective it doesn't matter if it's an O365 E3 Trial or Charity or Gov't Offer of the O365 E3 Product, within the customer's tenant they would just have the total of all those Subscriptions). I was dealing with all this in the 2019 - 2020 timeframe, so could be dated. There's also a semi-frequently updated list here: https://learn.microsoft.com/en-us/entra/identity/users/licensing-service-plan-reference But I've found it is never complete. --SaulRe: About Preconsented applications
Hi joakimidland I was just going though old emails and noticed Jill had tagged me on this. Did you manage to solve this? I haven't used the actual article you referenced, but the process seems similar to the one most CSPs have been using. What are you trying to do, exactly? Are you a CSP (via the Partner Center)? Do you have Delegated Admin Permissions to Customer Tenants? Do you have GDAP Relationships set up? The process I, and I think most CSPs, use is outlined in this post to the forum: Configuring the Secure App Model for PowerShell / API / Graph scripting with GDAP for Partners | Microsoft Community Hub In particular Nick's post: https://tminus365.com/my-automations-break-with-gdap-the-fix/ You are right, there's not much point if you have to log into each customer tenant and consent to your app. The way around that is to leverage the Partner Center API: after the customer has been added to your CSP Partner Center, and a GDAP relationship established you use the Partner Center API to add the Consent to the Customer's Tenant automatically, using a POST to this endpoint: https://api.partnercenter.microsoft.com/v1/customers/$CustomerTenantId/applicationconsents and a payload containing the Application Grants (App IDs + API permissions) you want, which causes your App Registration to appear as a pre-consented Enterprise App in the Customer's Tenant. If you're doing something else, then I'm not sure. But I think the Partner Center API is what you need to use to add the App to your Customers and ensure it is pre-consented (which is possible due to a pre-existing delegated admin (GDAP) relationship). https://learn.microsoft.com/en-us/partner-center/developer/get-started Under Security you'll see the sections on GDAP, the https://learn.microsoft.com/en-us/partner-center/developer/secure-app-model-framework, and granting consent: https://learn.microsoft.com/en-us/partner-center/developer/control-panel-vendor-apis I hope that helps, if you're still having issues. If you found an alternate solution or are doing something else please post back so others can learn as well. --SaulRe: Microsoft Partner Center API Sku Property
Hello ahart3 , I think you're confused between OEM and CSP products. "P73-08328" is an OEM part number, for example: https://ca.ingrammicro.com/site/productdetail?id=A300-730A7G Where as the Partner Center uses CSP part numbers which are composed of Product IDs and SKU IDs (you'll also probably find Offer IDs and other IDs via the API's, since they can be purchased for different terms [1Y vs 3Y or monthly, etc], and there can be discounted for Gov't, Edu, Charity, etc). For example look at: https://learn.microsoft.com/en-us/partner-center/announcements/2024-october#new-software-launches---november-latest-versions You need both the Product ID and SKU ID. More details here: https://learn.microsoft.com/en-us/partner-center/pricing/software-pricing Most of all this changed when MS implemented NCE. --SaulRe: Microsoft Partner Center API - 401 Unauthorized when using access token
@JaySivaloganathan, Unfortunately I don't use grant_type=client_credentials, I don't know if that's possible with the delegated permission structure for GDAP to access Customers. I, like most people I think, use grant_type=resource_token. Where you obtain a RefreshToken (good for 90 days, but can be renewed whenever obtaining an AccessToken) and then redeem that an AccessToken (good for 60 mins) when needing to access the Partner Center or any Customer APIs. If you are JUST trying to access the Partner Center APIs (and not connect to any Customer resources) you may be able to use client_credentials, but I've not tried. Things to check: What permissions / scopes have you added to your Client App (the one referenced by your client_id)? You have not passed a scope= in your POST, what is the default scope in the data returned? I tried your POST request (using my App ID, which is also in Canada, but as I said: is set up for Refresh Token usage) and the resource ends up being the MS Graph's AppID: Check your AccessToken using https://jwt.io/ and see what the "aud" is. I tried making a request against https://graph.microsoft.com/v1.0/users and it didn't return a 401, but instead a "InvalidAuthenticationToken" error -- because the resource was wrong of course. Try adding resource=https://api.partner.microsoft.com to your request. When you do that you should get this back: And the "aud" in the AccessToken matches. I still couldn't GET the data you wanted, but as I said my setup is based around Refresh Tokens. For info on that, see: https://techcommunity.microsoft.com/t5/partner-led-questions-tech/configuring-the-secure-app-model-for-powershell-api-graph/m-p/3820555 Hopefully some of that helps. If not, try working through the links in the above link and configuring things using Refresh Tokens. --SaulRe: Missing Microsoft Partner (4990cffe-04e8-4e8b-808a-1175604b879f) API permission
You're welcome yashubale , "Please let me know if you need anything from my end to dig deeper into the issue. I know this is a tech community and not a dedicated support channel, please excuse for that." Worse, this a partner led tech community. So we're all just MS Partners, same as you. Unfortunately if your problem persists you'll need to contact your MS Partner account rep. Unless JillArmourMicrosoft has someone else she can ping who might be able to help? Sorry 😞Re: Missing Microsoft Partner (4990cffe-04e8-4e8b-808a-1175604b879f) API permission
JillArmourMicrosoft and yashubale , Are you trying to add under "Enterprise applications" or "App registrations"? The linked document is about App registrations. I can find it just fine, from my AAD/Entra CSP Partner Tenancy: OR: That is from going to App registrations and selecting an existing App of mine (if you can't find it when creating a NEW App, try adding the app without permissions and then go back and add them later: find the App, go to Manage, API permissions, and then "Add a permission" and "APIs my organization uses"). I tried both: "Microsoft Dev" and "4990cffe-04e8-4e8b-808a-1175604b879f" (the whole ID) to find it. I CAN find it under Enterprise Apps, but I don't think that's where the article is directing you (but I had to search by the whole app ID) : If you're trying all that and STILL CAN'T find it... I don't know.... Is your Tenant linked to an MS Partner Center account? When I go to one of my CUSTOMER'S Tenants and search for that App ID and create an App registration I CAN find it, but it has a DIFFERENT NAME: And if I search for Microsoft Dev I CAN'T find it: So my guess is that if you can't find it at all there's something not set correctly in or for your Tenant that allows it to be added (for whatever reason). The App ID isn't listed on the normal list of Well Known MS Apps, so maybe it's specific to Partners? https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in There aren't a lot of hits when I Google for it (even using Bing), so it's obviously niche. But it is certainly MS Partner related. If you go to https://partner.microsoft.com and log in with an AAD/Entra account from the tenant you are trying to add that App ID to an App Registration IN ... is that your MS Partner Account? If you go to top-right Gear, Account Settings, Organization Profile, Identifier does it list your Associated Partner ID on the CSP tab? Under Tenants does it list your Microsoft Entra tenant ID? If not, then try with your MS Partner Tenant. If it does... you'll probably need to contact your MS Partner rep and have them check things. If it helps I did this from my Canadian Partner Tenant. When I tried my US Partner Tenant I had the same experience as from a CUSTOMER tenant ... BUT I don't have the same admin permissions in our US tenant... so maybe it is a PERMISSION issue? Do you have Global Admin? Hopefully some of that is useful, if not I'm afraid you'll need to contact your MS Partner support person. --SaulRe: GDAP renewal time is approaching
Just a quote note to say: I noticed today that MS has included "Organizational Branding Administrator" in GDAP now. See" https://learn.microsoft.com/en-us/partner-center/customers/gdap-faq#which-microsoft-entra-roles-were-made-available-in-partner-center-ui-in-july-2024Re: Billed and unbilled daily rated usage reconciliation API v2 (GA)
If a new API (v2) is lacking certain info/fields from the original API (v1) you'll need to contact Microsoft, and use the original API in the mean-time. How or who to contact at MS to make that request I don't know, it would depend on the API. You'd need to look for support links and maybe file an issue?Re: MCA Bulk Attestation Tool question
BenB675 , I've never used the MCA Bulk tool, but it looks very similar to the GDAP Bulk Migration tool, so I can only offer some general advice: Yes, it should be http://localhost, not https. It's just the allowable addresses the app can submit for the callback when authenticating. (it's specified in the code, in TokenProvider.cs) Probably wouldn't hurt to remove and re-create the Partner Center Native App (or just make a new one, and use the new App ID) if you are concerned you don't have it configured correctly. The resource mentioned, 00000003-0000-0000-c000-000000000000, is the MS Graph API. I couldn't see any mention of it on the setup page, but that could imply that some API permissions are missing. They can be added under API Permissions on the App Registration in AAD/Entra. I don't know what would be needed. That same file (TokenProvider.cs) references a scope for https://graph.windows.net/.default, which is the old AzureAD Graph (the new MS Graph end point is https://graph.microsoft.com) But the AAD Graph is deprecated (and it's old GUID is 00000002-0000-0000-c000-000000000000) so I wonder if something needs to be updated? You could try posting an Issue for the package here: https://github.com/microsoft/Partner-Center-DotNet-Samples/issues (or search to see if any open Issues are relevant) There's some troubleshooting info on the FAQ for the tool: https://learn.microsoft.com/en-us/partner-center/customers/microsoft-customer-agreement-bulk-attestation-tool-faq But it doesn't list your error, AADSTS650057. That error again implies missing permissions, likely for MS Graph. That's about all I can offer, sorry. --SaulRe: I can't see my customer in the reports in partner earned credit
marcelo306g , Unfortunately I don't think I really understand what the problem is. If it's to do with not getting some designation or entitlement due to Customers not showing up: I feel like that's something you'll need to speak to your rep about. I don't know anything about who should show up, what drives different designations, or how you get to some next Partner level, etc. (aka "sales stuff" 🙂 If it's that you have a Customer with an Azure Subscription that you don't have access to -- that you should: you'll need to make sure that you have a GDAP Relationship with them, groups mapping to your chosen Entra/AAD Roles. Usually the AdminAgents group is granted "Owner" permissions to any Azure Subscriptions, but you can gran different permissions to different groups (though possibly only the 3 "special" Groups: AdminAgents, HelpdeskAgents, and SalesAgents -- though I've not experimented much, except to confirm it works with one of those groups). If you get grab the ObjectID of your AdminAgents group (or any other you want to check) you can confirm the permissions with something like: Get-AZRoleAssignment -Scope "/subscriptions/<SUBSCRIPTION ID>" | where ObjectId -eq <GROUP OBJECT ID> Running as a Global Admin or Subscription Owner of the Customer's Tenant. You can assign Contributor or Reviewer if you'd prefer. For more info see: https://learn.microsoft.com/en-us/partner-center/customers/reinstate-csp If they have lost access to their own Azure Subscription see: https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin?tabs=azure-portal --SaulRe: Configuring the Secure App Model for PowerShell / API / Graph scripting with GDAP for Partners
jonwbstr24 , Yes, I'm not sure I would put much stock in Microsoft's desire (or willingness) to update and support various PowerShell modules these days (with 2 exceptions: the auto/machine-generated MgGraph module, which "works" but isn't really user-friendly. And the ExchangeOnlineManagement module, currently at V3 -- which is generally pretty good) ... the PartnerCenter and other modules are either not maintained or are deprecated (and will likely stop working entirely when AzureAD Graph is retired). I would suggest making direct REST API calls, which can be done in PowerShell, for example: $body = @{ "grant_type" = "refresh_token" "refresh_token" = $RefreshToken "client_id" = $ClientId "client_secret" = $ClientSecret "resource" = "https://api.partnercenter.microsoft.com" } $response = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantId/oauth2/token" -Method Post -Body $body -ContentType "application/x-www-form-urlencoded" This is how Kelvin's CIPP app works (the source-code for the https://github.com/KelvinTegelaar/CIPP-API will show you some examples using PowerShell - including authenticating to Partner Center, Graph, and even API access to Exch Online. Or you can use any language (I've mainly switched to JavaScript/Node). Nick's https://tminus365.com/my-automations-break-with-gdap-the-fix/ I linked to above has some examples as well, look for the REST API / Invoke-RestMethod sections. Unless the community is going create a module, or fork and maintain existing modules, you're better off making yourself a collection of a few scripts/functions (eg, to redeem an RefreshToken for an AccessToken, make API calls with the AccessToken, and perform a "get-all" for when there's more than one page of results, and some functions to provision the GDAP App Consent, etc) than relying upon a PowerShell module that may work now, but may not in the future... --SaulRe: GDAP renewal time is approaching
Hi jonwbstr24 , We're looking into GDAP renewals, as they're coming up for us as well. We also selected a lot of Roles (you never know...) including Global Admin (just in case...) only to find out that Auto Renew doesn't work if GA is included 😞 I mostly do automation and development so I've not personally run into something I couldn't do with the Roles we have assigned (which is most, but not all -- and NOT Global Admin, that was strictly for "just in case" and I don't believe we've used it). But if you've found things that can't be done - or require many, many roles (which need to be configured for each customer's GDAP Relationship) that would be a drag. If you can convince MS to allow auto-renew this time, until they tweak the Roles -- I'd support it. Like you, our Customers expect us to "entirely manage their infrastructure and services" so there's no real "what do the clients think?" for us, it's more "we need this to do as they ask: manage everything efficiently". However I doubt MS will go for it, but you never know. I believe the reason is simply "fewer permissions is more security". If you CAN live without the Global Admin Role, I just noticed this: https://learn.microsoft.com/en-us/partner-center/expiring-gdap-relationships-and-auto-extend-gdap#removing-global-administrator-role You can remove the GA Role from a GDAP Relationship. I've not tried it, but it should allow auto-renew to be enabled (which can be done via API I believe). If we automate creating the GDAP Relationships and Role/Group assignments then perhaps having so many Roles to accomplish what you need (ie. everything but GA) I think it will be fairly painless. We'll see... --SaulRe: .NET SDK integration
I don't use the .NET SDK, but using JavaScript (and standard REST APIs) and/or PowerShell (using REST APIs and/or the Partner Center PS Module) works fine to connect to the Partner Center. You do have limited API functionality with an Indirect/Tier2 CSP Partner Tenant, you get full functionality only if you are a Direct/Tier1 Partner CSP. The link to "Enable API access" you included works fine - it's just about registering your AAD/Entra App. You must use an account with Global Admin AND AdminAgent privileges. Works for your regular/primary account and Sandbox (I've set up and used the Sandbox in the past, but don't use it really any more), but the steps are current. Authentication details are on this page: https://learn.microsoft.com/en-us/partner-center/developer/partner-center-authentication For delegated admin access we mainly use the Native App + User access -- for the Secure App Model (not the Web App-only auth), but it will depend on what you're doing. You'll need to get a Refresh Token (and renew it at least every 90 days) then redeem it for an Access Token (good for 60 mins) and use that as the Bearer token (unless the .NET SDK takes care of all this for you?) --SaulRe: Microsoft Partner selling
JillArmourMicrosoft , They need to be directed to however they can sign up to become a Microsoft Partner so they can, I assume, re-sell CSP services. Their Microsoft rep perhaps? Or perhaps they can work with an existing distributor such as Ingram Micro, Pax8, SherWeb, TechData, etc and become an Indirect Partner through them? I don't know what the process is to become an MS Partner. [not knowing anything about their product or business I can't say this is the best approach. A hosted SaaS offering or the Azure Marketplace may be better options? Or maybe reselling Azure products as an MS Partner is best?] --SaulRe: PNP related tests are failed due to an expired MS HLK filter on 30th Jan 2024.
JillArmourMicrosoft , I believe Rajkumar is talking about the MS Hardware Lab Kit: https://learn.microsoft.com/en-us/windows-hardware/test/hlk/ This doesn't have anything to do with Office 365 or the CSP Partner Center, as far as I know. I don't know where best to shift Rajkumar's request, some forum dealing with hardware device drivers I would think. Unless that would also be encompassed by this Partner Community? (in which case I can't offer any ideas or assistance...) --SaulRe: No more Graph API rights for new customers tenants with GDAP
JillArmourMicrosoft and @Arnaud_K, You usually need AppPlusUser authentication to leverage Delegated rights for your customers. In your screenshot the new tenant appears to be missing the Scopes. Did you provision your AzureAD/Entra Enterprise App in your tenant? Did you add the Consent in the Customer's tenant (It'll be under their AAD, under Enterprise Applications, set Application Type = "All Applications" (or clear the filter) to view) I don't know why it would work for existing but not new tenants (as DAP should have been removed a while ago). I would step through the process of creating your App and adding the Consents to the new Tenants and see if a step was missed. There's a bunch of info/links in this post: https://techcommunity.microsoft.com/t5/partner-led-tech-topics/configuring-the-secure-app-model-for-powershell-api-graph/m-p/3820555/highlight/true#M1 The bulk of the (current) info is Nick's post: https://tminus365.com/my-automations-break-with-gdap-the-fix/ If you have deployed the App/Consents to the customers and now need to update he has a follow-up post on updating them: https://tminus365.com/gdap-multi-tenant-automation/ The principles are the same for using the Graph API and the Graph PowerShell SDK. You should be able to connect to your Customers with Get-MgUser just fine using Refresh and Access Tokens. --SaulConfiguring the Secure App Model for PowerShell / API / Graph scripting with GDAP for Partners
Hi whomever may find this! With the old https://www.microsoftpartnercommunity.com/t5/Partner-Center-Security-Guidance/ct-p/partner-center-security-guidance going read-only as of March 8th, 2023 I thought I'd post a few useful links here in case someone is searching and unable to post on the old forums. The 2 main GDAP related threads on the old forum that feature info on getting Secure App Model to work with GDAP and the Exchange Online V3 PowerShell module (with the ExO automation App ID: a0c73c16-a7e3-4564-9a95-2bdf47383716 being retired eventually) are: https://web.archive.org/web/20230524021116/https://www.microsoftpartnercommunity.com/t5/Secure-Application-Model/MS-Graph-and-Partner-GDAP-access-customer-tenant-via-graph/td-p/69514 https://web.archive.org/web/20230524165847/https://www.microsoftpartnercommunity.com/t5/Secure-Application-Model/Retirement-of-the-Legacy-Exchange-Online-Public-Client-ID-app-ID/td-p/84770 These are both long threads, lots of info in a meandering kind of way. They disappeared after June 30th, 2023 - so these are links to the Internet Archive's WaybackMachine. But they're how we worked it all out - so useful background. So the best place to find current, step-by-step instructions for getting things to work is this post: https://tminus365.com/my-automations-break-with-gdap-the-fix/ It appears Nick has collected up all the info from the above 2 links, tested it, and made a fairly complete blog post, so start there. (note: for the ExO V3 stuff you must use the Customer's initial onmicrosoft.com domain for things to work properly) Big thanks to him! Nick has 2 additional posts that may be of interest as well. One on https://tminus365.com/how-to-leverage-microsoft-apis-for-automation/. And one on https://tminus365.com/gdap-multi-tenant-automation/. For some background info you can check out some of these links: The code leverages the https://learn.microsoft.com/en-us/partner-center/developer/secure-app-model-framework. It can be implemented in https://learn.microsoft.com/en-us/partner-center/developer/enable-secure-app-model#powershell. Setting it up involves a https://learn.microsoft.com/en-us/powershell/partnercenter/multi-factor-auth?view=partnercenterps-3.0. But many (most?) of us likely followed https://www.cyberdrain.com/connect-to-exchange-online-automated-when-mfa-is-enabled-using-the-secureapp-model/ (or https://www.gavsto.com/secure-application-model-for-the-layman-and-step-by-step/ too) ... originally. Though still useful background info these links have lots of outdated info, eg. they still reference Msol and AzureAD commands, but you can still mostly use them to follow along. There's also a post about https://www.gavsto.com/msp-powershell-for-beginners-part-2-securely-store-credentials-passwords-api-keys-and-secrets/ secrets, like the RefreshTokens. For CURRENT info, use the link above for https://tminus365.com/my-automations-break-with-gdap-the-fix/. Msol/MSOnline doesn't work with GDAP and AzureAD uses the old AzureAD Graph which is also being retired (use MS Graph instead, which works with GDAP). Remember: RefreshTokens are good for 90 days, redeem them for an AccessToken which is good for 60 mins. After 60 mins get another one. Before 90 days are up, get an AccessToken (which always includes a new RefreshToken) and save it instead of the old one. You can repeat that forever. But you may need to restart the process if the account you used initially changes its password - so use a dedicated account. For: Exchange Online and the https://learn.microsoft.com/en-us/powershell/partnercenter/exchange-online-gdap-app?view=partnercenterps-3.0 module and you can refer to the posts in this https://www.microsoftpartnercommunity.com/t5/Secure-Application-Model/Retirement-of-the-Legacy-Exchange-Online-Public-Client-ID-app-ID/td-p/84770, since there are mistakes and omissions in the official MS docs. Main error: use the original .onmicrosoft.com domain as the CustomerTenantID when connecting with Connect-ExchangeOnline If you use their public customer.com or their TenantID (Guid) it will work inconsistently, and you'll have problem writing (reading may work) The Secure App Model mainly uses Delegated permissions, see: https://learn.microsoft.com/en-us/graph/auth/auth-concepts and there's more info https://learn.microsoft.com/en-us/graph/permissions-overview?tabs=http Any Graph API calls will list Permissions needed depending on if you're using Delegated or Application, with https://learn.microsoft.com/en-us/graph/api/user-get?view=graph-rest-1.0&tabs=http#permissions for example. We generally use Delegated since we're accessing on behalf of Customers. You'll need to ensure your Secure App Registration has the required Graph permissions AND so does your customer Consent. Hopefully that helps someone! --Saul [Edited to add the WaybackMachine links and Nick's new posts]Re: Getting 403: "Insufficient privileges to complete the operation.
JillArmourMicrosoft and @JohnWites, I don't know off the top of my head, but you'd likely need to provide more info. Access "User Properties" where/how? In the Partner Center? Or in AzureAD/Entra via the web GUI? Or via API or PowerShell? (using Graph or AzureAD or ?) Is it just you or is anyone else in your Org able to access Users in this Customer? Is it all users for this one Customer, or just a certain user? And other Users with other Customers are just fine? Are your a Tier1/Direct or Tier2/Indirect Partner? If it's just the Partner Center, I don't think that has to do with GDAP, that's for delegated privileges, as in accessing their AzureAD, ExO, SP, etc. Partner Center is your portal, permissions in there are via the AdminAgents, HelpdeskAgents, and SalesAgents groups. You would need to be a member of AdminAgents or Helpdeskagents to do anything with the Customer's users (such as assign Licenses). Global Admin is for your Tenant. This would be the same for using the website or the ParnerCenter PowerShell module. If it's the website I'd also strongly suggest trying Incognito/Private mode in your browser [and try Chrome, Edge, and Firefox] to see if that makes a different -- I HAVE seen weird issues go away when using Incognito mode, which means you need to clear your Cookies and Site Data/Storage for the Partner Center website. You may also have to remove and recreate the whole relationship, through if you are already reselling them products I would contact MS or your Tier1 first. If it's an issue with the Customer's AzureAD, ExO, etc (using Delegated Permissions) then it does rely on GDAP: what group are in you and and AAD Roles are mapped to that Group? Is it Active? I'd try recreating the GDAP relationship (Terminate the old one after) and see if that helps. Don't add Global Admin or you won't be able to auto-renew. I hope some of that helps or at least provides some avenues to try and narrow it down. But I've never seen that error, though to be honest: I don't use the Partner Center that much myself, most of what I do I do using PowerShell and APIs using the Secure App Model. --SaulRe: Configuring the Secure App Model for PowerShell / API / Graph scripting with GDAP for Partners
bKeski , Correct, and as others have noted: Per-User MFA isn't yet fully available in the MS Graph API, though parts of it are in the beta end-point: https://learn.microsoft.com/en-us/graph/api/resources/userregistrationdetails?view=graph-rest-beta You can add your voice to speed this up: https://feedbackportal.microsoft.com/feedback/idea/12d10bfb-10e3-ec11-a81b-000d3a03dba2 Sadly, while the MS Online and Azure AD Graph based modules will be deprecated March 30th, 2024 [and "Once these modules are deprecated, they will continue to work for a minimum of six (6) months before being retired"], they are currently not receiving any new features: https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/important-azure-ad-graph-retirement-and-powershell-module/ba-p/3848270#:~:text=Current%20support%20for%20Azure%20AD%20Graph%20and%20legacy%20PowerShell%20modules I assume this means making them work with GDAP - they only support DAP. So while they may continue to work throughout most of 2024 they won't work for Partners using GDAP (which is now required) since they rely upon DAP. I don't have an answer for that. Maybe JillArmour can dig into things on the Microsoft side of things and see what we're supposed to do: we must use GDAP not DAP, but that means using MS Graph, but it doesn't support Per-User MFA actions, and the older MSOnline module relies upon the older Azure AD Graph which doesn't support GDAP. So we're stuck. And Per-User MFA is still supported, even if it's not the ideal way of managing MFA. --Saul
