Explore enterprise desktop

Page 1

Plan for upgrades and retirement

At some point, you may have to decide whether to upgrade or retire company hardware. First, you must decide whether upgrading is necessary. You based this decision on factors such as the age of the current computers, their performance, and the cost of upgrading compared to continuing to use them. In most cases, consider the following factors:

You'll need facilities to store systems undergoing refurbishment and a place to store them until you return them to the user’s workspace.

You can upgrade software in place at a user’s workstation.

Some organizations have procedures to refurbish used equipment and test stock items before deployment or after users return them.

Retirement

This phase focuses on successfully removing a system from production when it's no longer useful. As you retire legacy systems and replace them with new systems, you must efficiently complete this effort without interrupting daily organizational business needs or end-user work. Other factors that you must consider when planning the retirement phase include:

IT professionals should perform computer pickup in a way that causes the least interruptions to users.

Like your refurbishing efforts, you should also prepare computers for reselling. If

Administrative processing, you can accomplish this with an existing inventory system.

You might need to perform packing and shipping and a loading-dock area for pickups.

It would be best to consider the equipment’s residual or resale value for accounting.

BYOD and Unenrollment

In BYOD scenarios, users may either replace their devices or leave the organization. The IT department must consider how to address organizational data and applications on the user’s device. Services like Microsoft Intune can selectively wipe and remove applications and application data.

Page 2

Windows client editions and capabilities

It's essential that you select the most suitable edition for your organization before you install Windows.

Home (Individual home use - Everyone)

Home is the consumer-oriented desktop edition of Windows. It offers the familiar Windows experience for PCs, tablets, and the new hybrid laptop/tablets. Features with Home edition include:

Microsoft Edge

Windows Hello

Virtual Desktops

Photos, Maps, Mail, Calendar, Music and Video, and other built-in universal Windows apps

Device encryption

Firewall and virus protection

Always On VPN

New updates and features received automatically

Pro (small business/advanced users - Everyone)

Pro builds on the features of Windows Home, with many extra features like BitLocker and virtualization. Some of the features Pro edition provides:

Windows Autopilot:

Dynamic Provisioning

Mobile Device Management (MDM) support

Domain Join

Ability to join Azure Active Directory

Group Policy Management

BitLocker

Assigned Access

Remote Desktop

Client Hyper-V

Microsoft Store for Business

Windows Update for Business

Enterprise Data Protection

Granular user-interface Control

Enterprise State Roaming

ReFS (Resilient File System)

Persistent memory

SMB Direct

Expanded Hardware Support

Enterprise (Large enterprise organizations - Volume Licensing customers only)

Enterprise builds on the features of the Pro edition, they can choose the pace at which they adopt new technology. Enterprise also supports a broad range of options for operating system deployment and device and app management. Some of the features Enterprise edition provides:

Universal Print

Start menu layout control

Microsoft Defender Credential Guard

Microsoft Defender Application Control

Microsoft Defender Application Guard

Microsoft Application Virtualization (App-V)

Microsoft User Experience Virtualization (UE-V)

License rights

DirectAccess.

Enterprise LTSC (restrictive change requirements- Volume Licensing customers only)

Enterprise Long Term Servicing Channel (LTSC) is a special edition of Enterprise that Microsoft won't update with any new features, it only gets security updates and other important updates. A typical example would be a PC used as part of a medical or industrial system. These environments are typically closed systems designed to a particular specification that traditional updates would affect. The differences include:

Doesn't receive feature upgrades

No Microsoft Edge browser (can be installed separately)

No Microsoft Store client

Many built-in universal Windows apps are missing

Microsoft releases an updated version of the LTSC edition approximately every three years.

Pro Education and Education (Comparable to Pro for school - Academic Volume License)

Pro Education and Education offer the same features as Pro and Enterprise editions, except for the Long-Term Servicing Channel.

IoT Core/Enterprise (Fixed purpose and appliance devices - Windows IoT Distributors)

The IoT Edition is designed for fixed-purpose devices. Windows 10 IoT Core is a smaller OS designed to run a single app, while Windows 10/11 IoT Enterprise is a full version of Windows Enterprise with specialized features. LTSC is deployed to a computer for a specific process. It's installed by and licensed by the company using it. IoT is embedded on a particular device or appliance by the manufacturer. A consumer might purchase the device, but the manufacturer has already purchased the license.

