Exchange Online Shared Mailboxes Limit Now 50GB!

Although these limits have been in effect for some time now, it is good to finally have an official confirmation that Shared Mailboxes in Office 365 now also have 50GB of mailbox storage available!

 

Source: Exchange Online Limits

DirSync vs AADSync

The eventual successor to Azure Active Directory Synchronization Tool (DirSync) is the Azure Active Directory Synchronization Service, also known as AADSync. Although AADSync provides new features that DirSync does not, it also lacks a few features currently in DirSync, especially in the first GA version... So what exactly are the differences between the two?!

For a comparison chart of the features that each of these tools currently supports for synchronizing your directory with Azure Active Directory, visit the Directory Integration Tools webpage.

Exchange 2013 OWA “The following files couldn't be attached” error

If are trying to add a large attachment to an email in Outlook Web App (OWA) you might get one of the following errors:
• The following files weren't attached because adding them would cause the message to exceed the maximum size limit of 10 MB: filename.
• The following files couldn't be attached: Filename. Please try again later.

As you can see from the first error, the problem is self-explanatory: the attachment is just too big. In Exchange 2013 the default maximum message size for an attachment is 10 megabytes (MB).

To Increase this limit you need to follow these steps:
  1. Increase the maximum message size for the organization by using the Set-TransportConfig cmdlet;
  2. Increase the maximum message size for the Send connectors by using the Set-SendConnector cmdlet;
  3. Increase the maximum message size for the Receive connectors using the Set-ReceiveConnector cmdlet;
  4. Increase the following settings in the OWA Web.config file:
    • maxAllowedContentLength (value in bytes);
    • maxReceivedMessageSize (value in bytes);
    • maxStringContentLength (value in bytes);
    • maxRequestLength (value in kilobytes).
  5. Increase the following settings in the EWS web.config file:
    • maxAllowedContentLength (value in bytes);
    • maxReceivedMessageSize (value in bytes).
  6. Stop and then restart the MSExchangeOWAAppPool application pool;
  7. Stop and then restart the MSExchangeServicesAppPool application pool.


IMPORTANT: due to the new architecture of Exchange 2013, steps 4 and 5 must be performed in both of the following locations:
  • The Client Access server on which the Web.config files are located in the following path: %ExchangeInstallPath%\FrontEnd\HttpProxy
  • The Mailbox server on which the Web.config files are located in the following path: %ExchangeInstallPath%\ClientAccess

Also, in step 4, please note that not all settings are present on both files.

AADSync ProxyAddresses Not Synchronized to Office 365

If you have installed the first publicly available version of AADSync (v1.0.0419.0911), the eventual successor to DirSync, you might have noticed that the ProxyAddresses attribute will not get synchronized to Office 365. Unfortunately this means that all proxy addresses will be gone in Exchange Online!

It turns out this is not a configuration error, but a bug with this release... Microsoft statement is that “currently Proxyaddresses will not work with AADSYNC, and will be addressed in the next release”.

As such, you have two alternatives:

   1. Update to the latest version of AADSync, v1.0.0470.1023 (obviously recommended!);

   2. If, for some reason, you don’t want to upgrade, edit the existing rule to sync the proxyaddresses attribute.

Permissions lost after moving mailbox from Exchange 2003 to Exchange Online in hybrid environment

Consider the following scenario:

• Your on-premises Exchange organization includes mailboxes that are hosted in Exchange 2003;
• Your on-premises Exchange organization is set up for a hybrid deployment together with Exchange Online;
• You move users or shared mailboxes from on-premises Exchange to Exchange Online.

 

After you move these mailboxes, you notice that the original mailbox permissions are not retained.

You might also notice that when you run the Add-MailboxPermission cmdlet in Exchange Online, you receive an error stating:

The ACL for the object “CN=user,CN=Users,DC=letsexchange,DC=com" is not in canonical order (Deny/Allow/Inherited) and will be ignored.

