Atlas Technica Blog

5 Must-Know SIEM Questions Answered

Atlas Technica — Fri, 20 Mar 2026 17:11:14 GMT

How EDR, SIEM, and SOC Work Together

Atlas Technica — Fri, 20 Mar 2026 17:09:00 GMT

Cyberattack Infographic

Atlas Technica — Fri, 20 Mar 2026 17:06:15 GMT

Modernizing IT for a New York Professional Services Organization with Microsoft Cloud

Atlas Technica — Fri, 20 Mar 2026 16:40:34 GMT

Modernizing IT for a New York Professional Services Organization with Microsoft Cloud

Executive Summary

A mid-sized professional services organization in New York City partnered with Atlas Technica to modernize its architecture and simplify day-to-day operations. Atlas delivered a governed Microsoft cloud foundation that unified collaboration, deploying Windows 365 and Azure Virtual Desktop for end user productivity, and a right-sized Azure platform to host critical services with resilient connectivity to on-premises locations and partner networks. The Azure build included a fit-for-purpose landing zone, structured networking, identity integration, backup and recovery, and selective Windows Server workloads where that model best served operational needs.

Background and goals

The organization manages a distributed workforce with a mix of knowledge workers and field staff. They needed consistent access to line of business systems without the complexity and cost of maintaining their on-premises VDI host and sprawling endpoint configurations. Objectives included establishing a robust collaboration baseline in Microsoft 365, consolidating and standardizing user access through Azure based workspaces, and building a governed cloud foundation that internal IT and Atlas could operate jointly. A financial review of moving from VMware Horizon to Azure Virtual Desktop framed the decision and sequencing for change, indicating significant return on investment. Atlas’ wealth of onboarding experience brought together well-defined project management, disciplined change enablement, and a steady technical cadence. Workstreams spanned tenant readiness, device and application access, network and identity guardrails, and structured user onboarding. The implementation included a carefully planned migration timeline with emphasis on quality control and user\company acceptance to ensure the end user experience was protected while Atlas steadily improved the client’s posture and operations.

Workspace and security baseline

Microsoft 365 became the organizing layer for identity, mail, and collaboration, with Atlas managed services covering configuration, monitoring, and user support. User onboarding guidance formalized how accounts, licenses, and groups are created and synchronized, how email hygiene and archiving are applied, and which devices and profiles are in scope for Cloud PC and AVD access. Following documented process reduced variability and gave internal IT transparency for approvals and change requests as user adoption proceeded.

Virtual desktop modernization on Azure

Atlas replaced VMware Horizon with Azure Virtual Desktop, delivering pooled session hosts with consumption-based billing and native Microsoft 365 integration. ROI analysis documented the shift from private cloud or co-located infrastructure to AVD and showed material cost and operational benefits over time. To extend savings and simplify operations, Atlas used the third-party platform Nerdio to automate scale down and shutdown of session hosts during low-demand periods and to right-size disks as usage patterns stabilized. This reduced compute and storage spend while maintaining user experience. AVD was built, validated, and handed over within the same governance model as servers and networking, so daily operations, security, and change control remain consistent.

Security, Resilience and data protection

Data resiliency was extremely important to the client, so we started with protection before polish. From the first build, we turned on the guardrails that keep people and data safe. Conditional Access controlled how users signed in, encryption kept information safe at rest, one. We checked these controls as we went, then checked them again, so the foundation was sound. As the platform took shape, we readied operations too, making sure Azure services were healthy and large-scale onboarding of people and devices could happen without surprises. We treated governance and documentation as deliverables, not afterthoughts, so the teams who would run the environment had the workplans, runbooks, and checklists they needed across Azure, Microsoft 365, Intune, and email security.

Outcomes

A unified Microsoft cloud foundation now streamlines operations and strengthens governance, with Azure hosting the right mix of services and reliable connectivity to on-premises sites and partner networks. End user computing is modernized on Azure Virtual Desktop, and Windows Server workloads run under the same Azure governance, reducing complexity and spending compared to the previous Horizon environment. The platform is documented for steady operations and ongoing improvement as the business grows.

How Atlas Technica Worked with an Early Stage Quant Fund to Modernize their IT Infrastructure

Atlas Technica — Fri, 20 Mar 2026 16:38:46 GMT

How Atlas Technica Worked with an Early Stage Quant Fund to Modernize their IT Infrastructure

Executive Summary

An early-stage, SEC-registered quantitative fund partnered with Atlas Technica to rapidly establish a secure Microsoft 365 foundation, introduce Windows 365 Cloud PCs for consistent end-user experience, and deploy a right-sized Azure platform tailored to Linux based research workflows and centralized data access. This setup emphasized governance, segmentation between productivity and research environments, and a stepwise path to reduce reliance on home-hosted Linux infrastructure without disrupting any existing workflows. The engagement hit a March functional milestone, then stabilized and closed in early April 2025 for a clean transition into a steady-state operations and ongoing optimization.

Read the story - Background and goals

The client began their onboarding with a lean team of under 10 users, SEC regulated responsibilities, and a strategic desire to keep tight control over research environments while adopting a managed baseline for identity, collaboration, and security. This combination required a pragmatic approach: implement a strong governance and compliance posture for the firm at large, while preserving autonomy and performance characteristics where the research stack demanded it.Prior to onboarding with Atlas, leadership operated unmanaged, home-hosted Linux servers linked via Tailscale and asked for Azure-hosted Linux resources backed by performant shared storage. Windows 365 Cloud PCs would act as secure jump boxes, separating productivity from research compute while maintaining low friction access to resources. The onboarding plan explicitly recognized these patterns to prevent disruption as trust, telemetry, and governance matured.

