New MCPP Subscription in Azure
Hi, Apologies if this is the wrong forum. Earlier this year I renewed my Action Pack subscription and had to link my billing profile at the same time. Once that had gone through, I noticed that I had a new Azure subscription called 'MCPP Subscription' I still also have my Microsoft Partner Network subscription which has all my resource groups etc in. My query is what is this new subscription? Should I start using it? My credits are linked to the old MPN subscription. I've not been able to find anything so far about it either on general internet searches or this community. many thanksPSA: Verified Publisher (Wrong) Assumptions
First and foremost, thank you, Nilesh Vishwakarma and Deepack, for sharing your internal knowledge to dispel the unnecessarily confusing topic of App Verified Publisher. I'll dive into the details of the issues, the confusion, and what I gathered during a few meetings with Microsoft Support. But first, for those seeking the simple TLDR guidance (specifically for the Verified MPN): The organization/tenant the App is under must have its own Partner Account; you can't come in with your own MPN for your clients; it needs to be their (your clients') MPN Account. Even if you created the App (the App Owner), you need some sort of Global Admin type access, and it seems like you also need some access in the associated MPN account. VERY IMPORTANT: Even if you can see and click on the Verified Publisher link to add an MPN ID, any errors you encounter are likely due to lacking rights in one or both systems. VERY IMPORTANT: The Microsoft documentation for troubleshooting this issue may lead you astray. After several days of troubleshooting on my own—reading, researching, and even involving Microsoft Support—the issue was finally resolved when my client created an MPN account, logged into Entra, clicked the Verify link, and entered their MPN ID. The takeaway here? Assume you're at the mercy of the zero trust hammer, and for something as simple as single sign-on authentication, your clients must become Microsoft Partners. For those not interested in the juicy details or listening to a grumpy gray beard rant, you are hereby released; the above are the main points to remember when applying a Verified Publisher to your App. For the rest of you, read on, and hopefully, you'll pick up more details and maybe even find it entertaining... First, if you are creating a simple App for SSO (work/school) for use on your client's website, you need to create the App on the tenant that holds the AD/Entra accounts. This makes sense. Furthermore, a publisher is required to be on the hook for and prove the validity of the App, visible to users during the consent. This also makes sense. However, what doesn't make sense is that the App Owner cannot assign the MPN ID, and even more so, anyone who is creating that App for their client needs also to have access to their client's MPN Account, and, for that matter, that the client should even need that MPN Account. Let's start with an extreme example... I'm building a website for a construction company that doesn't have an IT team. Because they have AD/Entra and I'm a loyal "Microsoft Partner" (see what I did there), we decided to go with Azure and Entra. First, I need to explain the access I think I need to the client (who is not technical). I'm on my way, creating the App and website, and I get to this Verified Publisher thing. Okay, no problem... I can click on this link to add my MPN ID. Nope, that's the first error. After finally figuring out that they need to become a Microsoft Partner, you help walk your (again, non-technical) client through this process. Okay, so you are back at the Verified Publisher with your (ahem, I mean their) new MPN ID. Again, you click on the link and add their MPN ID, and another error occurs: "The MPN ID you provided does not exist, or you do not have access to it. Please provide a valid MPN ID and try again." Okay, first, the MPN ID is valid; second, it exists; and third, what access do I need? This kitchen sink error message is not very helpful. But hey, there's a "learn more" link. Okay, so you go through hours of rummaging through the docs, and nothing is really apparent, but look at this—there's a Troubleshooting section. On the first bullet point, step four provides a link to verify the MPN (https://partner.microsoft.com/en-us/pcv/accountsettings/connectedpartnerprofile), but this reveals a "Sorry, something went wrong. Please try again later" error page. With humility, you create one of your two allowed support tickets... and when going through the same steps, they mention something about access and start naming the people that could apply the Verified Publisher... so, we have to call our (non-technical) client again to come on the chat to be walked through how to add the MPN ID, and boom, it works. At this point, you're probably part happy, part embarrassed (for no reason), and part angry. Here's the problem—well, one of them. If you don't have access to do something, we are all trained to see disabled buttons/links; if the developers are really good, they change the CSS/cursor on hover, and if they're really, really good, they provide a tooltip explaining the access that is needed to click the button or link. BUT, for all that is good, don't provide a clickable link, a non-disabled textbox, and a non-disabled button to add something we can't add in the first place. Furthermore, do not provide an overly elaborate yet somehow vague validation message. I expect more from Microsoft. Secondly—and this is a self-preservation thing—requiring our clients also to become Microsoft Partners dilutes the value of being a Microsoft Partner. I see a cartoon of a word bubble above a technical person saying, "I'm a Microsoft Partner," and in the next frame, it shows a roofer, a janitor, a homemaker, and a plethora of a thousand people, all with the same word bubble saying, "Yeah, so are we!!!" Although this is a funny view of it, the reality is that it was hard enough to explain to clients why you want to add your MPN ID to their Azure subscription or what that means... but now, why would they, when they have that same feeling of ownership as with the App, and now armed with their own MPN ID? It truly is diluting the value of a Microsoft Partnership and, further, making it harder to justify adding our MPN ID to signal to MS who we are serving. This is directly tied to how we can obtain a Silver or Gold Partnership. This seems to have been built without consideration for agencies, small businesses, and clients outside the tech field.
I can't see my customer in the reports in partner earned credit
I have a client who has an Azure Subscription (Azure Plan) and my Guest user has an Admin RBAC on the subscription scope, but I can't see my customer in the reports on partner earned credit. For that reason, I am not able to reach the partner designation because my partner punctuation in the designation does not appear. My user is a guest in the customer tenant and has already linked my partner ID in the Management Partner Blade. I need help. Thanks in advance for your time.Registrieren im Cloud-Partner-Programm
Hallo, ich verfüge über ein Azure-Konto und will mich nun für das Cloud-Partner-Programm registrieren. Es wird aber kein E-Mail-Account akzeptiert. Ich kann mich weder mit dem Azure-Konto anmelden, noch ein neues erstellen. Was mache ich falsch? Vielen Dank Klaus Götzer Translation I have an Azure account and now I want to register for the Cloud Partner Program. However, no e-mail account is accepted. I can't sign in with the Azure account, nor can I create a new one. What am I doing wrong? Thank you very much Klaus GötzerHow to integrate Microsoft User Authentication using Microsoft Entra ID: A Step-by-Step Guide to Use
Microsoft Entra ID, also known as Azure AD (Active Directory), offers numerous advantages. Whether you're prioritizing security or seeking a well-organized and automated User Management system, this tool is your go-to for building a secure authentication system, be it for a web app, mobile app, or any other application.
Create GDAP ForeignPrincipal RBAC on Azure Subscriptions without Reseller relationship
Hi Partner team, We'd like to see some improvements made to GDAP + Azure when supporting workloads in regions outside of the CSP support regions/markets. Foreign Principal Objects (FPO) should be created in the destination tenant when establishing a GDAP relationship, not just a Reseller relationship. As a partner in one country, I can't support an Azure Subscription using GDAP in a remote tenancy. The only workaround is Guest Users (which conflicts with users who are GDAP for other non-Azure workloads) or new accounts. Regards,
