• Home
• Microsoft Exams
• MS-203 - Microsoft 365 Messaging

MS-203 Microsoft Practice Test Questions and Exam Dumps

Question 1

You have a Microsoft Exchange Server 2019 organization that contains 200 mailboxes. You need to add a second email address to each mailbox using a format of the first letter of each user's last name, followed by the user's first name, and then @fabrikam.com. You convert all the mailboxes to shared mailboxes, and then run the Set-Mailbox cmdlet with the -EmailAddressPolicyEnabled $false parameter. Does this meet the goal?

A. Yes
B. No

Answer: B

Explanation:

The goal is to add a second email address to each mailbox in a specific custom format. The format is described as using the first letter of the user's last name, followed by the user's first name, and ending with @fabrikam.com. The focus is clearly on modifying or appending an additional email alias with a specific naming convention to user mailboxes.

Let’s evaluate the solution provided:

The proposed solution involves converting all mailboxes to shared mailboxes, and then running the Set-Mailbox cmdlet with -EmailAddressPolicyEnabled $false.

Let’s break down both parts:

1. Converting to Shared Mailboxes:

• A shared mailbox is typically used when multiple users need access to a common mailbox (like support@ or info@).

• Shared mailboxes do not require a license, but this is mainly for resource-sharing purposes.

• Converting user mailboxes to shared mailboxes is not required nor appropriate for the scenario. The users still need their mailboxes for day-to-day use.

• Also, converting all user mailboxes to shared mailboxes might disrupt access and licensing, and it's not a standard or recommended step for just modifying email addresses.

2. Using -EmailAddressPolicyEnabled $false:

• This part does make sense in context. By setting -EmailAddressPolicyEnabled to $false, you are telling Exchange not to automatically manage the email addresses for the mailbox via policies, which allows you to manually assign addresses.

• However, this step alone does not actually add the required email address to the mailboxes. It only allows you to make manual changes, but it doesn’t apply them by itself.

So while the second part is necessary, the first part (converting to shared mailboxes) is inappropriate and unnecessary for achieving the stated objective. Also, the solution never includes the actual command to add the desired email address format using a calculated syntax (e.g., via scripting or a loop with Set-Mailbox and a constructed SMTP address).

Thus, the proposed solution is incomplete and incorrect, and does not meet the goal.

The correct answer is: B

Question 2

You have a Microsoft Exchange Server 2019 organization that contains 200 mailboxes. You need to add a second email address to each mailbox. The address must have a syntax that uses the first letter of each user's last name, followed by the user's first name, and then @fabrikam.com. Solution: 

You create an email address policy that uses the %1s%g@fabrikam.com email address format. Does this meet the goal?

A. Yes
B. No

Answer: B

Explanation:
This question evaluates whether the proposed solution (an email address policy using %1s%g@fabrikam.com) will generate the desired email format, which is:

First letter of the last name + First name + @fabrikam.com
(For example, if the user is John Smith, the desired email address would be sJohn@fabrikam.com.)

To break this down, let's look at what the format variables actually represent in Exchange email address policies:

• %g = given name (first name)

• %s = surname (last name)

• %1s = first letter of the surname

• %1g = first letter of the given name

Now let's analyze the proposed policy format: %1s%g@fabrikam.com

• %1s gives the first letter of the last name

• %g gives the first name

So, putting these together, %1s%g will generate:
First letter of last name + First name (e.g., for John Smith → sJohn@fabrikam.com)

This does match the desired syntax.

However, despite what it looks like, there’s an important clarification to make: Exchange does not support %1s in email address policies. As per Microsoft's official documentation, the supported variables for email address policies in Exchange Server are:

• %m = alias

• %r = display name

• %g = given name

• %s = surname

• %i = initials

• %d = domain name

Partial string selectors like %1s or %1g are not valid in Exchange email address policies. This type of substring logic must be handled through custom scripting, such as PowerShell, and cannot be accomplished using native email address policy variables.

Therefore, the solution of using %1s%g@fabrikam.com in an email address policy will not work because Exchange does not support that format natively.