Building the foundation

Atlas established the Microsoft 365 tenant and applied managed protections aligned to the firm’s regulatory profile. Given the startup context and staged rollout of compliance tooling, Atlas Technica’s Cyber Bundle offering complete with endpoint protection, network monitoring, SIEM with 24/7 managed SOC was deployed to support audit readiness and ongoing operational reporting, with cadence and scope designed to scale as the team grew.In parallel, Atlas standardized collaboration and identity under Microsoft 365 and ensured the operating model could support future archiving and journaling requirements typical for regulated investment firms. This enabled the environment to evolve toward the desired compliance posture without rework, while keeping early operations streamlined for a small team.

End-user computing

Windows 365 Enterprise Cloud PCs were deployed for users to provide a consistent, governed desktop experience, regardless of their local device or location. By design, Cloud PCs also served as clean jump points into research resources where appropriate, helping the team preserve necessary isolation between day-to-day productivity and their research environment. This structure supported rapid onboarding while reinforcing access boundaries that would be important as the firm scaled.To accommodate user experience and latency considerations, Atlas documented regional placement options for Cloud PCs such as relocating to the UK where beneficial, while preserving reliable VNet communication with Linux resources in Azure. This plan ensured any future regional updates would not come at the cost of network access or control.

Platform build for research workloads

Atlas deployed a compact Azure estate dedicated to the research tier, migrating Linux virtual machines built from the client’s image guidance so toolchains, libraries, and kernel settings matched the team’s baseline from day one. A centralized, readoptimized data layer was exposed only to the Linux tier to minimize latency and reduce blast radius, enforcing access from research subnets while keeping productivity environments segmented.Storage was intentionally designed to support two validated access patterns without architectural churn: shared reads over Azure Files using NFS for datasets and models, and local highIO workloads backed by managed disks on specific VMs when lowlatency scratch or writeheavy operations were required; this allowed the environment to tune performance and cost as usage stabilized. This approach created a clear runway for cost control and iterative performance optimization as research workloads matured.Operationally, the existing connectivity model was preserved: Tailscale agents remained on the Linux hosts to maintain established peertopeer access patterns and avoid disruption to researchers’ workflows. Monitoring and governance were aligned to the existing configuration, outlining a logical path to bring additional Linux workloads into Azure over time once performance, trust, and telemetry targets were met.

Project timeline

Procurement, scheduling, and quality control were coordinated to meet a March functional go-live that aligned with the firm’s launch plan. After acceptance, the Atlas team worked to ensure the project moved through stabilization and closed it in early April 2025, transitioning the client to a steady state to support. This cadence balanced urgency with the rigor needed for a regulated startup.

Outcomes

A secure Microsoft 365 foundation with managed protections and a defined path for bolded audit and operational reporting needs as the firm scales, minimizing rework while preserving speed in the first months of operation.
Windows 365 Cloud PCs are in place for a consistent, governed user experience, with clear separation between daily productivity and research compute to maintain both agility and control.
An Azure-based Linux research environment with centralized, read-optimized storage and controlled connectivity, preserving existing operating patterns (including Tailscale) and documenting a stepwise path to consolidate more Linux workloads in Azure over time without operational shock.
Timely onboarding and acceptance: March functional milestone achieved, stabilization completed, and closed in early April 2025, enabling handoff to support and smooth daily operations.

ScreenConnect

Atlas Technica — Fri, 20 Mar 2026 16:35:54 GMT

In today's interconnected digital landscape, ensuring the security of your systems and data is paramount. Recent events have underscored the importance of promptly addressing vulnerabilities to protect against potential exploits. One such instance involves an older version of Connectwise ScreenConnect, also known as ConnectWise Control, which has been identified as susceptible to exploitation.

At Atlas Technica we take the security of our systems and the data of our clients seriously. Our control instance is hosted by ConnectWise, and as soon as the vulnerability was discovered ConnectWise upgraded our system to the latest version, fortifying our defenses against potential threats.

After the upgrade, we conducted a thorough review of our system logs. This proactive measure allowed us to ascertain that our server was patched before any suspicious activity occurred. This rapid response not only safeguards our own data but also ensures the continued security of our clients' information.

However, it is essential to recognize that firms hosting their own instances of ConnectWise may be vulnerable if they are using older versions of ScreenConnect. If your organization falls into this category, (Atlas clients do not) it is imperative to act promptly. ConnectWise has released a patch to address the vulnerability, and it is crucial for affected firms to upgrade their service instances to the latest version without delay.

By staying vigilant and promptly addressing vulnerabilities, organizations can mitigate the risks posed by potential exploits. Proactive measures such as regular system updates, robust monitoring protocols, and swift response to security advisories are essential components of a comprehensive cybersecurity strategy.

In conclusion, the recent vulnerability in older versions of Connectwise ScreenConnect serves as a reminder of the ever-present need to prioritize cybersecurity. At Atlas, we remain committed to safeguarding our systems and data, ensuring the continued trust and confidence of our clients. We encourage all organizations to remain vigilant, stay informed about potential vulnerabilities, and take proactive steps to protect their digital assets. In today's digital age, the best defense is a proactive and vigilant approach to cybersecurity.

How to provide Azure environment access to a third-party

Atlas Technica — Fri, 20 Mar 2026 16:34:01 GMT

There are usually three common approaches when you need to provide access to your Azure environment to a third party, such as external contractors, vendors, partner organizations, or a managed service provider (MSP). There are many pros and cons to each of these, which will be described in this article from the perspective of identity and access management (IAM). As a bonus, this article will also touch on one overlooked approach, which can be especially beneficial for MSPs.