Page 3

Select client edition

Not all editions of Windows can run on all device types. This discussion will help you decide which form factor and edition of Windows to choose in different scenarios.

Form factors

Microsoft designed Windows to run on several form factors:

Desktop PC

Laptop

Tablet

Hybrid

HoloLens

Surface Hub

32-bit and 64-bit editions

Windows 11 is only available in 64-bit. Desktop editions of Windows 10 are available in both 32-bit and 64-bit versions. Devices running 32-bit installations of Windows are becoming increasingly rare. Whether you use Windows 10 or 11, install or upgrade to the 64-bit version of Windows to take advantage of the increased performance, memory, and security capabilities available with 64-bit hardware. Some reasons include:

Most devices in use today have 64-bit architectures.

If you install a 32-bit edition of Windows 10 on 64-bit processor architecture, the OS doesn’t take advantage of any 64-bit processor architecture

64-bit editions of Windows require 64-bit drivers. Most device manufacturers no longer offer a 32-bit driver on new products.

The 64-bit edition of Windows supports running native 32-bit and 64-bit applications.

32-bit editions of Windows should only be installed on legacy hardware or drivers that only support 32-bit architectures or when 16-bit Windows applications are used in the organization.

Hardware requirements

OS requirements

Windows will still install with some of these requirements not being met. However, you might compromise the user experience and operating system performance if the computer doesn't meet or exceed the following specifications:

Windows 10

Processor: 1 gigahertz (GHz) or faster processor, or system on a chip (SOC)

RAM: 1 GB for 32-bit or 2 GB for 64-bit

Hard disk space: 16 GB for 32-bit or 20 GB for 64-bit

Graphics card: DirectX 9 or newer with Windows Display Driver Model (WDDM) 1.0 driver

Display: 800x600 pixels

Windows 11

Devices must meet the following minimum hardware requirements to install or upgrade to Windows 11:

Processor: 1 gigahertz (GHz) or faster with two or more cores on a compatible 64-bit processor or system on a chip (SoC).

RAM: 4 gigabytes (GB) or greater.

Storage: 64 GB or greater available storage

Graphics card: Compatible with DirectX 12 or later, with a WDDM 2.0 driver.

System firmware: UEFI, Secure Boot capable.

TPM: Trusted Platform Module (TPM) version 2.0.

Display: High definition (720p) display, 9" or greater monitor, 8 bits per color channel.

Internet connection: Internet connectivity is necessary to perform updates, and to download and use some features

Feature-specific requirements

Windows client offers more options if the correct hardware is present. Some of the hardware/software requirements for various additional features:

Windows Hello: requires a specialized illuminated infrared camera for facial recognition, iris detection, or a fingerprint reader

Two factor authentication: Requires using a PIN, fingerprint reader, illuminated infrared camera, or phone with Wi-Fi or Bluetooth capabilities.

Snap: Windows might limit the number of simultaneously snapped applications depending on the monitor’s resolution.

Secure boot: Secure boot requires firmware that supports Unified Extensible Firmware Interface (UEFI) and has the Microsoft Windows Certification Authority in the UEFI signature database.

DirectX: Some applications may require a graphics card with a higher version of DirectX for optimal performance.

BitLocker to Go: Requiring a USB flash drive. This feature is available in Windows Pro and above editions.

Client Hyper-V: A processor with second-level address translation (SLAT) capabilities and 4 GB.

Miracast/Windows Projection: Requires a display adapter that supports WDDM, and a Wi-Fi adapter that supports Wi-Fi Direct.

Wi-Fi Direct Printing: Requires a Wi-Fi adapter that supports Wi-Fi Direct and a device that supports Wi-Fi Direct Printing.

InstantGo: InstantGo works only with computers designed for connected standby. InstantGo allows network connectivity in standby mode.

DirectStorage: DirectStorage requires an NVMe SSD to store and run games that use the Standard NVM Express Controller driver and a DirectX12 GPU with Shader Model 6.0 support.

Device drivers

Windows will detect most hardware and install the driver to support the device. Many companies producing hardware have their drivers certified at the Windows Hardware Quality Labs and delivered through Windows updates. However, you might not find a built-in driver for a specific piece of hardware. Depending on your deployment method, you may need the driver deployment to complete parts of the OS installation. The best way to find hardware drivers is to search the manufacturer’s website.

Check for Hyper-V compatibility

