Azure Lighthouse: Bring Your Partner In, Without Letting Their Identities In (part 2 of 3)
See part 1 – Implementing Azure Lighthouse: A Technical Guide for Service Providers and Enterprises (part 1 of 2) See part 3 – Should You Use the New Microsoft Entra Tenant Governance or Azure Lighthouse? (part 3 of 3) [to be published on 7/23/26] The three traditional ways in, and what each leaves behind When a provider needs to operate your Azure resources, there are three common patterns. Microsoft’s own cross‑tenant management guidance describes the starting point bluntly: “an administrator in the customer’s tenant must create and manage user accounts for the service provider.” (cross‑tenant management experience) B2B guest accounts. You invite each provider engineer into your tenant through Microsoft Entra External ID and assign them Azure roles. A real user object is created in your directory (its UPN carries the #EXT# marker) and it can be “managed like an employee, for example, added to groups or assigned to applications.” Convenient, but now it’s your object to track, review, and eventually delete. Member (local) accounts. You create internal accounts, sometimes licensed, for provider staff. Microsoft’s secure external access guidance lists the drawbacks of these “local credentials” plainly: “Access continues after external user terminates,” the Member user type “grants too much default access,” and you take on “password and multifactor authentication management… [and] identity cleanup.” Member users also receive broad default directory permissions, they can enumerate users, create security groups, and register applications. Service principals with shared secrets. You register an app and hand the provider a client secret or certificate. Microsoft’s app‑registration security guidance is explicit: “Don’t use password credentials… they are often mismanaged and can be easily compromised,” and you must “roll over credentials frequently.” And because an app object and its service principal are governed separately from the Azure role assignments they hold, deleting the app won’t revoke the access it was granted in your subscriptions, those assignments persist as separate objects until you remove them. Each of these makes the provider’s identity your operational problem, and the bill grows with every new vendor. The hidden cost: you inherit an identity‑lifecycle problem External identities have no HR signal inside your tenant. Microsoft’s identity governance overview notes that lifecycle automation is normally “tied to the representation of that person in an HCM or HR system”, but the provider’s joiners, movers, and leavers live in their HR system, not yours. When an engineer leaves the provider, nothing in your tenant knows. So you compensate with machinery. To keep guest sprawl in check you run access reviews and entitlement management, capabilities that require a Microsoft Entra ID Governance or Entra Suite license. You watch for stale guest accounts, which Microsoft flags only after a 90‑day inactivity default. Because partner devices aren’t managed by you, device‑based Conditional Access blocks them whenever you enforce such a policy, so you build per‑partner exclusion lists. And you rotate service‑principal secrets on a schedule. Now multiply all of that by every vendor. Every vendor adds external identities, guests, members, and service principals, into your own Microsoft Entra tenant, where they become your responsibility to govern. The result is external‑identity debt. Microsoft’s access‑reviews guidance warns that “excessive access rights can lead to compromises… [and] audit findings as they indicate a lack of control over access.” And it runs against Zero Trust, which treats identity as the primary security perimeter: every external account you hold is a piece of attack surface you now own. A lesser‑known exposure: identities that can create subscriptions There’s a subtler reason to keep external partners out of your directory, and it has nothing to do with the roles you assign them. By default, any identity that exists in your tenant, including a guest or a member account, can create new subscriptions in your tenant, or bring external ones into it, without holding any Azure permission you granted. Those subscriptions land inside your tenant and inherit your directory, yet they originate outside your procurement, billing, and governance, and it’s surprisingly easy to miss that it happened. It’s a real gap, and closing it takes deliberate, tenant‑wide controls that many organizations simply haven’t put in place. (The specifics are best worked through privately with your Azure and billing administrators.) The point that matters here is about where the partner’s identity lives: the exposure exists only because there is an account in your tenant to exercise it. A Lighthouse provider has no identity in your tenant at all, so this entire class of exposure simply doesn’t apply to them. It’s one more thing you never have to govern when the partner never becomes a resident of your directory. A better model: Azure Lighthouse Azure Lighthouse takes a different approach called Azure delegated resource management. Instead of importing the provider’s people into your directory, it lets authorized users who remain entirely in the provider’s own tenant operate on your resources, “without having an account in that customer’s Microsoft Entra tenant or being a co‑owner of the customer’s tenant.” Azure Lighthouse projects the provider’s identities onto your subscriptions through Azure Resource Manager. The only objects created in your tenant are two ARM resources you can audit and remove. Mechanically, you (specifically, an Owner or equivalent in your tenant) deploy a small Azure Resource Manager template, or accept a private Marketplace offer, that creates two resources in your subscription: a registration definition (which managing tenant, and which built‑in roles for which provider principals) and a registration assignment (binding that to a subscription or resource group). From then on, when a provider user acts on your resources, Azure Resource Manager checks those two resources and authorizes the request. Access is one‑directional, from the managing tenant to yours, and it exists only because you deployed it. Crucially, no provider user, guest, member, or service‑principal object is ever created in your directory. Provider identities, and the MFA, Conditional Access, and device‑compliance policies that govern them, stay where the provider already manages them. There is also no extra charge for Azure Lighthouse itself. Conditional Access Policy Considerations Because provider users authenticate in their tenant, your Conditional Access policies do not apply to them. Microsoft states it directly in the recommended security practices: “Conditional access policies on customer tenants don’t apply to users who access the customer’s resources through Azure Lighthouse. Only policies set on the managing tenant apply.” That’s a natural consequence of the identity living with the provider. It just means the controls move from “policies you enforce” to “controls you require and verify”: insist the provider enforces MFA and Conditional Access on its own users, write it into the contract, and use Azure Policy to restrict which managing tenants can ever be delegated to. Think of it as a shared‑responsibility split: You control The provider controls Joint Delegated scope (subscription or resource group) User lifecycle (joiner/mover/leaver) Evidence & audit cadence Which managing tenant is approved MFA / Conditional Access Incident response process The exact built‑in roles granted PIM activation policy Security‑review schedule Azure Policy guardrails, monitoring, log export Device posture & group membership Revocation, at any time Side‑by‑side: it’s about who owns the work The strongest argument for Lighthouse isn’t that it can do things the alternatives can’t, a well‑run B2B program can also use named identities, access reviews, and PIM. The difference is who owns the operational burden, and how much of it lands in your directory. Consideration B2B guest Member account Service principal Azure Lighthouse Identity object in your directory Yes (#EXT#) Yes Yes (app + SP) None Identity‑lifecycle owner You You You The provider Offboard the Azure access Manual cleanup Manual cleanup Manual + rotate secret Remove delegation (one action) Privilege‑escalation prevention Depends on roles + your IAM Depends Depends Blocked by the platform Per‑person audit trail (ARM) Yes (named guest) Yes No (shared identity) Yes (your Activity Log) JIT for privileged roles Possible, you configure & license Possible, you configure Usually not Possible, provider configures Your IAM blade stays clean No No No Yes Governance‑licensing owner You (Entra ID Governance) You You The provider (for JIT) The rest of this article walks the Azure Lighthouse column. Benefit 1, Identity lifecycle stays with the provider Because the identity lives in the provider’s tenant, the provider’s own joiner‑mover‑leaver process governs it automatically. When an engineer leaves, the provider disables that account in their directory, and the person’s access to your delegated scope is gone, with no lingering object in your tenant to find and remove. The best practice of assigning access to a security group makes this even cleaner: the provider adds and removes individuals from the group on their side, and you never touch the delegation. Contrast that with the member‑account drawback, “access continues after external user terminates”, and the difference is stark. Provider turnover stops creating identity‑cleanup work in your directory; your job shifts to governing the delegation and verifying the provider’s lifecycle controls. Benefit 2, Least privilege you don’t have to police Azure Lighthouse won’t even let a provider hold the roles that would let them take over. Per the role‑support rules, delegation supports the Azure built‑in roles except: The Owner role can’t be delegated. Custom roles and classic administrator roles aren’t supported. Roles with DataActions (data‑plane) permissions aren’t supported. Roles carrying Microsoft.Authorization/* write/delete actions (role assignments, role definitions, locks, deny assignments) aren’t supported. User Access Administrator is allowed only for the narrow purpose of assigning roles to managed identities, and you specify exactly which. The practical effect: a delegated provider cannot grant itself more access, edit your role assignments, set resource locks, create deny assignments, or lock you out of your own resources. Least privilege here is enforced by the platform, not by your vigilance. One honest nuance to scope carefully: Lighthouse operates at the Azure Resource Manager control plane only and grants no direct data‑plane access, no reading blob contents or Key Vault secret values, as the cross‑tenant documentation explains. But a few control‑plane actions can surface data indirectly (for example, a role that allows listKeys can return storage account keys), so choose the built‑in roles you delegate deliberately. Benefit 3, One action ends it, for either party Offboarding a whole vendor is normally a scavenger hunt across guests, accounts, secrets, and scattered role assignments. With Lighthouse it’s a single step. As the remove‑delegation guidance puts it, after a delegation is removed “no users in the service provider’s tenant will be able to access the resources that had been previously delegated.” When a project ends, removing the single delegation instantly cuts off the provider’s access to your scope, and leaves nothing behind in your directory. Either party can perform the removal. And importantly, either party can end it. You, an Owner in your tenant, can remove the offer from the Service providers page at any time, without involving the provider. The provider can also remove the delegation from their side when the engagement wraps up, provided they were granted the Managed Services Registration Assignment Delete Role during onboarding (a recommended practice). Removal is unilateral on either side, takes effect for all of the provider’s users at once, and touches only the Lighthouse delegation, any other access a vendor holds is separate. Benefit 4, Complete, named visibility Delegation doesn’t mean flying blind. Every action a provider takes is recorded in your Azure Activity Log, and the “Event initiated by” column shows the specific provider user by name, the same place you see your own administrators’ actions. Logs are retained 90 days in‑portal and can be exported for longer, and you can set activity‑log alerts on critical operations. Interestingly, those provider users don’t clutter your Access Control (IAM) blade, “these users and their role assignments don’t appear in Access Control (IAM).” You manage them in the dedicated Service providers experience instead, so your native role assignments stay clean. You can also use built‑in Azure Policy definitions to audit existing delegations or deny delegation to any managing tenant that isn’t on your approved list. Benefit 5, Just‑in‑time access, not standing privilege Standing privileged access is a well‑documented risk: with a permanent assignment, as Microsoft’s PIM documentation describes, “a user can always use the role without performing any actions.” Lighthouse supports a better pattern through eligible authorizations, which use Microsoft Entra Privileged Identity Management so a provider user must activate a privileged role just‑in‑time. Activation is time‑bound (between 30 minutes and 8 hours), can require MFA, and can require approval. Just‑in‑time elevation flows through Microsoft Entra PIM. When approval is required, the approver is in the provider’s tenant, not yours. Your safeguards are MFA, the bounded activation window, review at onboarding, and full Activity‑Log visibility. Per the eligible‑authorizations documentation, you can designate “up to 10 users or user groups in the managing tenant who can approve or deny requests.” In other words, approval, when required, is granted by the provider’s own approvers, not by the customer. That’s a deliberate design choice, and your safeguards are real and layered: customers can “review all role assignments, including those in eligible authorizations, before the onboarding process,” you can require MFA on activation, the activation window is capped, and every elevation appears in your Activity Log. (Two practical notes: eligible authorizations need the provider to hold an Entra ID Governance/PIM license, and they aren’t supported in national clouds.) Benefit 6, Scale without sprawl Because each provider is a separate delegation, the model scales cleanly: add a vendor by adding a delegation, remove one without touching the others, and govern them all from one place. And the management happens with the Azure tools you already use, cross‑tenant. The cross‑tenant management experience spans Microsoft Sentinel, Microsoft Defender for Cloud, Azure Policy at scale, Azure Arc for hybrid servers and Kubernetes, and Azure Monitor, none of which require importing identities to make work. For managed security providers in particular, this is significant: a single SOC can manage Sentinel workspaces across many customer tenants while each customer’s data stays in their own tenant, and the provider’s queries and playbooks stay in theirs. Govern delegations, not people Step back and the deepest benefit comes into focus. The traditional model asks you to govern external people, accounts, and secrets, forever, inside your directory. Lighthouse changes the unit of governance to a single approved delegation: a managing tenant, a scope, a set of roles, and a revocation switch. That shift has four consequences worth internalizing: Vendor turnover never becomes your identity churn. Your directory doesn’t accumulate vendor identities as your vendor list grows. Privilege escalation is blocked by the platform, not policed by your team. The identity lifecycle, and the PIM/governance licensing for just‑in‑time access, sits with the provider, the party that actually employs the people. “But we’ve already built all this” If your team has invested in JML automation, recurring access reviews, Conditional Access exclusion lists, secret‑rotation pipelines, and entitlement management, that’s real and valuable work, and it works. The reframe is simple: those processes manage a problem that Lighthouse removes for Azure control‑plane partner access. You can keep spending effort, licensing, and residual risk to govern people you don’t employ, or you can retire that specific machinery for this use case. Keep your governance program for your own workforce; stop extending it to other companies’ staff. Deploy it well: secure‑by‑design guardrails Treat these as part of the design, not as caveats: Require and verify provider MFA/PIM, your Conditional Access doesn’t apply to their users, so make it a contractual obligation and ask for evidence. Delegate least privilege, use the narrowest built‑in roles, and avoid roles that can surface keys unless you truly need them. Restrict approved managing tenants with Azure Policy (audit or deny). Export Activity Logs beyond the 90‑day window to meet your retention requirements, and alert on critical operations. Prefer JIT (eligible authorizations) for any privileged role. Mind the boundaries, some scenarios (such as Microsoft Defender for Cloud) require whole‑subscription delegation, and Lighthouse can’t span a national cloud and the public cloud. Where Lighthouse stops, and what to use instead Lighthouse is deliberately scoped to the Azure Resource Manager control plane. It does not grant Microsoft Entra ID directory roles (like Global Administrator) and it does not cover Microsoft 365 workloads such as Exchange, SharePoint, Teams, or Intune. When a provider genuinely needs to manage identities consider Microsoft Entra Tenant Governance as described in part 3, or for managing Microsoft 365 the companion product is Microsoft 365 Lighthouse, a separate service with its own model. Beyond MSPs: it’s not only for service providers Two adjacent scenarios are worth knowing about: Enterprises with multiple tenants. If your own organization spans several Microsoft Entra tenants (through acquisitions, or separation of dev/test from production), you can use Azure Lighthouse within the enterprise to manage resources across them from one place, the same delegation model, applied internally. CSP partners. For partners transacting through the Cloud Solution Provider program, Lighthouse narrows the broad “Admin Agent” AOBO model. Instead of every Admin Agent having sweeping access to every customer, Lighthouse “helps improve security by limiting broad access” with granular, per‑customer, per‑role assignments. Getting started: a low‑risk pilot You don’t have to commit your production estate to prove the model. A sensible first step: Delegate one non‑production subscription to the provider’s tenant. Grant least‑privilege built‑in roles, with JIT (eligible authorizations) for anything privileged. Require MFA for your own admins, and require the provider to enforce MFA on its delegated users (your Conditional Access doesn’t reach them). Turn on activity‑log alerts and an Azure Policy that restricts approved managing tenants. Review after 30 days, then expand. The provider builds the onboarding ARM template (Microsoft publishes ready‑to‑use samples on GitHub), and you deploy it with an Owner account. Because you can remove the delegation at any time, the downside is bounded and reversible, while the upside compounds with every vendor you onboard this way. Summary Letting a partner operate your Azure environment doesn’t have to mean adopting their people into your directory. With Azure Lighthouse, the provider brings their own governed identities, you grant a scoped and fully revocable delegation that you approve, every action is attributed in your own logs, the platform itself prevents privilege escalation, and the identity‑lifecycle burden stays with the company that employs the staff. You stop governing other people’s employees, and start governing one clean, auditable relationship. That’s a better deal for your security team, your auditors, and your partners alike. Further reading Azure Lighthouse What is Azure Lighthouse? Azure Lighthouse architecture Cross‑tenant management experiences Tenants, users, and roles Recommended security practices Create eligible authorizations (JIT/PIM) Onboard a customer Remove a delegation Monitor service‑provider activity View and manage service providers Enterprise (multi‑tenant) scenarios Azure Lighthouse and the CSP program Azure Lighthouse samples (GitHub) Microsoft Entra, RBAC & Zero Trust B2B collaboration overview Properties of a B2B guest user Plan secure external access Access reviews Entitlement management Privileged Identity Management Default user permissions Clean up stale guest accounts App‑registration security best practices Azure RBAC overview Azure identity management & Zero Trust
Wish: Add 'Customer Name' to Azure Portal Views as a Column (or 'Group By') Option
I work for a CSP and use Azure Lighthouse to manage many customer environments. All of the Azure portal views are focused on the concept of the subscription being the top level management object in Azure (I'm excluding Management Groups for policy management). I'm sure this works well for single organisations that use Azure portal, but for CSPs we need to be able to order/arrange/group lists based on customer name first and then by subscription. In other words, our administration view has to start one level above subscription compared with most organisations. I know you can change the directory filter if you want to work on a single customer's environment and limit the view to their resources, but most often we are managing at scale and operating on multiple customer estates at once and as such we need lists to be built around the customer as the topmost object rather than the subscription. When we are confronted with a long list of subscriptions (some of which being unhelpfully named 'Subscription 1' or 'Azure' by customers who have not followed CAF...) it is impossible to determine which customer that sub relates to without following each and every subscription link. It's onerous. Not all customers allow us to impress a subscription naming convention on their Azure environment (we might be contracted to only support a subset of their subscriptions and they are unwilling to change them). An example would be the Virtual Machines list. Microsoft offers no fewer than 33 'Group By' attribute options, none of which is 'Customer'. Some views allow you to add a column and Group By tag, but a surprisingly small number of views support column manipulation. I'm hoping someone from the MSFT PG sees this and hears my plea: please keep CSPs in mind when designing Azure Portal and allow us to add a column for 'Customer Name' throughout, it would be of huge benefit to us!Azure Lighthouse – An Independent Software Vendor’s perspective
Hello folks I partnered with the product group and actual IT professionals outside of Microsoft to create a video series where we look at Azure Lighthouse and its benefits from a variety of different perspectives. If you’ve ever had to deploy, manage, and support a workload or an application in someone else’s subscription you know the problems that come with that territory. Azure Lighthouse can help you. So, stay tuned because today we’ll discuss exactly that with Josep Mascaro from Sage.
MSP Azure Lighthouse - cannot access Azure Policies deployed at Management Group Level
Hi, We're an MSP company that provides Azure services to other companies. We're using Azure Lighthouse to allow team members to access the client's Azure Subscriptions. Currently, we've ran into an issue that when Azure Policies are deployed at a Management Group level, we don't have visibility to them. The reason is that Azure Lighthouse gives us access at the Subscription level and not a Management Group level. If Azure Policy is deployed at a Management Group level, we won't be able to see or edit it. Has anyone else encountered this? Does anyone know how to access Management Groups through Azure Lighthouse? Or if there is another way to configure this for a Service Provider? Regards, JosephAzure Lighthouse - A service provider perspective
Hello folks I partnered with the product group and actual IT professionals outside of Microsoft to create a video series where we look at Azure Lighthouse and its benefits from a variety of different perspectives. Have you thought about how you can safely provide support to a customer with their Azure subscription? How you can help your customers manage their environment efficiently without using bespoke tools and processes? And all the while lightening the administrative burden that comes with managing the access levels, invitation, and directory listings. Well, stay tuned because today we’ll discuss exactly that with James Brookbanks, Chief Technology Officer at Rhipe
Azure Lighthouse nedir?
Binlerce Microsoft iş ortağı ve azure portalını kullanan işletme, Azure üzerindeki, kaynak havuzlarında bulunan on binlerce aboneliğini ve bir milyondan fazla Azure kaynağını temsil eden Azure tanent arasındaki hizmetleri yönetmek için Azure Lighthouse'u kullanıyor. Azure Lighthouse ile, hizmet sağlayıcılar ve kendi azure portalını yöneten işletmeler, Azure'un kapsamlı ve sağlam yönetim araçlarını kullanarak daha yüksek operasyonel verimlilik elde edebilir hatta ediyorlar. Artık hibrit yapılar içinde daha yüksek otomatize edilmiş, ölçeklenebilir ve gelişmiş yönetim becerileri ile mevcut kaynakları görüntüleyebilir ve yönetebilirsiniz. Yönetilen Servis Sağlayıcıların (MSP’lerin) hibrit yapılar ile lokasyonunda bulunan kaynaklar üzerinden müşterilerine hizmet vermesi yaygındır. Birçok MSP ortağı bu gelişmiş senaryolarda birleşik bir yönetim çözümü elde etmek için Azure Lighthouse'a ve Azure Arc'a güveniyor. MSP'ler, Azure kaynak yönetimi aracılığıyla müşterilerinin şirket içi ortamlarını yönetmek için hizmet tekliflerini genişletebilir, kaynakları ölçekli olarak yönetebilir ve Azure ilkelerini kullanarak uyumluluğu yönetebilir. Azure Lighthouse, Azure Politikası ve Azure Arc'ı kullanan bir Azure Uzman MSP ve ISV olan yapılar bir çok sektördeki hizmetleri hibrit yapılar sayesinde müşterilerine uyumluluk ve performans sağlar. Azure Arc, hibrit ortamlarda ki sanal makinelerinizi kolayca yönetmenizi sağlarken Azure Lighthouse ile kullanılan Azure Politikası, müşterilerin kullandığı tüm bulutlarda ve özel veri merkezlerinde veya şube ofislerinde tüm müşterileri arasında tutarlılık, güvenlik ve uyumluluk elde etmelerine yardımcı olur. Azure üzerindeki HITRUST 9.1 sertifikalı çözümleri, kurumsal kuruluşların kolaylıkla buluta geçişlerini ve buluta daha güvenli bir şekilde hızlanmalarını sağlıyor. Azure hizmetleri için zengin bir uyumluluk referans mimarisi kütüphanesi, benzersiz Otomatik Korumalar ve İyileştirme teknolojimiz ile birlikte Azure Lighthouse ve Azure bulutunun gerçek potansiyelini ortaya çıkarır. Görsel ve kullanımı kolay uyumluluk kontrol panelimiz ve esnek raporlarımız, uyumluluğu göstermek için gereken şeffaflık ve görünürlük sağlar. Azure lighthose deneyimlerini paylaşan ve ilgimi çeken bir firma müşterileri adına ekranlar, mikrofonlar, kameralar, hoparlörler ve Microsoft Teams'in gerçek zamanlı özellikleri de dahil olmak üzere Microsoft işbirliği cihazlarının (Surface Hubs 1, 2 ve Microsoft Teams Rooms) sağlık durumlarını Azure üzerinden yönetiyor. Birincil izleme aracı olarak Azure Monitor'e ve güvenli erişim mekanizması olarak Azure Lighthouse'a dönerek, son teknoloji cihaz yönetimini sağlamaktadır. Tüm müşterilerinin konsolide görünümleri ile gözetim sağlar ve hızlı sorun çözümü için iş akışlarını tetikleyen zamanında uyarılar sağlar. Azure Lighthouse daha akıcı kullanıcı deneyimleri ve daha yüksek müşteri memnuniyeti yaratarak firmaya avantaj sağlamıştır. Azure Lighthouse ayrıca, Azure Networking MSP'leri gibi birden çok hizmet sağlayıcısının, müşteri tesislerinden Azure'daki müşteri aboneliklerine kadar optimize edilmiş hibrit bağlantı oluşturmasını ve çalıştırmasını sağlamıştır. Bir çok işletme Azure Sanal WAN ve Azure Express Route tabanlı müşteriler için karma bir ağı planlamak, oluşturmak ve işletmek için Azure Lighthouse'ni kullanır. “Azure Lighthouse, Hizmet Olarak Ağ Platformumuzu müşterilerimize genişletmemize ve Azure'da Windows Sanal Masaüstü gibi evden çalışma çözümlerini artırmamıza olanak sağladı.” Azure Lighthouse — Azure'da ölçekli yönetim senaryoları için yenilikler yapmaya devam ediyor Azure ve hibrit mülkleri yönetmek için geliştirilmiş hizmetler ile ortak müşterilerimize değer katmaya devam eden tüm ortaklarımızı tebrik ediyoruz. Ekibimiz, iş ortağı ekosistemimiz için yenilik yapmak için her zaman olduğu kadar motive ve sonuç olarak sürekli olarak yeni Azure Lighthouse yetenekleri ekliyoruz. İşte birkaç önemli nokta: Hizmet sağlayıcılar artık, müşterilerin kaynak temsilci eylemlerini izleyen etkinlik günlükleri aracılığıyla kendi Azure kontrol düzlemlerinde ekipleri için bildirim ve işe alım iş akışlarını tetikleyebilir. Müşteriler artık yönetilen hizmet tekliflerini, diğer portalları veya pazar yerlerini ziyaret etmek yerine kendi Azure portal deneyimleri içinde, hizmet sağlayıcıları görünümlerinde yükseltebilir. Komut satırı arabirimi (CLI), API'lar (abonelik işlevi) ve PowerShell arasından seçilen otomasyon araçları artık bir Azure aboneliğinin yönetilen ve yönetilen kiracı içeriğini görüntüleyebilir. Servis sağlayıcılar, uyumluluk ve işten çıkarma ihtiyaçlarını hızlandırmak için müşteri tarafından yetkilendirilen Azure kapsamlarını kendi başlarına yönetmeyi devre dışı bırakabilir. Azure Yedekleme Gezgini ve Yedekleme raporları artık servis sağlayıcılar için müşteri verimliliğini artıran konsolide görünümler sunarak operatör verimliliğini artırıyor. Azure Lighthouse artık Microsoft Azure Government'ta bulunan FEDRAMP Yüksek sertifikalı bir hizmettir. İş ortakları artık doğrudan İş Ortağı Merkezi'nden yönetilen hizmet tekliflerini taslak haline getirebilir ve yayınlayabilir ve tek bir portalda teklifi ve olası satış yönetimini kolaylaştırabilir. Azure Lighthouse Yardım ve Destek deneyimleri, ortak sorunlar için önerilen çözümler de dahil olmak üzere, kiracıların sorunları kendileri çözmek için daha fazla öngörü ile yönetmesini güçlendirmek dahil. Kaynak: https://azure.microsoft.com
Azure Lighthouse deprecated code
Hi all, I'm trying to onboard a tenancy utilising ARM templates using the cli Azure cli. Additionally, I have tried using the PowerShell with cli plugin also but receiving deprecated errors. When using the Azure CLI documented ion the below URL when logged in to the Azure environment I'm receiving the following error: "This command has been deprecated and will be removed in a future release. Use 'deployment sub list' instead". After changing the syntax I'm still encountering issues. Does anyone know if the syntax for deploying ARM templates has changed? Web Site used https://docs.microsoft.com/en-us/azure/lighthouse/how-to/onboard-customer