Let’s start from the worst case scenario and move towards better alternatives.

Shared account(s) for external users in your Entra ID tenant

That access scenario is common for small and medium organizations where a third party is provided with a few impersonalized accounts in a client’s Entra ID tenant. In other words, they are used by multiple people to manage the client’s environment in the Azure cloud. The usual reasoning for such an access design decision is that it’s simple, quick to set up, and minimizes license costs and the attack surface, as fewer accounts are handed over to an external organization or user(s).

Despite its simplicity, that approach to accessing client Azure environments has a few serious drawbacks:

Using shared accounts is generally a bad security practice, as many people know the account credentials, and investigating user activity becomes a titan’s quest: you cannot be sure who exactly used a shared account at any given moment.
Those few user accounts are often overprivileged, granting administrative permissions to many systems and applications, making them ideal for credential theft attacks.
Securely handling those shared accounts by third parties requires additional effort from both sides.

Those security risks can be partially mitigated by enforcing a multitude of protocols including a strong password policy, regular password rotations, using a password manager with access control, and, most importantly, enforcing mandatory multi-factor authentication (MFA) for those accounts. Still, the shared account usage pattern creates more security threats than benefits, and it is something that is strongly not recommended.

The only probable exception from that recommendation is break-glass accounts, which are known/accessible by very few people. However, those accounts are not intended for regular use, should be used only in exceptional circumstances, and should be extensively monitored/alerted when used for authentication.

Regular user accounts for external users in your Entra ID tenant

Many enterprise-scale organizations prefer providing individual user accounts in their Entra ID tenants to external contractors, vendors, etc. The most obvious reason for that IAM practice is having complete control over the account security policies. In that scenario, an organization (client) can leverage all available identity protection capabilities in their user access management setup: password policies, conditional access, access restrictions, monitoring, logging, suspicious activity detection, etc.

In large companies, identity and access management are usually performed in-house for security reasons, and they dictate the rules for accessing the organization’s environment.

The first notable downside of this approach is that the client now needs to manage the entire user account lifecycle for external users, meaning it needs to provision new accounts for such users and decommission them when required. The last part is often overlooked and delayed as it requires an efficient notification process between the client and third parties when a third-party user account provided by the client should be deactivated. If there is no such process in place, a security gap will be created when a third-party user is no longer authorized to access the client environment, whereas their personalized account in the client tenant is still active and can be used to gain that access.

Secondly, in the MSP access scenario, when a single engineer can manage multiple client Azure environments, that creates an overhead of maintaining and securing many individual accounts for accessing different client environments. When the engineer parts ways with the MSP, the latter needs to reach out to all the clients the engineer had accounts with and ask them to revoke that access.

Thirdly, as those user identities are housed in the client tenant, the client needs to license them accordingly to comply with application license requirements.

What if you could eliminate clients’ need to manage user identities on their side while still giving clients enough access controls?

Guest user accounts in your Entra ID tenant

The concept of guest user accounts has existed in Entra ID for quite some time. In short, it allows you to invite a user into your organization using their external identity, e.g., their user account in another Entra ID tenant.

While providing you with all security controls you can enforce on user accounts in your (client) tenant, as in the previous scenario, that approach also simplifies access revocation for such identities: as soon as a guest account is deactivated in its home tenant, it cannot authenticate and access your (client) tenant, too. You can also disable (or modify) guest account access in your (client) tenant without affecting its state and permissions in its home and other tenants. Sounds like a perfect solution, or not?

One caveat with guest account access is that you must still onboard (invite) those accounts to your tenant and configure their access. With some effort and a well-designed access model, that process can be automated and monitored for proper access configuration.

Another point worth mentioning is that with guest user accounts, you have little to no control over their authentication process, which happens outside your (client) tenant. In other words, you might need to make an additional effort to configure some advanced authentication controls on your side, like requesting additional MFA enrollment and its usage by guest users in your tenant.

Overall, managing guest user access at scale requires careful planning and deploying services like Microsoft Entra External ID to handle advanced scenarios. If designed properly, that scenario can be a solid foundation for providing access to external identities in your tenant.

[Bonus part] Delegated access with Azure Lighthouse

Despite being introduced back in 2019, that solution for delegated access to Azure resources is often overlooked when designing third-party access to your Azure environment. The basic idea of that solution is simple: you can delegate access to your Azure subscriptions and/or resource groups with specific permissions to specific security principals in an external (e.g., MSP) tenant.

Apart from configuring delegated access in your tenant, MSPs can create service templates by packaging managed services they offer with required permissions to fulfill them into Azure Marketplace offers, simplifying the onboarding experience for new customers.

After the target Azure resources are onboarded for delegated access with Azure Lighthouse, those (guest) service principals can access and manage them. Plus, as those service principals can represent security groups (usually a preferred approach here) in another tenant, you can basically abstract yourself from managing access for individual user accounts.

In addition, MSP engineers can now access different client environments using their home (MSP) tenant user accounts without needing to remember and manage multiple access accounts. Because the delegated permissions in Azure Lighthouse can be different from client to client and from scope to scope, they also don’t need to worry about using correct access profiles, as they are already pre-configured for them.

Those benefits can also be seen as a disadvantage, as you have no explicit control over who can manage the Azure resources you delegated access to because it’s controlled on the MSP side by managing the membership of security groups referred by security principals in the Azure Lighthouse deployment template.

Another aspect of using Azure Lighthouse for delegated access to Azure resources is that you don’t have control over the authentication process for the security principals in the MSP tenant. So, the principle of least privileged access becomes even more critical in that access scenario, as you likely want to reduce the potential blast radius in case a service principal (user account) with delegated access is compromised in the MSP tenant.