To verify compatibility, open PowerShell window or a command prompt and run systeminfo.exe. If all listed Hyper-V requirements have a value of Yes, your system can run the Hyper-V role. You'll see the following message from systeminfo.exe if Hyper-V is already enabled on the system: Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.

Page 4

Azure Active Directory

Active Directory Domain Services is a directory service that provides methods for storing directory data and makes this data available to network users, administrators, and other devices and services. It runs as a service on Windows Server, referred to as a domain controller. It is part of the platform as a service (PaaS) offering and operates as a Microsoft-managed directory service in the cloud. With Azure AD, you also have access to a set of features that aren’t natively available in AD DS, such as support for multi-factor authentication, identity protection, and self-service password reset.

You can use Azure AD to provide more secure access to cloud-based resources for organizations and individuals by:

Configuring access to applications

Configuring single sign-on (SSO) to cloud-based SaaS applications

Managing users and groups

Provisioning users

Enabling federation between organizations

Providing an identity management solution

Identifying irregular sign-in activity

Configuring multi-factor authentication

Extending existing on-premises Active Directory implementations to Azure AD

Configuring Application Proxy for cloud and local applications

Configuring Conditional Access for users and devices

Azure AD constitutes a separate Azure service. Its most elementary form doesn't incur any extra cost and is referred to as the Free tier. If you subscribe to any Microsoft Online business services, you automatically get Azure AD with access to all the Free features. By default, when you create a new Azure subscription by using a Microsoft account, the subscription automatically includes a new Azure AD tenant named Default Directory.

Azure AD tenants

Unlike AD DS, Azure AD is multi-tenant by design and is implemented specifically to ensure isolation between its individual directory instances. It’s the world’s largest multi-tenant directory, hosting over a million directory services instances, with billions of authentication requests per week. Within an Azure subscription, you can create multiple Azure AD tenants. Having multiple Azure AD tenants might be convenient if you want to test Azure AD functionality in one tenant without affecting the others. At any given time, an Azure subscription must be associated with one, and only one, Azure AD tenant. This association allows you to grant permissions to resources in the Azure subscription (via RBAC) that exist in that particular Azure AD tenant.

You can associate the same Azure AD tenant with multiple Azure subscriptions. This allows you to use the same users, groups, and applications to manage resources across multiple Azure subscriptions. Each Azure AD tenant is assigned the default Domain Name System (DNS) domain name, consisting of a unique prefix. The prefix, is derived from the name of the Microsoft account you use followed by the onmicrosoft.com suffix. Adding at least one custom domain name to the same Azure AD tenant is possible and common this utilizes the DNS domain namespace that the corresponding company or organization owns.

Azure AD schema

The Azure AD schema contains fewer object types than that of AD DS. Most notably, it doesn't include a definition of the computer class, although it does include the device class. The process of joining devices to Azure AD differs considerably from the process of joining computers to AD DS. The Azure AD schema is also easily extensible, and its extensions are fully reversible. Azure AD and its services define a concept of modern management. Azure AD doesn't include the organizational unit (OU) class, which means that you can't arrange its objects into a hierarchy of custom containers, Objects of the Application and servicePrincipal classes represent applications in Azure AD. An object in the Application class contains an application definition and an object in the servicePrincipal class constitutes its instance in the current Azure AD tenant. Separating these two sets of characteristics allows you to define an application in one tenant and use it across multiple tenants by creating a service principal object for this application in each tenant. Azure AD creates the service principal object when you register the corresponding application in that Azure AD tenant.

Compare Azure AD and Active Directory DS

Characteristics of AD DS

AD DS is the traditional deployment of Windows Server-based Active Directory on a physical or virtual server. It’s only one component of the Windows Active Directory suite of technologies, which also includes Active Directory Certificate Services (AD CS), Active Directory Lightweight Directory Services (AD LDS), Active Directory Federation Services (AD FS), and Active Directory Rights Management Services (AD RMS).

AD DS is a true directory service, with a hierarchical X.500-based structure.

AD DS uses Domain Name System (DNS) for locating resources such as domain controllers.

You can query and manage AD DS by using Lightweight Directory Access Protocol (LDAP) calls.

AD DS primarily uses the Kerberos protocol for authentication.

AD DS uses OUs and GPOs for management.

AD DS includes computer objects, representing computers that join an Active Directory domain.

