About SUPERHUB
We aim to empower businesses and their employees to #WORKSMARTER with cloud solutions.
Discover More
GDAP capabilities allow partners to control access to their customers’ workloads in order to better address their security concerns. Partners can offer more services to customers who might be uncomfortable with the current levels of partner access. They can also offer services to customers who have regulatory needs that require least-privileged access to partners.
SUPERHUB empowers corporates to #WORKSMARTER by providing cloud solutions and managed services with secure, least-privileged access, helping businesses navigate digital transformation, enhance productivity, and meet regulatory needs.
GDAP is a security feature that provides partners with least-privileged access following the Zero Trust cybersecurity protocol. It lets partners configure granular and time-bound access to their customers’ workloads in production and sandbox environments. This least-privileged access needs to be explicitly granted to partners by their customers.
Partners’ access can be partitioned per customer. With GDAP, partners no longer have access to all customer tenants across Azure subscriptions through Admin agents by default. Instead, partners managing Azure are part of a separate security group, which is a member of the Admin agent group. This group grants owner role-based access control (RBAC) access on all Azure subscriptions for that customer.
Granular delegated admin permissions (GDAP) give partners access to their customers’ workloads in a way that is more granular and time-bound, which can help to address customer security concerns.
With GDAP, partners can provide more services to customers who might be uncomfortable with the high levels of partner access.
GDAP also helps with customers who have regulatory requirements to provide only least-privileged access to partners.
Someone with the Admin agent role at a partner organization can create a GDAP relationship request.
Yes. GDAP relationship requests expire after 90 days.
No. Permanent GDAP relationships with customers aren’t possible for security reasons. The maximum duration of a GDAP relationship is two years.
No, GDAP relationship does not support subscriptions purchased through enterprise agreements.
If the GDAP relationship with your customer expires, request a GDAP relationship again.
You can use GDAP relationship analytics to track GDAP relationship expiration dates and prepare for their renewal.
To extend or renew a GDAP relationship, the partner or customer must set Auto extend to Enabled.
Learn more at Manage GDAP Auto extend and API.
Yes, if GDAP is active, it could be extended.
Say a GDAP is created for 365 days with auto extend set to Enabled. On the 365th day, End Date would be effectively updated by 180 days.
No emails would be sent to partner and customer.
Yes, any active GDAP can be auto extended.
No, customer consent isn’t needed to set auto extend to Enabled against an existing active GDAP.
No, granular permissions assigned to security groups continue as is.
No, admin relationship with Global Administrator role can’t be auto extended.
The Expiring Granular Relationships page is available only to partner users having Global Administrators and Admin Agent roles.
This page helps filter GDAPs expiring across different timelines, and helps update auto extend (enable/disable) for one or more GDAPs.
No. There’s no change to a customer’s existing subscriptions when a GDAP relationship expires.
Refer to Troubleshoot Microsoft Entra multifactor authentication issues and Can’t use Microsoft Entra multifactor authentication to sign in to cloud services after you lose your phone or the phone number changes for guidance.
Partner must request Privileged authentication administrator Microsoft Entra role when creating first GDAP, to be able to reset password and authentication method for a user (admin or nonadmin).
Privileged Authentication Administrator role is part of the roles being set up by MLT (Microsoft Led Tool) and is planned to be available with Default GDAP during Create Customer flow (planned for September).
Partner could have the customer admin try Reset password. As a precaution, partner must set up SSPR (Self-service password reset) for their customers. Refer to Let people reset their own passwords.
Within a partner organization, people with the Admin agent role receive a termination notification.
Within a customer organization, people with the Global admin role receive a termination notification.
Yes. Partners can see when a customer removes GDAP in the Partner Center activity logs.
No. GDAP is an optional capability for partners who want to manage their customer’s services in a more granular and time-bound way. You can choose which customers you want to create a GDAP relationship with.
The answer depends on how you want to manage your customers.
If you want your partner users to be able to manage all customers, you can put all of your partner users into one security group and that one group can manage all of your customers.
If you prefer to have various partner users managing various customers, assign those partner users to separate security groups for customer isolation.
Yes. Indirect resellers (and indirect providers and direct-bill partners) can create GDAP relationship requests at Partner Center.
As part of GDAP setup, ensure that security groups created in partner tenant with partner users are selected. Also ensure the desired Microsoft Entra roles are assigned to the security group. Refer Assign Microsoft Entra roles.
Customers can now exclude CSPs from conditional access policy so that partners can transition to GDAP without getting blocked.
Include users – This list of users typically includes all of the users an organization is targeting in a Conditional Access policy.
The following options are available to include when creating a Conditional Access policy:
Select users and groups
External partner access – Conditional Access policies that target external users might interfere with service provider access, for example granular delegated admin privileges. For more information, see Introduction to granular delegated admin privileges (GDAP). For policies that are intended to target service provider tenants, use the Service provider user external user type available in the Guest or external users selection options.
Exclude users – When organizations both include and exclude a user or group, the user or group is excluded from the policy, as an exclude action overrides an include action in policy.
The following options are available to exclude when creating a Conditional Access policy:
Guest or external users
For more information, see:
Yes, regardless of the support plan you have, the least privileged role for partner users to be able to create support tickets for their customer is Service support administrator.
No, the partner can’t currently terminate a GDAP in Approval Pending status. It would expire in 90 days if the customer takes no action.
Only after 365 days (clean-up) post the GDAP relationship is Terminated or Expired, you can reuse the same name to create a new GDAP relationship.
Yes, a partner can manage their customers across regions without creating new partner tenants per customer region. Do note that this is applicable only to customer management role provided by GDAP (Admin Relationships). Transaction role and capabilities are still limited to your authorized Territory
No, service provider cannot be part of multi-tenant organization, they are mutually exclusive.
For information about APIs and GDAP, see the Partner Center developer documentation.
Yes. We recommend that partners use the beta GDAP APIs for production and later switch to APIs v.1 when they become available.
Although there’s a warning, “Use of these APIs in production applications isn’t supported,” that generic guidance is for any beta API under Graph and isn’t applicable to the beta GDAP Graph APIs.
Yes. GDAP relationships can be created using APIs, enabling partners to scale this process. Creating multiple GDAP relationships isn’t available at Partner Center, however. For information about APIs and GDAP, see the Partner Center developer documentation.
The API works for one security group at a time, but you can map multiple security groups to multiple roles at Partner Center.
Make individual calls for each resource. When making a single POST request, pass only one resource and its corresponding scopes.
For example, to request permissions for both https://graph.windows.net/Directory.AccessAsUser.All and https://graph.microsoft.com/Organization.Read.All, make two different requests, one for each.
Use the provided link to search for the Resource name: Verify first-party Microsoft applications in sign-in reports – Active Directory. Example:
To find the Resource ID (example: 00000003-0000-0000-c000-000000000000 for graph.microsoft.com):
This error usually occurs when an incorrect identifier is used in the query filter.
To resolve it, make sure you’re using the enterpriseApplicationId property with the correct resource ID, not the resource name.
For enterpriseApplicationId, don’t use a resource name like graph.microsoft.com
Instead, for enterpriseApplicationId, use the resource ID, such as 00000003-0000-0000-c000-000000000000.
Example: Earlier in graph.microsoft.com resource only “profile” scope was consented. Now we want to add profile and user.read also.
To add new scopes to a previously consented application:
ⓘNote: If your application requires permissions for multiple resources, execute the POST method separately for each resource.
Concatenate the required scopes using a comma followed by a space. Example: “scope”: “profile, User.Read”
1. Confirm that the ‘displayName’ and ‘applicationId’ properties in the request body are accurate and match the application you’re trying to consent into the customer tenant.
2. Ensure that you’re using the same application to generate the access token that you’re attempting to consent into the customer tenant.Example: If the application ID is “12341234-1234-1234-12341234”, then the “appId” claim in the access token should also be “12341234-1234-1234-12341234”.
3. Verify that one of the following conditions is met:
To manage Azure with per-customer access partitioning (which is the recommended best practice), create a security group (such as Azure Managers) and nest it under Admin agents.
To access an Azure subscription as an owner for a customer, you can assign any Microsoft Entra built-in role (such as Directory readers, the least privileged role) to the Azure Managers security group.For steps to set up Azure GDAP, see Workloads supported by granular delegated admin privileges (GDAP).
Yes. For information about how to restrict a user’s administrator permissions by assigning least privileged roles in Microsoft Entra, see Least privileged roles by task in Microsoft Entra.
We recommend assigning the Service support administrator role. To learn more, see Least privileged roles by task in Microsoft Entra.
To reduce the gap between Microsoft Entra roles available via. Partner Center API vs. UI, below list of 9 roles were made available in Partner Center UI in July 2024.
No. The least privileged role for partner users to be able to create support tickets for their customer is the Service support administrator. Therefore, to be able to create support tickets for the customer, a partner user must be in a security group and assigned to that customer with that role.
For information about all the roles, see Microsoft Entra built-in roles.
For information about workloads, see Workloads supported by granular delegated admin privileges (GDAP).
Many roles are used for Microsoft 365 Admin Center. For more information, see Commonly used Microsoft 365 admin center roles.
Yes. Create a security group, assign approved roles, and then assign partner tenant users to that security group.
Read-only access to customer’s subscriptions is provided by the Global reader, Directory reader, and Partner tier 2 support roles.
We recommend removing the partner agents from the Admin agent role and adding them to a GDAP security group only. That way, they can administer services (service management and log service requests, for example), but they can’t purchase and manage subscriptions (change quantity, cancel, schedule changes, and so on).
The security groups assigned to the relationship lose access to that customer. The same thing happens if a customer terminates a DAP relationship.
Yes, removing the GDAP relationships with a customer doesn’t terminate the partners’ reseller relationship with the customer. Partners can still purchase products for the customer and manage Azure budget and other related activities.
No. All roles in a GDAP relationship have the same time to expiration: the duration that was chosen when the relationship was created.
No. You don’t need GDAP to fulfill orders for new and existing customers. You can continue to use the same process to fulfill customer orders in Partner Center.
GDAP relationships are per-customer. You can have multiple relationships per customer. Each GDAP relationship can have different roles and use different Microsoft Entra groups within your CSP Tenant.
In Partner Center, role assignment works at customer-to-GDAP relationship level. If you want to multicustomer role assignment, you can automate using APIs.
Guest accounts do not work with GDAP. Customers must remove any guest accounts to get GDAP to work.
No, you don’t need DAP or GDAP to purchase Azure Plans and provision Azure subscriptions for a customer. The process to create an Azure Subscription for a customer is documented at Create a subscription for a partner’s customer – Microsoft Cost Management + Billing.
By default, the Admin Agents group in the Partner’s tenant becomes the owner of the Azure Subscriptions provisioned for the customer. Sign in to the Azure portal using your Partner Center ID.
To provision access to the customer, you need a GDAP relationship. The GDAP relationship must include at minimum the Microsoft Entra role of Directory Readers.
To provision access in Azure, use the access control (IAM) page. For AOBO, sign in to Partner Center, and use the Service Management page to provision access to the customer.
GDAP currently only supports Microsoft Entra built-in roles. Custom Microsoft Entra roles aren’t supported.
GDAP guest admins are unable to manage their own security information at My Security-Info. Instead, they’ll need the assistance of the tenant admin they’re a guest in for any security info registration, update, or deletion. Organizations can configure cross-tenant access policies to trust the MFA from the trusted CSP tenant. Otherwise GDAP guest admins will be limited to only methods registerable by the tenants admin (which is SMS or Voice). To learn more, see Cross-tenant access policies.
Aligning to the Guiding principle of Zero Trust: Use least privilege access:
We recommend using a least-privileged role by task and workload tasks Workloads supported by granular delegated admin privileges (GDAP) supported by GDAP.
When it’s necessary to work around listed known issues, work with your customer to request a time-bound Global Administrator role.
We don’t recommend replacing the Global Administrator role with all possible Microsoft Entra roles.
Yes. During the transition period, DAP and GDAP will coexist, with GDAP permissions taking precedence over DAP permissions for Microsoft 365, Dynamics 365, and Azure workloads.
DAP and GDAP coexist during the transition period. However, GDAP will eventually replace DAP to ensure that we provide a more secure solution for our partners and customers. It’s advised that you transition your customers to GDAP as soon as possible to ensure continuity.
There are no changes to the existing DAP relationship flow while DAP and GDAP coexist.
DAP is currently granted when a new customer tenant is created. Starting September 25, 2023, Microsoft will no longer grant DAP for new customer creation and will instead grant Default GDAP with specific roles. The default roles vary by partner type, as shown in the following table:.
| Microsoft Entra roles Granted For Default GDAP | Direct Bill Partners | Indirect Providers | Indirect Resellers | Domain Partners | Control Panel Vendors (CPVs) | Advisor | Opted out of Default GDAP (No DAP) |
|---|---|---|---|---|---|---|---|
| 1. Directory Readers. Can read basic directory information. Commonly used to grant directory read access to applications and guests. | x | x | x | x | x | ||
| 2. Directory writers. Can read and write basic directory information. For granting access to applications, not intended for users. | x | x | x | x | x | ||
| 3. License Administrator. Can manage product licenses on users and groups. | x | x | x | x | x | ||
| 4. Service Support Administrator. Can read service health information and manage support tickets. | x | x | x | x | x | ||
| 5. User Administrator. Can manage all aspects of users and groups, including resetting passwords for limited admins. | x | x | x | x | x | ||
| 6. Privileged Role Administrator. Can manage role assignments in Microsoft Entra, and all aspects of Privileged Identity Management. | x | x | x | x | x | ||
| 7. Helpdesk Administrator. Can reset passwords for non-administrators and Help Desk administrators. | x | x | x | x | x | ||
| 8. Privileged Authentication Administrator. Can access to view, set, and reset authentication method information for any user (admin or nonadmin). | x | x | x | x | x | ||
| 9. Cloud Application Administrator. Can create and manage all aspects of app registrations and enterprise apps except App Proxy. | x | x | x | x | |||
| 10. Application Administrator. Can create and manage all aspects of app registrations and enterprise apps. | x | x | x | x | |||
| 11. Global Reader. Can read everything that a Global administrator can, but can’t update anything. | x | x | x | x | x | ||
| 12. External Identity Provider Administrator. Can manage federation between Microsoft Entra organizations and external identity providers. | x | ||||||
| 13. Domain Name Administrator. Can manage domain names in cloud and on-premises. | x |
Partners can implement Privileged Identity Management (PIM) on a GDAP security group in the partner’s tenant to elevate the access of a few high-privilege users, just in time (JIT) to grant them high-privilege roles like Password admins with automatic removal of access.
Until January 2023, it was required that every Privileged Access Group (former name for the PIM for Groups feature) had to be in a role-assignable group. This restriction has been removed. Given this, it’s possible to enable more than 500 groups per tenant in PIM, but only up to 500 groups can be role-assignable.
Partners can use both role-assignable and non-role-assignable groups in PIM. This effectively removes the limit on 500 groups/tenant in PIM.
With the latest updates, there will be two ways to onboard group to PIM (UX-wise): from the PIM menu or from the Groups menu. Regardless of the way you choose, the net result is the same.
For more information, see Privileged Identity Management (PIM) for Groups (preview) – Microsoft Entra.
GDAP is generally available with support for all Microsoft commercial cloud services (Microsoft 365, Dynamics 365, Microsoft Azure, and Microsoft Power Platform workloads). For more information about how DAP and GDAP can coexist and how GDAP takes precedence, see How will GDAP take precedence over DAP.
This action can be carried out by APIs.
No. Your PEC earnings won’t be affected when you transition to GDAP. There are no changes to PAL with the transition, ensuring that you continue to earn PEC.
If a partner’s customer has DAP only and DAP is removed, PEC isn’t lost.
If a partner’s customer has DAP, and they move to GDAP for Office and Azure simultaneously, and DAP is removed, PEC isn’t lost.
If the partner’s customer has DAP, and they move to GDAP for Office but keep Azure as-is (they don’t move to GDAP) and DAP is removed, PEC won’t be lost, but Azure subscription access will be lost.
If an RBAC role is removed, PEC is lost, but removing GDAP won’t remove RBAC
When the user is part of both the GDAP security group and the DAP Admin agents group and the customer has both DAP and GDAP relationships, GDAP access takes precedence at the partner, customer, and workload level.
For example, if a partner user signs in for a given workload and there’s DAP for the Global admin role and GDAP for the Global reader role, the partner user only gets Global reader permissions.
If there are three customers with GDAP roles assignments to only GDAP security group (not Admin agents):
| Customer | Relationship with partner |
|---|---|
| Customer 1 | DAP (no GDAP) |
| Customer 2 | DAP + GDAP both |
| Customer 3 | GDAP (no DAP) |
The following table describes when a user signs in to a different customer tenant.
| Example user | Example customer tenant | Behavior | Comments |
|---|---|---|---|
| User 1 | Customer 1 | DAP | This example is DAP as-is. |
| User 1 | Customer 2 | DAP | There’s no GDAP role assignment to the Admin agents group, which results in DAP behavior. |
| User 1 | Customer 3 | No access | There’s no DAP relationship, so the Admin agents group doesn’t have access to customer 3. |
| User 2 | Customer 1 | DAP | This example is DAP as-is |
| User 2 | Customer 2 | GDAP | GDAP takes precedence over DAP because there’s a GDAP role assigned to user 2 through the GDAP security group even if the user is part of the Admin agent group. |
| User 2 | Customer 3 | GDAP | This example is a GDAP-only customer. |
| User 3 | Customer 1 | No access | There’s no GDAP role assignment to customer 1. |
| User 3 | Customer 2 | GDAP | User 3 isn’t part of the Admin agent group, which results in GDAP-only behavior. |
| User 3 | Customer 3 | GDAP | GDAP-only behavior |
DAP and GDAP aren’t eligible association types for Solutions Partner designations and disabling or transitioning from DAP to GDAP won’t affect your attainment of Solutions Partner designations. Your renewal of legacy competency benefits or Solutions Partner benefits will also not be affected.
Go to Partner Center Solutions Partner designations to view what other partner association types are eligible for Solutions Partner designations.
With respect to the relationship between Azure Lighthouse and DAP/GDAP, think of them as decoupled parallel paths to Azure resources, so severing one shouldn’t affect the other.
Managed Service Providers (MSPs) enrolled in the Cloud Solution Provider (CSP) program as indirect resellers or direct bill partners can now use Microsoft 365 Lighthouse to set up GDAP for any customer tenant. Because there are a few ways that partners are managing their transition to GDAP already, this wizard lets Lighthouse partners adopt role recommendations specific to their business needs. It also lets them adopt security measures like just-in-time (JIT) access. MSPs can also create GDAP templates through Lighthouse to easily save and reapply settings that enable least-privileged customer access. For more information, and to view a demo, see the Lighthouse GDAP setup wizard.
MSPs can set up GDAP for any customer tenant in Lighthouse. To access customer’s workload data in Lighthouse, a GDAP or DAP relationship is required. If GDAP and DAP coexist in a customer tenant, GDAP permissions take precedence for MSP technicians in GDAP-enabled security groups. For more information on requirements for Microsoft 365 Lighthouse, see Requirements for Microsoft 365 Lighthouse.
The correct sequence to follow for this scenario is:
Create a GDAP relationship for both Microsoft 365 and Azure.
Assign Microsoft Entra roles to security groups for both Microsoft 365 and Azure.
Configure GDAP to take precedence over DAP.
Remove DAP.
ⓘ Important: If you don’t follow these steps, existing Admin agents managing Azure might lose access to Azure subscriptions for the customer.
The following sequence could result in losing access to Azure subscriptions:
Remove DAP: You won’t necessarily lose access to an Azure subscription by removing DAP. But at this time you can’t browse the customer’s directory to do any Azure RBAC role assignments (such as assigning a new customer user as subscription RBAC contributor).
Create a GDAP relationship for both Microsoft 365 and Azure together: You might lose access to the Azure subscription at this step as soon as GDAP is set up.
Assign Microsoft Entra roles to security groups for both Microsoft 365 and Azure: You’ll regain access to Azure subscriptions after Azure GDAP setup is complete.
If you have Azure subscriptions without DAP that you manage as owner, by adding GDAP for Microsoft 365 to that customer, you might lose access to the Azure subscriptions. To avoid that, move the customer to Azure GDAP at the same time that you move the customer to Microsoft 365 GDAP.
ⓘ Important: If these steps aren’t followed, existing Admin agents managing Azure might lose access to Azure subscriptions for the customer.
No. Relationships, once accepted, aren’t reusable.
If you have an existing reseller relationship with the customer, you’ll still need to establish a GDAP relationship in order to can manage their Azure subscriptions.
Once this is done, you’ll be able to manage your customer’s Azure subscription via AOBO. The subscription can’t be managed via CLI/Powershell.
Yes, you can create an Azure plan even if there’s no DAP or GDAP with an existing reseller relationship; however, in order to manage that subscription, you’ll need DAP or GDAP.
As partners transition from DAP to GDAP, they must ensure the following are in place to see Company details:
When a CSP logs into their customer’s Azure portal (portal.azure.come) using their CSP credentials and a GDAP relationship exists, the CSP notices that their username is “user_” followed by some number. It doesn’t display their actual username as in DAP. This is by design.
| Tenant type | Availability date | Partner Center API behavior (POST /v1/customers) enableGDAPByDefault: true |
Partner Center API behavior (POST /v1/customers) enableGDAPByDefault: false |
Partner Center API behavior (POST /v1/customers) No change to request or payload |
Partner Center UI behavior |
|---|---|---|---|---|---|
| Sandbox | September 25, 2023 (API Only) | DAP = No. Default GDAP = Yes | DAP = No. Default GDAP = No | DAP = Yes. Default GDAP = No | Default GDAP = Yes |
| Production | October 10, 2023 (API + UI) | DAP = No. Default GDAP = Yes | DAP = No. Default GDAP = No | DAP = Yes. Default GDAP = No | Opt-in/out available: Default GDAP |
| Production | November 27, 2023 (GA rollout completed on December 2) | DAP = No. Default GDAP = Yes | DAP = No. Default GDAP = No | DAP = No. Default GDAP = Yes | Opt-in/out available: Default GDAP |
Partners must explicitly grant granular permissions to security groups in the Default GDAP.
As of October 10, 2023, DAP is no longer available with reseller relationships. The updated Request Reseller Relationship link is available in Partner Center UI, and the API contract “/v1/customers/relationship requests” property URL returns the invitation URL to be sent to the admin of the customer tenant.
Yes, partners must explicitly grant granular permissions to security groups in the Default GDAP to manage customer.
Partners with reseller relationship only without DAP or GDAP can create customers, place & manage orders, download software keys, manage Azure RI. They can’t view customer company details, can’t view users or assign licenses to users, can’t log tickets on behalf of customers, and can’t access & administer product specific admin centers (For example, Teams admin center.)
For a partner or CPV to access and manage a customer tenant, their app’s service principal must be consented in customer tenant. When DAP is active, they must add the app’s service principal to the Admin Agents SG in the partner tenant. With GDAP, partner must ensure their app is consented in customer tenant. If the app uses delegated permissions (App + User) and an active GDAP exists with any of the three roles (Cloud Application Administrator, Application Administrator, Global Administrator) consent API can be used. If the app uses application only permissions, it must be manually consented to, either by the partner or customer having any of the three roles (Cloud Application Administrator, Application Administrator, Global Administrator), using tenant-wide admin consent URL.
If you’re seeing the following error:
“We are unable to validate your ‘Create new GDAP relationship’ request at this time. Be advised anonymous connections aren’t allowed for this service. If you believe you received this message in error, please try your request again. Click to learn about action you can take. If the issue persists, contact support and reference message code 715-123220 and Transaction ID: guid.”
Change how you connect to Microsoft to allow our identity verification service to run properly, so we can ensure your account hasn’t been compromised and is compliant with regulations that Microsoft must adhere.
After trying these steps, you’re still unable to connect, we suggest consulting with your IT Help Desk to check your settings to see if they can help identify what is causing the issue. Sometimes the issue is in your company’s network settings, in which case your IT administrator would need to address the problem for instance, by safelisting our site or other network setting adjustments.
Restricted (Direct Bill): New GDAP (Admin Relationships) CANNOT be created. Existing GDAPs and their role assignments CAN be updated.
Suspended (Direct Bill/Indirect Provider/Indirect Reseller): New GDAP CANNOT be created. Existing GDAPs and their role assignments CANNOT be updated.
Restricted (Direct Bill) + Active (Indirect Reseller): For Restricted Direct Bill: New GDAP (Admin Relationships) CANNOT be created. Existing GDAPs and their role assignments CAN be updated. For Active Indirect Reseller: New GDAP CAN be created, existing GDAPs and their role assignments CAN be updated.
When offboarded new GDAP cannot be created, existing GDAP and their role assignments cannot be updated.
Yes. The current release of GDAP supports all products: Microsoft 365, Dynamics 365, Microsoft Power Platform, and Microsoft Azure.
Sources: Microsoft GDAP frequently asked questions| Microsoft Partner Center
