O365 and OWA: Room Listing Display Limitations



Although quite versatile and feature-rich, Exchange Online does have certain limits that distinguish it from on-premise Exchange.

For example, if you’re accustomed to booking rooms via OWA hosted from an on-premise Exchange organization, you expect to see a list of all available rooms.

In Exchange Online however, there’s a default system setting (which, as of this writing can’t be changed) that limits the number of rooms displayed to 100.  In large enterprises, this can cause some user frustration.

One work-around is to use the scheduling assistant to search for the room you want.  This is helpful, but may not satisfy all users’ needs.

Another method – which I consider to be more elegant – is to create room lists.

Room lists organize room resources into a specific type of distribution group that contains, well, rooms.

This is obviously very useful for large, geographically distributed firms that have many locations and far more than 100 bookable rooms.

So for example, to create a room list for all bookable rooms in the New York office you could issue the following PowerShell command (when connected to your tenant via a remote PowerShell session):

New-DistributionGroup -Name “New York Meeting Rooms” -RoomList

And to add rooms to this room list you’d use the following cmdlet:

Add-DistributionGroupMember -Identity “New York Meeting Rooms” -Member room120

Of course, some amount of planning and thought is needed to organize your rooms into these groups so your users can make sense of it all.  But once you’ve done that background work, room lists will make life much easier for people who access Exchange exclusively through OWA.

Using Role Based Access Control to Securely Manage Exchange Online



Exchange employs a permissions and access control model called Role Based Access Control (or RBAC).

The RBAC security model uses a hierarchy of access, organized into parent objects called ‘Management Role Groups’ and child objects called ‘roles’. Management Role Groups are composed of roles (for example, the Compliance Management role group contains the roles Data Loss Prevention and Information Rights Management – among others – which fall under the umbrella of compliance).
It’s important to note that users can be granted a mixture of rights that fit their job roles (for example, John Smith, who works in legal, can be assigned the ‘Legal Hold’ role from the Compliance Management role group and the ‘Retention Management’ role from the Records Management role group).


The above illustration is an overview of how permissions can be apportioned within Exchange.

Note how for example, administrators (as a category) can be granted rights in several role groups whose component roles – and therefore, role assignments – cross a variety of action areas.

Exchange’s management role groups are as follows:
Compliance Management (manage compliance settings)
Discovery Management (perform mailbox searches)
Help Desk (view and manage recipient configuration)
Hygiene Management (manage Exchange anti-spam features and grant permissions for antivirus products to integrate with Exchange)
Organization Management (manage Exchange objects – system super user)
Recipient Management (create, manage and remove recipient objects)
Records Management (configure retention policy tags, transport rules, etc.)
UM Management (Members of this management role group can manage Unified Messaging organization, server, and recipient configuration)
View-Only Organization Management (view recipient configuration and system properties)

Let’s detail each group’s components.


Compliance Management Role Group

This role group will allow a specified user, responsible for compliance, to properly configure and manage compliance settings within Exchange in accordance with a defined policy.”


Data Loss Prevention (intercepting the transmission of sensitive data types such as credit card, Social Security numbers, etc.)

Information Rights Management (members of this role can configure email encryption settings and related tasks)

Mailbox Import Export (members of this role can export items from and import item into mailboxes)

Retention Management (members of this role can configure mail retention policies)

View-Only Audit Logs (members of this role can search audit logs)

View-Only Configuration (members of this role can view all non-recipient Exchange configuration settings)

View-only Recipient (members of this role can view the configuration of recipients – i.e., mailboxes, mail users, mail contacts and distribution lists)

Discovery Management Role Group

Members of this management role group can perform searches of mailboxes in the Exchange organization for data that meets specific criteria.”


Legal Hold
Mailbox Search


Hygiene Management

Members of this management role group can manage Exchange anti-spam features and grant permissions for antivirus products to integrate with Exchange.”


Transport Hygiene
View-Only Configuration
View-Only Recipients

Help Desk Role Group

Members of this management role group can view and manage the configuration for individual recipients and view recipients in an Exchange organization. Members of this role group can only manage the configuration each user can manage on his or her own mailbox.  Additional permissions can be added by assigning additional management roles to this role group.”


