MSP Masterclass Part 5: How to Connect Azure, AWS, GCP, Intune, and Microsoft 365 to Lansweeper 

Your Clients’ Cloud Is Growing Faster Than Any Network Scanner Can See. Ask any MSP what their biggest asset visibility challenge is, and you’ll hear variations of the same answer: the network. IP ranges, credential management, scan scheduling. Ask about cloud, and the answers get murkier. 

A client adds a storage bucket in AWS. Someone spins up a virtual machine in Azure to test a new application. A Microsoft 365 tenant accumulates devices in Intune that were never added to anyone’s formal asset register. A GCP project quietly scales. None of it shows up in a network scan. None of it appears in the traditional inventory. And nobody in IT or Security has a full picture of what’s actually deployed – across which cloud, in which subscription, running which resources. 

Cloud isn’t a separate environment that clients occasionally use. For most organizations, it’s where the majority of new infrastructure is being built. If your asset discovery doesn’t reach it, your inventory isn’t just incomplete – it’s becoming less accurate every week. 

In Part 5 of the Lansweeper MSP Masterclass series, Thomas Van Havere walks through cloud discovery: what platforms Lansweeper connects to, how cloud actions are configured, and how they slot into the same action framework you’re already using for agentless and agent-based discovery. This post covers everything you need to actually set it up. 

What Cloud Discovery Covers 

Lansweeper supports direct cloud-to-cloud connections across five major platforms: 

• Microsoft Azure – virtual machines, storage, networking, databases, and the full spectrum of Azure resource types 

• Amazon Web Services (AWS) – EC2 instances, S3 buckets, Lambda functions, and other AWS resource types 

• Google Cloud Platform (GCP) – compute instances, storage, and GCP project resources 

• Microsoft Intune – managed devices enrolled in Intune, including mobile devices and endpoints not visible to network scanning 

• Microsoft 365 / Office 365 – Microsoft 365 tenants and associated assets 

Each of these is configured as a cloud action in Lansweeper – the same action framework used for agentless IP scanning and agent-based discovery, now extended to pull data directly from cloud provider APIs. One action framework. Three discovery types. One unified inventory. 

How Cloud Actions Work: The Same Flow, Different Target 

If you’ve followed the earlier Masterclass episodes and already configured agentless IP actions or agent-based actions, cloud actions will feel immediately familiar. The configuration flow is the same: name the action, authenticate, define what to pull, set a trigger, save. 

To create a cloud action: navigate to Discovery → Actions → Create Action, and at the action type step, select Cloud instead of Agentless or Agent-Based. 

You’ll then see the list of supported cloud providers: Microsoft Azure, AWS, GCP, Intune, and Microsoft 365. Select the platform you want to connect, click Create, and the wizard walks you through the rest. 

The differentiating step – what makes cloud actions distinct from network scan actions – is authentication. Rather than mapping credentials like a Windows domain account or SNMP community string, cloud discovery uses API-level authentication against your cloud provider. The specifics differ per platform, but the pattern is consistent: you set up an application registration or service account in the cloud platform, grant it read access to the resources you want Lansweeper to see, and bring the resulting credentials (tenant IDs, application IDs, key vault URIs, service account keys) into Lansweeper to complete the connection. 

This configuration needs to happen in the cloud platform before Lansweeper can be set up – and that’s the step that trips most people up, because it’s not in Lansweeper; it’s in Azure, or AWS, or GCP. The good news: Lansweeper’s documentation walks through the exact steps for each platform. Every cloud action wizard includes a Learn More link that opens the relevant knowledge base article directly. The guidance covers what to register, what permissions to assign, what credentials to retrieve, and how to bring them back into Lansweeper. 

Thomas is explicit about this in the video: cloud authentication setup is specific to each client’s cloud environment, and no two configurations will be identical. The documentation is the place to start, not the wizard. 

Microsoft Azure: A Closer Look 

Thomas demonstrates the Azure setup in the video, so it’s worth walking through the specific elements in detail. 

What Azure authentication requires: 

• Tenant ID – your Azure Active Directory tenant identifier 

• Application ID – the ID of the Azure app registration you create for Lansweeper 

• Key Vault URI – the URI of an Azure Key Vault used to securely store and retrieve credentials 

The setup process in Azure involves three steps: registering an application in Azure AD, adding it to the Microsoft Graph API with appropriate permissions, and creating federated credentials. The Lansweeper knowledge base article covers each step in sequence. 

Once authentication is configured and Lansweeper has access, the connection returns a list of your Azure subscriptions. You select which subscriptions to pull into Lansweeper – you don’t have to include all of them. If a client has subscriptions segmented by department, business unit, or environment (production vs. dev/test), you can be selective about what comes in. 

What to pull: Within each subscription, Lansweeper presents a list of Azure resource types – virtual machines, storage accounts, networking components, databases, containers, and more. The list is extensive. Thomas’s recommendation in the video: pull everything. The reason is practical richer asset data means better network diagrams and more complete infrastructure maps in the Lansweeper platform, features covered in later Masterclass episodes. You can always deselect resource types later. 

One important detail on deselection: If you later decide to stop pulling certain asset types, those assets won’t automatically disappear from the Lansweeper inventory. They’ll remain until either a cleanup rule removes them, or you manually delete them. Build this into your client onboarding process: document what’s in scope, and if scope changes, plan the cleanup step deliberately. 