Integrating Azure Lighthouse with Entra ID Privileged Identity Management (PIM) on the MSP side can strengthen the security of using delegated access. However, requiring such additional controls from the customer side requires auditing MSP processes and building trust relationships with your MSP. From the technical side, you, as a client, can only monitor MSP activity within the scope of delegated management.

Compared to the scenario with guest user accounts in your tenant, Azure Lighthouse removes the overhead of managing individual guest user identities in your tenant for the cost of less control of what specific users in the MSP tenant will have access to your Azure environment. As in the previous case, it can be a very efficient and secure access model with proper permissions, scopes and monitoring configurations.

As you might conclude after reading about the described access model, there is no one perfect design for access solutions. Each has some tradeoffs, which you can try to compensate with additional controls like automation, monitoring, regular auditing, etc. The most important thing is to know about those drawbacks and how to deal with them in your specific use case. Plus, you need to understand how your solution for delegated access to your Azure environment fits into the overall security design in your organization.

In the next part of this series, there will be some ideas presented on configuring delegated access to client Azure environments with Azure Lighthouse and integrating it with Entra ID PIM for better control access elevation.

About Atlas Technica

Atlas Technica was founded in 2016 with two main goals: to provide the best customer service experience possible for their clients, and to use best-in-class public cloud technology to do so. There is a clear need among hedge funds and other alternative investment firms for an IT provider that will put service first. Atlas Technica's mission is to shoulder the burden of IT management, user support, and cybersecurity compliance so you don't have to. Atlas Technica has offices located throughout New York, London, California and Florida. For more information, visit www.atlastechnica.com.

About the Author

Andrew Matveychuk is a Cloud Solution Architect with 20+ years of experience in the IT industry, focusing on cloud governance, security, cost management, automation, monitoring and other DevOps and SRE practices. He is also an author of one of the top Azure Policy repositories on GitHub and a recognized contributor in Azure Community. Andrew oversees the Cloud Solutions practice at Atlas Technica and helps our clients to design and deploy secure, scalable and efficient cloud solutions. For more details, please check his LinkedIn profile at: linkedin.com/in/andrewmatveychuk/

Stop Paying for Downtime

Shaiyan Mhamud — Fri, 20 Mar 2026 16:31:17 GMT

Stop Paying for Downtime: Understanding Serverless Architecture with Azure Functions

Does your application code really need to run on a D8_v5 VM when Azure Functions can do it for less?‍

Virtual machines have been the backbone of cloud infrastructure for good reason. They are highly configurable, stable, and reliable, which makes them a strong fit for predictable workloads that need consistent performance and full control over the environment. They also offer a familiar operating model for teams moving from on premises and they support applications that require custom configurations or OS-level access.

A tradeoff here is operational drag. VMs must be patched, rebooted, and monitored on a regular cadence, and scaling introduces even more work with scale sets, load balancers, and networking that all need to be designed and maintained. That effort adds up; and it often consumes time that would be better spent on features.

There is also an architectural mismatch for modern patterns. Modularity suffers when the default unit of deployment is a long running machine, which can nudge teams toward tightly coupled designs and away from highly modular, event driven, or microservice oriented systems that favor small, rapidly deployable components.

Finally, the cost profile can be unforgiving. VMs are easy to overprovision for spikes and then sit idle for long stretches while the meter keeps running, which is especially painful for intermittent or unpredictable workloads. Even when you scale, you often pay with extra capacity or added configuration complexity that increases both spend and overhead.

Enter Serverless Compute

Serverless computing flips the script by removing some of this complexity and introducing three key advantages.

First, infrastructure management is abstracted away. You do not patch servers, schedule reboots, or chase OS drift because the platform takes care of it; this frees real time even when you have patching automated.

Second, high availability and elastic scaling are built in. Serverless platforms typically run across multiple availability zones by default, so you avoid the heavy lift of designing and maintaining your own availability architecture.

Third, cost efficiency. You pay for execution, not idleness, which lets your application scale to zero when there is no work to do and then ramp instantly when demand returns.

What Are My Options?

By now, you are probably wondering what serverless compute services you can leverage to improve operations in your organization. Among the many serverless services available, Azure Functions is Microsoft’s event-driven compute platform. With Azure Functions, you deploy your code and its dependencies, and the platform takes care of the rest. It can handle thousands of concurrent executions out of the box, integrate seamlessly with services like Storage and Event Grid, and will bill only for the compute time used. No more idle boxes eating at your budget.

You have options for what kind of Azure Function you deploy, and the right one depends on latency, networking, and scale:

On the Flex Consumption plan, Functions scale horizontally with flexible compute choices, VNET integration, and dynamic scale-out up to 1,000 instances, all without server management.

If you need predictable low latency and VNET connectivity, the Premium plan is the sweet spot. Pre-warmed workers eliminate cold starts and give you more powerful instance sizes when your code needs headroom.

Already invested in App Service? The Dedicated (App Service) plan runs Functions alongside your web apps at standard App Service rates, which can simplify operations for teams that want reserved capacity.

Prefer containers? Azure Container Apps can host containerized Function apps for teams that want a fully managed environment utilizing containerization.

‍

When to Choose Azure Functions Over VMs

Before diving into where Azure Functions excel, let’s touch on where they might not be the best choice. If your application is built as a tightly coupled monolith, breaking it into discrete serverless functions can be more trouble than it is worth.

Latency expectations matter too. On the default serverless plans, cold starts can add noticeable delay to the first request after idle periods. If you require consistent, low-latency responses, use the Premium plan with pre-warmed workers; that removes the cold start latency while keeping the operational model of Functions.

