Endpoint Management in the Microsoft Cloud

In the world of IT, an endpoint refers to a computing device or a hardware device connected to a network – this includes computers/workstations, servers, and mobile devices. Endpoints are vulnerable to cyberattacks due to their direct exposure to the internet, potential security misconfigurations, and susceptibility to malware infiltration. This is why it is crucial for any IT infrastructure to ensure endpoints are appropriately managed. Cloudforce works hard to ensure all endpoints are protected across our organization while following best practices.

Three endpoints Cloudforce closely manages are mobile devices, workstations, and servers. These three endpoints are managed through various tools in the Microsoft cloud, allowing us to streamline endpoint management, ensure a seamless user experience, automate repetitive tasks, and fortify our security posture against ever-evolving threats.

Our computers and workstations are maintained through numerous configurations and policies throughout their lifecycle. Much of this maintenance is done through Microsoft Intune. Intune is a powerful endpoint management platform that allows Cloudforce to successfully manage its device ecosystem with enhanced efficiency, security, and adaptability. SCCM, or System Center Configuration Manager, has been Microsoft’s premier endpoint management platform for a long time. However, with the continuous improvement of Intune over the years, there has been a push for Intune to adopt many of SCCM’s key features.

There are many ways to enroll a device into Intune, and these methods differ based on what type of device it is. Cloudforce uses two methods to enroll Windows devices in Intune. By having an Entra ID P2 license (formally known as Azure AD Premium P2 license) and having auto-enrollment for Intune configured in our Azure tenant, we can have end users enroll a device themselves by logging into the Windows device with their work or school account. Cloudforce also uses the MDM auto-enrollment group policy object (GPO) to enroll all Entra ID (formally known as Azure AD) hybrid joined devices into Intune. We can automatically enroll in Entra ID through GPO because we’ve integrated our on-premises Active Directory Domain Services (AD DS) with Entra ID using the Azure AD Connect client, which synchronizes the two systems. The only Windows devices supported for hybrid joining to Entra ID are:

  • Windows 10
  • Windows 11
  • Windows Server 2016, version 1803
  • Windows Server 2019

To enroll domain controllers via hybrid join, the minimum required domain controller version is Windows Server 2008 R2 for Windows 10 or newer devices.

It is also important to note that due to all the account and device data being synced between Azure/Intune and your AD DS, there are some key scenarios where the line of sight between Azure/Intune and AD DS can break. These scenarios include:

  • Device password change
  • User password change
  • Trusted Platform Module (TPM) reset

During the beginning of a workstation lifecycle, a Cloudforce computer is enrolled into Intune via a feature called Autopilot. Autopilot is a deployment and provisioning service that streamlines and simplifies the initial setup and configuration of Windows 10 and Windows 11 devices, enhances the out-of-box experience for end users, and reduces the IT overhead traditionally associated with device onboarding. Autopilot allows you to create different deployment profiles to configure the provisioning process to your company’s needs. Internally we have a “hybrid” Autopilot profile for our workstations, which we enroll with Autopilot’s manual registration process. A hybrid Autopilot profile is used when the devices being enrolled will be domain joined to a local Active Directory as well as registered in Entra ID. With Autopilot, you can either kick off the enrollment process yourself by manual registration or, in most cases, have the manufacturer do it for you with OEM registration. For example, say a company is to buy a batch of laptops from Microsoft. If this company has an Autopilot profile set up in Intune, they can provide Microsoft with their proof of purchase and their Azure Tenant ID. This way the device can be registered to your tenant, and Microsoft can find and apply the intended profile prior to shipping out to the company or straight to the employee. Once the end user logs on, the Autopilot profile installs apps and configures settings. However, this example is a little more complex for hybrid devices. A hybrid device needs a line of sight to the domain during provisioning, so running the Autopilot process yourself while on-prem and connected to the network is fine. However, this becomes a challenge when you want to ship devices pre-provisioned from the manufacturer. To solve this, you can use an Always On VPN, a domain join profile, and the Intune Connector for Active Directory client. The Always On VPN is added to the Intune configuration profiles that target a dynamic group the Autopilot computers automatically join when enrolled. The Intune Connector for Active Directory client is installed on a server with a line of sight to your domain controllers. This server needs permission to create computer objects in the on-premises Active Directory domain. Its role is to take the Autopilot computers in Azure targeted by the domain join profile and add a respective computer object to an organization unit (OU) in the on-premises Active Directory domain. Once the new computer object in the on-premises Active Directory syncs to Azure as a hybrid joined device, the old device, originally enrolled in Azure, will be automatically deleted after a while. It’s important to note that regardless of the registration method, hybrid Autopilot will need both configurations stated above in a domain join profile and the Intune Connector for Active Directory client.

Image source

“With great power, comes great responsibility!” Just as easily as one can deploy a great solution, another can make a deployment leading to a misconfiguration and/or company-wide issue. This is why Cloudforce limits access to the Intune Administrator role and first tests new applications, scripts, or configurations in an isolated environment before rolling them out.  After testing in an isolated environment, we move on to a small preview group of employee user accounts or endpoints, and then finally target the full scope of the deployment.