Reset Password
User Options
View-Only Recipients


Organization Management

(note how this management role group forms a set of which the other groups are essentially subsets)…

Members of this management role group have permissions to manage Exchange objects and their properties in the Exchange organization. Members can also delegate role groups and management roles in the organization.”


Audit Logs
Data Loss Prevention
Distribution Groups
Federated Sharing
Information Rights Management
Legal Hold
Mail Enabled Public Folders
Mail Recipient Creation
Mail Recipients
Mail Tips
Message Tracking
Move Mailboxes
Org Custom Apps
Org Marketplace Apps
Organization Client Access
Organization Configuration
Organization Transport Settings
Public Folders
Recipient Policies
Remote and Accepted Domains
Reset Password
Retention Management
Role Management
Security Group Creation and Membership
Team Mailboxes
Transport Hygiene
Transport Rules
UM Mailboxes
UM Prompts
Unified Messaging
User Options
View-Only Audit Logs
View-Only Configuration
View-Only Recipients


Recipient Management

Members of this management role group have rights to create, manage, and remove Exchange recipient objects in the Exchange organization. “

Roles :

Distribution Groups
Mail Enabled Public Folders
Mail Recipient Creation
Mail Recipients
Message Tracking
Move Mailboxes
Public Folders
Recipient Policies
Reset Password
Team Mailboxes


Records Management

Members of this management role group can configure compliance features such as retention policy tags, message classifications, transport rules, and more.

Audit Logs
Message Tracking
Retention Management
Transport Rules


View-Only Organization Management

Members of this management role group can view recipient and configuration objects and their properties in the Exchange organization.


View-Only Configuration
View-Only Recipients



Consider the following example, in which there are four categories of users who interact with Exchange Online:

1.) Administrators – full access (create policies, create recipient objects, create groups and distribution lists, modify critical system settings, delete system and recipient objects, interact with Microsoft engineering at the system level as peer)

2.) Administrators – specialized access (view system configuration, view recipient properties, run system reports, possess super user privileges in one or more management role group but not all)

3.) Help Desk (full access to help desk level activities such as create recipient mailbox, modify mailbox properties, release false positive SPAM from quarantine, view and modify distribution lists and related end-user supportive tasks)