Finally, consider your workload’s resource demands. Functions are not designed for heavy compute or large memory footprints, so services with significant resource demands are better suited for virtual machines.

Where Azure Functions Shine

Think event-driven and bursty. Functions are excellent at reacting to things that happen elsewhere: a file lands in Blob Storage, a message hits a queue, an event fires from Event Grid, and your code runs exactly when needed, and then scales to zero when work has been done. If your API traffic is sporadic, that “scale up fast, idle at zero” behavior maps directly to both performance and cost outcomes.

Looking for an easy win? Scheduled jobs like nightly cleanups, weekly reports, monthly archiving are low hanging fruit. These do not need a server chugging along for 8,760 hours a year. A timer trigger does the work and hands the rest back to the platform. And for lightweight microservices; image resizing, link previews, notifications. Functions let you ship small, focused code that integrates easily with other managed services.

Azure Functions in Practice

Let’s take that image resizing scenario from earlier and build a simple example to see what using Azure Functions look like in practice. First, let’s develop a use case scenario.

Scenario: MediaCorp hosts a social media platform and needs to resize user-uploaded images into multiple resolutions for their platform. Instead of deploying a full VM or containerized service, they opt to use Azure Functions.

Workflow:

A User uploads an image via the site, which is stored in Azure Blob Storage in a container, images-unprocessed.
An Azure Function is triggered by the blob upload event.
The function uses a small, lightweight image process library to generate resize versions.
The function stores the images in a container, images-processed and updates a Cosmos DB database with the metadata on each derivative (dimensions, format, URL, etc.).

Let’s start with some sample code:

import io

import os

import uuid

import logging

import json

from datetime import datetime, timezone

from typing import Tuple  # safer across Python versions

import azure.functions as func

from PIL import Image, ImageOps

from azure.storage.blob import BlobServiceClient, ContentSettings

from azure.core.exceptions import ResourceExistsError

from azure.cosmos import CosmosClient, PartitionKey, exceptions

# Load local.settings.json if running locally and not in Azure Functions runtime

if not os.getenv("FUNCTIONS_WORKER_RUNTIME"):

settings_file = os.path.join(os.path.dirname(__file__), "local.settings.json")

if os.path.exists(settings_file):

with open(settings_file) as f:

settings = json.load(f)

for key, value in settings.get("Values", {}).items():

if key not in os.environ:

os.environ[key] = value

# Environment variables (use getenv to avoid KeyError)

STORAGE_CONN_STRING = os.getenv("STORAGE_CONN_STRING") or os.getenv("AzureWebJobsStorage")

PROCESSED_CONTAINER = os.getenv("PROCESSED_CONTAINER", "images-processed")

COSMOS_ENDPOINT = os.getenv("COSMOS_ENDPOINT")

COSMOS_KEY = os.getenv("COSMOS_KEY")

COSMOS_DB_NAME = os.getenv("COSMOS_DB_NAME", "cosmosaemsp")

COSMOS_CONTAINER_NAME = os.getenv("COSMOS_CONTAINER_NAME", "imageDerivatives")

SIZES = {

"thumb": (150, 150),

"medium": (640, 640),

"large": (1280, 1280),

}

# Fail fast if critical settings are missing

if not STORAGE_CONN_STRING:

raise RuntimeError("Missing STORAGE_CONN_STRING or AzureWebJobsStorage app setting")

if not COSMOS_ENDPOINT or not COSMOS_KEY:

raise RuntimeError("Missing COSMOS_ENDPOINT or COSMOS_KEY app settings")

# Initialize clients

blob_service_client = BlobServiceClient.from_connection_string(STORAGE_CONN_STRING)

processed_container_client = blob_service_client.get_container_client(PROCESSED_CONTAINER)

try:

processed_container_client.create_container()

except ResourceExistsError:

pass

cosmos_client = CosmosClient(COSMOS_ENDPOINT, COSMOS_KEY)

cosmos_db = cosmos_client.create_database_if_not_exists(COSMOS_DB_NAME)

cosmos_container = cosmos_db.create_container_if_not_exists(

 id=COSMOS_CONTAINER_NAME, partition_key=PartitionKey(path="/id")

)

app = func.FunctionApp(http_auth_level=func.AuthLevel.FUNCTION)

def _normalize_format_and_mode(img: Image.Image, target_ext: str) -> Tuple[Image.Image, str, str, str]:

"""

Returns (image, format_str, content_type, normalized_ext).

"""

ext = target_ext.lower().lstrip(".")

if ext in ("jpg", "jpeg"):

fmt = "JPEG"

content_type = "image/jpeg"

if img.mode not in ("RGB", "L"):

 img = img.convert("RGB")

norm_ext = ".jpg"

elif ext == "png":

fmt = "PNG"

content_type = "image/png"

norm_ext = ".png"

elif ext == "webp":

fmt = "WEBP"

content_type = "image/webp"

norm_ext = ".webp"

else:

 # Default to source format, else PNG

fmt = (img.format or "PNG").upper()

if fmt == "JPEG" and img.mode not in ("RGB", "L"):

 img = img.convert("RGB")

content_type = f"image/{fmt.lower()}" if fmt else "application/octet-stream"

norm_ext = ".jpg" if fmt == "JPEG" else ".png"

return img, fmt, content_type, norm_ext

def _get_base_and_ext(name: str) -> tuple[str, str]:

base = os.path.basename(name)

if "." in base:

stem, ext = base.rsplit(".", 1)

return stem, "." + ext

return base, "" # let normalizer set a sane extension

