Admin‑On‑Behalf‑Of issue when purchasing subscription
Hello everyone! I want to reach out to you on the internet and ask if anyone has the same issue as we do when creating PAYG Azure subscriptions in a customer's tenant, in which we have delegated access via GDAP through PartnerCenter. It is a bit AI formatted question. When an Azure NCE subscription is created for a customer via an Indirect Provider portal, the CSP Admin Agent (foreign principal) is not automatically assigned Owner on the subscription. As a result: AOBO (Admin‑On‑Behalf‑Of) does not activate The subscription is invisible to the partner when accessing Azure via Partner Center service links The partner cannot manage and deploy to a subscription they just provided This breaks the expected delegated administration flow. Expected Behavior For CSP‑created Azure subscriptions: The CSP Admin Agent group should automatically receive Owner (or equivalent) on the subscription AOBO should work immediately, without customer involvement The partner should be able to see the subscription in Azure Portal and deploy resources Actual Behavior Observed For Azure NCE subscriptions created via an Indirect Provider: No RBAC assignment is created for the foreign AdminAgent group The subscription is visible only to users inside the customer tenant Partner Center role (Admin Agent foreign group) is present, but without Azure RBAC. Required Customer Workaround For each new Azure NCE subscription, the customer must: Sign in as Global Admin Use “Elevate access to manage all Azure subscriptions and management groups” Assign themselves Owner on the subscription Manually assign Owner to the partner’s foreign AdminAgent group Only after this does AOBO start working. Example Partner tries to access the subscription: https://portal.azure.com/#@customer.onmicrosoft.com/resource/subscriptions/<subscription-id>/overview But there is no subscription visible "None of the entries matched the given filter" https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin?tabs=azure-portal%2Centra-audit-logs#step-1-elevate-access-for-a-global-administrator from the customer's global admin. and manual RBAC fix in Cloud console: az role assignment create \ --assignee-object-id "<AdminAgent-Foreign-Group-ObjectId>" \ --role "Owner" \ --scope "/subscriptions/<subscription-id>" \ --assignee-principal-type "ForeignGroup" After this, AOBO works as expected for delegated administrators (foreign user accounts). Why This Is a Problem Partners sell Azure subscriptions that they cannot access Forces resources from customers to involvement from customers Breaks delegated administration principles For Indirect CSPs managing many tenants, this is a decent operational blocker. Key Question to Microsoft / Community Does anyone else struggle with this? Is this behavior by design for Azure NCE + Indirect CSP? Am I missing some point of view on why not to do it in the suggested way?Questions about Deparments and Accounts (patterns) for Azure Enrollments
Hi guys, while thinking about which "Department/Account" Setup methodology is the best for our organization, there appear some questions from my site. As you know, there are three common patterns for Azure Enrollments (https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption/appendix/azure-scaffold#departments-and-accounts). In additional to these 3 options (functional, business unit, geographic) there is one more way like this: Enterprise -> Accounts -> Subscriptions This is an away, without creating a Department before. My questions are: Questions to deparment: What are the advantage of building a pattern with Deparments? I mean, why should I create it Departments, when a direct connections between (Enterprise and Accounts) is possible? What disatvantage has a pattern like Enterprise -> Accounts -> Subscriptions (without deparments)? Due to the reason, that deparments are not deletable (only set to inactive) and one department name, which was in use, isn't usable anymore for new active deparment I tought that we could set the Name of the deparment like this: "Department 1", "Department 2", "Department 3" etc. The knowledge which department is which deparment in our organization we would do this information in two place: 1) in cost center of the deparment 2) in our internal documentation. Question here: Is there any reason or any restriction to information, if we would do it described above? Questions to Subscription: Is in a EA offer possible, to move one or more Subscription from one Deparment A to department B ? If yes, with or without downtime? Questions to Accounts: Is it possible to assign mutiple Account to one Department? Is it possible to move one Account assigned to Department A to Department B with all their Subscriptions? If yes, with or without downtime? Please let me know if you need some more informations. Thank you for your reply in advance.
Blob Storage aggregation across domain / subscriptions to reduce cost --- possible
Block Blob storage has pricing tiers based on TB stored. You receive a discount for each level you achieve. These tiers exist for all Storage Account Type i.e. Blob, General Purpose v1 and v2. I wanted to know if there is a mechanism to "link" tenant domains and or Azure subscriptions to aggregate the total amount of data stored in blob cool such that I could achieve the lower cost spend tiers more quickly. Trying to think of ways to save money. Thank you