This is because Exchange 2003 uses a mailbox security descriptor system that is no longer used by Exchange Online. Because of this, when an Exchange 2003 mailbox is moved to Exchange Online, the original mailbox security descriptors are ignored and permissions are not kept.

To resolve this issue, run the FixMailboxSD command-line tool to correct the security descriptions on the on-premises Exchange 2003-based servers.

This is a small utility to fix mailbox security descriptors in Microsoft Exchange that have become non-canonical. It must be run on a machine with Exchange System Manager, as it relies on the interfaces exposed by CDOEXM, but it will work against mailboxes on 2003 or 2007 (not 2010 or 2013).

The tool uses CDOEXM from C# to read the MailboxRights object from the IExchangeMailbox interface. It then iterates through the DACL and puts all the ACEs in canonical order, and saves the changes.

The syntax of the tool is very straightforward:

FixMailboxSD “DN of mailbox”

For example:

FixMailboxSD “CN=nuno,CN=Users,DC=letsexchange,DC=com”

The tool will display a summary view of the current DiscretionaryAcl, and then show a summary view of the DACL after it has reordered it. It will then save the changes and return to a command prompt.

 

Exchange 2013 default OWA apps do not work

When you install Exchange Server 2013 on a Window Server 2012 R2-based computer, default apps (such as Bing map and Action item) in Outlook Web App do not work depending on the version of Exchange installed.

 

This issue occurs because the logic to load app resources is broken in Windows Server 2012 R2. To resolve this issue, install Cumulative Update 5 for Exchange Server 2013.

msExchangeRecipientTypeDetails Active Directory Values

A while back, while performing a migration to Office 365, I had to convert a Distribution Group into a Room List. However, due to the nature of the migration, I didn’t have access to an on-premises Exchange to use the Shell and convert it, so I had to resort to using ADSIedit. So how do we do this using ADSIedit?

 

There is a reference field that specifies what a recipient type is, as far as on-premises AD/Exchange is concerned, Recipient Type Details = msExchRecipientTypeDetails.

 

As many other AD attributes, these are represented by an Integer value in AD. Here are all the possible values for Recipient Type Details:

Object Type	RecipientTypeDetails	Value Name
User Mailbox	1	UserMailbox
Linked Mailbox	2	LinkedMailbox
Shared Mailbox	4	SharedMailbox
Legacy Mailbox	8	LegacyMailbox
Room Mailbox	16	RoomMailbox
Equipment Mailbox	32	EquipmentMailbox
Mail Contact	64	MailContact
Mail User	128	MailUser
Mail-Enabled Universal Distribution Group	256	MailUniversalDistributionGroup
Mail-Enabled Non-Universal Distribution Group	512	MailNonUniversalGroup
Mail-Enabled Universal Security Group	1024	MailUniversalSecurityGroup
Dynamic Distribution Group	2048	DynamicDistributionGroup
Public Folder	4096	Public Folder
System Attendant Mailbox	8192	SystemAttendantMailbox
System Mailbox	16384	SystemMailbox
Cross-Forest Mail Contact	32768	MailForestContact
User	65536	User
Contact	131072	Contact
Universal Distribution Group	262144	UniversalDistributionGroup
Universal Security Group	524288	UniversalSecurityGroup
Non-Universal Group	1048576	NonUniversalGroup
Disabled User	2097152	DisabledUser
Microsoft Exchange	4194304	MicrosoftExchange
Arbitration Mailbox	8388608	ArbitrationMailbox
Mailbox Plan	16777216	MailboxPlan
Linked User	33554432	LinkedUser
Room List	268435456	RoomList
Discovery Mailbox	536870912	DiscoveryMailbox
Role Group	1073741824	RoleGroup
Remote Mailbox	2147483648	RemoteMailbox
Team Mailbox	137438953472	TeamMailbox

 

 

As such, all I had to do was locate the Distribution Group in AD, update its msExchRecipientTypeDetails attribute to 268435456 and wait for DirSync to replicate the change.