def _resize_image(original: Image.Image, max_w: int, max_h: int) -> Image.Image:

img = ImageOps.exif_transpose(original.copy())

img.thumbnail((max_w, max_h), Image.LANCZOS)

return img

def _upload_blob_bytes(container_name: str, blob_name: str, data: bytes, content_type: str) -> dict:

blob_client = blob_service_client.get_blob_client(container=container_name, blob=blob_name)

blob_client.upload_blob(

 data,

 overwrite=True,

 content_settings=ContentSettings(content_type=content_type),

)

props = blob_client.get_blob_properties()

return {

"url": blob_client.url,

"sizeBytes": props.size,

"eTag": props.etag,

"lastModified": props.last_modified.isoformat(),

}

@app.function_name(name="image_resizer")

@app.blob_trigger(

 arg_name="input_blob",

 path="images-unprocessed/{name}",

 connection="STORAGE_CONN_STRING",

)

def image_resizer(input_blob: func.InputStream) -> None:

name = input_blob.name.split('/')[-1] # Extract filename from blob path

logger = logging.getLogger("image_resizer")

logger.info("Triggered for blob: %s (size: %s bytes)", input_blob.name, input_blob.length)

try:

data = input_blob.read()

img = Image.open(io.BytesIO(data))

except Exception as e:

logger.exception("Failed to open image: %s", e)

return

original_format = (img.format or "").upper()

source_ct = f"image/{original_format.lower()}" if original_format else "application/octet-stream"

stem, ext = _get_base_and_ext(name)

doc_id = str(uuid.uuid4())

now = datetime.now(timezone.utc).isoformat()

result_doc = {

"id": doc_id,

"sourceBlobName": name,

"sourceLength": input_blob.length,

"sourceFormat": original_format or "UNKNOWN",

"sourceContentType": source_ct,

"createdAt": now,

"variants": [],

}

for label, (max_w, max_h) in SIZES.items():

try:

resized = _resize_image(img, max_w, max_h)

out_img, fmt, ct, norm_ext = _normalize_format_and_mode(resized, ext or ".png")

out_bytes = io.BytesIO()

save_kwargs = {}

if fmt == "JPEG":

save_kwargs.update(quality=90, optimize=True)

elif fmt == "WEBP":

save_kwargs.update(quality=80, method=6)

out_img.save(out_bytes, fmt, **save_kwargs)

out_bytes.seek(0)

out_blob_name = f"{stem}_{label}{norm_ext}"

upload_info = _upload_blob_bytes(

PROCESSED_CONTAINER, out_blob_name, out_bytes.getvalue(), ct

)

 result_doc["variants"].append({

"label": label,

"width": out_img.width,

"height": out_img.height,

"contentType": ct,

"format": fmt,

"blobName": out_blob_name,

"url": upload_info["url"],

"sizeBytes": upload_info["sizeBytes"],

"eTag": upload_info["eTag"],

"lastModified": upload_info["lastModified"],

"createdAt": now,

})

logger.info("Uploaded variant %s -> %s", label, upload_info["url"])

except Exception as e:

logger.exception("Failed to process/upload variant '%s': %s", label, e)

try:

cosmos_container.upsert_item(result_doc)

logger.info("Upserted Cosmos DB doc id: %s with %d variants", doc_id, len(result_doc["variants"]))

except exceptions.CosmosHttpResponseError as e:

logger.exception("Cosmos DB upsert failed: %s", e)

Notice the @app.blob_trigger decorator. This decorator allows the function to run when a blob upload has completed.

Now let’s get started with deploying our function app. Our prerequisites are python, a code editor and Azure Functions Core Tools.

Let’s first define some variables:

export LOCATION="eastus"

export RG="rg-mediacorp-img" # Keep names lowercase; storage must be <=24 chars, letters+digits only

export RND=$(printf "%05d" $RANDOM)

export STORAGE="stmediacorp${RND}"

export FUNC="func-mediacorp-img-${RND}"

export COSMOS="cosmos-mediacorp-${RND}"

export DB="MediaCorp"

export COLL="Images"

RG=rg-mediacorp-img

LOCATION=eastus

STORAGE=stmediacorp$RANDOM # Needs to be globally unique, lowercase, <=24 chars

FUNC=func-mediacorp-img-$RANDOM # Needs to be globally unique

COSMOS=cosmos-mediacorp-$RANDOM #Needs to be globally unique

DB=MediaCorp

COLL=Images

Then we can create our resource group:

az group create -n "$RG" -l "$LOCATION"

With our resource group created, let’s start deploying some of the resources:

az storage account create -g "$RG" -n "$STORAGE" -l "$LOCATION" --sku Standard_LRS --kind StorageV2 # Create ingress/egress containers (requires data-plane RBAC like “Storage Blob Data Contributor”)

# Get storage connection string for data-plane operations STORAGE_CONN=$(az storage account show-connection-string -g "$RG" -n "$STORAGE" --query connectionString -o tsv)

# Create ingress/egress containers using the connection string (no RBAC needed) az storage container create --name images-unprocessed --connection-string "$STORAGE_CONN" >/dev/null az storage container create --name images-processed --connection-string "$STORAGE_CONN" >/dev/null

# Database and container (partition key = /id to match your documents) az cosmosdb sql database create -g "$RG" -a "$COSMOS" -n "$DB" >/dev/null az cosmosdb sql container create -g "$RG" -a "$COSMOS" -d "$DB" -n "$COLL" \ --partition-key-path "/id" \ --throughput 400 >/dev/null az cosmosdb sql container create \ -g $RG -a $COSMOS -d $DB -n $COLL \ --partition-key-path "/originalFile" \ --throughput 400 # Get Cosmos connection string for app settings