4.) End-users (request modifications, request object creations such as distribution lists, report errors

Within these four main categories, it’s possible to create specific security groupings.

Administrators – full access will have super user privileges within all management role groups:

Compliance Management (manage compliance settings)
Discovery Management (perform mailbox searches)
Help Desk (view and manage recipient configuration)
Organization Management (manage Exchange objects – system super user)
Recipient Management (create, manage and remove recipient objects)
Records Management (configure retention policy tags, transport rules, etc.)
View-Only Organization Management (view recipient configuration and system properties)
Administrators – specialized access will have super user privileges within management role groups that are relevant to their job function. For example, a technical liaison working for Legal would need to possess the ability to place mailboxes on legal hold, search mailbox contents and perform other activities related to gathering information about and from user mailboxes.

So, Administrator – specialized access legal would be granted assignments from following role groups:

Compliance Management
Discovery Management

From the Compliance Management role group, the Administrator – specialized access, legal would obtain the mailbox-import-export role and from Discovery Management, legal hold and mailbox search.

Help Desk – self-explanatory. Help Desk personnel will be granted role assignments from the Help Desk Management Role group. These roles are limited to a subset of the querying and recipient object manipulation capabilities of the more robust admin roles.

The default Help desk roles are:

Reset Password
User Options
View-Only Recipients

Note that it’s possible to add roles from other management role groups to individual Help Desk personnel (for example, Help Desk managers or more senior level Help Desk team members)
End-users – End users are recipients of the policies and configuration changes made by administrators and help desk personnel. End-users are also a source of feedback information about overall system health and performance

As you can see, it’s possible to use the building blocks Role Based Access Control provides to assemble a very granular permissions model for a variety of job assignments which require interaction with Exchange.


Exchange 2013’s Admin Center: A Walk-through


Exchange 2013 introduces administrators to the web-based Exchange Admin Console, a more streamlined, efficient and user-friendly management interface for controlling Exchange.

Of course the best, and most powerful tool for managing Exchange remains the shell but for performing simpler administrative tasks the EAC does quite nicely.  Also, the EAC provides a common control interface for hybrid deployments (i.e., combined deployments of on-premise and Office 365 Exchange).

In this post, we’ll review the EAC’s various feature panes, describing the actions you can take in each.

But before we get to that, let’s take a comparative look at the first level screens of  Exchange 2010’s Management Console and Exchange 2013’s EAC.


First, Exchange 2010’s Management Console (click on the image to enlarge):


In the above, control of various Exchange elements (such as send connectors, CAS configuration and database management) is divided across function areas defined by organization, server and mailbox management sections. It takes a bit of getting used to and can’t be called intuitive.

Now, let’s look at Exchange 2013’s Administration Console (click on the image to enlarge):

Main Page

Here, feature panes are organized according to globally defined tasks, eliminating the sometimes confusing redundancy of the Exchange 2010 Management Console and the need to use many clicks and sub-clicks to accomplish your goal.

Let’s review each feature pane’s details (quotes are from this Technet article about the EAC – and the environment from which the screenshots were taken was built on Amazon Web Services as described by me here).  Click on images to enlarge.

The Recipients Pane:


This is where you’ll manage mailboxes, groups, resource mailboxes, contacts, shared mailboxes, and mailbox migrations and moves.”

The Permissions Pane:


This is where you’ll manage administrator roles, user roles, and Outlook Web App policies.

The Compliance Management Pane:


This is where you’ll manage In-Place eDiscovery, In-Place Hold, auditing, data loss prevention (DLP), retention policies, retention tags, and journal rules.”

The Organization Pane:


This is where you’ll manage the tasks that pertain to your Exchange Organization, including federated sharing, Outlook Apps, and address lists.”

The Protection Pane:


This is where you’ll manage anti-malware protection for your organization.

The Mail Flow Pane:


This is where you’ll manage rules, delivery reports, accepted domains, email address policies, and send and receive connectors.

The Mobile Pane:


This is where you’ll manage the mobile devices that you allow to connect to your organization. You can manage mobile device access and mobile device mailbox policies.”

The Public Folders Pane:

public folders-tab

In Exchange 2010, you had to manage public folders by using the Public Folder Management Console, which was located outside of the EMC in the Toolbox. In Exchange 2013, public folders can be managed from within the public folders feature area.”

The Unified Messaging Pane:

unified messaging-tab

This is where you’ll manage UM dial plans and UM IP gateways.”

The Servers Pane:


This is where you’ll manage your Mailbox and Client Access servers, databases, database availability groups (DAGs), virtual directories, and certificates.”

The Hybrid Pane:


This is where you’ll set up and configure a Hybrid organization.”


CAS Arrays (important, and not as hard as you think)

Alive...and archived!!

An often overlooked part of building a new Exchange 2010 or 2013 instance is the creation of a CAS array.  If you do a bit of Googling on the subject you’ll find a lot of information, much of it confusing, which gives you the impression it’s a Herculean undertaking.

In fact, the key elements of CAS arrays can be described quite simply:

1.)  CAS arrays provide failover for Outlook clients by abstracting the servers within your Exchange organization

2.) Outlook obtains server information from the database a user’s mailbox resides on- this is defined by the DB’s RPCClient setting (which is shown within Outlook at the following location):

Outlook Server Settings






3.) To view all mailbox databases’ RPCClient setting, issue the following Powershell command:

Get-MailboxDatabase | select name,rpcclientaccessserver | ft -auto

4.) To set a mailbox database’s RPCClient property, use this syntax:

Set-MailboxDatabase Database-Name -RpcClientAccessServer cas-array-name.your-domain.com

Now we can bring all this together into a scenario.

The RPCClient setting is an active directory object which, by itself, does not provide a load balancing function.  That’s best done using a hardware load balancer such as a KEMP (Windows Network Load Balancing is also an option but not as robust, in my opinion).

So, keeping that in mind, the first thing you should do is create a DNS name/Host A record for your cas array; let’s say cas-array.mydomain.com to keep it simple.

Next, you assign this name to your mailbox databases by issuing the Powershell command listed above:

Set-MailboxDatabase “Your Database Name” -RpcClientAccessServer cas-array-name.mydomain.com

Third, you should assign the IP address you assigned to the Host A record cas-array to a virtual IP on your hadware load balancer (virtualizing access to two or more CAS servers within your org).

Now, any users created on (or moved to) the databases with the cas-array.mydomain.com RPCClient property will have this name as their server setting within Outlook.

Which means that should you lose a CAS server, Outlook users will still be able to perform normal mail functions.

Amazon Web Services: Building an Exchange Test Environment


Amazon provides a cloud computing platform named Amazon Web Services (AWS).

Although AWS is primarily targeted towards enterprise-level customers such as Expedia, who use it to host their extensive web server farms and cloud-based data centers, there’s also an affordable tier called Elastic Computing 2 (EC2). Amazon also provides rapidly deployable test-drive environments for several Microsoft server products, including Exchange. No doubt these are useful for a variety of testing scenarios but unfortunately don’t give you an opportunity to build and configure an entire environment from scratch.  For that, you’ll need EC2.

Using EC2, it’s possible to build a modest-sized Exchange test environment at a reasonable cost (as of this writing, a four server environment cost approx. $40 to  $50 per month to keep online.  Note that pricing is flexible and dependent on virtual machine specs and uptime, among other factors).

You’ll need an Amazon account to get started (yes, the same account you use for shopping).

Once you’ve logged into the EC2 dashboard, you can create a virtual machine instance:

Create Instance

You’ll be presented with a list of Amazon Machine Images including Linux and Windows images.

Choose and Amazon Machine Image

By scrolling down, you’ll see a list of Windows Server options.  For building an Exchange server environment, I’ve typically used Windows Server 2008 Base 64-bit

Windows Server 2008 Base

The best option for making a low-cost testing platform is the t2.micro machine type which is included in the free tier.  Although the servers in this tier are indeed free, there are associated costs for bandwidth usage, CPU time and so on. See the AWS EC2 pricing guide for full information.

Choose an instance type-review and launch

In this example, we’re accepting the default machine configuration (i.e., no expansion of the standard RAM and hard drive space options) so we can choose the “Review and Launch” button at the bottom of the page to proceed.

Choose an instance type-review and launch

Recently, Amazon introduced solid state drives (SSD) as an option for their virtual instances.  In my experience, the SSD drives are an excellent choice for creating reasonably performing machines (especially in the free tier where the machines are not particularly robust – 30 GB of hard drive space and low RAM configs).

Boot from General Purpose SSD

Amazon Web Service instances are secured with public key data.  Part of the process of creating a machine is making a key pair (or selecting an already existing one)


choose a key pair

Once you’ve downloaded a key pair the instance will launch

Initiating Launch

There are several other tasks required to build your Exchange test environment using AWS. The biggies include:

1.)    Downloading trial copies of Exchange 2010 or Exchange 2013 from Microsoft.com

2.)    Creating a domain controller and configuring its DNS to use the DC’s external IP as the lookup host (about which, see below)

3.)    Configuring the AWS security group your machines are part of to allow the public IP addresses of your instances inbound access to all member servers.  This is a critical step for creating an Active Directory and Exchange environment since, by default, the EC2 instances use DHCP for IP addressing.  Their public addresses however, are fixed and so, these can be used to work around this limitation as per the image shown below, which diagrams the topology for a simple, two node DAG cluster Exchange set-up:

AWS domain topology

There’s quite a bit more to say but this post shows the basics – at least as I’ve experienced and worked out.  With AWS it’s possible to make – for a fairly low cost – a sandbox for safely practicing on a working Exchange environment.

Auditing Mailbox Access

Bogart, Humphrey (Maltese Falcon, The)_02

Sooner or later, executives and other users with sensitive information will request some sort of special handling of their mailboxes.  For example, not long ago I was tasked with finding a way of making the mailboxes of senior execs inaccessible (even from an admin point of view) to all except the execs themselves.

Of course, this wasn’t practical and died a quiet death.  But the idea of knowing who (or what process) accesses a mailbox is very practical with Exchange 2010.

This technet article describes the process…

