Want more control over Sent Items when using shared mailboxes?
Edit 6/15/2015: We are starting to make this feature available again in Office 365. Note that the new shared mailbox Sent Items behavior is disabled by default. If you want to enable it for your users, you can do so by using cmdlets mentioned below. Additionally, we are still on track to ship this to our on-premises customers in Exchange 2013 CU9, as mentioned before. Whether a mailbox is used by multiple users as a collaborative tool or a communication gateway to customers, retaining a record of emails sent from a shared mailbox remains an important business requirement. In Exchange 2010, there was a way to configure this behavior, but we did not have this feature starting with Exchange 2013. Our customers have told us that a shared mailbox should keep a copy of emails sent from the mailbox by all members of the mailbox in its own Sent Items folder. We have taken that feedback and decided to make some changes to how sent mails are handled for shared mailboxes. We are excited to announce that once this feature is enabled for you (see below), by default all shared mailboxes will retain a copy of emails sent from the mailbox. You will no longer have to figure out which mailbox member sent an email as the shared mailbox or on behalf of it. How does it work? Emails can be sent as the shared mailbox itself or on behalf of it by member(s) of the mailbox, assuming proper permissions have been granted. This feature is designed to retain a copy of an email sent from the shared mailbox in the Sent Items folder of the shared mailbox. The same behavior can be expected for emails sent on behalf of the shared mailbox, when configured to do so. A copy of the sent mail will also reside in the Sent Items folder of the member’s personal mailbox. Note: If the user has used the Outlook 2013 feature to change the folder that Sent Items are saved to, the messages will be copied to that folder instead of the user’s Sent Items folder. Users can reconfigure this by clicking the “Save Sent Items To” button on the Email Options tab. Administrators have control over this feature for either mails Sent As or Sent on Behalf of a shared mailbox. The table below summarizes where sent mails reside when members of a shared mailbox send mail from the shared mailbox. User Mailbox Shared Mailbox Sent Items Exchange 2010 Exchange 2010 Controlled through settings in KB2632409 Exchange 2010 Exchange 2013 (any version) Controlled through settings in KB2632409 Exchange 2013 CU9 (or newer) Office 365 Exchange 2010 The sent mail will be delivered to both the Inbox of the shared mailbox as an email attachment* and to the user mailbox' sent items Exchange 2013 CU9 (or newer) Office 365 Exchange 2013 CU9 (or newer) Office 365 The sent mail will be delivered to the Sent Items folder of shared mailbox and to the user mailbox' sent items *In a scenario where the user’s mailbox is on an Exchange 2013 CU9 server (or an Exchange 2013 without CU9 installed) and the shared mailbox is on an Exchange 2010 server, the shared mailbox will get an email message that looks like the following: This behavior will continue until the shared mailbox is moved to an Exchange 2013 CU9 server. Because this can happen even between Exchange 2013 servers (pre-CU9 and CU9), you might want to wait in turning the feature on for your on-premises deployment until you have completely rolled out Exchange 2013 CU9 to all of your servers. Who can use this feature? The feature is going to be available to all customers with shared mailboxes in Office 365 (phased rollout starting on 6/15/2015), as well as our on-premises customers (starting with Exchange 2013 CU9). Note: if after installation of Exchange 2013 CU9 in an on-premises environment you do not see the new CMDlet parameters, you should run /preparead explicitly with CU9 setup. How do I enable/disable this feature? In Office 365 and Exchange 2013 CU9, this feature is disabled by default. Enable the feature In Office 365, using the Admin portal, you can select your shared mailbox by going to Groups > Shared mailboxes first: Then Edit the Sent items copy status of the mailbox: Using PowerShell, for emails Sent As the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $True For emails Sent On Behalf of the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $True Disable the feature For messages Sent As the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSentAsEnabled $False For emails Sent On Behalf of the shared mailbox: set-mailbox <mailbox name> -MessageCopyForSendOnBehalfEnabled $False What else do I need to know? The administrator for your organization has to create the shared mailbox and add you to it as an user, before you can use it. If you are an Office 365 Small Business administrator, see Create and use shared mailboxes. If you are an administrator for a different version of Office 365 or an on-premises Exchange administrator, see the TechNet article Create a Shared Mailbox. If you are currently using a client registry key to duplicate messages sent from a shared mailbox to a sent items folder of the sender, you should remember to remove client registry keys if you enable this feature server side. If you do not remove client registry keys, you could see duplicate messages in Sent Items folders (one created by client registry keys and one by the server). If one of the transport rules prevents messages larger than certain size and the message being sent is over that size, then the message will not be delivered to the its original recipient and will also not be copied to the sent items of the shared mailbox. Philip LohCommon mailbox recovery scenarios for hybrid environments
Within the support organization at Microsoft we definitely see cases where customers are trying to recover deleted mailboxes. Typically, by the time a customer has contacted us they have tried everything they know as well as suggestions found online to recover the mailbox. It is often a completely avoidable and honest mistake that led to the deletion of the user’s Active Directory account in the first place. If you ever find yourself having a similarly bad day, then this article is meant to be your guide to not only getting through it, but to also come out of it as a superhero who is able to recover user accounts and mailboxes to a fully functional state without data loss. What you will learn from this article The main objective of this article is to help you recover a cloud mailbox after the corresponding on-premises user account has been deleted. If you do not have Directory Synchronization in place, then this article is not for you. With no Directory Synchronization in place you should view this article instead. Scenario that are covered There are many different mailbox recovery scenarios you may find yourself in. We will cover the most common scenarios throughout the course of this article to assist you in identifying the best recovery option for your own situation. Recover a mailbox that was deleted due to Directory Synchronization filtering changes resulting in filtering out the on-premises Active Directory user account associated with the cloud mailbox Recover a mailbox when the on-premises Active Directory user account associated with the cloud mailbox was accidentally or purposely deleted Recover a mailbox when the on-premises Active Directory user account associated with the cloud mailbox was accidentally or purposely deleted and the mailbox is on litigation hold All of the above scenarios have the same result. The associated user account in Office 365 becomes deleted due to one of the scenarios above and causes the mailbox to go into a soft-deleted state. Mailboxes in a soft-deleted state are recoverable for a period of 30 days before they are permanently removed from Office 365 and become unrecoverable. It is extremely important to attempt a proper user account recovery before blindly creating a new user account and merging the mailbox data. If you are able to restore the user account properly you will likely not lose any of the user data from the other services such as OneDrive and SharePoint. In addition, the user impact is pretty much non-existent when the original account is restored. There would be no need to create new profiles, no need to reset passwords, the user could simply log in and resume working from where they left off before. Recovery Process One of the challenges in restoring a mailbox is knowing which recovery option to use. If you know the recovery option you need, then can jump to it using the hyperlinks below. Otherwise we invite you to follow along with the article and we will guide you to the proper place. Restore a user account that was removed due to Directory Synchronization scope changes Restore a user account that was removed from on-premises AD with the recycle bin enabled Restore a user account that was removed from on-premises AD with no recycle bin enabled Restore a deleted user’s mailbox data to a new or alternate mailbox Restore an inactive user mailbox Restore a user that was removed due to Directory Synchronization Scope changes In some of the more complex customer environments it is sometimes beneficial to synchronize only certain Active Directory groups or Organizational Units (OUs) into Office 365. While this is not a common practice for most of our customers the process to configure filtering (if you are not familiar) is documented here. When configured, if a user is moved from an OU that is being synchronized to an OU that is not being synchronized, then Office 365 will see this action as a user account deletion. This causes the user account to be deleted within Office 365 and as a result the user’s mailbox also ends up in the previously mentioned soft-deleted state. The good news is the recovery for this scenario is quite simple. All you need to do is move the user back into the OU they were originally in. Assuming that the OU the user was previously in is still being synchronized, the next time Directory Synchronization complete the user and all associated data will be restored. By default, directory synchronizations occur every three hours and after you move the user back to the proper OU you will have to wait for the next sync cycle to take place. However, if you are like me and cannot wait, then you can force the synchronization. This article contains the necessary information to force a synchronization to take place immediately. Restore a user account that was removed from on-premises AD with the recycle bin enabled This scenario is a bit more common than the previous one. Many of our customers have realized the benefits that come with having the Active Directory recycle bin enabled. If you are not familiar with this feature and you are interested in learning more, then you can check it out here. The Active Directory recycle bin works as it sounds, when an object is deleted you can essentially undo the deletion without the kind of complex AD authoritative restoration process we all used and loved in the past. The good news is if you have the Active Directory recycle bin feature, it is a valid option to recover the deleted user. However, if you deleted the user prior to enabling this feature in your environment, then it will be of no help. Recovery steps: Follow this guidance to restore the user account using LDP or PowerShell Note: While less common, if you are using Directory Synchronization filtering (explained here), you need to be sure you restore the user to an OU that is within the Directory Synchronization scope. In an environment where more than one domain controller exists, ensure that the restored object has replicated before you proceed. Wait until your next Directory Synchronization cycle has complete or follow this article to force an immediate synchronization if you are using AAD Connect It is that easy and you will end up with the mailbox and all of the rest of the user data intact. Restore a user account that was removed from on-premises AD with no recycle bin enabled If you made it this far in the document, you likely are thinking “darn it I should have enabled the recycle bin for Active Directory”. While I agree with that sentiment, all is not lost. You can still recover your user account and mailbox data. In addition, you can still recover the data associated with other services, you just have a more difficult process to follow. The reason we try so har d to restore the original user account is so all of the data associated with the user is also restored. If you were to recreate a new user account on-premises (even with the same name as the deleted user), when the user syncs to Office 365 it will have a new object GUID. This means that any SharePoint, OneDrive, Exchange, and any other data or permissions associated with the user will be lost. The last good way to restore a user and all of their associated data may seem a bit backward, but it works and the user will back up and running with their data in no time. Before continuing make sure Directory Synchronization is up to date. You can force a sync with AAD Connect rather than waiting for the normal sync window to complete its next cycle. In the Office 365 portal (http://portal.office.com), expand the Users pane on the left. Then select the Deleted Users container and identify the user you would like to have restored. Select the object and hit restore on the right hand side of the screen (see image 1). This will restore the cloud user and the associated mailbox, SharePoint, and other service data. Image 1: Restoring a deleted office 365 user Ensure that the restored user has a license assigned. For details on how to license a user go here. Return to Users pane on the left once again. Then from the Active Users container, find the restored cloud user. Double-click the user to view the properties and change the UserPrincipalName namespace to the contoso.onmicrosoft.com address of your tenant and then save the changes (see image 2). Image 2: Modifying the UPN namespace Using the Azure AD PowerShell module, clear the immutableID of the restored Msoluser object by running the cmdlet below. We need to clear the immutableID to allow for a softmatch as the restored Msoluser has the immutableID of the deleted AD user. Set-Msoluser -UserPrincipalName user@contoso.onmicrosoft.com -ImmutableID “ “ For details on how to install and connect to the Azure AD PowerShell, go here. Next, create a new remote mailbox from either the Exchange Admin Center or Exchange Management Console on-premises (see images 3 and 4). It is important to ensure the SMTP address of the new remote mailbox is the same as the SMTP address of the user account that was restored. Meaning if the SMTP address of the user you are restoring is Ted@contoso.com, then the new remote mailbox you should create on-premises should have the same SMTP address. Following this step accurately will ensure a process called soft matching is performed. Soft matching links the new on-premises user account that was created behind the scenes as part of creating a new remote mailbox to the restored cloud mailbox based on the SMTP address. Image 3: Creating a new remote mailbox in Exchange 2013 Admin Center Image 4: Creating a new remote mailbox in Exchange 2010 Management Console Again, force a Directory Synchronization. To do that force a sync with AAD Connect. Then back in the portal expand the Users pane on the left again. Then from the Active Users container, find the restored cloud user and double-click on the user to view the properties. Check the UPN to see if it is the same as the newly created on-premises user. Restore a deleted user’s mailbox data to a new or alternate mailbox If none of the above recovery options are able to work for your situation, then you can still recover the mailbox data. While this process works and is a great way to recover mailbox data that would otherwise be lost, you still lose data associated with other services such and OneDrive and SharePoint. I would treat option as a last resort after all other options have failed. The steps outlined in this article will take you through a recovery process that involves creating a new user on-premises, synchronizing that user to Office 365, and merging the data from the soft deleted mailbox. Restore an inactive user mailbox The last scenario we are covering is the inactive mailbox scenario. For those that may not know, an Inactive Mailbox is a mailbox associate with a user that was placed on Litigation Hold then deleted. In order to preserve the data and keep it searchable we retain the mailbox contents and allow you to reuse the license that was previously assigned to the deleted user. More information on Inactive Mailboxes can be found here. If you accidentally deleted a user that was on Litigation Hold and you needed to restore the user, you can follow the steps below. Connect to the exchange online PowerShell using your tenant admin credentials, for details go here. Run the cmdlet: Get-Mailbox "<UPN of inactive mailbox>" -InactiveMailboxOnly | Select Name, DisplayName, MicrosoftOnlineServicesID, ExchangeGuid Run the cmdlet: New-Mailbox -Name "<Name from Step 2>" -InactiveMailbox " <ExchangeGuid from Step 2>" -MicrosoftOnlineServicesID "<MicrosoftOnlineServicesID from Step 2>" -Password (ConvertTo-SecureString -String 'Pa##w0rd goes here' -AsPlainText -Force) After the cmdlet in Step 3 completes successfully, wait at least 5 minutes for replication between the exchange online forest and the Azure AD forest. Once the Azure AD object for the new mailbox is visible, apply an exchange online license. Then create a new remote mailbox from either Exchange Admin Center or Exchange Management Console on-premises (see image 5 and 6). It is important to make sure that the SMTP address of the new remote mailbox is the same as the SMTP address of the user that was restored. Meaning if the SMTP address of the user you are restoring is Ted@contoso.com, then the new remote mailbox you should create on-premises should have the same SMTP address. This will ensure that we do a process called soft matching that links the on-premises user that was just created to the restored cloud mailbox based on the SMTP address. Image 5: Creating a new remote mailbox in Exchange 2013 Admin Center Image 6: Creating a new remote mailbox in Exchange 2010 Management Console Again, force a Directory Synchronization, to do that just force a sync with AAD Connect. Then back in the portal expand the Users pane on the left again. Then from the Active Users container, find the restored cloud user and double-click on the user to view the properties. Check the UPN to see if it is the same as the newly created on-premises user. In Summary It is best to set yourself and your organization up for the easiest possible mailbox and user recovery scenarios. When possible, try to do things like enabling the Active Directory Recycle Bin and educate all of your IT staff on the ramification of deleting users. Also know that in the end there are a lot of ways to recover a user and the associated data, make sure you use the option that fits your needs. I wanted to thank Timothy Heeney for a lot of help and discussion during the creation of this article. Bio AwojobiExchange 2013/2016 Monitoring Mailboxes
Note 10/2022: This article also applies to Exchange Server 2019. Introduction Exchange Server 2013 introduced a new feature called Managed Availability, which is a built-in monitoring system with self-recovery capabilities. Managed Availability performs continuous tests (probes) that simulate end-user actions, to detect possible problems with Exchange components or their dependencies. If probes are failing, it performs gradual simple recovery actions to bring the affected component in healthy state. It uses special type of mailboxes, called Monitoring Mailboxes or health mailboxes, to simulate end-user kinds of tests. The life cycle of monitoring mailboxes is taken care entirely by Managed Availability components. In this post, we’ll see how Managed Availability takes care of monitoring mailboxes, what best practices to keep monitoring mailboxes happy are and some related troubleshooting. Monitoring Mailboxes Functioning of Managed Availability is implemented by Microsoft Exchange Health Manager Service running on each Exchange Server 2013 role. The Microsoft Exchange Health Manager Service is responsible for creating and maintaining monitoring mailboxes Let’s take a look at how the Health Manager creates them! How do we create monitoring mailboxes? The MS Exchange Health Manager Service runs in two processes, MSExchangeHMHost.exe and MSExchangeHMWorker.exe (let’s call it the HM worker). HM worker process, at the time of startup, checks for availability of monitoring mailboxes and creates monitoring mailboxes as needed. Starting with Exchange Server 2013 Cumulative Update 1, accounts for monitoring mailboxes are created under following container in the domain Exchange server resides: <ADdomain>\Microsoft Exchange System Objects\Monitoring Mailboxes Example: The logic HM worker process uses to detect and create monitoring mailboxes depends on Exchange Cumulative Update (CU) installed, Exchange role installed on the box and mailbox databases present. The Following logic was used to create monitoring mailboxes for Exchange Server 2013 servers between RTM to Cumulative Update 5: One monitoring mailbox per mailbox database copy, plus one for all of CAS servers. Here’s an example of monitoring mailboxes created on Exchange Server 2013 SP1 server that hosts both CAS and mailbox role: [PS] C:\>Get-Mailbox -Monitoring | ft displayname,whencreated DisplayName WhenCreated ----------- ----------- HealthMailboxb285a119be6649b3a89574f078e947f5 11/10/2014 9:07:29 AM HealthMailbox60d8a8d1285e41bfa5ce1ef1fb93d14e 11/10/2014 9:07:36 AM The display name of the monitoring mailbox created for database copy contained the GUID of the mailbox database for which it was created. Example: The display name of the monitoring mailbox created for CAS server contained the GUID of the Exchange server for which it was created. Example: The following logic is used to create monitoring mailbox for Exchange Server 2013 Cumulative Update 6 and onwards: One monitoring mailbox for each mailbox database copy hosted on mailbox role, plus ten monitoring mailboxes for each CAS server. The following naming convention is used for the display name of the monitoring mailbox created for a database: “HealthMailbox-“ + host name of server + “-“ + database name. At the startup, the HM worker checks for name of databases present on the server and then checks for presence of monitoring mailboxes with display name as explained above. If it doesn’t find a monitoring mailbox for a specific database, it creates a new monitoring mailbox. That means, if you rename DB1 to DB2, HM worker will create new monitoring mailbox for DB2 on next startup. And the following naming convention is used for display name of the monitoring mailbox created for a CAS server: “HealthMailbox-“ + host name of the CAS server + “-001” through “010.” We attempt to distribute the monitoring mailboxes created for CAS servers across the mailbox databases available. Let’s make this real: Imagine that you have only one Exchange server running Exchange 2013 CU6 or newer in the org (server is named EXCH1) that hosts both CAS and Mailbox role and has only one mailbox database, 11 monitoring mailboxes will be created. Example: The Health Manager Service will create more mailboxes according to the logic explained above as you go on adding more databases or server roles. Password resets HM Worker is responsible for maintaining the password for Monitoring mailboxes. HM worker uses a complex algorithm to generate password to be used for monitoring mailbox. The password for monitoring mailbox is reset under the following conditions: A new health mailbox is being created Each time HM Worker process starts and is not able to retrieve the existing password for the monitoring mailbox Any other scenario where HM Worker is not able to get hold of existing password for the monitoring mailbox Best practices Here are some best practices regarding management of user accounts associated with monitoring mailboxes as well as mailboxes themselves: Do not apply third party customized password policies to user accounts of monitoring mailboxes Exclude monitoring mailboxes from user account lockout policies Do not move the user accounts out from the Monitoring Mailboxes container Do not change the user account properties, like restricting password change etc. Do not change AD permission inheritance Since HM worker handles password resets for monitoring mailboxes, in a large environment, it is normal to see increased password reset traffic for monitoring mailbox accounts; note that doing one of the things above might increase the frequency of those resets Do not move the monitoring mailboxes between mailbox databases Do not apply mailbox quotas to monitoring mailboxes If applying a retention policy, ensure the data within the monitoring mailbox is retained for a minimum of 30 days before being deleted If you see a mailbox size increasing significantly for specific monitoring mailbox; you can simply disable the specific mailbox. The HM worker will create a new mailbox at next startup. Common tasks with monitoring mailboxes How to list monitoring mailboxes The Get-Mailbox command is provided with special parameter “-Monitoring” to list only the monitoring mailboxes. Here are some examples: To list all monitoring mailboxes present in the organization: Get-Mailbox –Monitoring To list monitoring mailboxes present on a database: Get-Mailbox –Monitoring -Database <database name> However, the mailboxes listed above may not be associated with the server on which database is hosted. As explained in creation logic, the name of Client Access Server or the mailbox database is important in searching for monitoring mailbox associated and in creation of monitoring mailbox. Use the following command to list the monitoring mailboxes associated with a specific server: Get-Mailbox -Monitoring | ?{$_.DisplayName -like "*-<servername>-*"} Example: Get-Mailbox -Monitoring | ?{$_.DisplayName -like "*-exch2-*"} | ft name,displayname,database Use the following command to list the monitoring mailbox associated with a specific database: Get-Mailbox -Monitoring | ?{$_.DisplayName -like "*-<name of database>"} Example: Get-Mailbox -Monitoring | ?{$_.DisplayName -like "*-db2exch2"} | ft name,displayname,database,servername Troubleshooting tips Here are some troubleshooting methods for monitoring mailboxes. How to re-create monitoring mailboxes (NOT considered regular maintenance!) The mailbox database removal doesn’t cleanup the AD user account associated with monitoring mailboxes. This can then result in orphaned AD user accounts. This happens because of deny permission inherited on Monitoring Mailboxes container. KB article 3046530has details on this, as well as the workaround to resolve it. If there are too many orphaned monitoring mailbox accounts, you may want to re-create them. Steps: 1) Make sure “Monitoring Mailboxes” container is present Open Active Directory Users & Computers Click on View and select “Advanced Features” The Browse to Microsoft Exchange System Objects Verify the presence of the “Monitoring Mailboxes” container. Example: If the Monitoring Mailboxes container is missing: Make sure you have Exchange Server 2013 CU1 or above installed. Perform PrepareAD with the Exchange Server 2013 version installed. 2) Stop the “Microsoft Exchange Server Health Manager” service on all Exchange Server 2013 servers. 3) Open Exchange Management Shell and use following command to disable existing health mailboxes: Get-Mailbox -Monitoring | Disable-Mailbox 4) Go back to Active Directory users & computers, right click on domain and search for “HealthMailbox” 5) Delete the health mailbox user accounts. 6) Wait for AD replication or force AD replication. 7) Start the “Microsoft Exchange Server Health Manager” on all Exchange Server 2013 servers. Bhalchandra Atre Updates 6/2/15: Updated best practices to include information on aging out data via retention policies.Ask The Perf Guy: What’s The Story With Hyperthreading and Virtualization?
There’s been a fair amount of confusion amongst customers and partners lately about the right way to think about hyperthreading when virtualizing Exchange. Hopefully I can clear up that confusion very quickly. We’ve had relatively strong guidance in recent versions of Exchange that hyperthreading should be disabled. This guidance is specific to physical server deployments, not virtualized deployments. The reasoning for strongly recommending that hyperthreading be disabled on physical deployments can really be summarized in 2 different points: The increase in logical processor count at the OS level due to enabling hyperthreading results in increased memory consumption (due to various algorithms that allocate memory heaps based on core count), and in some cases also results in increased CPU consumption or other scalability issues due to high thread counts and lock contention. The increased CPU throughput associated with hyperthreading is non-deterministic and difficult to measure, leading to capacity planning challenges. The first point is really the largest concern, and in a virtual deployment, it is a non-issue with regard to configuration of hyperthreading. The guest VMs do not see the logical processors presented to the host, so they see no difference in processor count when hyperthreading is turned on or off. Where this concern can become an issue for guest VMs is in the number of virtual CPUs presented to the VM. Don’t allocate more virtual CPUs to your Exchange server VMs that are necessary based on sizing calculations. If you allocate extra virtual CPUs, you can run into the same class of issues associated with hyperthreading on physical deployments. In summary: If you have a physical deployment, turn off hyperthreading. If you have a virtual deployment, you can enable hyperthreading (best to follow the recommendation of your hypervisor vendor), and: Don’t allocate extra virtual CPUs to Exchange server guest VMs. Don’t use the extra logical CPUs exposed to the host for sizing/capacity calculations (see the hyperthreading guidance at https://aka.ms/e2013sizing for further details on this). Jeff Mealiffe Principal PM Manager Office 365 Customer ExperienceDude, Where's My Single Instance?
In Exchange Server 2010, there is no more single instance storage (SIS). To help understand why SIS is gone, let's review a brief history of Exchange. During the development of Exchange 4.0, we had two primary goals in mind, and SIS was borne out of these goals: Ensure that messages were delivered as fast and as efficient as possible. Reduce the amount of disk space required to store messages, as disk capacity was premium. Exchange 4.0 (and, to a certain extent, Exchange 5.0 and Exchange 5.5) was really designed as a departmental solution. Back then, users were typically placed on an Exchange server based on their organization structure (often, the entire company was on the same server). Since there was only one mailbox database, we maximized our use of SIS for both message delivery (only store the body and attachments once) and space efficiency. The only time we created another copy within the store was when the user modified their individual instance. For almost 19 years, the internal Exchange database table structure has remained relatively the same: Then came Exchange 2000. In Exchange 2000, we evolved considerably - we moved to SMTP for server-to-server connectivity, we added storage groups, and we increased the maximum number of databases per server. The result was a shift away from a departmental usage of Exchange to enterprise usage of Exchange. Moreover, the move to 20 databases reduced SIS effects on space efficiency, as the likelihood that multiple recipients were on the same database decreased. Similarly, message delivery was improved by our optimizations in transport, so transport no longer benefited as much from SIS either. With Exchange 2003, consolidation of servers took off in earnest due to features like Cached Exchange Mode. Again the move away from departmental usage continued. Many customers moved away from distributing mailboxes based on their organization structure to randomization of the user population across all databases in the organization. Once again, the space efficiency effects of SIS were further reduced. In Exchange 2007, we increased the number of databases you could deploy, which again reduced the space efficiency of SIS. We further optimized transport delivery and completely removed the need for SIS from a transport perspective. Finally, we made changes to the information store that removed the ability to single instance message bodies (but allowed single instancing of attachments). The result was that SIS no longer provided any real space savings - typically only about 0-20%. One of our main goals for Exchange 2010 was to provide very large mailboxes at a low cost. Disk capacity is no longer a premium; disk space is very inexpensive and IT shops can take advantage of larger, cheaper disks to reduce their overall cost. In order to leverage those larger capacity disks, you also need to increase mailbox sizes (and remove PSTs and leverage the personal archive and records management capabilities) so that you can ensure that you are designing your storage to be both IO efficient and capacity efficient. During the development of Exchange 2010, we realized that having a table structure optimized for SIS was holding us back from making the storage innovations that were necessary to achieve our goals. In order to improve the store and ESE, to change our IO profile (from many, small, random IOs to larger, fewer, more sequential IOs), and to resolve our inefficiencies around item count, we had to change the store schema. Specifically, we moved away from a per-database table structure to a per-mailbox table structure: This architecture, along with other changes to the ESE and store engines (lazy view updates, space hints, page size increase, b+ tree defrag, etc.), netted us not only a 70% reduction in IO over Exchange 2007, but also substantially increased our ability to store more items in critical path folders. As a result of the new architecture and the other changes to the store and ESE, we had to deal with an unintended side effect. While these changes greatly improved our IO efficiency, they made our space efficiency worse. In fact, on average they increased the size of the Exchange database by about 20% over Exchange 2007. To overcome this bloating effect, we implemented a targeted compression mechanism (using either 7-bit or XPRESS, which is the Microsoft implementation of the LZ77 algorithm) that specifically compresses message headers and bodies that are either text or HTML-based (attachments are not compressed as typically they exist in their most compressed state already). The result of this work is that we see database sizes on par with Exchange 2007. The below graph shows a comparison of database sizes for Exchange 2007 and Exchange 2010 with different types of message data: As you can see, Exchange 2007 databases that contained 100% Rich Text Format (RTF) content was our baseline goal when implementing database compression in Exchange 2010. What we found is that with a mix of messaging data (77% HTML, 15% RTF, 8% Text, with an average message size of 50KB) that our compression algorithms are on par with Exchange 2007 database sizes. In other words, we mitigated most of the bloat caused by the lack of SIS. Is compression the answer to replacing single instancing all together? The answer to that question is that it really does depend. There are certain scenarios where SIS may be viable: Environments that only send Rich-Text Format messages. The compression algorithms in Exchange 2010 do not compress RTF message blobs because they already exist in their most compressible form. Sending large attachments to many users. For example, sending a large (30 MB+) attachment to 20 users. Even if there were only 5 recipients out of the 20 on the same database, in Exchange 2003 that meant the 30MB attachment was stored once instead of 5 times on that database. In Exchange 2010, that attachment is stored 5 times (150 MB for that database) and isn't compressed. But depending on your storage architecture, the capacity to handle this should be there. Also, your email retention requirements will help here, by forcing the removal of the data after a certain period of time. Business or organizational archives that are used to maintain immutable copies of messaging data benefit from single instancing because the system only has to keep one copy of the data, which is useful when you need to maintain that data indefinitely for compliance purposes. If you go back through our guidance over the past 10 years, you will never find a single reference to using SIS around capacity planning. We might mention it has an impact in terms of the database size, but that's it. All of our guidance has always dictated designing the storage without SIS in mind. And for those that are thinking about thin provisioning, SIS isn't a reason to do thin provisioning, nor is SIS a means to calculate your space requirements. Thin provisioning requires an operational maturity that can react quickly to changes in the messaging environment , as well as, a deep understanding of the how the user population behaves and grows over time to sufficiently allocate the right amount of storage upfront. In summary, Exchange 2010 changes the messaging landscape. The architectural changes we have implemented enable the commoditization of email - providing very large mailboxes at a low cost. Disk capacity is no longer a premium. Disk space is cheap and IT shops can take advantage of larger, cheaper disks to reduce their overall cost. With Exchange 2010 you can deploy a highly available system with a degree of storage efficiency without SIS at a fraction of the cost that was required with previous versions of Exchange. So, there you have it. SIS is gone. - Ross Smith IVOutlook clients receive error 0x8004010f when downloading the Offline Address Book
EDIT 10/01/2008: To read the updated (and more comprehensive) guidance for troubleshooting errors 0x8004010f, please go here. There are a multiple reasons for why an Outlook client can receive the 0x8004010f sync error. Unfortunately, 0x8004010f is just a generic MAPI error and will show up for a variety of problems. Here is what the error looks like under err.exe (Microsoft Exchange Server Error Code Look-up Tool): C:\WXP\system32>err 0x8004010f # for hex 0x8004010f / decimal -2147221233 ecNotFound ec.h ecAttachNotFound ec.h ecUnknownRecip ec.h ecPropNotExistent ec.h MAPI_E_NOT_FOUND mapicode.h # 5 matches found for "0x8004010f" This is what the error looks like from the sync log from within Outlook: 12:45:53 Synchronizing Mailbox <dgoldman> 12:45:53 Done 12:45:54 Microsoft Exchange offline address book 12:45:54 0x8004010f Some of the most common reasons for Outlook clients to receive the 0x8004010f error with regards to downloading the OAB are listed below. Most of these are documented and I have linked articles to each of these to help everybody out. Please note that these solutions can change a small bit depending on unknown factors in a company's environment. An administrator decommissioned the last Exchange server in a site and never pushes replicas to another Exchange server. A new OAB is created in the active directory and the information store never reads the active directory during its maintenance schedule. This will result in the OAB files never being generated and the Outlook client will fail to download anything. The information store has an invalid EntryID that points to the legacy EX:/ folders. Again there is nothing for the client to download. An outlook client logging in from one domain to another domain and attempting to log in to another users mailbox. The OAB was never generated or some OAB folders are missing from the public folder store. Multiple OAB Version folders exist of the same type. Clients are attempting to download the OAB files from a public folder store that have not received the replicated updates. The offline address book list object has a missing address list. The offline address book list object has an incorrect address list. Send/As changes in the store affect users accounts with no mailbox full rights to another mailbox. If you are seeing this error on an Exchange 2007 server and your OAB is generated by an Exchange 2007 server, please make sure of the following: 1. Make sure that you have added the replicas of OAB to the Exchange 2007 server 2. Make sure public folder replication is working. 3. Make sure the OAB is public folder enabled and you have OAB Version 2, OAB Version 3 and OAB Version 4 checked off so your legacy clients can download the OAB files from the public folder store. 4. Make sure that if you are using an Outlook 2007 client, your OAB is Web Distribution enabled and the OAB files have been replicated over to the Client Access Server. For more information on this process please see this blog: http://blogs.msdn.com/dgoldman/archive/2006/10/23/outlook-client-fails-to-download-the-oab-with-error-0x8004011b.aspx and http://blogs.msdn.com/dgoldman/archive/2006/08/25/How-Exchange-2007-OAB-Files-are-replicated-to-a-Client-Access-Server-for-download.aspx 5. If you are removing your last Exchange 2003 server from the org, please make sure that you follow our documentation on this process. - Dave Goldman
Graph API access to Exchange Server 2019 hybrid setup (on prem mailbox)
I read within the Microsoft docs (https://docs.microsoft.com/en-us/graph/hybrid-rest-support) that it should be possible to access basic resources like calendar or mail via the Graph API. Behind the scenes, when Microsoft Graph identifies that a REST API call is attempting to access an on-premises mailbox in a hybrid deployment, it proxies the REST request to an on-premises REST endpoint which then processes the request. This discovery makes accessing the REST API possible. We are using a hybrid setup with Exchange Server 2019 and on Prem mailboxes, but unfortunately I'm not able to access any data from there via Graph API.
