______________________________
In This Chapter
- Types of Objects
- Creating Users
- Enabling Mailbox
- Deleting Users
- Modifying Users
- Converting Types
- Reporting
______________________________
There is a saying in IT that the perfect network doesn’t have any pesky users. While it’s true admin work would be much easier without users, it completely defeats the purpose of having a network at all. In fact, users should be a key focus point of your network because they are the ones that create the company and make sure it is creating revenue. Which in turn pays for the network and your salary; at least in most cases.
So, users are fundamental in your network and obviously, the topic of this chapter. In this chapter, we will discuss creating and managing users along with all the secondary configuration options that will benefit your users, network and your admin responsibilities.
While the Exchange Admin Center offers a great deal of configuration options regarding the creation, management, etc. of users, you will hopefully see the major benefits of PowerShell when requiring bulk creation and changes. Knowing what is possible with Exchange Management Shell (EMS) might have some impact on how best to provision your users, your use of attributes and other conventions. It might be prudent to review those practices.
There are different types of objects that this chapter will address:
- User Mailbox
- Mail Enabled User
- Mail Contact
- Resource Mailbox
- Archive Mailbox
- Public Folder Mailbox
- Shared Mailbox
- Remote Mailbox
A User Mailbox is an AD user with a mailbox. This is different from a Mail User that can log in, but has no mailbox, and will only forward to another email address. A Mail Contact is an object that represents an email address in another environment, but is not security enabled and therefore cannot login.
Resource Mailboxes have a disabled user account, like a User Mailbox they also have a calendar but it is designed for resource reservations like rooms and/or equipment. There are two types of resource mailboxes: Room and Equipment. These have a few different attributes and additional features to support planning meetings or equipment information.
A Shared Mailbox has a disabled user account. The idea is that normal user mailboxes get permission to access email and send as that mailbox, with all the data stored in that mailbox and not across different mailboxes. Useful for general email addresses like [email protected] etc., in which several people require access and send permissions.
With Modern Public Folders introduced in Exchange Server 2013, the infrastructure has changed radically and Public Folder data is no longer stored in a separate database, but in Public Folder Mailboxes in mailbox databases. The user experience has not changed however.
An Archive Mailbox is an additional mailbox linked to the user's primary mailbox, with the distinct difference that the Archive mailbox is only available via Outlook Desktop (ProPlus) and Outlook Web App (OWA) edition when connected to Exchange. This means that no offline access is available per design, it is meant primarily as a PST replacement.
To explain the intricacies of creating users who will be able to send and receive email, we should look a little into how Azure Active Directory (AAD) works and how Exchange Online leverages it.
There are two kinds of users possible, mailbox or mail enabled. The first is a user account that can be authenticated by the Azure Active Directory and has a mailbox connected to it. This means the user can send and receive email, manage calendars, contacts, etc. All that information is stored in Exchange Online.
A mail enabled user (or mail user for short) can also be authenticated by the Azure Active Directory, but does not have a mailbox. Their user object does have an email address and a forwarding address, most likely to a mailbox in another environment (i.e partner company). If anyone sends an email to this user, Exchange will forward the email to the forwarding address. For instance, if you are an IT consultant with multiple customers, it’s reasonable to not have to maintain multiple mailboxes. This way users of each environment can find you in the Address List and send email, you on the other hand will get all email in one mailbox depending on your forwarding address. Nice to know: that will also limit the need for Exchange Online Licenses.
New Mailbox
You can directly create a new mailbox without the need to create an Azure Active Directory user first, it will be automatically created. However, the options available to you are mostly limited to things related to Exchange, for instance a home path cannot be configured in the same action. You will probably need to configure the user with MSOL cmdlets if so required.
** Note ** If your environment is synced, creating users and mailboxes with New-MSOLUSer is not a recommended process. Instead the objects (user account and remote mailbox) should be initiated from your on-premises Exchange and Active Directory servers. If your environment is not synced and is cloud-only, then using New-MSOLUSer is the appropriate course of action as this will be the only way to create new objects in Exchange Online.
Use the following command to create a MSOL User object as the first step to creating a mailbox, we need to use the New-MSOLUser cmdlet:
New-MsolUser -UserPrincipalName [email protected] -DisplayName "Dom Rigel" -FirstName "Dom" -LastName "Rigel" -UsageLocation "US"
** Note ** When using spaces in the Name field, you are required to use quotation marks if there is a space. The UserPrincipalName should obviously be valid for the Domain (you might need to add UPN suffixes) and preferably should correspond to the primary SMTP address the account will be using.
You can define the password via a prompt:
$SecurePassword = Read-Host -Prompt "Enter password" -AsSecureString
or a pre-determined value:
$PlainPassword = "Th1sSho4ldB3Secr3t"
$SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
In both cases the passwords must adhere to the password policy in place. The first method is fine for single changes. The latter is ideal for bulk additions of mailboxes. Obviously, you can also define a randomly generated unique password for each new mailbox, which is from a security perspective preferable.
Once a user is created, it needs to be licensed for Exchange Online. See Chapter 6 for those details. Once the user is assigned a license, it does take a period of time for the mailbox to be created in Exchange Online. Once it is, you will be able to work with it in the Exchange Admin Center or Exchange PowerShell.
To define FirstName, LastName etc. at account creation:
Set-MsolUser Dom. [email protected] -FirstName Dom -LastName Rigel
In order to configure additional parameters for a mailbox we can use the 'Set-Mailbox' cmdlet. This cmdlet has a few parameters we can use to configure a mailbox:
PrimarySmtpAddress – Which defines the primary SMTP address or reply address for that mailbox. Do note that when using this parameter, the Email Address Policy (EAP) setting EmailAddressPolicyEnabled is set to $False which means no EAP is applied on this account. This can be useful if you don’t want this account to have all the SMTP addresses applied from an EAP, for instance with Shared Mailboxes. Or this mailbox will be used for a very specific purposes requiring only the set address. It is worth noting that creating and utilizing EAPs requires an on-premises Exchange server as this option is not available in Exchange Online.
AccountDisabled – When creating the mailbox and logon account, security policies might dictate you to disable the Active Directory account until it’s ready for use (maybe additional security settings are required) or when the actual user is allowed to use it. For these circumstance, you can use this switch, but no value is required (i.e. $False isn't needed).
There are several types of policies available in Exchange, you can set specific (custom) policies with the following aptly named policy parameters:
- ActiveSyncMailboxPolicy
- AddressBookPolicy
- RetentionPolicy
- RoleAssignmentPolicy
- SharingPolicy
Name, DisplayName, FirstName, LastName are all values that have a special relationship together. These values are used by other users or even admins to identify the correct mailbox to the real-world user. Especially in large organizations it is prudent to have a good naming convention in place, also planning for all deviations that will happen. No naming convention will incorporate every possible situation, especially if your users have very different cultural naming standards and practices.
FirstName and LastName were already discussed, but it still important to point out that these values can be used in your Email Address Policy. So, even though they are not mandatory, it might help with your Email Address Policies or help your users find the correct person within Exchange Online.
You can further specify the user's Office and Phone parameters. These are, by default, visible in address lists etc., so make sure that privacy regulations in your country/region are followed. Note that you can filter based on Office locations when using RecipientFilter with many Exchange cmdlets.
Furthermore, not even all Exchange related values can be set when creating the mailbox, it is highly likely that you must use other cmdlets to completely configure the mailbox account to your organizations requirements and/or liking.
If your user(s) already have an Active Directory account, some parameters are already configured via other means. This way you only must concentrate on Exchange specific attributes and thus cmdlet parameters.
You can mailbox enable a user with at least these parameters:
Enable-Mailbox -Identity Sjon.Lont
In this case Identity can be the Name, Display Name or other types of values, that can uniquely identify the target user account. Note that when not specifying other parameters the default values are used, the same when using the New-Mailbox cmdlets.
The cmdlet further behaves the same as the New-Mailbox cmdlet, with the distinct difference the AD account and the mandatory values are already provided.
You can enable the Archive Mailbox on an existing mailbox user with an archive switch:
Enable-Mailbox Dom.Rigel -Archive -ArchiveName "Dom Rigel Archive"
The ArchiveName specifies the name that identifies the Archive mailbox, otherwise the default naming is used, which is "In-Place Archive – " before the mailbox display name.
You can also create a new mailbox immediately with an archive by adding the -Archive switch to New-Mailbox or Enable-Mailbox.
The default archive quota and archive quota warning are 100 GB and 100 GB. These values cannot be changed in either the Admin Center or via PowerShell. However, we can adjust the archive and make it into an AutoExpanding archive if we have the proper licenses. This can be done with this command:
Enable-Mailbox Dom.Rigel -AutoExpandingArchive
Do not forget to apply the appropriate Retention Policy, which can be specified when Archive enabling the user with the -RetentionPolicy parameter.
Mail enabled contacts are a way to create entries in the Global Address List that users can use to email often used addresses outside of your environment. For instance, if you have a Shared Service Desk supplier, you can create a mail contact with a recognizable name and an internal email address which also contains a forwarding address.
To create a contact:
New-MailContact -Name "Richard Deck" -ExternalEmailAddress [email protected]
Note that the contact will get an SMTP address according Email Address Policy settings, however the ExternalEmailAddress is the primary address and all email sent to the contact will be forwarded to the external address.
To delete a contact:
Remove-MailContact "Richard Deck"
There are two options: deleting the mailbox or deleting the user account including the mailbox. It depends on your own requirements and situations which of the two options is valid.
To remove the mailbox and NOT the user:
Disable-Mailbox -Identity Dom.Rigel -PermanentlyDisable
** Note ** This only works if the user does not have an assigned Exchange License. In order to remove a mailbox without removing the user, the license for Exchange would have to be removed. See Chapter 6 for how to change licenses for users.
To remove the mailbox AND the user:
Remove-Mailbox -Identity Dom.Rigel -Confirm:$False
Alternatively, it’s also possible to change the type of a user mailbox to Shared to keep the data and email flow available. See later in this chapter on how to do this.
There is one constant, and that is that things change. This is definitely the case for users. A lot can be changed via Exchange PowerShell and it’s probable that a lot of settings are never changed or will require being changed.
But when it comes to modifying mailbox users, there are several things to consider. Most importantly, there is no single cmdlet that can modify everything on a mailbox. You must use the correct cmdlet for the required changes you want to make.
For an overview of all the attributes that (might) be subject to any modification, see the Reporting section later in this chapter. In that overview the Get-* cmdlets are used, but obviously to change the attributes you should use the Set-* variant or in some cases (like permissions) the option to use Add-* or Remove-* is also an option.
It’s not the goal of this book to review every possible modification available, we will show what we feel are the most important and common modifications.
The user object is where it all starts, whether it has a mailbox or is only mail-enabled. You can change the UPN of a user in the cloud, or maybe change the Display Name. To change a UserPrincipalName, there is a command called 'Set-MsolUserPrincipalName' like so:
Set-MsolUserPrincipalName -UserPrincipalName [email protected] -NewUserPrincipalName [email protected]
** Note ** Don't forget to connect to the MSOL service with either Connect-MSOLService or Connect-EXOPSSession (MultiFactor) before running these cmdlets.
There are a few other cmdlets that can be used to manipulate user accounts and we can find them again with the Get-Command technique:
Get-Command *MsolUser*
Which provides us with a short list of cmdlets:
Get-MsolUser
Get-MsolUserByStrongAuthentication
Get-MsolUserRole
New-MsolUser
Remove-MsolUser
Restore-MsolUser
Set-MsolUser
Set-MsolUserLicense
Set-MsolUserPassword
Set-MsolUserPrincipalName
There are several cmdlets that configure options on a (user) mailbox, most of those features are set with Set-Mailbox. There are other cmdlets that set other very specific settings, so if this cmdlet doesn’t provide what you want to change you might have to use another cmdlet.
Why not in one cmdlet? Some of the settings control specific user settings that a user should have access to. Because of that everything is controlled in one way or another with PowerShell and Role Based Access Control (RBAC), it’s sometimes easier to have a separate cmdlet for specific settings that are also configurable by users. It makes it easier to control those permissions (via Role Assignments with RBAC).
Settings on the mailbox include some email flow control such as addresses, forwarding or size/delivery restrictions, storage or quota settings and some policies. Others include junk email handling, OWA configuration (including features other than what is set via OWA Mailbox policies) and regional settings.
We will discuss some cmdlets in more detail below, in a per cmdlet way instead of a per scenario way.
Set-Mailbox
One example to change the email flow settings is to set a forwarding address to another user:
Set-Mailbox -Identity [email protected] -DeliverToMailboxAndForward:$True -ForwardingAddress [email protected]
Above we set this to an SMTP address, for which there must be a matching mail object for it; a mailbox, mail user or mail contact. If you needed to forward a message to an external SMTP address the ForwardingSmtpAddress property would be set instead.
With delivery restrictions, you can control what email is accepted or not.
Set-Mailbox -Identity [email protected] -RequireSenderAuthenticationEnabled:$True -AcceptMessagesOnlyFromSendersOrMembers @('[email protected]') -RejectMessagesFromSendersOrMembers @('[email protected]')
With RequireSenderAuthenticationEnabled only accounts in your Exchange Online Tenant can email this mailbox (this is enabled for distribution groups by default). You can also configure users or groups to be accepted or rejected explicitly, in this example email from Ann Ples is accepted and from Mike Soft is rejected. Note that those are multi-valued properties.
Another setting is the mailbox quota’s, mainly the IssueWarningQuota, ProhibitSendQuota and ProhibitSendReceiveQuota settings. There are also quota’s when using auditing and Litigation/In-Place hold, but the principle is the same. The big difference is that most mailboxes will use the default Database quota settings, but in case you need to override those settings you have to set them on the mailbox:
Set-Mailbox -Identity [email protected] -IssueWarningQuota '10737418240' -ProhibitSendQuota '11811160064' -ProhibitSendReceiveQuota '12884901888'
In this example the mailbox quotas are respectively 10GB, 11GB and 12GB, the normal input is in MB (megabytes) however you can explicitly state whether you use MB or GB etc.:
Set-Mailbox -Identity [email protected] -IssueWarningQuota 10GB
If you require to retain deleted items longer than the default 14 days that are a mailbox default:
Set-Mailbox -Identity [email protected] -UseDatabaseRetentionDefaults:$false -RetainDeletedItemsFor '30'
In this example the database retention defaults are disabled; the deleted items are retained for user recovery for 31 days. There is a limit in Exchange Online for the RetainDeletedItemsFor value and that is 30. If we try to set it greater than 30, then we get an error like so:
For setting additional SMTP addresses see example Adding/Removing an email address later in this chapter.
Set-MailboxAutoReplyConfiguration
Configures Out of Office (OOF) replies, including scheduling, inside and outside organization message. Basically, every possible setting the user can set. See Enabling and configure Out of Office settings by the admin for an example.
Set-MailboxJunkEmailConfiguration
Configure the User Junk folder with specifics in addition to what the user has configured via OWA/Outlook.
Set-MailboxJunkEmailConfiguration -Identity [email protected] -TrustedSendersAndDomains fabrikam.com
The above will add the fabrikam.com domain as a trusted sender and Exchange will handle those domains differently (however if you have valid spam filtering software, their settings probably take precedence).
Set-MailboxRegionalConfiguration
Configures regional settings on a specific mailbox, such as time zone, date format, language etc.. Users will be prompted the first time they log in OWA or it will be configured depending on the client. However, as an admin you can provision these settings.
See Setting Regional setting in this chapter for an example.
There are some settings specifically for OWA. The user can change these settings, but as in other similar examples it might be required to provision some settings for users.
Set-MailboxMessageConfiguration
Configures the behavior of OWA for a specific mailbox. For instance; the automatic addition of a signature, always show the 'From:' field when composing messages, conversation order and whether ReplyAll is the default response:
Set-MailboxMessageConfiguration -Identity [email protected] -AutoAddSignature $True -AlwaysShowFrom $True -ConversationSortOrder ChronologicalNewestOnTop -IsReplyAllTheDefaultResponse $False
Set-MailboxSpellingConfiguration
Set the spelling language in OWA, force check before sending the email and whether to ignore uppercase and mixed digits:
Set-MailboxSpellingConfiguration -Identity [email protected] -CheckBeforeSend $True -IgnoreUpperCase $True -IgnoreMixedDigits $True -DictionaryLanguage Dutch
Calendar settings can be changed to affect the way calendar invites are processed or to set timezones for instance. While you can configure calendar settings for user mailboxes during provisioning, you will likely have to perform these actions more often for Room and Equipment Mailboxes as users can change most of these settings themselves.
Set-MailboxCalendarConfiguration
Can change calendar configurations and is available to the user, but also the admins so they can provision certain settings for the users. Such as WorkDays/WorkingHours, the first week of the year, timezones and such. Some customization are for OWA only as Outlook (or other clients) have their own settings that supersede these.
Set-MailboxCalendarConfiguration -Identity [email protected] –WeekStartDay Monday
Sets the first day of the week to Monday, instead of the default Sunday.
Set-MailboxCalendarFolder
This cmdlet is only relevant when sharing a calendar with a federated Exchange organization or when Internet Publishing is allowed. You can reset the published URLs, change the date range of what is published and disable the sharing. You can only do this for you own mailbox, unless you change the Role Assignment.
Set-MailboxCalendarFolder administrator:Calendar -PublishEnabled $True -DetailLevel Limited
Set-CalendarProcessing
The cmdlet Set-CalenderProcessing configures the way Exchange will handle meeting requests. As previously stated, users can configure these settings themselves and some settings are not relevant for user mailboxes. However, they are for Room and Equipment mailboxes which can turn them into automatic booking systems. You can use the same principal for inactive mailboxes, previously owned by users and setting to refuse every meeting request.
Set-CalendarProcessing -Identity Auditorium -ProcessExternalMeetingMessages $True -AutomateProcessing AutoAccept -AddOrganizerToSubject $True -AddAdditionalResponse $True -AdditionalResponse "Your request has been accepted."
This example configures the Room mailbox Auditorium to process External meeting requests (coming from outside of the Exchange organization), automatically accepts the requests, changes the Subject to the name of the organizer and will reply with a customized response to the organizer.
You can set additional options like whether users can set a reoccurring meeting, maximum meeting duration and delegates that have to give approval.
Client Access
All client access related settings are performed with Set-CASMailbox. You can disable/enable and configure specific protocols, such as IMAP/POP or OWA, ActiveSync and Exchange Web Services (EWS). Basically, everything mailbox client connection related (with the exception of SMTP) can be configured.
Set-CASMailbox -Identity [email protected] -PopEnabled $False -ImapEnabled $False -EwsAllowEntourage $False -ActiveSyncEnabled $False
In this example, POP, IMAP and ActiveSync are disabled and EWS Entourage support (an Outlook for MacOS predecessor) is not allowed. Note that IMAP and POP are default enabled, but the service is by default disabled on every Exchange server. Thus, if an application or user requires either one of the protocols the services must be enabled and started. It’s a best practice to disable these protocols or to not publish the ports to the Internet as a way of increasing security.
Policies are an easy way to ensure users get the right configuration and is preferable to changing each specific user. There are several policies available:
- OWA Mailbox
- Retention
- RoleAssignmentPolicy
- SharingPolicy
- Mobile Device
OWA Mailbox policies regulate the Outlook Web App capabilities available to the user, the default has every feature enabled. For instance, Offline Mode is one often disabled feature in the default policy or other custom policies.
Retention policies give users and admins the option to regulate the retention of items in their mailbox or specific folders. When the mailbox is Archive enabled Retention policies (with the ”Move to Archive”) are commonly used, but an Archive mailbox is not required for their use.
Role assignments are part of Role Based Access Control (RBAC), the security model within Exchange. These policies regulate what users can carry out what actions on what objects, such as updating a distribution group for instance.
Sharing policies regulate sharing of calendar information within federated Exchange organizations or via Internet Calendar Publishing.
Mobile Device policies configure the security settings and features on connected mobile devices, via Exchange ActiveSync or the Outlook for iOS/Android app. Most commonly a mandatory PIN is set via these policies.
Obviously to assign or to change policies, the policies must exist. Assigning or changing the assigned policy on a mailbox is done via the Set-Mailbox or Set-CASMailbox cmdlet:
OWA Mailbox policy:
Set-CASMailbox -Identity [email protected] -OwaMailboxPolicy NoOfflineOWA
Retention Policy:
Set-Mailbox -Identity [email protected] -RetentionPolicy AutoCleanDeletedItems
Role Assignment policy:
Set-Mailbox -Identity [email protected] -RoleAssignmentPolicy EditSubsetGroups
Sharing policy:
Set-Mailbox -Identity [email protected] -SharingPolicy InternetSharing
ActiveSync Mailbox policy:
Set-CASMailbox -Identity [email protected] -ActiveSyncMailboxPolicy HighSecurity
See Chapter 9 for more information on managing non-user objects. For Mobile Device policies check Chapter 15.
These are different levels of permissions possible on Exchange mailboxes:
- Full Access
- Send As
- Send On Behalf
- Folder Permissions
To add Full Access permissions, use Add-MailboxPermission:
Add-MailboxPermission -user Mike.Soft -identity Ann.Ples -AccessRights FullAccess -InheritanceType All -Automapping $False
In this case Mike Soft will be granted full access on Ann Ples’ Mailbox, additionally this permission will be granted to all folders within the mailbox. The setting Automapping controls whether Ann’s mailbox is automatically added in Mike’s Outlook (via AutoDiscover), in this case by setting it to $false it will not. When the Automapping feature is not configured it is default True (which is also the case when using the Exchange Admin Center). This will not grant Send-As permissions, that is actually a recipient based permission and can be set via:
Add-RecipientPermission -Identity Ann.Ples -Trustee Mike.Soft -AccessRights 'Send As'
In this example user Mike has been granted Send As permissions to Ann’s Mailbox. Do note that Mike has to change the 'From:' value in Outlook to Ann’s email address. In cases where it is required that the actual sender is still visible, Send on Behalf is the best option. This must be configured with the Set-Mailbox cmdlet:
Set-Mailbox –Identity Ann.Ples -GrantSendOnBehalfTo Mike.Soft
In this example Mike has been granted Send on Behalf permissions. As with Send-As, Mike must change the 'From:' value in Outlook to make use of this permission. However, the recipient will now see the actual sender even if replies are sent back to the main mailbox (Ann’s). In some cases, Full Access is too broad therefore it is good to be able to set permissions on specific folders. Folder Permissions are set via the user itself in Outlook or OWA, but admins can use:
Add-MailboxFolderPermission -Identity Ann.Ples:Inbox -User Mike.Soft -AccessRights Owner
In this example, Mike gets Owner permissions on the Inbox folder inside Ann’s Mailbox. There are quite a lot of different permissions possible, be sure to read up on them at TechNet. Note that the Calendar folder has two additional permission roles specifically for availability visibility.
Additional information - https://technet.microsoft.com/en-us/library/dd298062(v=exchg.160).aspx
In this example, the Add-MailboxFolderPermission was used which adds permissions and lets previously set (not inherited) permissions as is. Use the Set-MailboxFolderPermission to edit previously assigned permissions, and Remove-MailboxFolderPermissions to remove permissions.
Note that the Well-Known folders (like Inbox, Calendar, Sent Items etc.) will change with regional settings set by the user (via OWA) or by language settings of Outlook when first connecting to their Mailbox. This might pose a challenge if you want to automate specific settings on those Well-Known folders. Luckily the FolderType is a constant and that value will tell you what kind of folder it is. Custom made folders (a second calendar for instance) have the folder type of "User Created". Use the following PowerShell one-liner in order to find the specific name of the Well-Known Calendar folder:
Get-Mailbox <Mailbox>|Get-MailboxFolderStatistics|Where {$_.FolderType -eq "Calendar"}
The value of the FolderType can be Inbox, Contacts, Sent Items, Deleted Items etc.. You can list this for a specific mailbox with:
Get-Mailbox <mailbox> |Get-MailboxFolderStatistics| Select FolderType
Below is a comprehensive list of often performed changes.
Enabling and configure Out of Office settings by the admin
Even with all the options available to a user to configure the Out of Office (OOF, which is an abbreviation for Out of Facility, harking back to early Exchange years when its predecessor was used internally), you might get requests to set this. Luckily this is relatively easily done:
Set-MailboxAutoReplyConfiguration -Identity Ann.Ples -AutoReplyState Enabled -InternalMessage "I’m currently out of office."
This is the simplest configuration, there are options to set a message for external users (i.e. not in the Exchange organization), setting a time period when the OOF status has to be enabled, automatically declining meeting request etc. Basically, every setting available to the user, when using a recent version of Outlook or OWA. However, for an admin this example will probably be sufficient in most cases.
In some cases you want to set regional settings for a user, so that the user has an even more fluid first logon experience and isn’t bothered by questions about language etc.. Especially valid if your organization is set in a single language region etc..
You can set the specific regional settings with:
Set-MailboxRegionalConfiguration -Identity "Hans de Vries" -Language nl-nl -DateFormat "dd-MM-yy" -LocalizeDefaultFolderName -TimeZone "W. Europe Standard Time"
In this example the user will have Netherlands Dutch language settings in OWA and in Outlook, the LocalizeDefaultFolderName parameter will change the well known folders like Inbox and Calendar to the localized versions (respectively ‘Postvak IN’ and ‘Kalender’ in this case). The latter could be important when you have scripts to set Calendar folder permissions or require to migrate to a non-Exchange environment via PST. Furthermore, the date format has been set to correspond with the region and the time zone has been set to West Europe.
Adding/Removing an Email Address
Even with Email Address Policies it is possible that the naming convention doesn’t provide the required SMTP address. Or the account requires additional SMTP addresses or the user changed his or her name.
** Note ** Don't forget that modifying properties of an object while connected to Exchange Online PowerShell is only supported for cloud only objects.
You can add email addresses with the Set-Mailbox cmdlet with the EmailAddresses parameter. However, if you use this parameter the value will replace all of the configured address (only to be added again by the Email Address Policy). Therefore you need to use a little different syntax:
Set-Mailbox Ann.Ples -EmailAddresses @{Add="smtp:[email protected]"}
In this example the [email protected] address is added to other addresses on the Ann Ples mailbox. Note the small caps type "smtp". If you change this to capital letters, this will become the Primary SMTP address. However, this could be overruled by any active Email Address Policy.
Removing an email address is achieved by using Remove instead of Add:
Set-Mailbox Ann.Ples -EmailAddresses @{Remove="smtp:[email protected]"}
In both cases, other SMTP addresses configured on the mailbox are not removed.
There are times you might have to change the type of the (user) object to another; types being user, resource or shared. Sometimes, converting a mail user to a full mailbox enabled user is required or when mergers have been completed Linked mailboxes might have to be converted to user mailboxes. This quickly summarizes the options and some of the things you should consider.
Converting Mail User to User Mailbox
There are situations that might require you to convert a mail user to a mailbox user.
In order to convert a Mail User into a Mailbox, you will need to assign an Exchange Online License. First, you will need to create the Mail User in Office 365:
Converting User Mailbox to Shared Mailbox
This might be useful when a person leaves the organization, but you are required to keep the data intact due to legal and/or compliance regulations. By converting the mailbox from user mailbox to shared, you disable the AD account (lowering the risk of breaches), give access to others within the company and you are still able to keep the mail flow intact.
** Note ** Shared mailboxe do not require an Exchange Online license, unless a Legal Hold is put in place.
You can convert mailbox types with the Set-Mailbox cmdlet:
Set-Mailbox -Identity PeteBlanket -Type Shared
You can change the type of mailboxes to Resources (Room, Equipment), Shared or User Mailboxes in this way with the Set-Mailbox cmdlet. Valid values are:
- Regular
- Room
- Equipment
- Shared
When changing the type of the mailbox, do not forget that additional configuration specifics for the new mailbox type is required depending on your organizational needs.
In this section, we will give some attention towards reporting on user mailboxes. This is discussed in more depth in Chapter 18 - Reporting, but there are some specifics that warrant a mention in this chapter.
It’s prudent to check with every update if there are any new commands or new attributes exposed in the Get cmdlets. Especially when new features are added, you’d expect to find some way of configuring those features. However, as Exchange is developed with Office 365 (or specifically Exchange Online) in mind you might encounter attributes that are of no use in the cloud (or vice versa). You can ignore those.
When you have a lot of objects, do not forget to add the -ResultSize parameter to your cmdlet preferably with "Unlimited" as a value, otherwise only 1,000 objects are returned. You will get a warning, but within a script you might miss that and it could result in incomplete processing or reporting of your environment. For testing purposes, you could use this to limit the number of objects returned and thus speed up your script.
Let’s see the relevant cmdlets, what kind of information they reveal and in some instances, some extra useful information. Do note that some cmdlets are not that obvious. Check the screenshots for some formatting suggestions, some -Identity fields are sometimes a bit more complex than just adding user identity values. Also, some cmdlets show more interesting information when you pipe the cmdlet to Format-List (FL in short), this has been used in the examples but is not required when using a script (as PowerShell returns objects not text).
Get-MsolUser
Lists attributes such as phone, address names etc. from Active Directory users, whether they are mail- or mailbox enabled or not. The focus is the Active Directory user object rather than the mailbox.
Get-MsolUser -Identity [email protected] | Fl
Get-Mailbox
Lists mailbox enabled objects, these can be of RecipientTypeDetail UserMailbox, Shared, Linked, Room or Equipment. The focus of this cmdlet is settings directly related to the mailbox functionality. Most interesting attributes are those related to quotas of not only the user mailbox but all kinds of quotas, mailflow handling, auditing, and the custom attributes.
Get-Mailbox -Identity [email protected] | Fl
Get-MailboxAutoReplyConfiguration
Configuration of the Out of Office (OOF) replies, including scheduling, and inside and outside organization message. Basically, every possible setting the user (or an admin) has set. With this you can check whether an OOF has been set.
Get-MailboxAutoReplyConfiguration -Identity [email protected]
Get-CalendarProcessing
Display the way Exchange will process meeting invites on the mailbox at hand. In most cases for user mailboxes the default settings will be adequate, however for Room, Equipment and maybe Shared mailboxes changes may be required. Due to privacy regulations, it might be required to remove the subject of a meeting from a room mailbox. Or you want to limit the way users are booking a meeting with a room mailbox.
Get-CalendarProcessing -Identity [email protected] | fl
Get-MailboxCalendarConfiguration
This cmdlet shows the configuration of the calendar specific settings, such as the time zone, working hours and such. You could use this to check whether users are correctly provisioned per their actual regional location or other considerations.
Most of these features influence Outlook Web App, although some are also valid for other clients. The EventsFromEmailEnabled* and Weather* settings are for Exchange online only (as some other features which are mention on the TechNet page for this cmdlet).
Note that this cmdlet does not change any calendar processing settings. See Get-CalendarProcessing for those settings.
Get-MailboxCalendarConfiguration -Identity [email protected] | Fl
Get-MailboxCalendarFolder
The cmdlet shows settings specifically targeted at sharing or publishing Calendar folder data of the user. It shows the period that data is visible, including the detail level for anonymous users. This is only the case when the calendar is shared, which is defined by the PublishEnabled attribute and the existence of publishing URLs.
Get-MailboxCalendarFolder -Identity [email protected]:Calendar
The same user now with a shared calendar:
Get-MailboxFolder
View information on folders in your own mailbox.
Get-MailboxFolder Damian:Inbox | Fl
Do note that you require the correct permissions on the mailbox, otherwise an error will be show stating that the mailbox doesn’t exist. It’s already trying to get information on the root folder and because you don’t have access it will think it doesn’t exist.
The default permissions are set via the Role Based Access Control role MyBaseOptions, this means that even an administrator can only use this cmdlet on their own mailbox, but will get this error when trying to query others. This obviously limits the use of this cmdlet for reporting.
Get-MailboxFolderPermission
Used to view folder permissions within mailboxes. You must specify the correct folder path, which for the default/ well-known folders in Exchange is dependent on the regional settings of the mailbox that create these folders at first login. So, the default Calendar folder might be named different in Spanish.
Also, note that the Calendar folder permissions have additional AccessRights available, AvailabilityOnly and LimitedDetails. Both influence the visibility of specific information of meetings (subject and location is also shown with LimitedDetails).
Get-MailboxFolderPermission -Identity [email protected]:Inbox
Get-MailboxFolderStatistics
View information on specific folders in a mailbox. This includes the folder size and number of items. For more information, you can add the -IncludeAnalysis switch, which can help with troubleshooting. It will return values that would otherwise remain empty, the reason being that it can take a while for the analysis to complete. The values however, can help with troubleshooting or reporting.
Get-MailboxFolderStatistics -Identity [email protected] -FolderScope Inbox -IncludeAnalysis
This would result into something like this excerpt:
Another parameter that might provide useful information for troubleshooting or reporting is the IncludeOldestAndNewestItems parameter. As the name suggests, you will then receive more information on the oldest and newest items in the specified mailbox.
Get-MailboxFolderStatistics -Identity [email protected] -FolderScope Inbox -IncludeOldestAndNewestItems
This would result into this:
Note that you do not supply a folder path, but rather a folder type with the FolderScope parameter. With this all folders of the same type are returned and not just one specific folder.
Valid input values for FolderScope are:
|
All |
Calendar |
|
Contacts |
ConversationHistory |
|
DeletedItems |
Drafts |
|
Inbox |
JunkEmail |
|
Journal |
LegacyArchiveJournals |
|
ManagedCustomFolder |
NonIpmRoot |
|
Notes |
Outlook |
|
Personal |
RecoverableItems |
|
RssSubscriptions |
SentItems |
|
SyncIssues |
Tasks |
The ManagedCustomFolder value returns output for all managed custom folders. The RecoverableItems value returns output for the Recoverable Items folder and the Deletions, DiscoveryHolds, Purges, and Versions subfolders. Also see TechNet. If you require information regarding statistics of the whole mailbox, see Get-MailboxStatistics.
Get-MailboxJunkEmailConfiguration
Use this cmdlet to see the User Junk Mail folder configuration for a specific mailbox, including any blocked or trusted email addresses or domains. This can be useful to determine whether your central anti-spam solutions requires some tweaking.
Get-MailboxJunkEmailConfiguration -Identity [email protected]
In this case the user has blocked a Wingtoys address.
** Note ** Realize that with Exchange Online Protection, these settings can require an additional step in troubleshooting messages ending up in the Junk Mail folder. See this Microsoft article on this:
Get-MailboxMessageConfiguration
Shows the configuration of Outlook Web App for a specific mailbox.
Get-MailboxMessageConfiguration -Identity [email protected]
Get-MailboxPermission
Shows the permissions set on the specific mailbox. Note that these are not permissions on the subsequent folders. The IsInherited column indicates whether the permission is inherited from a higher source from the Azure Active Directory (AAD) configuration as Mailbox permissions are actually AAD permissions.
Get-MailboxPermission -Identity [email protected]
If you require only the permissions of a specific user, you can use the -User parameter.
Get-MailboxPermission -Identity [email protected] -User Administrator
In some cases, you only want to report on non-inherited permissions i.e. directly assigned mailbox permissions, which are the permissions set if you use Exchange cmdlets. You can do that by filtering using the Where cmdlet.
Get-MailboxPermission -Identity [email protected] | Where {$_.IsInherited -eq $False}
Get-MailboxRegionalConfiguration
Use this cmdlet to extract regional settings on a specific mailbox, such as timezone, date format, language etc..
Get-MailboxRegionalConfiguration -Identity [email protected] | fl
The DefaultFolderNameMatchingUserLanguage indicates whether the default (or Well-Known folders such as Inbox) are localized, if True, those folders names are in the language indicated. This has an impact when you use specific cmdlets that target specific folders, for instance folder permissions.
Get-MailboxSpellingConfiguration
Retrieve spelling configuration set by the user for Outlook Web App.
Get-MailboxSpellingConfiguration -Identity [email protected]
Get-MailboxStatistics
Will show you statistics of a specific mailbox, such as the database name, size, number of items, the last logged on user etc. (although if this interests you, you should turn on auditing on those mailboxes for more detail information).
Get-MailboxStatistics -Identity [email protected] | fl
Retrieve client access settings on a specific mailbox such as what kind of protocols are enabled on this mailbox and the specific configuration of these protocols:
Get-CASMailbox -Identity [email protected]
Get-CASMailbox -Identity [email protected] | Fl