AD DS uses trusts between domains for delegated management.

You can deploy AD DS on an Azure virtual machine to enable scalability and availability for an on-premises AD DS. However, deploying AD DS on an Azure virtual machine doesn't make any use of Azure AD. Deploying AD DS on an Azure virtual machine requires one or more extra Azure data disks because you shouldn't use drive C for AD DS storage. These disks are needed to store the AD DS database, logs, and the sysvol folder. The Host Cache Preference setting for these disks must be set to None.

Characteristics of Azure AD

It’s important to realize that using Azure AD isn’t the same as deploying an Active Directory domain controller on an Azure virtual machine and adding it to your on-premises domain.

Azure AD is primarily an identity solution, and it’s designed for internet-based applications by using HTTP (port 80) and HTTPS (port 443)

Azure AD is a multi-tenant directory service.

Azure AD users and groups are created in a flat structure, and there are no OUs or GPOs.

You can't query Azure AD by using LDAP; instead, Azure AD uses the REST API over HTTP and HTTPS.

Azure AD doesn't use Kerberos authentication; instead, it uses HTTP and HTTPS protocols such as SAML, WS-Federation, and OpenID Connect for authentication, and uses OAuth for authorization.

Azure AD includes federation services, and many third-party services such as Facebook are federated with and trust Azure AD.

Azure AD as a directory service for cloud apps

When you deploy cloud services, you also need to have directory services in the cloud to provide authentication and authorization for these services. Because of this, each cloud service that needs authentication will create its own Azure AD tenant. When a single organization uses more than one cloud service, it’s much more convenient for these cloud services to use a single cloud directory instead of having separate directories for each It’s now possible to have one identity service that covers all Microsoft cloud-based services, Azure AD provides developers with centralized authentication and authorization for applications by using other identity providers or on-premises AD DS. Azure AD can provide users with an SSO experience.

The process of implementing Azure AD support for custom applications is rather complex, however, the Azure portal and Microsoft Visual Studio 2013 and later make the process of configuring such support more straightforward. In particular, you can enable Azure AD authentication for the Web Apps feature of Azure App Service directly from the Authentication/Authorization blade in the Azure portal. By designating the Azure AD tenant, you can ensure that only users with accounts in that directory can access the website.

Compare Azure AD Premium P1 and P2 plans

The Azure AD Premium tier provides extra functionality as compared to the Free and Office 365 editions. Azure AD Premium comes in two versions P1 and P2. You can procure it as an extra license or as a part of the Microsoft Enterprise Mobility + Security. Microsoft provides a free trial period that can be used to experience the full functionality of the Azure AD Premium P2 edition. The following features are available with Azure AD Premium P1:

Self-service group management. It simplifies the administration of groups where users are given the rights to create and manage the groups. End users can create requests to join other groups, and group owners can approve requests and maintain their groups’ memberships.

Advanced security reports and alerts. You can monitor and protect access to your cloud applications by viewing detailed logs that show advanced anomalies and inconsistent access pattern reports. Advanced reports are machine learning based.

Multi-factor authentication. Full multi-factor authentication (MFA) works with on-premises applications (using virtual private network [VPN], RADIUS, and others), Azure, Microsoft 365, Dynamics 365, and third-party Azure AD gallery applications.

Microsoft Identity Manager (MIM) licensing. MIM integrates with Azure AD Premium to provide hybrid identity solutions. MIM can bridge multiple on-premises authentication stores such as AD DS, LDAP, Oracle, and other applications with Azure AD.

Enterprise SLA of 99.9%. You're guaranteed at least 99.9% availability of the Azure AD Premium service.

Password reset with writeback. Self-service password reset follows the Active Directory on-premises password policy.

Cloud App Discovery feature of Azure AD. This feature discovers the most frequently used cloud-based applications.

Conditional Access based on device, group, or location. This lets you configure conditional access for critical resources

Azure AD Connect Health. You can use this tool to gain operational insight into Azure AD.

In addition to these features, the Azure AD Premium P2 license provides extra functionalities:

Azure AD Identity Protection. This feature provides enhanced functionalities for monitoring and protecting user accounts. You can define user risk policies and sign-in policies. In addition, you can review users’ behavior and flag users for risk.

Azure AD Privileged Identity Management. This functionality lets you configure additional security levels for privileged users such as administrators. You also define a policy workflow that activates whenever someone wants to use administrative privileges.