So, while the logic is sound in theory, the implementation is not valid given the constraints of Exchange Server's email address policy syntax.

The correct answer is B.

Question 3

You have a Microsoft Exchange Server 2019 organization that contains 200 mailboxes. You need to add a second email address to each mailbox using a format that includes the first letter of the user's last name, followed by the user's first name, and then @fabrikam.com. You convert all the mailboxes to shared mailboxes and run the Set-Mailbox cmdlet with the -EmailAddressPolicyEnabled $true parameter. Does this meet the goal?

A. Yes
B. No

Answer: B

Explanation:

In this scenario, the goal is to add a custom secondary email address to each mailbox using a very specific pattern: first letter of the last name + first name + @fabrikam.com.

Let’s break down what the solution attempts to do and why it does not meet the requirement:

1. Conversion to Shared Mailboxes:

• This is not necessary for modifying email addresses. Shared mailboxes are typically used for team or department inboxes that multiple users access.

• Converting all 200 user mailboxes to shared mailboxes is counterproductive unless you specifically intend to stop licensing the mailboxes or reassign their purpose.

• This step introduces administrative and user-access complications and does not help achieve the email alias addition goal.

2. Using Set-Mailbox -EmailAddressPolicyEnabled $true:

• Setting EmailAddressPolicyEnabled to $true means that the mailbox will be governed by email address policies defined in Exchange.

• Exchange will then automatically apply addresses based on those policies.

• However, the built-in email address policies in Exchange are relatively limited in logic and syntax options—they do not support custom address formats like "first letter of last name + first name".

• Therefore, this command does not ensure the addition of the required address format. In fact, it may overwrite any manually added addresses if the policy is reapplied.

• To implement a format like the one described, you would generally need a PowerShell script that loops through users, extracts the required components (first name, last name), and uses Set-Mailbox to manually add the custom SMTP address.

What would work instead:

• Leave the mailboxes as user mailboxes.

• Use Set-Mailbox -EmailAddresses @{add="smtp:<customformat>"} after generating the new address with a script that formats it as required.

• Ensure EmailAddressPolicyEnabled is set to $false so Exchange policies don’t override the manually set address.

Because neither converting mailboxes to shared nor enabling the default email address policy addresses the custom email format requirement, this solution does not meet the goal.

The correct answer is: B

Question 4

You have a Microsoft 365 subscription. Several users report today that they cannot access email from their mobile device. They successfully accessed their email from the same device yesterday. 

You need to identify which mobile device access rule applies to the devices. Which cmdlet should you run?

A. Get-ActiveSyncDeviceClass
B. Get-ActiveSyncOrganizationSettings
C. Get-MobileDevice
D. Get-MobileDeviceMailboxPolicy

Answer: A

Explanation:
This question deals with troubleshooting mobile device access issues in a Microsoft 365 environment. Specifically, users are experiencing a sudden inability to access email through their mobile devices even though access worked the previous day. The goal is to identify which mobile device access rule is currently being applied that may be causing this issue.

Let’s go through the cmdlet options to see which one is most suitable for this purpose:

A. Get-ActiveSyncDeviceClass
This cmdlet is used to retrieve information about the classes of mobile devices that have connected to the organization via Exchange ActiveSync. More importantly, it allows administrators to see which device access rules are being applied based on the device model, type, or class. For example, administrators can see whether a certain device class is allowed, blocked, or quarantined. This makes it the most direct and relevant cmdlet to identify which access rule may be preventing users from accessing email.

B. Get-ActiveSyncOrganizationSettings
This cmdlet retrieves the global ActiveSync settings for the organization. While it can show global settings such as whether device access rules are enforced or if new devices are quarantined by default, it does not provide detailed, per-device-class rule application. It is helpful for context but not for pinpointing which access rule affects specific devices.

C. Get-MobileDevice
This cmdlet retrieves information about the mobile devices associated with specific mailboxes. While it can show you whether a mobile device is connected, when it last synced, and the device's identity, it does not directly show which device access rule is applied. It is useful for device inventory and basic troubleshooting, but not for identifying applied rules.

