eDiscovery is a powerful feature available in Microsoft Exchange. It’s used by eDiscovery Managers for performing discovery searches across all mailboxes in the organization and is very important for the purpose of the Compliance and Legal issues.
By default, the Discovery Management role group is created when the first Microsoft Exchange Server is installed. As most of us know, this role group is responsible for allowing access to administrators to perform eDiscovery searches, and because it’s a Default role group, we can’t restrict the scope of the role group to specific mailboxes. Members of this role group can search all mailboxes across the organization.
So, what do you do when you get a request to restrict the eDiscovery search to a specific subset of mailboxes based on company or department? Is it even possible?
The answer to this is yes! We can utilize the power of Role Based Access Control (RBAC) to limit the search to a subset of mailboxes.
Note: The only RecipientRestrictionFilter in Microsoft Exchange Server 2013 and Exchange Online that is supported for a custom eDiscovery scope is the memberofGroup property for user mailboxes.
This blog post discusses such a scenario where the search is restricted to a specific department. For this to be supported in Microsoft Exchange 2013, we need to follow a common set of rules when creating custom scopes for eDiscovery.
John works for a company named TailSpin Toys. John has been given a new task within the company. John will be working as eDiscovery Manager within the company and will perform eDiscovery searches for a specific set of mailboxes that reside in the Accounting department. The Microsoft Exchange administrator will need to assign necessary permissions to John BUT will have to ensure John can’t perform eDiscovery searches on mailboxes in any department other than Accounting. In this scenario, we will restrict the scope of the search to a specific department named Accounting.
To implement this scenario we will walk through the following steps.
As per the scenario, the Exchange administrator creates Distribution Group named eDiscovery Accounting Users by running the following command.
New-DistributionGroup -Name "eDiscovery Accounting Users" -Alias "ediscoveryaccounting" -MemberJoinRestriction closed -MemberDepartRestriction closed -ModerationEnabled $true
The administrator then adds the required set of user mailboxes to the new group.
To list all user mailboxes that are part of the Accounting department, the Exchange administrator runs the following command.
Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'Department -eq "Accounting"'
The previous command can be used to create a variable that can be used with the Add-DistributionGroupMember cmdlet to add a group of users to a distribution group.
$members = Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize unlimited -Filter 'Department -eq "Accounting"'
The previous command creates a variable that contains all user mailboxes that have the value Accounting for the Department property in their user account. The following command will add the users to the Accounting distribution group.
$members | ForEach {Add-DistributionGroupMember "eDiscovery Accounting Users" -Member $_.Name}
Points to remember:
Custom scopes are needed when neither the implicit write scope nor the predefined relative scopes meet the needs of your business. Custom scopes enable you to define, at a granular level, the scope to which your management role will be applied.
For more information regarding the Custom scopes, please see Understanding management role scopes.
After the user mailboxes are added to the distribution group eDiscovery Accounting Users, the next step is to create a Custom Management Scope.
Create a custom management scope
Run the following command to save the properties of the eDiscovery Accounting Users group to a variable, which is used in the next command.
$DG = Get-DistributionGroup -Identity "eDiscovery Accounting Users"
The next step is to create a Custom scope where the RecipientRestrictionFilter is set to the distribution group created in Step1. After the Scope is created, it will be assigned to the Role Group that is created in a later step.
New-ManagementScope "Accounting Users eDiscovery Scope" -RecipientRestrictionFilter "MemberOfGroup -eq '$($DG.DistinguishedName)'"
After the Management Scope is created, you can verify the RecipientFilter by running the following command. This recipient filter will be used to define the scope of the eDiscovery search operation.
Note:
In this step, you will create a new management role group and assign it to the custom management scope named "Accounting Users eDiscovery Scope" that was created in previous step. To do this run the following command.
New-RoleGroup "Accounting Users eDiscovery Managers" -Roles "Mailbox Search","Legal Hold" -CustomRecipientWriteScope "Accounting Users eDiscovery Scope" -Members "John@tailspintoys.com"
The new role group will be created under Microsoft Exchange Security Groups container and will have the "Mailbox Search" and "Legal Hold" roles associated with it. The eDiscovery search scope will be restricted to the members of the eDiscovery Accounting Users distribution group, which is the RecipientFilter for the scope. John is added as member of the role group and will have the permissions to perform required administrative tasks.
If you want to add additional members to the role group, you can run the following command.
Add-RoleGroupMember "Accounting Users eDiscovery Managers" -Member "Jane@tailspintoys.com"
Note: It's important not to add unmonitored or unauthorized users to the Discovery Management role group as they will get access to discovery mailboxes, and they can search mailboxes across the entire organization.
To check the RoleAssignments associated with the "Accounting Users eDiscovery Managers" run the following command.
Get-RoleGroup "Accounting Users eDiscovery Managers" | FL
Run the following command to view the CustomRecipientWriteScope and the RecipientReadScope associated with the role.
Get-ManagementRoleAssignment "Mailbox Search-Accounting Users eDiscovery Managers" | FL
The previous command shows the roles being assigned to the “Accounting Users eDiscovery Managers” role group and also tells us that the RoleGroupType is set to Standard and the RecipientReadScope is set to Organization, which means all mailboxes across the Organization will be only visible to all the eDiscovery Managers. The Search will fail for mailboxes searched outside the scope when accessed by users who belong to Accounting Users eDiscovery Managers who belong to specific role group and have CustomRecipientWriteScope defined for certain subset of mailboxes.
Note: By default, all the mailboxes will be visible to eDiscovery Managers and the parameter RecipientReadScope cannot be overridden to restrict the same.
To create a discovery mailbox to store the search results of eDiscovery searches of mailboxes in the Accounting department, run the following command.
New-Mailbox –Name "Discovery mailbox-Accounting" –UserPrincipalName "eDSaccounting@tailspintoys.com" –Discovery
Note:
Add-DistributionGroupMember -Identity "eDiscovery Accounting Users" -Member "Discovery mailbox-Accounting"
The next step is to assign John the FullAccess permission to the discovery mailbox so he can open the discovery mailbox and view search results.
Add-MailboxPermission –Identity "Discovery mailbox-Accounting" –User "Tailspintoys\John" –AccessRights "FullAccess"
After the permissions have replicated, John can access the discovery mailbox.
Points to remember
For more information check below:
At this point, John performs a discovery search, choosing some of the mailboxes from Accounting and an appropriate date range and is able to get expected results. For more information on how to do a discovery search, please go here
Create an In-Place eDiscovery search
If John tries to perform a search on mailboxes outside the custom scope, the search will return the error shown below. This happens because the RecipientRestrictionFilter applied to the scope and in turn applied to the role group will check the MemberOfGroup property. When it finds the MemberOfGroup value of the user mailbox doesn’t match distinguished name of the eDiscovery Accounting Users distribution group, it confirms the user mailbox isn’t within the custom scope.
Even though you grant Mailbox Search role explicitly to the Role Group you won’t be able to search mailboxes outside the scope
By default the Administrator audit logging is enabled in the new installations of Microsoft Exchange 2013 and will capture the all the Cmdlets run directly in the Exchange Management Shell are audited. In addition, operations performed using the EAC are also logged because those operations run Cmdlets in the background. This will also include the eDiscovery Cmdlets run in the environment. The administrator needs to be member of Discovery Management Group in order to have access to MailboxSearch Cmdlets.
The Organization Management role group doesn't, by default, enable the discovery search feature for users or universal security groups (USGs) that are members of that role group. Members of the Organization Management role group must either be made members of this role group, or the Mailbox Search role listed later in this topic must be manually assigned to the Organization Management role group.
The audit log reports can be exported by the administrator using the EAC to track changes in your organization. Also, the administrator can run the In-Place eDiscovery & Hold report for specific date to check for the searches performed on that specific day. It will provide report for any modifications done to the search.
The administrator audit log will keep track of Cmdlets run in the environment and this way, any unauthorized access can be tracked down.
For more information check below links:
The scenario discussed in this blog post is always an available option for restricting the eDiscovery searches based on department or company. The only requirement is to use a distribution group for the subset of mailboxes on for you want to restrict eDiscovery. The only property on a user mailbox that you can use to create a recipient filter for a custom scope is distribution group membership (the actual property name is MemberOfGroup). If you use other properties, such as CustomAttribute, Department, or PostalCode, the search method will be considered unsupported.
Reference: http://ift.tt/1BtAFB1
So if you want to do a search for mailboxes across departments or separate companies you will have to manually add the users to the distribution group or use PowerShell to add users in bulk to a specific distribution group based on department or company.
Note:
In the above blog I have tried to discuss and walk you through the options related to the restricting the eDiscovery to discovery managers as per the business needs using Role Bases Access Control
I would like to thank Mark Johnson, Bharat Suneja, Nino Bilic, Jennifer Gagnon & Quentin Christensen for their help in validating the method described in the blog post!
Special Thanks to Ben Winzenz, Chris Pollitt, Matthew Byrd, Charlotte Raymundo for their contributions while this blog post was being written.
It’s been a while since we talked about VSSTester scipt!
Murali, who maintained the script before, asked me to take over it’s maintenance and thus I’m releasing this updated version. This script update is long overdue but better late than never! As before, you can grab a copy of the script from here.
What’s changed in v1.1:
For the nitty-gritty details on the script, please refer to the original blog post which announced it. The operation of the script is the same and should be fairly self-explanatory.
Here’s a screenshot preview of how the script starts now:
I hope this script helps you troubleshoot your database backups. Please give feedback in the comments or by emailing me directly (my email is in the script).
Best,
Exchange Server 2013 Cumulative Update 8 (CU8) and Exchange Server 2010 SP3 Rollup Update 9 (RU9) introduced a new feature to provide a more seamless experience for ActiveSync-enabled users who move from on-premises Exchange servers to Office 365.
This blog post explains the current situation with on-boarding Exchange ActiveSync (EAS) users as well as the new functionality offered.
Today, when a user's mailbox moved from Exchange on-premises to Exchange Online (Office 365), Outlook and Outlook Web App (OWA) have a seamless method to redirect the user to the new mailbox location. Outlook uses Autodiscover to redirect the user, and OWA provides a link to Office 365 login.
But what about ActiveSync-enabled devices? Before the above updates are installed, after the mailbox is moved, the user’s mail stops syncing on their EAS device because the device can no longer find the current location of the mailbox. The user has to manually re-configure the device with the new URL, or delete and recreate the email account on the device.
The reason for this behavior is that when a mailbox is moved from on-premises to Office 365, the device tries to connect to the user’s mailbox’s last location before the migration, which is the on-premises server. On-premises Client Access servers did not redirect devices to new mailboxes. If the user’s mailbox was not found in the source forest, the Client Access server would return an error message.
In short, this is the pre-update mail synchronization flow for an EAS device after a mailbox is moved from on-premises to Office 365:
A solution has been built (and shipped in above mentioned updates) to make sure mailbox moves from on-premises to Office 365 are seamless for EAS users, as well. Once the updates are installed on your on-premises servers and a mailbox is moved to Office 365, an EAS device should be able to find the new location of the mailbox and sync without any user impact or intervention.
Let’s take a detailed look at how the solution works:
Before the move, the EAS device configuration will show it is configured to sync with on-premises URL:
The flow after the mailbox is moved to Office 365:
From this point forward, the device will continue to sync with Office 365.
To make this work, certain prerequisites are required:
Let’s take a look at what is supported and unsupported scenarios with respect to this solution.
Note: The implementation of HTTP 451 depends on each device manufacturer. The end user experience may vary based device functionality. Contact your device manufacturer to confirm if your device supports an HTTP 451 response.
For all unsupported scenarios, users will get the same experience as without the solution, as described earlier.
The feature depends on the presence of a “TargetOwaURL” configured on the OrganizationRelationship. The Hybrid Configuration Wizard (HCW) creates and configures the OrganizaitonRelationship object and the TargetOWAURL, as well.
Here’s an example of Organization Relationship and TargetOWAURL:
You can re-run the Hybrid Configuration Wizard (HCW), if the Organization Relationship or TargetOWAURL are missing.
The solution should work as expected. However, if you are experiencing problems, here are some troubleshooting tips:
Examples:
IIS Log entries
Here’s an example of an error entry from the IIS logs of an Exchange Server 2010 SP3 RU8 CAS showing the error returned to the device:
1/26/2015 23:07:39 192.168.1.53 POST /Microsoft-Server-ActiveSync/Proxy/default.eas Cmd=Sync&DeviceId=AC94832BCFD9DCD19D299AD36D2CA8C5&DeviceType=WP8&Log=PrxFrom:192.168.1.63_V141_HH:
mail.batre.msftonlinerepro.com_Cpo19000_Fet19034_ExStk:H4sIAAAAAAAEAL2RzWrDQAyE74G8wx5dCH4Hpz%2fYBLcmpeci76q22s2uo5XB7tN3Q1iSU1sf2tNIMJpvQDVp9sG%2fSX4%2f6R5ch3lB%2fDw7nbRBPoBDJ9GAg5B365VSCkTVP96%2bBOS8ciQElj4x2Romp2kAm90szPrGVl37OpTX%2f6VtRxNlh%2fOfUQp9HInxDFpMuXzhgf1hj%2f1sGARNZeJrSZbXzrV4zlLDW%2b8EJ1H6rL8IK8EZG3OSbrEj17DXGMIejyMGyUqRISX3l3mjinBigrUt6A8F19tGPbXvqEVFI8MdCMQy69Wpcwnh0ddAtvXTFzY61Nj5AgAA_S123_Error:
UserHasNoMailbox_Dc:BonDC1.contoso.com_SBkOffD:L%2f-480_TmRcv23:07:20.2281657_TmCmpl23:07:39.2625704_ActivityContextData:ActivityID%3d14988279-6caf-4565-8363-4ed43211bc35%3bI32%3aATE.C%5bBonDC1.contoso.com%5d%3d2%3bF%3aATE.AL%5bBonDC1.contoso.com%5d%3d0%3bI32%3aADS.C%5bBonDC1%5d%3d2%3bF%3aADS.AL%5bBonDC1%5d%3d1.75745_ 444 CONTOSO\Mig8 192.168.1.63 - - 200 0 0 19050
Here’s an example of an error entry from the IIS logs of an Exchange Server 2013 CU8 Mailbox server, showing a successful HTTP redirect response sent to the EAS device:
2015-01-22 13:37:53 192.168.1.61 POST /Microsoft-Server-ActiveSync/default.eas User=user12@batre.msftonlinerepro.com&DeviceId=RSUA4U03JH48LAS6T7BD2TENV0&DeviceType=iPad&Cmd=Ping&Log=
RdirTo:TryToFigureOutEasEndpoint%3bhttps%3a%2f%2f outlook.Office 365.com%2fMicrosoft-Server-ActiveSync_V141_LdapC6_LdapL31_UserInfo:MailUser_Dc:BonDC1.contoso.com_Budget:(D)Conn%3a1%2cHangingConn%3a0%2cAD%3a%24null%2f%24null%2f0%25%2cCAS%3a%24null%2f%24null%2f0%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null%2f%24null%2f0%25%2cFC%3a1000%2f0%2cPolicy%3aDefaultThrottlingPolicy%5Fa53e58b3-edc1-4c36-be2c-0eec854b8637%2cNorm%5bResources%3a(DC)BonDC1.contoso.com(Health%3a-1%25%2cHistLoad%3a0)%2c%5d_ 443 user12@batre.msftonlinerepro.com 192.168.1.65 Apple-iPad2C2/1202.440 451 0 0 328
3. Verify the RemoteRoutingAddress
After user’s mailbox is moved from on-premises to Office365, the on-premises user object is converted into RemoteMailbox, and “RemoteRoutingAddress” is stamped on the user.
The RemoreRoutingAddress, stored in the “TargetAddress” Attribute, is used by on-premises Client Access servers to find out the correct Organization Relationship. On-premises Client Access servers try to find the Organization Relationship where the DomainName matches the SMTP domain of RemoteRoutingAddress.
Example:
RemoteRoutingAddress of the user is @Batre.mail.Onmicrosoft.com
Which is matching the following Organization Relationship:
In this case, the on-premises Client Access server will return TargetOWAURL from this Organization Relationship.
The EAS on-boarding solution will make it much easier for EAS users whose mailboxes are moved from Exchange on-premises to Office 365, because it provides a mechanism for the mobile device to be redirected to the Office 365 mailbox without user intervention.
Microsoft has recently released the March updates for the Outlook 2007/2010/2013 Junk E-mail Filter.
“This update provides the Junk E-mail Filter in Microsoft Office Outlook with a more current definition of which e-mail messages should be considered junk e-mail.”
The update is available for Outlook 2007, Outlook 2010 (32-bit, 64-bit) and Outlook 2013 (32-bit, 64-bit) or you can use Microsoft Update. As usual, the updates come with the corresponding Knowledge Base article:
The latest Cumulative Update for Exchange Server 2013 and Update Rollups for Exchange Server 2007 and 2010 were recently made available to download.
Cumulative Update 8 for Exchange Server 2013 (KB3030080)
Cumulative Update 8 for Exchange Server 2013 resolves issues that were found in Exchange Server 2013 SP1 since the software was released. This update rollup is highly recommended for all Exchange Server 2013 customers.
KB Articles: KB3030080
Update Rollup 9 For Exchange 2010 SP3 (KB3030085)
Update Rollup 9 for Exchange Server 2010 Service Pack 3 (SP3) resolves issues that were found in Exchange Server 2010 SP3 RU8 since the software was released. This update rollup is highly recommended for all Exchange Server 2010 SP3 customers.
For a list of changes that are included in this update rollup, see KB3030085.
This update rollup does not apply to Exchange Server 2010 Release To Manufacturing (RTM), Exchange Server 2010 Service Pack 1 (SP1) or Exchange Server 2010 Service Pack 2 (SP2).
For a list of update rollups applicable to Exchange Server 2010 RTM , Exchange Server 2010 Service Pack 1 (SP1) or Exchange Server 2010 Service Pack 2 (SP2), refer to the Knowledge Base article KB937052.
Update Rollup 16 for Exchange Server 2007 Service Pack 3 (KB3030086)
Update Rollup 16 for Exchange Server 2007 Service Pack 3 (SP3) resolves issues that were found in Exchange Server 2007 SP3 since the software was released. This update rollup is highly recommended for all Exchange Server 2007 SP3 customers.
For a list of changes that are included in this update rollup, see KB3030086.
This update rollup does not apply to Exchange Server 2007 Release To Manufacturing (RTM), Exchange Server 2007 Service Pack 1 (SP1) or Exchange Server 2007 Service Pack 2 (SP2).
For a list of update rollups applicable to Exchange Server 2007 RTM , Exchange Server 2007 Service Pack 1 (SP1) or Exchange Server 2007 Service Pack 2 (SP2), refer to the Knowledge Base article KB937052.
Related Links:
Today the Exchange Team released Rollup 9 for Exchange Server 2010 Service Pack 3 (KB3030085). This update raises Exchange 2010 version number to 14.3.235.1.
In addition to DST changes, this Rollup contains the following fixes:
Notes:
As with any Hotfix, Rollup or Service Pack, I’d recommend to thoroughly test this rollup in a test and acceptance environment first, prior to implementing it in production.
You can download Exchange 2010 SP3 Rollup 9 here.
When I discussed how some corrupt health mailboxes came about following my flattening of an Exchange 2013 server, I called them “zombie mailboxes”, which might have seemed unkind to some. In fact, it’s an accurate reporting of the fact that the Exchange Health Manager service will faithfully recreate two health mailboxes per mailbox database if it finds them missing. A Managed Availability probe cannot be deprived of its mailbox, after all.
You could have hours of harmless fun dealing health mailboxes and waiting for the Health Manager service to notice and recreate them, but this is probably not a very good use of your time and is certainly not a productive activity. Unless, of course, you need to be busy when a manager looks for you to do something which you’d really prefer to avoid, in which case declining on the basis that you have to “recreate some health mailboxes to keep Managed Availability working” is just the sort of excuse that comes in handy.
By now you might be convinced that I am super-sharp to notice that health mailboxes were corrupt. Alas, this couldn’t be further from the truth as I was blissfully unaware that anything was amiss until I noticed some device quarantine notifications show up in my mailbox. These notifications are created by Exchange ActiveSync (EAS) after you establish a mobile device access rule (otherwise known as an ABQ rule for “allow, block, or quarantine”) that quarantines unknown devices when an attempt is made to connect them to a mailbox. Exchange 2010 and Exchange 2013 support ABQ rules.
Managed Availability uses the health mailboxes to create synthetic transactions. One message category verifies that EAS is working properly by connecting to the health mailboxes to emulate an EAS transaction from a mobile device type called “EASProbeDeviceType”. The quarantine message (shown below) also tells us what health mailbox was used.
EAS quarantine notification for a health mailbox
The health mailboxes were recreated a short period after I removed the corrupt mailboxes. Managed Availability then attempted to use the new mailboxes for the EAS synthetic transactions. The new mailboxes were unknown to EAS and were not covered by any existing ABQ rule so their attempts to connect were intercepted and the devices quarantined. Of course, these aren’t real EAS clients and are not as important to deal with as would be messages about quarantined devices that belong to humans. On the other hand, it is important to allow Managed Availability to work as designed, so some action is necessary.
The easiest solution is to create an ABQ rule that permits the probes to connect to the health mailboxes with EAS. This takes less than a minute of administrator time to fire up EAC, go to the mobile tab, and create the necessary rule (below). Afterwards EAS will recognize “EASProbeDeviceType” as a valid device type, much like it might recognize a Windows Phone 8 device or an iPhone.
An EAS access policy for EASProbeDeviceType
The good news is that you might not have to create a rule at all. The default is to let any device connect to EAS and unless you made a decision to block selected devices you will probably discover that no ABQ rules are in place, which then means that the health mailboxes can connect as they wish. On the other hand, it’s entirely possible that you put some ABQ rules in place some time ago and have missed the quarantine messages about the EAS probes. But that would never happen, would it?
Follow Tony @12Knocksinna
The Exchange team is announcing today the availability of Cumulative Update 8 for Exchange Server 2013. The Cumulative Update Package and UM Language Packs are now available on the Microsoft Download Center. Cumulative Update 8 represents the continuation of our Exchange Server 2013 servicing and builds upon Exchange Server 2013 Cumulative Update 7. The release includes fixes for customer reported issues, minor product enhancements and previously released security bulletins. A complete list of customer reported issues resolved can be found in Knowledge Base Article KB3030080 . Customers running any previous release of Exchange Server 2013 can move directly to Cumulative Update 8 today. Customers deploying Exchange Server 2013 for the first time may skip previous releases and start their deployment with Cumulative Update 8 directly.
We would like to call your attention to a few items in particular about the Cumulative Update 8 release:
Read more at source: http://ift.tt/1GYooJf
Download it from here: http://ift.tt/1DxVy1s
Please join our ITPROCentral.com community at http://ift.tt/1vM4SGL
The Exchange team is announcing today the availability of Cumulative Update 8 for Exchange Server 2013. The Cumulative Update Package and UM Language Packs are now available on the Microsoft Download Center. Cumulative Update 8 represents the continuation of our Exchange Server 2013 servicing and builds upon Exchange Server 2013 Cumulative Update 7. The release includes fixes for customer reported issues, minor product enhancements and previously released security bulletins. A complete list of customer reported issues resolved can be found in Knowledge Base Article KB3030080. Customers running any previous release of Exchange Server 2013 can move directly to Cumulative Update 8 today. Customers deploying Exchange Server 2013 for the first time may skip previous releases and start their deployment with Cumulative Update 8 directly.
We would like to call your attention to a few items in particular about the Cumulative Update 8 release:
For the latest information and product announcements please read What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.
Cumulative Update 8 includes Exchange related updates to Active Directory schema and configuration. For information on extending schema and configuring the active directory please review the appropriate TechNet documentation. Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.
Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., CU8) or the prior (e.g., CU7) Cumulative Update release.
Note: Documentation may not be fully available at the time this post was published.
The Exchange team is announcing today the availability of Update Rollup 9 for Exchange Server 2010 Service Pack 3. Update Rollup 9 is the latest rollup of customer fixes available for Exchange Server 2010 Service Pack 3. The release contains fixes for customer reported issues and previously released security bulletins. Update Rollup 9 is not considered a security release as it contains no new previously unreleased security bulletins. A complete list of issues resolved in Exchange Server 2010 Service Pack 3 Update Rollup 9 may be found in KB3030085. Customers running any Service Pack 3 Update Rollup for Exchange Server 2010 can move to Update Rollup 9 directly.
Update Rollup 9 is available now on the Microsoft Download Center and will be distributed via Microsoft Update in April.
We would also like to remind users of Exchange Server 2010 that the product is now officially in Extended Support. We plan to release one more scheduled Update Rollup for Exchange Server2010 after which we will move to on-demand releases. Lifecycle policy for Exchange Server and other Microsoft products can be found on the Microsoft Support Lifecycle web site.
Note: Documentation may not be fully available at the time this post was published.
The Exchange team is announcing today the availability of Update Rollup 16 for Exchange Server 2007 Service Pack 3. This release adds support for Time Zone Updates released since Update Rollup 15. The release is a cumulative release and contains all fixes for customer reported issues previously reported as well as previously released security bulletins. Update Rollup 16 is not considered a security release as it contains no new previously unreleased security bulletins. More information about this release is available in KB3030086.
Update Rollup 16 is available now on the Microsoft Download Center and will be distributed via Microsoft Update in April.
Note: Documentation may not be fully available at the time this post was published.
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.
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) | 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) | Exchange 2013 CU9 (or newer) | 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 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.
The feature is available to all customers with shared mailboxes in Office 365 (starting now), as well as our on-premises customers (starting with Exchange 2013 CU9).
Shared mailboxes will have this feature enabled by default. No action is required.
This feature can be disabled by setting feature enable flag to FALSE:
For emails 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
If you then want to enable the feature again, you can do it as follows:
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
The world of technical book publishing is going through a transformation. More information is available than ever before online; software and hardware products evolve faster; people demand up to date knowledge that is also insightful and in-depth. These factors create enormous difficulties for the way that technical books were written, edited, and published in the past. Simply put, it is no longer acceptable for an outdated technical book to appear.
I’ve been immersed in the traditional approach since 1991 and have written fifteen books in that time. The usual approach is:
Phew! That’s a lot of work by a lot of people and it takes place over a long time. A book about a new version of Exchange would be usually agreed some months before the software is available but writing can’t start until the software is in reasonable shape, normally well on in the beta cycle. I’ve found that it is worthless to write about the software that is shipped to customers as the RTM (Release to Manufacturing) version because very few companies ever install the RTM version. It is better to base a book on software that has matured a little and the obvious bugs have been fixed.
Writing the text of a book might not finish until six months after RTM. During this time it is relatively easy for the author to keep up with new developments as people discuss the software, encounter bugs and workarounds, or find new ways to use it. That knowledge can be incorporated into the text as it arises.
The technical edit phase probably lasts two months, depending on the length of the book, and will overlap the writing phase somewhat. The author has to provide finished chapters to the editor, who checks them and then releases the chapters to the technical editor. Reviewed chapters flow back to the editor after a couple of weeks and are sent on to the author. The comments usually result in a set of updates to the chapters. Any new information that has come to hand about the software can be incorporated into the text at this point.
The copy editing phase kicks in as fully edited (through technical review and author update) chapters become available and the interaction between copy editor, editor, and author takes another four to six weeks.
Chapters are also being worked on by the desktop publishing expert to create the final form of the book. From this point on it becomes more difficult to accommodate new information because the page count is being finalized and insertion (or deletion) of material will affect page flow, indexing, and so on. It’s still possible to make changes, but the changes tend to be relatively minor. There’s no way that a section of a chapter will be rewritten at this point unless it is badly flawed and absolutely needs the work to be done.
A final round of reviews occurs after all the chapters are in their almost final form to identify any issues – code extracts are often problematic as pouring text from Word documents into desktop publishing packages can affect their formatting and meaning. The last few patches are made to the text, but now it’s really only done on a must-need basis.
The book now goes to the publisher and appears four to six weeks later. Noticing a mistake at this point produces real heartburn for all concerned, but it happens. That frustration continues as time goes by and new updates appear but the printed copies stay the same. I would very much like to have an update for my Exchange 2013 Inside Out: Mailbox and High Availability book, but that’s not going to happen anytime soon, despite the multitudinous updates that have appeared since the book was published in September 2013.
Everyone involved in moving a book from text to print attempts to work as efficiently as possible, but even so the entire process can take between nine and fifteen months. And it’s terribly difficult to accommodate changes due to software updates during the last three months.
Extended as it was, the process has worked for years. But that’s because a products like Exchange, SharePoint, Outlook, or Windows have been engineered in three or four year cycles, leading to releases like Exchange 2000, Exchange 2003, Exchange 2007. Exchange 2010, and Exchange 2013. It worked, but it’s been getting harder and harder as Microsoft has changed its engineering cadence in response to the faster release cycles of competitors and customer demands for new functionality sooner.
It’s crazy to think about using traditional publishing methods to produce a book about Office 365. Too many changes happen too quickly for the old approach to work. Anyone who stays abreast of the constant flow of announcements on the Office Blogs knows this. Any administrator responsible for an Office 365 tenant realizes that things are different in the cloud and that software can change daily. At the time of writing, Microsoft’s Office 365 Roadmap lists 46 engineering developments under way. That list is incomplete because it only includes the major efforts; bug fixes and adjustments to features happen all the time.
The work necessary to keep text up to date about Office 365 is enough to make an experienced author cry. It’s time for a new approach. That’s why Paul Cunningham (ExchangeServerPro.com), Michael Van Horenbeeck (nicknamed Van Hybrid for good reason), and myself will publish “Office 365 for Exchange Professionals” on May 3. The book is designed to explain Office 365 to experienced Exchange on-premises administrators, but I think it will be valuable to anyone who wants to learn more about Office 365.
We’ve been writing since last December and underestimated the effort necessary to stay abreast of new developments inside Office 365. But the work has justified our belief that this book would be impossible to do using traditional methods.
“Office 365 for Exchange Professionals” will be available for purchase as an eBook from ExchangeServerPro.com. We plan to update the book regularly, so the version you download from the site will be the latest text. We’ll probably take a bit of a rest after the first version appears, but you can expect regular updates from September onwards.
We’re still working on the text and won’t finalize it until April 15. I can tell you that the book currently spans some 550 pages divided into 18 chapters.
“Office 365 for Exchange Professionals” has been a fantastic project. Apart from learning a ton of stuff, we have received terrific support from the Exchange product development group and the MVP community. Jeff Guillet is the overall technical editor and he’s being helped by other MVPs who are reviewing individual chapters. And we have the pleasure of a foreword written by Microsoft Vice President Perry Clarke, who has led the development effort to take Exchange from being software designed for deployment inside corporate datacenters to cloud software that supports tens of millions of mailboxes with a very substantial record of meeting SLAs.
Hopefully you’ll like the book. And hopefully we will receive lots of ideas and suggestions that we can incorporate into the second edition, and the third edition, and so on. I suspect that this project might turn into an ongoing effort, but we’ll see how the first edition turns out and decide what happens then.
Now we had better get on and finish the book else it won’t be at Ignite.
– Tony (with a lot of help from his friends)