AWS and GCP: Same Pattern, Different Authentication 

The configuration flow for AWS and GCP mirrors Azure: create the action, authenticate, select resources, save – but the authentication method is different for each platform. 

For GCP, authentication is based on a service account and project-level access rather than app registrations. The resources available to select are GCP-specific (compute instances, storage buckets, Kubernetes clusters, and others). You select by project rather than by subscription. The principle is the same: scope what you want Lansweeper to discover, authenticate with read access, and let the cloud action handle the rest. 

For AWS, the setup similarly uses IAM roles and API keys rather than Azure AD app registrations. The knowledge base documentation linked from within the AWS cloud action wizard provides the exact IAM permissions required and the steps to configure them. 

In both cases: complete the cloud platform setup first, then come back to Lansweeper with the credentials in hand. The authentication fields in the wizard are the last step, not the first. 

Intune and Microsoft 365: The Managed Device Layer 

Intune and Microsoft 365 cloud actions deserve specific mention because they cover a device population that’s genuinely difficult to reach by any other method. 

Intune manages enrolled devices – Windows, macOS, iOS, Android – that an organization has registered for mobile device management. These are often the devices furthest from traditional network scanners: mobile phones, tablets, personal devices enrolled in BYOD programs, and remote endpoints managed entirely through Intune policies rather than on-premise infrastructure. A network scan will never see a mobile device connected to a cellular network. An Intune cloud action pulls the full enrolled device list directly from the Microsoft Intune API. 

Microsoft 365 extends discovery to the Microsoft 365 tenant itself – user accounts, licensing assignments, and the cloud-resident assets that live entirely within Microsoft’s infrastructure. For clients making heavy use of Microsoft 365, this data fills in a portion of the asset picture that’s otherwise completely invisible to on-premise tooling. 

Both Intune and Microsoft 365 actions use Microsoft Graph API authentication – the same underlying mechanism as the Azure app registration, which means if you’ve already set that up for an Azure connection, the groundwork is largely done for Intune and Microsoft 365 as well. The Lansweeper documentation covers the specific Graph API permissions required for each. 

Managing Cloud Actions Alongside Agentless and Agent-Based Actions 

Once you’ve created cloud actions for a client, they sit in the same Actions view as your agentless IP actions and agent-based actions. Lansweeper’s action filter – the All Types dropdown Thomas demonstrates in the video – lets you filter to just Cloud, just Agentless, or just Agent-Based at any time. In a mature client deployment with multiple action types configured, this filter is how you stay oriented without scrolling through a long combined list. 

A client environment running the full Lansweeper discovery stack will have: 

• Agentless actions for on-premise IP ranges and Active Directory 

• Agent-based actions for endpoints that roam off-network 

• Cloud actions for Azure, AWS, GCP, Intune, and Microsoft 365 

Each runs on its own schedule. Each pulls data into the same unified inventory. Each uses the same Lansweeper platform for reporting, dashboards, and downstream workflows. 

That’s the complete picture – on-premise infrastructure, endpoints wherever they happen to be, and cloud resources across every platform the client uses. Three discovery methods. One inventory. No manual reconciliation between separate tools. 

Why This Matters for MSPs 

The commercial case for cloud discovery isn’t complicated: your clients are spending money on cloud infrastructure. That infrastructure carries risk – misconfigurations, orphaned resources, unpatched virtual machines, over-provisioned identities. And most of it is invisible to the tooling that was built for on-premise environments. 

As an MSP, your ability to demonstrate full visibility – not just network visibility – is increasingly what separates a commoditized patching and monitoring service from a genuine managed security and IT operations practice. Clients who understand what’s in their cloud estate can be governed. Clients who don’t, accumulate risk in the dark. 

Cloud discovery gives you the data. What you do with it – remediation workflows, compliance reporting, cost optimization, vulnerability prioritization – is where your service value lives. 

A Note on Documentation 

Thomas emphasizes this throughout the video, and it’s worth reinforcing: the specific steps to authenticate each cloud platform in Lansweeper are in the documentation, not in this post. Cloud environments vary. Subscription structures, permission models, identity configurations, and network architectures are different for every client. The Lansweeper knowledge base articles – accessible directly from each cloud action’s Learn More link – are the authoritative guide for each platform’s setup. 

Use this post (and the video) to understand the framework, the supported platforms, and what to expect from the configuration flow. Use the documentation when you sit down to actually configure it. 

Watch the Full Video 

See Thomas walk through the full cloud action setup, including a live look at a configured Azure action with subscriptions and resource types selected: MSP Masterclass Part 5 – Cloud Discovery → 

Catch up on the full series: 

• Part 1 – MSP Architecture & Multi-Site Management → 

• Part 2 – Installing Lansweeper Discovery → 

• Part 3 – Agentless Discovery: Credentials, Actions & Active Directory → 

• Part 4 – Agent-Based Discovery: Three Deployment Methods → 

Coming up: With agentless, agent-based, and cloud discovery all configured, the next episodes will show what a fully populated Lansweeper environment looks like – dashboards, asset maps, network diagrams, and how to turn all of that discovery data into actionable intelligence.