D. Get-MobileDeviceMailboxPolicy
This cmdlet displays the mailbox policies that define what settings (such as password requirements, encryption, etc.) apply to mobile devices. These policies govern device behavior rather than access permissions. This cmdlet does not tell you why a device might be blocked.

Therefore, to determine which device access rule is being applied, the correct cmdlet is:

A. Get-ActiveSyncDeviceClass

This will show details like DeviceType, DeviceModel, and the AccessState (Allowed, Blocked, Quarantined) for those classes, making it the most effective cmdlet for solving the issue described.

Question 5

You have a Microsoft Exchange Online tenant where all users are assigned an Office 365 Enterprise E3 license. You want to ensure that users can connect to their Microsoft 365 mailboxes from an Android device only by using Microsoft Outlook. 

What should you create?

A. a conditional access policy in Azure Active Directory (Azure AD)
B. a data loss prevention (DLP) policy
C. an app protection policy in Microsoft Endpoint Manager
D. a connection filter policy in Exchange Online Protection (EOP)

Answer: A

Explanation:

The goal here is to restrict how users access their Exchange Online mailboxes specifically from Android devices, such that they can only use Microsoft Outlook and not other email apps (e.g., Samsung Email, Gmail, etc.).

Let’s evaluate each option:

A. Conditional Access Policy in Azure AD

This is the correct solution.

Azure Active Directory Conditional Access policies are designed to enforce specific access requirements based on a wide array of conditions, including:

• Device platform (e.g., Android)

• Client app type (e.g., browser, mobile apps, legacy protocols)

• User or group membership

• Location

• Sign-in risk

You can create a Conditional Access policy that:

• Targets all users or a selected group

• Applies to Android devices

• Grants access only if the client app is "Mobile apps and desktop clients"

• Requires the client app to be Microsoft Outlook only

To achieve the specific behavior mentioned in the question (allowing only Outlook on Android to access Exchange Online mailboxes), Microsoft recommends creating a Conditional Access policy that blocks unsupported client apps, allowing only approved client apps like Outlook.

Conditional Access also integrates with App Protection Policies and App-based Conditional Access, especially for Microsoft Intune-managed environments, but the basic enforcement can still be accomplished using Conditional Access alone.

B. Data Loss Prevention (DLP) Policy

DLP is used to detect and prevent the sharing or accidental leakage of sensitive information (like credit card numbers or SSNs). It does not control access methods or restrict which apps can be used. This is unrelated to the scenario.

C. App Protection Policy in Microsoft Endpoint Manager

App Protection Policies can help protect corporate data within apps like Outlook, Teams, etc., by enforcing controls like requiring a PIN or blocking copy/paste. However, they do not restrict access to only Outlook; they assume access is already granted and simply protect the app behavior.

You would use this in combination with Conditional Access for more granular control, but on its own, this is not enough to restrict access to only Outlook.

D. Connection Filter Policy in Exchange Online Protection (EOP)

Connection filters are used to block or allow email connections based on IP addresses. These apply to inbound email and anti-spam policies and have no control over client app behavior or mailbox access methods.

To restrict Android users to only use Microsoft Outlook for accessing Exchange Online mailboxes, you must use Conditional Access policies in Azure AD to enforce that restriction based on platform and app type.

The correct answer is: A

Question 6

You manage a hybrid deployment between Microsoft Exchange Online and on-premises Exchange Server 2019. The deployment contains a primary SMTP domain named contoso.com. Users have email addresses that use a syntax of firstname.lastname@contoso.com. A user named Ben Smith receives a new client computer. You configure the computer to access Ben Smith's mailbox. Ben Smith reports that he cannot connect to his mailbox from the new computer. You verify that other users can connect successfully to their mailbox and that new users can discover their mailboxes by using Autodiscover. You need to ensure that Ben Smith can connect to his mailbox from the new computer. 

What should you do?