Azure AD Domain Services

In most organizations today, line-of-business (LOB) applications are deployed on computers and devices that are domain members. When you consider moving these apps to run in Azure, one key issue is how to provide authentication services to these apps. To satisfy this need, you can choose to implement a site-to-site virtual private network (VPN) between your local infrastructure and the Azure IaaS, or you can deploy replica domain controllers from your local AD DS as virtual machines (VMs) in Azure. First option, authentication traffic will cross the VPN, while in the second option, replication traffic will cross the VPN and authentication traffic stays in the cloud. Microsoft provides Azure AD Domain Services as an alternative to these approaches. Because Azure AD can integrate with your local AD DS, when you implement Azure AD Connect, users can utilize organizational credentials in both on-premises AD DS and in Azure AD Domain Services.

Azure AD Domain Services provides several benefits for organizations, such as:

Administrators don't need to manage, update, and monitor domain controllers.

Administrators don't need to deploy and manage Active Directory replication.

There’s no need to have Domain Admins or Enterprise Admins groups for domains that Azure AD manages.

If you choose to implement Azure AD Domain Services, you need to be aware of the service's current limitations. These include:

Only the base computer Active Directory object is supported.

It’s not possible to extend the schema for the Azure AD Domain Services domain.

The organizational unit (OU) structure is flat and nested OUs aren't currently supported.

There’s a built-in Group Policy Object (GPO), and it exists for computer and user accounts.

It’s not possible to target OUs with built-in GPOs. Additionally, you can't use Windows Management Instrumentation filters or security-group filtering.

By using Azure AD Domain Services, you can freely migrate applications that use LDAP, NTLM, or the Kerberos protocols from your on-premises infrastructure to the cloud. You can also use applications such as Microsoft SQL Server or Microsoft SharePoint Server on VMs or deploy them in the Azure IaaS, without needing domain controllers in the cloud or a VPN to local infrastructure. You can enable Azure AD Domain Services by using the Azure portal. This service charges per hour based on the size of your directory.

Page 5

RBAC and user roles in Azure AD

Azure AD has a SaaS operational model and lacks support for computer objects and management capabilities via Group Policy settings. Therefore, the delegation model within Azure AD is considerably simpler than the same model in AD DS. Using the delegation model, you can grant permissions to applications. The specifics of these capabilities depend on the Azure AD edition (tier). Azure AD users can access Azure AD applications by using the web-based portal, referred to as My Apps, at https://myapps.microsoft.com. Another benefit of using this approach is the support for SSO.

Azure delegation model and role-based access control

The delegation model applies to the graphical interface that is available in the Azure portal. The Azure portal offers a much more flexible and precise way of restricting management of Azure resources by implementing RBAC. This mechanism relies on three built-in roles: owner, contributor, and reader. You can grant the intended access by associating an Azure AD object such as a user, group, or service principal with a role and a resource.

User roles in Azure AD

You can use three types of accounts with Azure AD:

An organizational account that the tenant administrator or a co-administrator creates within the default Azure directory

An account that references an organizational account you create in other Azure AD instances

An account that references a Microsoft account

You use the tenant administrator account to sign up for a new trial or paid subscription. To avoid mixing authentication methods, we recommend that you use organizational accounts to manage your Azure AD tenant. You can only manage Azure AD if you're a Global Administrator of the Azure AD instance. You can only sign in to an Azure portal if you’re the tenant administrator or if the tenant administrator has configured an organizational account to be a co-administrator. Within Azure AD, you can configure users with the following roles:

Global Administrator. This role has access to all administrative features and settings.

Limited administrator. You can then select one or more of the following administrative roles :

Password administrator

Service administrator

Billing administrator

Exchange administrator

Skype for Business administrator

User administrator

SharePoint administrator

Compliance Administrator

Security reader

Security administrator

Privileged role administrator

Intune Service administrator

Guest inviter

Conditional Access Administrator

User. This is a default role that doesn't provide any administrative rights.

These roles are applicable to management tools such as the Microsoft 365 and Intune portals, or the Azure AD module for Windows PowerShell cmdlets. When you’re using Privileged Identity Management, you can also configure the Security reader and Security administrator roles.

Create and manage users in Azure AD

You can manage Azure AD users, groups, and devices by using the Azure portal, the Microsoft Azure Active Directory module for Windows PowerShell, or Microsoft 365. You can add users to a directory, and also add users to groups.