Endpoint and key for app settings COSMOS_ENDPOINT=$(az cosmosdb show --name "$COSMOS" --resource-group "$RG" --query documentEndpoint -o tsv) COSMOS_KEY=$(az cosmosdb keys list --name "$COSMOS" --resource-group "$RG" --query primaryMasterKey -o tsv)

With the prep work finished, let’s finally deploy our function app with the below command:

az functionapp create \ --resource-group "$RG" \ --consumption-plan-location "$LOCATION" \ --runtime python --runtime-version 3.12 \ --functions-version 4 \ --name "$FUNC" \ --storage-account "$STORAGE"

We can configure app settings for the function app like so:

az functionapp config appsettings set -g "$RG" -n "$FUNC" --settings \ AzureWebJobsStorage="$STORAGE_CONN" \ STORAGE_CONN_STRING="$STORAGE_CONN" \ PROCESSED_CONTAINER="images-processed" \ COSMOS_ENDPOINT="$COSMOS_ENDPOINT" \ COSMOS_KEY="$COSMOS_KEY" \ COSMOS_DB_NAME="$DB" \ COSMOS_CONTAINER_NAME="$COLL" \ FUNCTIONS_WORKER_RUNTIME="python" \ AzureFunctionsJobHost__logging__logLevel__Default="Information" >/dev/null

Finally, let’s publish our function app.

func azure functionapp publish "$FUNC" --python --build remote

Now that we’ve published our function, let’s give it a whirl. We can start by uploading a file to blob storage to trigger the function.

az storage blob upload \ --account-name <storage> \ --container-name images-unprocessed \ --name sample.jpg \ --file ./sample.jpg \ --auth-mode login

Within a few seconds, we should see our function fire and the resized files in the images-processed container should finish uploading:

‍

Conclusion

Moving targeted workloads to Azure Functions lets you stop paying for idle capacity while gaining elasticity, simpler operations, and a cleaner path to modular, eventdriven design. For bursty APIs, scheduled jobs, and filedriven pipelines like the image resizing example, serverless compute delivers the right resources at the right time and zero when there is nothing to do. Our recommendation is to start with a low risk candidate, deploy on the Consumption plan, instrument with Application Insights, and measure before/after cost and latency. If you need consistent low latency or private networking, shift to the Premium plan with prewarmed instances. The result is the same: fewer servers to manage, faster delivery, and a bill that reflects execution, not downtime.

Remote Desktop: Azure Virtual Desktop vs. Win365\Cloud PC

Jackson Roberts — Fri, 13 Mar 2026 00:46:19 GMT

Overview

IT leaders face a challenge today. Work from home adds flexibility to end-user, but challenges to IT staff trying to project company data. How do we deliver a secure, managed windows desktop environment or access to company apps to a distributed workforce? Microsoft offers two services that, on paper, seem very similar. The decision then comes down to your workforce. Think about work rhythms, onboarding speed, the need for persistence, and how predictable you want costs to be.

What You’ll Learn

The core differences between AVD and Windows 365
How to choose based on usage patterns, cost predictability, and operational model
When a blended portfolio is the best answer

Concept Overview

Windows 365 provides dedicated, persistent 1:1 Cloud PCs delivered as a peruser subscription, managed like corporate devices via Intune, with predictable monthly costs and a stable user environment.

Azure Virtual Desktop (AVD) is a virtualization service in Azure that provides pooled, multisession Windows, and apponly delivery via RemoteApp. AVD can present full desktops or just applications; and supports autoscaling and pooled capacity to reduce costs while maintaining the experience for users.

Decision Guide

When Windows 365 Fits Best

Your users are steady, deskbound knowledge workers who benefit from a personal, persistent desktop and a stable configuration.
You want clear, peruser, permonth pricing tied to chosen vCPU/RAM/storage.
Device management should mirror standard endpoint patterns (Intune compliance, baselines, and apps), with minimal variability month to month.

When AVD Fits Best

Your workforce is elastic: contractors, external developers, interns, or teams with spiky demand over days or weeks.
You want pooled capacity with Windows multisession to improve density, reduce peruser cost, and scale up/down by schedule or demand.
You prefer apponly delivery for line of business applications, keeping user experience focused and admin overhead lower.

Cost and Operations: Predictability vs. Elasticity

Windows 365 emphasizes peruser cost predictability and operational simplicity, ideal when headcount and usage are steady.
AVD emphasizes elasticity and pooled efficiency. Combining windows multi-session with auto-scaling allows for performance requirements to ebb and flow with your team’s needs.

EndUser Experience

The client surface is converging. Users connect via the Windows App or a browser, so daily experience is consistent whether landing on a dedicated Cloud PC or a pooled session.

When to Blend Both

Many organizations use both: Windows 365 for steady, individualized desktops and AVD for the external contractors who need intermittent access. This portfolio approach maps services to realworld patterns, keeping experience consistent at the edge while optimizing cost and agility behind the scenes.

Atlas Angle: How We implement and Support

Atlas standardizes both models, working with your team to ensure secure and compliant operations. Our tried-and-true reference architecture allows us to deploy either service into your existing infrastructure as a complete product. We manage identity, network, storage, backup, and autoscaling for you. Our team of cloud experts will guide you through service role-out and support any on-going issues. Contact us today for more information.

Mobile Device Management: Securing corporate mobile devices with Microsoft Intune

Michael Strong — Fri, 13 Mar 2026 00:39:41 GMT