A. Modify the primarySmtpAddress property for the mailbox of Ben Smith.
B. Modify the RemoteRoutingAddress parameter for the mailbox of Ben Smith.
C. Modify the email address of Ben Smith to use a syntax of lastname.firstname@contoso.com.
D. Modify the email address of Ben Smith to use a syntax of firstname.lastname@contoso.onmicrosoft.com.

Answer: B

Explanation:
This scenario describes an issue in a hybrid Exchange deployment, where a user (Ben Smith) cannot connect to their mailbox from a new client computer, even though other users and Autodiscover work properly. The problem is isolated to Ben Smith, so it is likely related to his individual mailbox configuration.

In a hybrid setup, particularly one that uses Exchange Online and on-premises Exchange 2019, mailbox location discovery is managed through Autodiscover and RemoteRoutingAddress settings. Let’s review what each of the options would do:

A. Modify the primarySmtpAddress property for the mailbox of Ben Smith.
This would change the main email address Ben uses, but the primary SMTP address (e.g., firstname.lastname@contoso.com) is already consistent with the organization’s standard. The question doesn’t indicate any problems with the email address itself, so this is likely not the issue.

B. Modify the RemoteRoutingAddress parameter for the mailbox of Ben Smith.
This is the correct answer. In a hybrid configuration, mailboxes that are located in Exchange Online should have a RemoteRoutingAddress (also known as a target address) that typically uses the format user@domain.mail.onmicrosoft.com. This tells the on-premises Exchange server where to route mail and how to redirect Autodiscover requests for users whose mailboxes reside in the cloud. If Ben Smith’s RemoteRoutingAddress is missing or incorrect, the Autodiscover process from the new computer may fail to locate his mailbox in Exchange Online, leading to connection issues.

Fixing the RemoteRoutingAddress would typically look like this in PowerShell:

Set-MailUser "Ben Smith" -RemoteRoutingAddress ben.smith@contoso.mail.onmicrosoft.com

This ensures that Exchange knows to redirect client connections to the correct cloud mailbox.

C. Modify the email address of Ben Smith to use a syntax of lastname.firstname@contoso.com.
This would change the email address format, but again, the problem is not about email address formatting. Other users with the same syntax are working fine. Changing the email format doesn’t solve the Autodiscover or mailbox routing issue.

D. Modify the email address of Ben Smith to use a syntax of firstname.lastname@contoso.onmicrosoft.com.
This would assign him a cloud-based alias directly, but this is not typically used as a primary email address in hybrid environments. The @contoso.onmicrosoft.com domain is not the user-facing production domain. Also, this doesn’t address the routing or Autodiscover issue that is likely caused by a misconfigured RemoteRoutingAddress.

Therefore, the most targeted and appropriate fix is to ensure that Ben Smith’s RemoteRoutingAddress is correctly configured so that Autodiscover and mail flow can work as expected in the hybrid environment.

The correct answer is B.

Question 7

You have a Microsoft Exchange Online tenant with 1,000 user mailboxes and 10 mail-enabled users. These mail-enabled users have email addresses in the SMTP domains fabrikam.com and contoso.com. You need to convert the mail-enabled users into user mailboxes. 

What should you do first?

A. Remove the remote domains of fabrikam.com and contoso.com.
B. Assign a license to each user.
C. Add the users to an Office 365 group.
D. Modify the email forwarding settings of each user.

Answer: B

Explanation:

Mail-enabled users (also known as mail users) in Microsoft Exchange Online are typically users who have an external email address (outside the Exchange organization) but are listed in the Global Address List. They do not have an actual mailbox in Exchange Online, and their mail is forwarded to an external address.

The question asks how to convert these mail-enabled users into user mailboxes, meaning they need to have mailboxes hosted in Exchange Online, just like any standard licensed Office 365 user.

To do that, you must first:

Assign a valid Microsoft 365 license that includes Exchange Online

This is the first and most important step. A Microsoft 365 license (such as Office 365 E1, E3, or E5) includes Exchange Online service. Once a valid license is assigned:

• Exchange Online will provision a mailbox for the user.