You can create two types of user accounts on the Azure portal:

Member users: Are accounts that your Azure AD tenant manages.

Guest users: Are accounts that your Azure AD tenant doesn’t manage, but you want to assign permissions to the users. Although administrators can create these accounts, these accounts are often created automatically when users share content with external users.

There are essentially two ways to create and manage your users:

As cloud identities by using only Azure AD This option is the quickest and most straightforward method.

As directory-synchronized identities by using an on-premises directory service to synchronize with Azure AD: This method has the added complexity of installing and configuring synchronization software to ensure that directory objects synchronize successfully with Azure AD.

The Azure portal provides a simple web interface for creating and managing users, groups, and devices.

Create and manage users with the Azure portal

Using the Azure portal is the simplest method for creating single or small numbers of user accounts.

To create a single user, perform the following steps:

In the Azure portal, on the left pane, select Azure Active Directory.

Select Users and groups, and then select All users.

Select + New user.

Enter the following user information:

Name

User name: < unique name >

Profile - First Name/Last Name/Display Name: (choose appropriate values)

Properties: choose source of authority (default is Azure AD)

Groups: Select groups to which you want the new user to belong

Directory role: User, Global administrator, or Limited administrator

Select Create to finalize user creation. After the user is created, a temporary password appears.

Create and manage groups in Azure AD

Like using groups to simplify permissions management in AD DS, you can use groups in Azure AD to simplify management. If you implement directory synchronization, groups in your on-premises AD DS can synchronize with Azure AD. A synchronized group in Azure AD has the same membership as the group in AD DS, but the individual members are translated from on-premises user accounts to user accounts in Azure AD. Alternatively, if you don’t implement directory synchronization, then groups and their membership are managed entirely in the cloud.

You can create four group types in Azure AD:

Security. You can use this type of group to assign permissions, but you can’t use it to send emails.

Mail-enabled security. You can use this type of group to assign permissions, and you can send emails to members.

Distribution. You can use this type of group to send emails to members, but you can’t assign permissions.

Office365 groups. You can use this type of group to enable collaboration for members. You can email an office group, and it will store a copy of those emails. It also has storage space in SharePoint Online for files.

On the Azure portal, you can only create security groups and office groups. Other group types display on the Azure portal and can be managed on the Azure portal, but can’t be created on the Azure portal. You can create mail-enabled security groups and distribution groups in the Microsoft 365 portal.

Assign Membership

Membership for a cloud-based group can be assigned or dynamic. When you create a group with assigned membership, you need to add and remove group members manually. When you create a group with dynamic membership, members are based on a query of Azure AD objects. For example, dynamic membership can be based on a user’s department. You can create a membership rule based on a single attribute or an advanced membership rule where you can create complex queries based on multiple attributes.

When you create a group with dynamic membership, you need to select whether it’s for users or devices. Many Microsoft 365 features can use user-based groups. Intune uses device-based groups.

Groups from on-premises AD DS with dynamic membership don’t synchronize with Azure AD.

Manage Azure AD objects with PowerShell

You can also manage users, groups, and devices by using the Microsoft Azure Active Directory module for Windows PowerShell module. To run the Microsoft Azure Active Directory module for Windows PowerShell module, you need the following requirements:

Operating system. You must be running either Windows 7 or newer, or Windows Server 2008 R2 or newer.

Microsoft .NET Framework. You must install the Microsoft .NET Framework 3.51 feature.

Software updates. You must have installed all the updates required by the Microsoft cloud services to which you've subscribed.

Microsoft Online Services Sign-in Assistant. You must install the appropriate version of the Microsoft Online Services Sign-in Assistant for your operating system from the Microsoft Download Center.

To connect to Azure AD, at the Microsoft Azure Active Directory module for Windows PowerShell prompt, type the following command, and then select Enter:

Copy

Connect-MsolService

You're then prompted for administrator credentials. Once you provide your administrator credentials, you’re ready to execute cmdlets for Azure AD.

Create users by using bulk import

You can import a .csv file containing account information to create multiple users in bulk, such as exporting from an existing on-premises directory, or use Azure PowerShell scripting to generate multiple accounts. To use bulk import, you first must assemble your user information, You then need to create a .csv file You can then use Microsoft Azure Active Directory module for Windows PowerShell commands to process this .csv file and create the user accounts

