Completing mailboxes
You now have a new mailbox. Although it is functional in that
it could be used to send and receive email, in the eyes of an
administrator, the new mailbox is incomplete. Many operations might be
performed on a new mailbox before it is completely ready to be handed
over to the tender mercies of its owner. Tasks that might be performed
include the following:
Add the new mailbox to distribution groups. For example:
Add-DistributionGroupMember -Identity 'DG Dublin Users' -Member 'Kelly, Kevin' –BypassSecurityGroupManagerCheck
Update
mailbox properties so that the new mailbox is discovered by the queries
used to determine the membership of dynamic distribution groups. In this example, you put a value in one of the customized attributes:
Set-Mailbox -CustomAttribute1 'Sales' -Identity 'Kelly, Kevin'
Update
other mailbox properties that are not revealed by EAC. Many of the
properties people associate with a mailbox are actually updated with
the Set-User cmdlet rather than the Set-Mailbox cmdlet because they
belong to the base Active Directory user object rather than to the
mailbox. In this example, you update a number of properties with the
Set-User cmdlet to fill out the directory information for the new
mailbox:
Set-User -City 'Sydney' -Company 'Contoso' -CountryOrRegion 'Australia'
-Department 'IT' -Manager 'Redmond, Tony (IT)' -Office 'Sydney'
-Phone '8170-19944' -Title 'VP APJ' -Identity 'Bracy, Colleen (IT)'
Enable
a personal archive for the mailbox. This can be done during the initial
creation, but some administrators prefer to leave this action until
after users confirm that they want an archive.
Enable-Mailbox –Archive –Identity 'Kelly, Kevin'
It
can take quite a long time to populate all the properties for a new
mailbox fully. For this reason, many administrators script the process
of creating a new mailbox and use the EAC only for one-off mailbox
creation. The scripts used to create a mailbox range from moderately
simple (basically a collection of one-line EMS commands) to very
complex. In the latter case, the scripts usually accept a feed from an
identity provisioning or HR management system that maintains
information about employees and produces the necessary commands to
create a ready-to-go mailbox.
The
methods used to create new mailboxes range from once-off operations to
sophisticated scripts used to generate hundreds or thousands of
mailboxes following a company merger. Some companies write code to
integrate mailbox creation into their new employee on-boarding process,
whereas others are happy to send support tickets to their
administrators to request new mailboxes on an on-demand basis. Using
EAC to create a bunch of mailboxes isn’t much fun because the joy of
navigating multiple screens rapidly becomes a tedious slog after you’ve
done it once or twice.
Because Exchange has supported scripting
since Exchange 2007, many EMS scripts are available on the Internet
that can be used to automate the bulk creation of mailboxes, including
the population of properties such as retention policies and the
addition of new mailboxes to distribution groups. A simple search will
reveal many scripts that you can download and amend to create a bulk
load script that’s appropriate for your organization.
Creating new room and resource mailboxes
The code to create a new room mailbox is similar to that used
to create a user mailbox, except that you use the –Room parameter to
mark it as a room mailbox. For example:
New-Mailbox -Name 'Conference Room A' -Alias 'Confa'
-OrganizationalUnit 'contoso.com/Exchange Resources' -UserPrincipalName 'confa@contoso.com'
-SamAccountName 'Confa' -FirstName 'Conference' -Initials '' -LastName 'Room A' –Room
To see a list of current rooms, use this command:
Get-Mailbox –Filter {RecipientTypeDetails –eq 'RoomMailbox'}
The
code to create a new equipment mailbox is also similar. In this case,
the –Equipment parameter is passed to mark the mailbox as an equipment
mailbox. For example:
New-Mailbox -Name 'Projector Conference A' -Alias 'ProjConfA'
-OrganizationalUnit 'contoso.com/Exchange Resources'
-UserPrincipalName 'ProjConfA@contoso.com'
-SamAccountName 'ProjConfA' -FirstName 'Projector' -Initials ''
-LastName 'Conference A' –Equipment
To see the current equipment mailboxes, type:
Get-Mailbox –Filter {RecipientTypeDetails –eq 'EquipmentMailbox'}
Room
and equipment mailboxes are created with disabled Windows accounts. It
is a good idea to group these accounts in their own OU and to consider
assigning these mailboxes to their own database to isolate them clearly
from regular mailboxes.
Exchange
2013 is a highly capable multilingual product that supports server
components running in at least 11 languages and client components
(Outlook Web App and EAC) in over 60 languages from Amharic to Welsh.
The exact count increases all the time as Microsoft completes the task
of translating the language-dependent parts of the product into a new
language. Only the language-dependent
server components are installed on servers that support the CAS role.
Thus, a multirole server has both server and client language-dependent
capabilities.
Users select the language they want to use with
Exchange the first time they connect to a mailbox with a client.
Sometimes the selection is implicit, as when you connect with a client
such as Outlook that’s already running in a selected language, and
sometimes it is explicit, as when someone uses Outlook Web App to open
a mailbox, and a language setting is not present for the mailbox. Every
time it starts, Outlook Web App checks whether the language and time
zone values are set for the mailbox. If one or both of these values are
missing, Outlook Web App displays the dialog box shown in Figure 2
and pre-populates the selection with whatever language is the default
on the workstation. Of course, there is no compulsion on the user to
accept the proposed language, and he is free to select from any of the
languages Exchange supports. After the selection is made, Exchange
updates the languages property of the user’s mailbox, and Outlook Web
App continues by displaying the mailbox contents in all the glory of
the selected language. You can check on the language any user uses as
follows:
Get-Mailbox –Identity TRedmond | Select Languages
You
can set the user’s language with the Set-Mailbox cmdlet. For example,
to force the user to use Welsh, you execute the following command:
Set-Mailbox –Identity Young –Languages "cy-gb"
The next time the user connects to Outlook Web App, she will see Outlook Web App in Welsh (Figure 3).
Exchange cannot do anything about translating the messages sent to a
user into the user’s preferred language (perhaps this will be a feature
in a future release), but all the text strings and command prompts are
translated into the chosen language.
Of
course, if the user connects using a client that includes
language-dependent code installed on a workstation such as Outlook, the
change in language will have no effect because Outlook cannot switch
languages in the same way Outlook Web App can. Outlook Web App has this
ability because all the language-dependent text strings and other
components it needs are installed on the Mailbox server, and Outlook
Web App can retrieve them from there.
EAC uses the same language
value as Outlook Web App to determine which language-dependent text it
should present to a user. Assume that you assign the person shown using
Outlook Web App previously the Server Management RBAC role. If she then
started EAC, she’d see something like the screen shown in Figure 4.
Note the effect of RBAC in that EAC has recognized that users who hold
the Server Management role should not be able to see all the options
available to more privileged administrations such as those who are
members of the Organization Management role group.
For
those who are interested, “cy” stands for “Cymru,” which is Wales in
Welsh, whereas “gb” indicates that Welsh is a language of the GB
country. The same approach is taken to the different variations of
English, in which you have the following:
En-us English as in the United States
En-ie English as in Ireland
En-gb English as in the United Kingdom
Some variations of English, such as en-au (Australia), which are not supported
You
can assign multiple language values to a mailbox. For example, in this
instance, you update a mailbox to create a list of languages comprising
Welsh, U.K. English, and French. In most cases, this won’t have much
effect because Exchange always selects and uses the first language it
finds in the list unless those language components are not available on
the Mailbox server. Because Exchange 2013 installs all languages, the
language the user prefers should always be available.
Set-Mailbox –Identity Young –Languages "cy-gb", "uk-gb", "fr-fr"
Some
companies like to set default language and time zone values as part of
the process of creating new mailboxes. Exchange facilitates this
through the Set-MailboxRegionalConfiguration cmdlet, which enables
administrators to provide a full set of regional information for a
mailbox. This example sets my mailbox to use the Ireland variant of
English as the mailbox language together with the appropriate time
zone, date format, and time format for the region:
Set-MailboxRegionalConfiguration –Identity 'Tony Redmond' –Language 'en-IE'
–TimeZone 'GMT Standard Time' -DateFormat 'dd/MM/yyyy' –TimeFormat 'H:mm'