Intune allows many ways to manage devices. By adopting Intune’s configuration profiles instead of traditional GPOs used in on-premises Active Directory environments, Cloudforce gains the flexibility of cloud-based management, enabling seamless device configuration and control from anywhere with internet connectivity. Traditional GPOs require the device to have a line of sight to the domain via VPN or the endpoint to be in the office and on the network. GPOs can still serve an important role in some environments.

When it comes to mobile devices, by default, Intune is configured to allow the enrollment of Windows, Android, and Samsung Knox standard devices. For iOS and macOS devices, an Apple MDM push certificate is required for the devices to be managed in Intune. Cloudforce manages the Apple push certificate with a company account unassociated with any personal Apple account. You may be wondering what happens to a personal device when enrolling it into Intune. This is done with the Company Portal, an app free to download that allows employees to access company resources. While Intune is an endpoint management platform, enrolling personal devices through the Company Portal is primarily focused on managing and securing corporate data, as well as allowing access to company resources. It should not access or interfere with personal data stored on the device, such as personal emails, photos, or apps. Some mobile operating systems like Android enforce a clear separation between personal and work-related data, allowing organizations to manage only the corporate side.

During the onboarding process, Cloudforce employees download the Company Portal and log in with their work or school account allowing them to gain access to company data if their devices are in accordance with our compliance and Conditional Access policies.

Now that we have covered the onboarding and management of our end user-facing endpoints, what about the maintenance of our internal servers? This is where Azure Automation comes into play.

At Cloudforce, Azure Automation plays a role in both the solutions we provide our clients and our internal operations. An example that comes to mind is our use of Automation accounts to streamline patching our internal servers with a feature called Automation Update Management, which provides a centralized solution to keep your virtual machines and on-premises servers up to date with the latest updates, security patches, and compliance requirements. Automation Update Management depends on a Log Analytics agent to send data to Azure about updates and patches, whether the machine is on-premises or in the cloud. This data includes information about missing patches on servers and their criticality.  However, it’s important to note that the Log Analytics agent is going to be deprecated come August 31st, 2024. The deprecation of the Log Analytics agent prompted Microsoft to release the Azure Update Manager into preview as the second version of Automation Update Management. Microsoft has not yet released guidance to migrate from Automation Update Management to Azure Update Manager and has recommended that customers continue to use the Log Analytics agent in the meantime.


Image Source

Any business that has endpoints needs proper security measures in place to protect itself from ever-evolving attacks. Defender for Endpoint enables us to do just that by collecting security data on endpoints and reporting back to Microsoft Defender Security Center to enable threat detection and response features that are configurable to your business needs. In Intune’s endpoint security section, Cloudforce makes use of configurable policies as well. Here you’re able to deploy personalized policies for anything from BitLocker encryption deployments to Conditional Access policies where you can limit or allow end users to access company resources based on conditions like their geographical location. Two interesting features we make use of at Cloudforce are endpoint detection and response (EDR) policies and attack surface reduction (ASR) policies. By defining EDR policies, you can specify how the platform should respond to various threat scenarios, providing guidance on automated threat containment and remediation actions. ASR policies help prevent malware and ransomware attacks by limiting the exposure of vulnerable applications. They achieve this by blocking certain suspicious behaviors, such as executable content from email and web-based sources, thereby reducing the potential entry points for threats.

In Defender for Endpoint, Cloudforce employs ASR policies to reduce vulnerabilities by configuring:

  • ASR Rules: These are the rules to target behaviors that malware and/or malicious apps trying to infect an endpoint typically use.
  • App and Browser Isolation: This uses Windows Application Guard, a feature of Defender for Endpoint.

With compliance policies in Intune, Cloudforce can ensure that devices adhere to security and organizational requirements. Devices marked as non-compliant can be restricted from accessing corporate resources until they meet compliance criteria. Compliance policies can target things like:

  • Jail Broken Device
  • Rooted Device
  • Simple Password
  • Lack of Antivirus
  • Lack of Antispyware

Conditional Access is a policy-based access control feature that allows organizations to define and enforce access rules and conditions based on numerous factors, including user identity, device health, location, and more. Conditional Access policies can use the results of compliance policies as a condition. For example, if a Cloudforce mobile device is trying to access company data but is marked as non-compliant by any of the previously stated Cloudforce compliance policies, it will not be able to access company data. Another example is the Conditional Access policy to block all non-US IPs; however, exceptions can be made for employees traveling abroad.


Matthew Day

Matthew grew up in College Park, MD, only a mile from the University of Maryland. He always loved sports and computers growing up, and ended up falling in love with baseball, which he played from the time he was five up through college. Matthew is a graduate of Coppin State University, where he spent four years as a starter and team captain on their Division I baseball team. Matthew is very thankful for his time there, as it showed him how to remain focused, work hard, lead and take responsibility for a group. Matthew speaks French, a little Russian, and he's learning Spanish. As a Cloud Services Associate at Cloudforce, Matthew also enjoys learning new technology and helping others learn as well.

Recommended for you.