Synchronize objects from AD DS to Azure AD

Numerous deployment scenarios for Microsoft Azure AD don’t involve an on-premises AD DS environment. However, for many organizations that have some services on their networks and some services in the cloud, synchronization and integration between Azure AD and on-premises AD DS is the way to deliver the best user experience. Directory synchronization enables user, group, and contact synchronization between on-premises Active Directory and Azure AD. In its simplest form, you install a directory synchronization component on a server in your on-premises domain. All your user accounts, groups, and contacts from Active Directory then replicate to Azure AD. Those accounts can then sign in and access Azure services.

With Azure AD Free or Basic, the synchronization flow is in one direction, from local AD DS to Azure AD. However, with Azure AD Premium, you can replicate some attributes from Azure AD to AD DS. For example, you can configure Azure AD to write passwords back to an on-premises AD DS.

Azure AD Connect

Microsoft provides Azure AD Connect to perform directory synchronization between Azure AD and AD DS. By default, Azure AD Connect synchronizes all users and groups. If you don’t want to synchronize your entire on-premises AD DS, directory synchronization for Azure AD supports limited filtering and customization of attribute flow based on the following values:

OU

Domain

User attributes

Applications

When directory synchronization is enabled, you have the following authentication options:

Separate cloud password. When you synchronize a user identity and not the password, the cloud-based user account will have a separate unique password. This can be confusing for users.

Synchronized password. If you enable password synchronization, the AD DS user password syncs with the identity in Azure AD. This allows users to authenticate by using the same credentials, but it doesn’t provide seamless SSO, because users still receive prompts to authenticate cloud services.

Pass-through authentication. When you enable pass-through authentication, Azure AD uses the cloud identity to verify that the user is valid, and then passes the authentication request to Azure AD Connect. This option provides true SSO because users don’t receive multiple prompts to authenticate cloud services.

Federated identities. If you configure federated identities, the authentication process works similarly to pass-through authentication, but AD FS performs authentication on-premises instead of Azure AD Connect. This authentication method provides claims-based authentication that multiple cloud-based apps can use.

When you install Azure AD Connect, you need to sign in as a local Administrator of the computer on which you're performing installation. Additionally, you'll receive prompts for credentials to the local AD DS and Azure AD. The local AD DS account must be a member of the enterprise administrators group. The Azure AD account must be a global administrator. If you’re using AD FS or a separate SQL Server instance, you'll also receive prompts for credentials with management permissions for those resources.

The computer that is running Azure AD Connect needs to communicate with Azure AD. If the computer needs to use a proxy server for internet access, then more configuration is necessary. No inbound connectivity from the internet is necessary because Azure AD Connect initiates all communication.

Azure AD Connect must be on a domain member. Installing Azure AD Connect on a domain controller is supported, but this typically occurs only in smaller organizations with limited licensing.

When you install Azure AD Connect, you can use express settings or custom settings. Most organizations that synchronize a single AD DS forest with an Azure AD tenant use the express settings option. When you choose express settings, the following options are selected:

SQL Server Express is installed and configured.

All identities in the forest are synchronized.

All attributes are synchronized.

Password synchronization is enabled.

An initial synchronization is performed immediately after install.

Automatic upgrade is enabled.

You can enable other options during installation when you select custom settings, such as:

Pass-through authentication.

Federation with AD FS.

Select an attribute for matching existing cloud-based users.

Filtering based on OUs or attributes.

Exchange hybrid.

Password, group, or device writeback.

After deploying Azure AD Connect, the following occurs:

New user, group, and contact objects in on-premises Active Directory are added to Azure AD; however, no licenses for cloud services, such as Microsoft 365, are automatically assigned to these objects.

Attributes of existing user, group, or contact objects that are modified in on-premises Active Directory are modified in Azure AD; however, not all on-premises Active Directory attributes synchronize with Azure AD.

Existing user, group, and contact objects that are deleted from on-premises Active Directory are deleted from Azure AD.

Existing user objects that are disabled on-premises are disabled in Azure; however, licenses aren’t automatically unassigned.

Page 6

mobile application management