Keeping company data safe on phones and tablets doesn’t have to be a headache. Mobile Device Management (MDM) is how organizations set basic safety rules for devices (think: screen lock, encryption, updates) and keep access to work apps in check. Microsoft Intune is Microsoft’s cloud service that delivers MDM (and app-level protection) across iOS/iPadOS, Android, Windows, and macOS. In this post we’ll explain what Intune can manage on corporate devices, a little bit on how it works behind the scenes, which options to choose for different scenarios, and a review an example of a rollout plan so users stay productive while your data stays protected.

What is MDM and why should I care?

Mobile Device Management (MDM) is a set of tools and rules applied to the device itself. You can enforce a passcode, passcode complexity, encrypt storage, push Wi‑Fi/VPN settings, deploy apps, and remotely wipe corporate data from a lost device or, in the case of corporate devices, wipe the device completely.

Microsoft Intune is Microsoft’s cloud platform for managing those devices at scale. Because it’s part of Microsoft 365, you can combine device health checks with Conditional Access so only healthy, compliant devices can reach email, Teams, OneDrive, and other work resources.

What can IT control with Intune?

Enrollment

To become managed, a device first needs to be enrolled into Intune. This process is straightforward, and users can self-enroll, provided basic instructions. Users download an app and simply sign in with their work account to enroll their devices through the Company Portal (or built-in flows on Windows/macOS).

Compliance policies

These are the standards a device must meet to be considered safe. If a device falls out of compliance, Intune can flag it and limit access until it’s fixed. You can specify a sizeable number of configuration items to check, but among the basic items onboard a phone or tablet which are checked for compliance are: passcode/biometric standards, auto‑lock, minimum OS/security patch levels, jailbreak or root detection\prevention, and whether your device is data-encrypted or has other core protections.

Configuration profiles

Think of these as templates that preconfigure devices so users don’t have to. You push the right settings once, and everyone gets them automatically. Things such as Wi‑Fi and VPN profiles, Email profiles and certificates, device restrictions, developer options, etc. can be “canned” as a configuration set and applied automatically to devices.

App management

IT can centrally install, update, and remove apps so people get what they need without hunting through app stores or calling support. Among the management functions included with Intune is the ability to deploy/retire store apps, line‑of‑business apps, and web apps. You can control update cadence and app versions, and on Android, use a Work Profile to provide “corporate versions” of work apps, while keeping the personal apps separate.

Conditional Access

This feature checks the device’s health and identity signals before letting it gain access to Microsoft 365 and company data. This is the gatekeeper which allows access to Microsoft 365 only from compliant devices, or blocks devices that are out of date, risky, or unmanaged.

Remote actions

If a device is lost, stolen, or being repurposed, you can act quickly to protect company data—no need to physically touch the device. There are differing levels of management depending on whether your devices was issued by your company, or if your device is a personal device. You can perform a full wipe (factory reset) for lost/stolen devices with corporate managed devices. For BYOD, you can perform a selective wipe to remove corporate data and apps only, while leaving personal data fully untouched and intact.

Rolling Out Device Management

Start with a pilot

Begin with a small pilot group to validate the enrollment process and confirm device readiness. Test critical functions like email and app deployment to ensure smooth operation. Use pilot feedback to refine policies before scaling to the wider organization.

Define Compliance Early

Establish clear baseline requirements such as minimum OS version, passcode strength, and encryption. Include jailbreak/root detection to prevent compromised devices from accessing corporate resources. Document compliance standards upfront so users and IT staff know expectations from day one.

Staged Configuration

The first phase of your rollout should focus on baseline security controls and deployment of required core applications. Once these basics are in place, you can introduce Conditional Access, starting in “reportonly” mode before enforcing policies. Finally, once all devices are brought into compliance, all controls can be enforced.

Monitor and Tune

Continuously track noncompliant devices and investigate failed enrollment attempts. Review app installation success rates and measure user impact to identify friction points. Adjust policies iteratively to balance strong security with a seamless user experience.

What about privacy?

On corporate owned devices, use is typically governed by appropriate computer use policies, and personal use of corporate devices should be limited and restricted, or altogether eliminated, as your company can seize or wipe your device at any time. On BYOD devices, it’s critical to be transparent about what IT can and cannot see. IT doesn’t “take over” your personal device, rather IT typically sees device model, OS, compliance state, and installed corporate apps and corporate data only—not personal photos, messages, personal emails, or personal app contents. For a more detailed review, please see Microsoft’s official guidance: What info can your organization see when you enroll your device? - Microsoft Intune | Microsoft Learn

The takeaway

Microsoft Intune gives you the levers to secure corporate mobile devices end‑to‑end: automated enrollment, strong baselines, smart access controls, and fast remote actions when things go wrong. And deployment of Intune is relatively straightforward; start small, lock in your compliance rules, then turn on Conditional Access—your users stay productive while your data stays protected.

FAQ

Do we need MDM if we already protect apps?
Yes. MDM manages the device (updates, Wi‑Fi, certificates, wipe). MAM (app protection) manages the app’s data. Corporate devices benefit from both.

Can users keep personal apps on corporate phones?
Yes, if you allow it. Android separates work and personal. iOS supervised devices can still allow personal use while protecting data.

What happens when someone leaves?
Either factory‑reset the device or do a selective wipe of corporate data, depending on ownership and policy.

Will this slow people down?
Not if you stage the rollout and keep rules reasonable—biometrics allowed, required apps preinstalled, and clear guidance for users.

Why can’t I access company data without Intune on my device?
One of the biggest benefits of using Intune is to enable convenient and secure access to corporate data on mobile devices, and to prevent unrestricted access. Your organization’s security policies ultimately dictate the terms of access.

‍