Because mailboxes can potentially contain sensitive, high business impact (HBI) information and personally identifiable information (PII), it’s important that you track who logs on to the mailboxes in your organization and what actions are taken. It’s especially important to track access to mailboxes by users other than the mailbox owner. These users are referred to as delegate users.

By using mailbox audit logging, you can log mailbox access by mailbox owners, administrators, and delegates (including administrators who have full mailbox access permissions). Mailboxes are considered to be accessed by an administrator only in the following scenarios:


full here…


Exchange 2010 and Antivirus: Best Practices



Antivirus software is a necessary annoyance, required because of the (essentially) Wild West character of Internet connectivity.

Although critically important, when it comes to Exchange servers AV applications shouldn’t be deployed without regard for the messaging system’s behaviors and dependencies.

Fortunately, Microsoft provides a solid guide to using file-level AV scanning on Exchange 2010 servers.

An excerpt:

File-level scanners are frequently used. However, if they are configured incorrectly, they can cause problems in Exchange 2010. There are two types of file-level scanners:

  • Memory-resident file-level scanning refers to a part of file-level antivirus software that is loaded in memory at all times. It checks all the files that are used on the hard disk and in computer memory.
  • On-demand file-level scanning refers to a part of file-level antivirus software that you can configure to scan files on the hard disk manually or on a schedule. Some versions of antivirus software start the on- demand scan automatically after virus signatures are updated to make sure that all files are scanned with the latest signatures.


full here at Technet…

Setting a Database Activation Preference

forbidden-planet (1)

Recently, I had to recreate one of my DAGs (a topic I’ll get into another time). At the end of the process, I had to alter the activation preference of the member databases.  Via PowerShell this is easily achieved.

Let’s say, for example, that your DAG has two servers, EXCHSRV01 and EXCHSRV02 and two databases, MBDB01 and MBDB02. To view the current activation preferences for one of the hosted databases you can issue the following command from an Exchange Management Shell window:

Get-MailboxDatabase “MBDB01″|fl server, databaseCopies, activationPreference

The output will be similar to this:

Server: EXCHSRV01
DatabaseCopies: {MBDB01\EXCHSRV01, MBDB01\EXCHSRV02}
ActivationPreference: {[EXCHSRV02, 1], [EXCHSRV01, 2]}

In this scenario, I’d like to change the activation preference so that MBDB01\EXCHSRV01 is the primary DAG database\host.  To do this I issue the following cmdlet and switch combination:

Set-MailboxDatabaseCopy -identity ‘MBDB01\EXCHSRV01’ -ActivationPreference 1

To confirm, simply re-use: Get-MailboxDatabase “MBDB01″|fl server, databaseCopies, activationPreference



Remote Wipe Doesn’t Work!

The other day I tried to perform the remote wipe of an ActiveSync device and, to my surprise, received a “cannot be found” error.  The device – and its relationship with Exchange – certainly existed so what was up?



It turns out the cause was the relocation of the user’s account within AD.

Check out this echangeserverpro article, which explains the cause and cure (excerpt):
“In the comments of my article on user-initiated remote wipes for Exchange ActiveSync devices, Jonathan has described a situation in which administrator-initiated remote wipes fail if the user account has been moved to a different OU after the ActiveSync device association was created.”


full at exchangeserverpro…


Alive...and archived!!
Alive…and archived!!

Surely one of the most useful features of Exchange 2010 is that – out of the box – it gives you the ability to create an archiving infrastructure and server-based archiving policies. This is a generally good thing for every environment and a spectacularly excellent thing (only a slight exaggeration) if your messaging platform is serving an organization with mandated data retention requirements.
But don’t take my word for it; here’s an excerpt from MSFT’s intro to Exchange’s online archiving:

“Unlike Outlook Data Files (.pst) that are only accessible on the computer where the file is saved, items in the Personal Archive are available in Outlook from any computer that you use or in Outlook Web App (OWA).

If you previously archived messages to an Outlook Data Files (.pst), you can open those archives and move messages from that file into the Personal Archive. This makes all of your messages accessible online with Outlook Web App (OWA) or from other computers where you use Outlook 2010.

full here..
And this msexchange.org article provides an very nice step by step guide to setting up your archiving infrastructure