Intune Mobile Application Management (MAM) refers to the suite of Intune management features you can use to publish, push, configure, secure, monitor, and update mobile apps for your users using policies. If you use MAM without enrollment (MAM-WE), a work or school-related app that contains sensitive data can be managed on almost any device, including personal devices in bring-your-own-device (BYOD) scenarios. Many productivity apps, such as the Microsoft Office apps, can be managed by Intune MAM. You can use Intune app protection policies independent of any mobile-device management (MDM) solution. This independence helps you protect your company's data with or without enrolling devices in a device management solution. Intune MAM supports two configurations:

Intune MDM + MAM: IT administrators can only manage apps using MAM and app protection policies on devices that are enrolled

MAM without device enrollment: MAM without device enrollment (MAM-WE) allows IT administrators to manage apps using MAM and app protection policies on devices not enrolled with Intune MDM. Apps can be managed by Intune on devices enrolled with third-party EMM providers or not enrolled with an MDM at all.

You can create mobile app management policies for Office mobile apps that connect to Microsoft 365 services. You can also protect access to Exchange on-premises mailboxes by creating Intune app protection policies for devices with Outlook for iOS and Android-enabled devices with hybrid Modern Authentication. The important benefits of using app protection policies are:

Protecting your company data at the app level. Because mobile app management doesn't require device management, you can protect company data on both managed and unmanaged devices.

End-user productivity isn't affected, and policies don't apply when using the app in a personal context. The policies are applied only in a work context, which gives you the ability to protect company data without touching personal data.

There are additional benefits to using MDM with app protection policies, and companies can use app protection policies with and without MDM at the same time. MDM makes sure that the device is protected. Some examples:

You can require a PIN to access the device, or you can deploy managed apps to the device. You can also deploy apps to devices through your MDM solution, to give you more control over app management.

App protection policies make sure that the app-layer protections are in place. For example, you can:

Require a PIN to open an app in a work context

Control the sharing of data between apps

Prevent the saving of company app data to a personal storage location

Supported platforms for app protection policies

App protection policies are only supported by Android and iOS. When you enroll Windows devices with Intune, you can use Windows Information Protection, which offers similar functionality.

Considerations for mobile application management

Intune provides a robust set of mobile application protection policies enabled for Intune-managed apps. These policies provide comprehensive protection to mobile apps and data without requiring complete device management. The following are some of the key benefits of using Intune-managed apps:

Restrict copy-and-paste and save-as functions: Intune-managed apps can be configured to restrict copy-and-paste and save-as functions, which help prevent accidental data leakage or unauthorized data sharing.

Configure web links to open inside the Intune Managed Browser app: IT administrators can configure web links to open inside the Intune Managed Browser app, ensuring that sensitive corporate data isn't accessed through a less secure web browser.

Enable multi-identity use and app-level conditional access: Intune-managed apps enable multi-identity use, meaning users can have multiple identities within a single app. Additionally, app-level conditional access ensures that access to sensitive data is granted only to authorized users and devices.

Apply data loss prevention policies without managing the user's device: With Intune-managed apps, data loss prevention policies can be applied without managing the user's entire device. This approach provides an extra layer of security without compromising on user experience.

Enable app protection on devices managed with 3rd party EMM tools: Intune-managed apps can be enabled with app protection, even on devices managed with 3rd party EMM tools. This functionality ensures that apps and data are always secure, regardless of the device management strategy being used.

One challenge many Intune administrators face is tracking which apps do or don’t support MAM policies. To overcome this challenge, Intune provides an app protection policy report enabling administrators to view a comprehensive list of all apps with MAM policies enabled. This report makes it easy to stay on top of app protection policies and ensure that all corporate data is fully secured.

Page 7

Describe Azure AD join

With Windows 11 or later, devices can join an AD DS domain and Azure AD. Azure AD join allows devices running Windows 10, Windows Server, or later operating systems to join an AD domain. Devices must meet specific requirements, such as having the correct ports open and not being joined to another AD DS domain. Azure AD allows devices to access cloud-based resources and Azure-based resources through SSO. Intune can manage and provision devices registered with Azure AD, but Group Policy cannot be used.

Businesses Largely in the CloudAzure Active Directory join (Azure AD join) can benefit you if you currently operate and manage identities for your business in the cloud or are moving to the cloud soon.

It also means that students will be able to sign into Windows with their Azure AD accounts and get access to Microsoft 365 resources in Office applications.

You may want to join devices to Azure AD in these scenarios:If most applications and resources that you use are in the cloud.

If you want to separate temporary accounts.

If you want to enable users to join their own devices to the organizational environment.