• The user will then become a regular mailbox user instead of just a mail-enabled user.

After assigning the license:

• The object type in Exchange Online will change automatically once the mailbox is created.

• You may also need to remove any external forwarding addresses (but that's a later step).

Let’s analyze the incorrect options:

A. Remove the remote domains of fabrikam.com and contoso.com

This is not necessary. These domains are likely accepted domains in your tenant. Removing them could disrupt mail flow. It’s unrelated to the conversion of mail-enabled users to mailboxes.

C. Add the users to an Office 365 group

Office 365 groups are collaborative group mailboxes and file shares—not used for converting individual users to mailboxes. Adding mail users to groups won’t create a mailbox for them.

D. Modify the email forwarding settings of each user

This could be something you do after conversion, especially if forwarding was configured to an external address, but it’s not the first or required step to convert the user.

Summary

The first step to convert a mail-enabled user to a mailbox user is to assign a valid Exchange Online license, which triggers the mailbox creation process.

The correct answer is: B

Question 8

Which two of the following tasks are typically performed during the migration of mailboxes to Microsoft 365? (Choose 2.)

A. Setting up hybrid configuration for seamless coexistence between on-premises and cloud environments
B. Creating a new Microsoft 365 tenant for each user in the organization
C. Configuring Transport Layer Security (TLS) to secure email traffic
D. Performing an Exchange Online migration using tools such as the Microsoft Exchange Migration Wizard
E. Migrating shared mailboxes first to minimize downtime

Answer: A and D

Explanation:
When organizations move their email infrastructure from on-premises Exchange servers to Microsoft 365 (Exchange Online), there are several standard procedures that are commonly followed to ensure a smooth transition. Two key aspects of this migration are establishing a hybrid configuration and using the Microsoft Exchange migration tools.

A. Setting up hybrid configuration for seamless coexistence between on-premises and cloud environments
This is a core step in many mailbox migrations, especially when the organization wants to move mailboxes in phases rather than in a big bang approach. The Hybrid Configuration Wizard (HCW) allows for features like free/busy calendar sharing, mail routing, and global address list (GAL) synchronization across on-premises and Exchange Online. It also facilitates seamless mailbox moves using tools like the New-MoveRequest PowerShell cmdlet. Therefore, this is a typical and often essential task during many Microsoft 365 migration projects.

B. Creating a new Microsoft 365 tenant for each user in the organization
This is incorrect. Microsoft 365 tenants are created per organization, not per user. A single tenant can support thousands of users. Creating a tenant for every user would be not only unnecessary but also extremely inefficient, complex, and contrary to standard Microsoft cloud architecture.

C. Configuring Transport Layer Security (TLS) to secure email traffic
Although TLS is a best practice for securing email traffic, it is not specifically a migration task. It is part of general email security management and applies to both cloud and on-premises environments. While ensuring secure communication during and after migration is important, configuring TLS is not typically listed as a direct migration step unless addressing a specific compliance or connectivity issue.

D. Performing an Exchange Online migration using tools such as the Microsoft Exchange Migration Wizard
This is a direct and essential task during mailbox migration. Microsoft provides tools like the Exchange Admin Center migration wizard, PowerShell cmdlets, and third-party tools to move user mailboxes to Exchange Online. The specific tool depends on the type of migration being performed (e.g., cutover, staged, hybrid, or IMAP migration). This task is central to the actual movement of mailbox data from on-premises infrastructure to the cloud.

E. Migrating shared mailboxes first to minimize downtime
This is incorrect. Shared mailboxes do not require licenses in Microsoft 365 and are typically migrated after or alongside regular user mailboxes, not before. There is no standard practice to migrate shared mailboxes first to reduce downtime, especially because downtime is usually minimized through proper scheduling, mailbox move batches, and hybrid coexistence configurations—not by the order of mailbox types migrated.

In summary, setting up hybrid coexistence (A) and using the Exchange Online migration tools (D) are two standard and essential steps in most Microsoft 365 mailbox migrations.

The correct answers are A and D.