Forum Discussion
GDAP and the 'Printer Administrator' role
You are probably not doing anything wrong. The Printer Administrator role being available in a GDAP relationship does not mean that every service using that role supports GDAP.
Universal Print is not currently listed as a supported GDAP workload. Its documentation also states that both users and administrators need an eligible Universal Print license. A GDAP partner identity remains in the partner tenant, so a customer Universal Print license cannot normally be assigned to it. That combination explains the 401 error, especially since a licensed local tenant administrator can open the portal.
For now, the practical solution is to use a named account in the customer tenant, assign it an eligible Universal Print license and grant only the Printer Administrator role. Administrative units can be used if access should be limited to certain printers. Avoid using Global Administrator for routine printer management.
There is currently no published commitment for broader Universal Print GDAP support. A Partner Center support request can confirm the limitation for your specific tenant and record the need for future support, but changing the GDAP roles alone is unlikely to resolve the 401 error.
- jonwbstr24Aug 07, 2026Iron Contributor
Hi Nathan! Thanks for the reply. It's always nice to have some sort of confirmation my assumptions are probably right.
On a side note, in my experience the Partner center team is responsible for confirming the GDAP relationship is provisioned, and it's the product owner's responsibility to handle any support related to GDAP after that. I'm not really sure who owns the documentation or how that gets updated, but I'm confident the partner center support and product support teams don't do it directly.
I'm not in a big hurry to open a ticket with the product support team for this just yet, since Microsoft is limiting the number of cases partners can open. The tickets I have already opened on similar queries that I expected to be non-decremented are still counting against our agreement and we're having trouble identifying who is responsible for setting a ticket to non-decremented.
Support engineers say it's the PSAM's responsibility and the engineers are just responsible for the technical aspects of the ticket. The engineer I am talking to at the moment for a different case says he doesn't even have access to make such a change. Our PSAM says they can change the flag but try to avoid overriding what the technician has already set.
I understand from our PSAM that there is a process for reviewing cases, but their focus is on moving everyone to UfP, so it is unlikely we'll get them non-decremented.
Things like "Testing our entitlements" that was closed without providing any support is currently counted against the support agreement.