Quantcast
Channel: You Had Me At EHLO…
Viewing all 607 articles
Browse latest View live

Email retention for deleted items in Office 365 is changing


Automated Hybrid Troubleshooting Experience

0
0

One of the more popular deployment options for Office 365, and more specifically Exchange Online, is the Exchange Hybrid Configuration. This deployment option gives customers a way to move some of their mailboxes to Exchange Online, while keeping some on-premises. Our goal with an Exchange Hybrid configuration is to make the two physically separate environments operate as if they were one. Features such as Mail Flow, Free/Busy, MailTips, and compliance features like eDiscovery searches work seamlessly even for mailboxes in different environments.

While all of this automation is great, there are some tradeoffs. When something goes wrong with the Hybrid Configuration Wizard (HCW), what do you do? We’ve heard complaints like, “This thing is a black box!” and “Why do the errors have to be so vague?” While we are proud of the work we’ve done with the HCW, we agree that troubleshooting some of the problems can be difficult.

Announcing a New Automated Troubleshooting Experience

The first version of the new automated troubleshooting experience is quite simple. You run a troubleshooter (http://aka.ms/HCWCheck) from the same server on which HCW failed (Internet Explorer only at this time). This will collect the HCW logs and parse them for you.

If you are experiencing a known issue, there will be a message that tells you what went wrong and then provide you with a link to an article that contains the solution.

Added Benefit

The troubleshooter has predetermined sets of patterns it looks for in the HCW logs to determine the conclusion. Whether it finds a conclusion or not, the HCW logs are uploaded to our datacenter and made available to a support professional in the event that you open a case. This can dramatically reduce the amount of time it takes for your issue to get resolved.

Moving forward

We plan on adding more complex checks and diagnostic results to this troubleshooter. We are working on a series of troubleshooters that will automate troubleshooting and data collection efforts for things like Migrations, Free/Busy, and OAUTH issues.

Got feedback?

We would love to hear any feedback you have. Drop us a line at HCWCheckFeedback@microsoft.com

Kudos goes to the following folks that made this possible:

Saidivya Velagapudi, Caius Preda, Scott Roberts, Nikhil Chinchwade, Karl Buhariwala, Timothy Heeney, Jeremy Kelly, Wei Wu, Cathy Westman, Gabriel Popescu, and numerous others

The Exchange Hybrid Team

Exchange On-Premises TAP accepting nominations (again)

0
0

It has been almost exactly two years now that we had a post about our Exchange On-Premises TAP program and how you can (and why you would want to) nominate yourself for the program.

Well, the time is right again, and we would like to re-invite you to apply and we will consider you for the program.

Please head over to the original post (and follow the process outlined there) to apply. Thank you for your interest!

Exchange On-Premises TAP Program accepting nominations

David Espinoza

Managed Availability Responders

0
0

Responders are the final critical part of Managed Availability. Recall that Probes are how Monitors obtain accurate information about the experience your users are receiving. Responders are what the Monitors use to attempt to fix the situation. Once they pass throttling, they launch a recovery action such as restarting a service, resetting an IIS app pool, or anything else the developers of Exchange have found often resolve the symptoms. Refer to the Responder Timeline section of the Managed Availability Monitors article for information about when the Responders are executed.

Definitions and Results

Just like Probes and Monitors, Responders have an event log channel for their definitions and another for their results. The definitions can be found in Microsoft-Exchange-ActiveMonitoring/ResponderDefinition. Some of the important properties are:

  • TypeName: The full code name of the recovery action that will be taken when this Responder executes.
  • Name: The name of the Responder.
  • ServiceName: The HealthSet this Responder is part of.
  • TargetResource: The object this Responder will act on.
  • AlertMask: The Monitor for this Responder.
  • ThrottlePolicyXml: How often this Responder is allowed to execute. I’ll go into more details in the next section.

The results can be found in Microsoft-Exchange-ActiveMonitoring/ResponderResult. Responders output a result on a recurring basis whether or not the Monitor indicates they should take a recovery action. If a ResponderResult event has a RecoveryResult of 2 and IsRecoveryAttempted of 1, the Responder attempted a recovery action. Usually, you will want to instead skip looking at the Responder results and go straight to Microsoft-Exchange-ManagedAvailability/RecoveryActionResults, but let’s first discuss the events in the Microsoft-Exchange-ManagedAvailability/RecoveryActionLogs event log channel.

Throttling

When a recovery action is attempted by a Responder, it is first checked against throttling limits. This will result in one of two events in the RecoveryActionLogs channel: 2050, throttling has allowed the operation, or 2051, throttling rejected the operation. Here’s a sample of a 2051 event:

throttlingevent

In the details, you will see:

ActionId

RestartService

ResourceName

MSExchangeRepl

RequesterName

ServiceHealthMSExchangeReplEndpointRestart

ExceptionMessage

Active Monitoring Recovery action failed. An operation was rejected during local throttling. (ActionId=RestartService, ResourceName=MSExchangeRepl, Requester=ServiceHealthMSExchangeReplEndpointRestart, FailedChecks=LocalMinimumMinutes, LocalMaxInDay)

LocalThrottleResult

<LocalThrottlingResult IsPassed="false" MinimumMinutes="60" TotalInOneHour="1" MaxAllowedInOneHour="-1" TotalInOneDay="1" MaxAllowedInOneDay="1" IsThrottlingInProgress="true" IsRecoveryInProgress="false" ChecksFailed="LocalMinimumMinutes, LocalMaxInDay" TimeToRetryAfter="2015-02-11T14:29:57.9448377-08:00"> <MostRecentEntry Requester="ServiceHealthMSExchangeReplEndpointRestart" StartTime="2015-02-10T14:29:55.9920032-08:00" EndTime="2015-02-10T14:29:57.9448377-08:00" State="Finished" Result="Succeeded" /> </LocalThrottlingResult>

GroupThrottleResult

<not attempted>

TotalServersInGroup

0

TotalServersInCompatibleVersion

0

Hopefully, you recognize the first few fields. This is the RestartService recovery action, which restarts a service. The ResourceName is used by the recovery action to pick a target; for the RestartService recovery action, it is the name of the service to restart. The RequesterName is the name of the Responder, as listed in the ResponderDefinition or ResponderResult channels.

The LocalThrottleResult property is more interesting. Recovery actions are throttled per server, where the same recovery action cannot run too often on the same server, and per group, where the same recovery action cannot run too often on the same DAG (for the Mailbox role) or AD site (for the Client Access role). If a value is -1, this level of throttling is not used; for example, MaxAllowedInOneHour is not interesting if only 1 action is allowed per day. In this example, the MSExchangeRepl resource was already the target of a recovery action within the last 60 minutes, and so the recovery action did not pass the LocalMinimumMinutes throttling. As this recovery action attempt was blocked by local throttling, the group throttling was not attempted. This table has a description of each of the limits mentioned in this event:

ThrottlingResult attribute

Local throttle config attribute name

Group throttle config attribute name

Description

IsPassed

  

True if throttling will allow the recovery action. Otherwise, false.

MinimumMinutes,

LocalMinimumMinutes,

GroupMinimumMinutes

LocalMinimumMinutesBetweenAttempts

GroupMinimumMinutesBetweenAttempts

The time that must elapse before this recovery action may act upon the same resource on this server or in this group.

TotalInOneHour

  

The number of times this recovery action has acted upon this resource on this server or in this group in the last hour.

MaxAllowedInOneHour,

LocalMaxInHour

LocalMaximumAllowedAttemptsInOneHour

n/a

The number of times this recovery action is allowed to act upon this resource on this server or in this group in one hour.

TotalInOneDay

  

The number of times this recovery action has acted upon this resource on this server or in this group in the last 24 hours.

MaxAllowedInOneDay,

LocalMaxInDay,

GroupMaxInDay

LocalMaximumAllowedAttemptsInADay

GroupMaximumAllowedAttemptsInADay

The number of times this recovery action is allowed to act upon this resource on this server or in this group in 24 hours.

IsRecoveryInProgress,

RecoveryInProgress,

GroupRecoveryInProgress

  

Whether this recovery action is already acting upon this resource and has not completed. If True, the new action will be aborted.

TimeToRetryAfter

  

The time after which this recovery action would be allowed to act on this resource on this server or in this group.

The GroupThrottleResult has the same fields, and also gives details about the recovery actions that have taken place on the other servers in the group.

If the action is not throttled, event 500 will be logged in the Microsoft-Exchange-ManagedAvailability/RecoveryActionResults channel, indicating that the recovery action is beginning. If it succeeds, event 501 is logged. This is the most common case and where you’ll usually want to start. These events also have details about the recovery action that was taken and the throttling it passed. Recovery actions that start and then fail are still counted against throttling limits. For more information about recovery actions, read the What Did Managed Availability Just Do to This Service? article.

Viewing Throttling Limits

So what is the best way to find out what recovery action throttling is in place? You could wait for the Responder to begin a recovery action and view the throttling settings in the RecoveryActionsLogs channel, but there are two places that will be more timely. The first is the Microsoft-Exchange-ManagedAvailability\ThrottlingConfig event log channel. The second is the Microsoft-Exchange-ActiveMonitoring/ResponderDefinition channel, introduced in the first section of this artcile. The advantage of the ThrottlingConfig channel is that you can see all the Responders that can take a particular recovery action grouped together, instead of having to check every Responder definition. Here’s a sample event from the ThrottlingConfig event log channel:

Identity

RestartService/Default/*/*/msexchangefastsearch

RecoveryActionId

RestartService

 

ResponderCategory

Default

 

ResponderTypeName

*

 

ResponderName

*

 

ResourceName

msexchangefastsearch

 

PropertiesXml

<ThrottleConfig Enabled="True" LocalMinimumMinutesBetweenAttempts="60" LocalMaximumAllowedAttemptsInOneHour="-1" LocalMaximumAllowedAttemptsInADay="4" GroupMinimumMinutesBetweenAttempts="-1" GroupMaximumAllowedAttemptsInADay="-1" />

 

The Identity of a throttling configuration is a concatenation of the next five fields, so let’s discuss each. The RecoveryActionId is the Responder’s throttling type. You can find this as the name of the ThrottleEntries node in the Responder definition’s ThrottlePolicyXml property. The ResponderCategory is unused and is always Default right now. The ResponderTypeName is the Responder’s TypeName property. The ResourceName is the object the Responder acts on. In this example, the throttling for Responders that use the RestartService recovery action to restart the MSExchangeFastSearch process are allowed on any server up to 4 times a day, as long as it has been 60 minutes since this recovery action has restarted it on that server. The group throttling is not used.

The second method to view throttling limits is by the Microsoft-Exchange-ActiveMonitoring/ResponderDefinition events. This will include any overrides you have in place. Here is the value of the ThrottlePolicyXml property from a ResponderDefinition event:

<ThrottleEntries> <RestartService ResourceName="MSExchangeFastSearch"> <ThrottleConfig Enabled="True" LocalMinimumMinutesBetweenAttempts="60" LocalMaximumAllowedAttemptsInOneHour="-1" LocalMaximumAllowedAttemptsInADay="4" GroupMinimumMinutesBetweenAttempts="-1" GroupMaximumAllowedAttemptsInADay="-1" /> </RestartService> </ThrottleEntries>

You can see that these attribute names and values match the ThrottlingConfig event’s PropertiesXml values.

Changing Throttling Limits

There may be times when you want recovery actions to occur more frequently or less frequently. For example, you have a customer report of an outage and you find that a service restart would have fixed it but was throttled, or you have a third-party application that does particularly poorly with application pool resets. To change the throttling configuration, you can use the same Add-ServerMonitoringOverride and Add-GlobalMonitoringOverride cmdlets that work for other Managed Availability overrides. The Customizing Managed Availability article gives a good summary on using these cmdlets. For the PropertyName parameter, the cmdlet supports a special syntax for modifying the throttling configuration. Instead of specifying the entire XML blob as the override (which will work, but will be harder to read later), you can use ThrottleAttributes.LocalMinimumMinutesBetweenAttempts, or the other properties, as the PropertyName. Here’s an example:

Add-GlobalMonitoringOverride -ItemType Responder -Identity Search\SearchIndexFailureRestartSearchService –PropertyName ThrottleAttributes.LocalMinimumMinutesBetweenAttempts -PropertyValue 240 -ApplyVersion "15.00.1044.025"

To only allow app pool resets by the ActiveSyncSelfTestRestartWebAppPool Responder every 2 hours instead of 1, you could use the command:

Add-GlobalMonitoringOverride -ItemType Responder -Identity ActiveSync.Protocol\ActiveSyncSelfTestRestartWebAppPool -PropertyName ThrottleAttributes.LocalMinimumMinutesBetweenAttempts -PropertyValue 120 -ApplyVersion “Version 15.0 (Build 1044.25)”

If you want you servers to reboot when the MSExchangeIS service crashes and cannot start at the rate of all of your servers once a day and no more often than one in the DAG every 60 minutes, you could use the commands:

Add-GlobalMonitoringOverride -ItemType Responder -Identity Store\StoreServiceKillServer -PropertyName ThrottleAttributes.GroupMinimumMinutesBetweenAttempts -PropertyValue 60 -ApplyVersion “15.00.1044.025”

Add-GlobalMonitoringOverride -ItemType Responder -Identity Store\StoreServiceKillServer -PropertyName ThrottleAttributes.GroupMaximumAllowedAttemptsInADay -PropertyValue -1 -ApplyVersion “15.00.1044.025”

The LocalMaximumAllowedAttemptsInADay value is already 1, so each server would still reboot at most once per day. If the override was entered correctly, the ResponderDefinition event’s ThrottlePolicyXml value will be updated, and there will be a new entry in the ThrottlingConfig channel.

These may be poor examples, but it is hard to pick good ones as the Exchange developers pick values for the throttling configuration based on our experience running Exchange in Office 365. We don’t expect that changing these values is going to be something you’ll want to do very often, but it is usually a better idea than disabling a monitor or a recovery action altogether. If you do have a scenario where you need to keep a throttling limit override in place, we would love to hear about it.

Abram Jackson
Program Manager, Exchange Server

Be the first to learn what’s next for Exchange and Office 365 at Microsoft Ignite - Full session list now available

0
0

This morning we released the complete list of sessions offered at Microsoft Ignite, including the full list of Exchange sessions. Ignite is the premier event for the Exchange community, bringing together the people who build Exchange and those who work with it every day. If you are one of the many Microsoft Exchange Conference (MEC) alumni, Ignite is the evolution of MEC. Be there as we talk about what’s coming next in Exchange, announce new Office 365 innovations and share our overall technology vision and strategy.

Deep technical content

At Ignite, we’ll have over 65 breakout sessions dedicated to Exchange on-premises and online, 9 hands-on-labs (HOLs) and 2 pre-day offerings for Exchange IT Pros – many of these offerings presented for the first time at Ignite. You will hear from Exchange engineering, deployment and support teams, as well as independent MVP experts. Ignite offers more than just Exchange content, providing easy access to a broad set of content across Microsoft technologies. You will find over 550 sessions ready for selection at Ignite. So go broad and deep with leading experts from Microsoft and the community on topics ranging from product overview, best practices, how-to, deep-dives, vision and roadmap – tailored by role, level, and specific interests. Here as few sessions you will find on the agenda for Ignite.

TitleSpeakerLevel
Exchange Server Preferred ArchitectureRoss Smith IV300
Under the Hood with DAGsTim McMichael400
Exchange Hybrid: Make Office 365 Work for YouMichael Van Horenbeeck and Timothy Heeney300
Experts Unplugged: Exchange Top IssuesExchange and Office 365 Support Teams300
MVPs Unplugged: The Journey to Microsoft Exchange OnlineExchange MVPs300

View all sessions featuring Exchange product technology here.

Unrivaled community & networking opportunities

If you’ve been to MEC in the past, you know the real magic happens with the connections you make on site – impromptu geek-out whiteboard sessions, ad-hoc syncs and afterhours at the big and small parties. We are building a complete Ignite experience to deliver opportunities to network at Ignite as Exchange MVP Jason Sherry shared with us early in the Ignite planning process.

"The key thing for me is the networking and open dialog that can easily be had with anyone there. Easy access to my peers and product group. We powwow and can then walk to sessions together. Interacting with your peers and socializing is the biggest benefit."– Jason Sherry, Exchange MVP & MEC Alumni, @JasonSherry

We’re hosting six large theaters in the spacious expo hall at the event to serve as community zones – these provide a platform for community leaders to share their knowledge and experience with attendees as well as comfortable meeting places for the spontaneous conversations that crop up. The content in these theaters is 100% community-driven; you can expect community-run panel discussions, short fire-starter sessions in which you share an idea with the community and get immediate feedback and birds of a feather session in which people with similar interests gather for discussion, and maybe some of that ‘controlled chaos with clarity’ this community is known for.

Mealtimes and after hours provide a whole new slew of opportunities to network and make connections, from scheduled events including the Welcome Reception Monday night and Attendee Party Thursday night to more informal gatherings including meal-time mashups with seating by topic or geography so every meal at the conference becomes a chance to meet someone with similar interests.

Join in

Register today and join us at Ignite!

image

Want more control over Sent Items when using shared mailboxes?

0
0

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 MailboxShared MailboxSent Items
Exchange 2010Exchange 2010Controlled through settings in KB2632409
Exchange 2010Exchange 2013 (any version)Controlled through settings in KB2632409

Exchange 2013 CU9 (or newer)
Office 365

Exchange 2010The 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 and the shared mailbox is on an Exchange 2010 server, the shared mailbox will get an email message that looks like the following:

image

This behavior will continue until the shared mailbox is moved to an Exchange 2013 CU9 server.

Who can use this feature?

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).

How do I enable/disable this feature?

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

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.

Paul Lo

Network Ports for Clients and Mail Flow in Exchange 2013

0
0

Once upon a time in a land far, far away I wrote an article that told our action packed supportability story about the relationship of firewalls and Exchange servers. While the majority of response was positive to this purposefully lighthearted article (if you can’t enjoy your work why do it? :), there were other comments similar to the following:

“This isn’t official, it isn’t on TechNet!”

I’ll refer to the statement on the blog’s homepage:

This is the official blog of the Exchange Server Product Group.  All content here is considered authoritative and supported by Microsoft, unless otherwise specified.”

“It has a picture of cheese. I’m not using that as official guidance.”

You don’t like cheese? What did it do to you? Is it the smell? I’ll admit some of them do smell quite awful. I received a bruised toe from dropping a cheese wheel once.

“I don’t like spaghetti!”

Well that’s more for R5!

Terrible humor aside for a moment, we still recognized the need some of you had for something a bit more shall we say… polished. One of our wonderfully tenacious content developers, Chris Davis, took it upon himself to charge into battle and spent quite a bit of time tracking down everything required to put together this new article. In the end Chris has come up with a thorough TechNet article, without cheese, that we hope will provide you with everything required to stand up a perfectly healthy Exchange 2013 deployment all while staying within the support statement from the Exchange PG.

As a reminder we look at all Exchange servers across an entire organization’s deployment as one organic entity that rely on each other for proper function. Microsoft still does not support configurations when Exchange servers have network port restrictions that interfere with or alter communications with other Exchange servers, Active Directory servers, or Lync servers, as the new article states up front in much more clear wordage than before, and because of this the document focuses on client connectivity and mail flow into and out of the Exchange organization.

We hope the new article is put to good use and welcome commentary if there are any scenarios you feel we left out.

http://aka.ms/Exchange2013Ports

Brian Day
Senior Program Manager
Office 365 Customer Experience

New Time Zone updates available for Exchange Server 2007 Service Pack 3

0
0

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.

The Exchange Team


Announcing Update Rollup 9 for Exchange Server 2010 Service Pack 3

0
0

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

Announcing Cumulative Update 8 for Exchange Server 2013

0
0

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:

  • Calendar and Contact Modern Public Folders favorites added in Outlook are now accessible in OWA
  • Batch Migration of Public Folders to 2013 improves migration throughput and PF migration experience
  • Smoother migration for EAS clients to O365 with automatic profile redirect upon successful Hybrid migration to O365 (EAS client must support HTTP 451 redirect)

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

Exchange 2013 Monitoring Mailboxes

0
0

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:

image

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:

image

The display name of the monitoring mailbox created for CAS server contained the GUID of the Exchange server for which it was created.

Example:

image

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:

image

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 or retention policies to monitoring mailboxes

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

Get-Mailbox –Monitoring
Get-Mailbox –Monitoring -Database <database name>
Get-Mailbox –Monitoring –Server <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 3046530 has 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:

image

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”

image

image

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

Exchange ActiveSync on-boarding to Office 365

0
0

Introduction

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.

EAS On-boarding

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:

EAS OnBoarding

  1. The EAS device tries to sync using the currently configured URL and hits the on-premises Client Access server.
  2. The on-premises Client Access server checks if the user’s mailbox is present.
  3. The Client Access server gets a response that the user mailbox is not found.
  4. The Client Access server returns a “UserHasNoMailbox” error to the mobile device, which is displayed in the form of the following error message:

image

Solution

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:

solution

Before the move, the EAS device configuration will show it is configured to sync with on-premises URL:

image

The flow after the mailbox is moved to Office 365:

  1. The EAS device tries to sync using the currently configured URL and connects to the on-premises Client Access server.
  2. The Client Access server checks if the user mailbox is present.
  3. The Client Access server gets a response that the user mailbox is not found.
  4. The Client Access server triggers a query to find the “TargetOWAURL” property present on the organization relationship object for the Office 365 tenant. The “RemoteRoutingAddress” property, present on the remote mailbox, is used to find the correct organization relationship.
  5. The Client Access server receives the TargetOWAURL configured on the Organization Relationship.
  6. The Client Access server sends the URL in an HTTP 451 response to the device.
  7. The EAS device tries to sync with the new URL, which should be successful.
  8. The EAS profile on the device is updated to the Office 365 URL.

image

From this point forward, the device will continue to sync with Office 365.

To make this work, certain prerequisites are required:

  • All on-premises Exchange 2010 Client Access servers handling EAS requests must be running at least Service Pack 3 RU9.
  • Exchange 2013 Mailbox roles handling EAS requests must be running CU8.
  • The EAS version on the device should be 14 or higher, and the device must be able to handle 451 redirect responses.
  • The Exchange on-premises organization has successfully set up hybrid with their Office 365 tenant.
  • The OrganizationRelationship object must exist in the on-premises Active Directory environment and the TargetOWAURL should be populated with the Office 365 URL.
  • The username and password for the user must remain the same after the move to Office 365. The user experience will not be seamless if the username or password is changed after the mailbox is moved to Office 365.

Supported and Unsupported Scenarios

Let’s take a look at what is supported and unsupported scenarios with respect to this solution.

Supported scenarios:

  • This feature covers mailbox migrations from Exchange 2010 or Exchange 2013 on-premises to Office 365 (Dedicated or Multi-Tenant).
  • This feature applies to devices that are EAS-compatible and that support HTTP 451 redirection.

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.

Unsupported scenarios:

  • This feature does not support:
    • Mailboxes moved from Exchange Server 2007 to Office 365, since Exchange Server 2007 EAS version is 12.1.
    • Off-boarding a mailbox from Exchange Online to on-premises.
    • Cross forest mailbox move between two Exchange Server 2013 or Exchange Server 2010 orgs.
  • EAS devices or applications that do not process HTTP 451 redirects will continue to require manual intervention (the Outlook app for Android and iOS devices (previously known as Acompli) is an example of this).

For all unsupported scenarios, users will get the same experience as without the solution, as described earlier.

Organizationrelationship and TargetOwaURL

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:

image

You can re-run the Hybrid Configuration Wizard (HCW), if the Organization Relationship or TargetOWAURL are missing.

Troubleshooting

The solution should work as expected. However, if you are experiencing problems, here are some troubleshooting tips:

  1. Confirm all the pre-requisites have been met.
  2. Make sure the device is actually hitting the on-premises CAS. Check the HTTP Proxy or IIS Log on the CAS to make sure the device is reaching it. You can also see the server’s response. The key is to search for the name of user that is not able to connect to the server.

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%2foutlook.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

image

Which is matching the following Organization Relationship:

image

In this case, the on-premises Client Access server will return TargetOWAURL from this Organization Relationship.

Conclusion

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.

Bhalchandra Atre

VSSTester script updated – troubleshoot Exchange 2013 and 2010 database backups

0
0

It’s been a while since we talked about VSSTester script!

Murali, who maintained the script before, asked me to take over the script 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:

  • Exchange 2013 support
  • Execution option #3 (custom) is removed
  • Better user input handling
  • Output formatting improvements
  • Execution speed optimization (in particular, gathering system and application events)
  • Various bugfixes (e.g. forcing log file overwrites so that you can run the script multiple times on the same machine)

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:

image

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,

Matthew Huynh

Using RBAC to restrict Discovery Searches

0
0

Introduction

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.

Restricting eDiscovery to a specific department using a RecipientFilter

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.

  1. Create a distribution group for the Accounting department and add the required set of user mailboxes as members of the distribution group.
  2. Define a custom scope to include only the users who are members of the Accounting department distribution group created to limit the scope of the mailboxes that can be searched. This is achieved by using the RecipientRestrictionFilter and the DistributionListMembership as criteria for the new scope.
  3. Create a new role group, and assign the new custom scope, add the “Mailbox Search” and “Legal Hold” roles, and then add John as member of the role group so he will be the dedicated eDiscovery manager for the Accounting department
  4. Create a new dedicated discovery mailbox for the eDiscovery searches to be saved and assign full access permissions to John

1. Create and configure the distribution group for the Accounting department

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 theAccountingdepartment, 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:

  • The Distribution group has to be a Mail Enabled Universal Distribution Group and can be created using the Exchange Admin Center or the Exchange Management Shell.
  • The Distribution group created can have more than one Owner.
  • Ensure that the moderation is enabled and the distribution group is hidden from the global address list (GAL).
  • Also, members shouldn’t be automatically added to the distribution group and they shouldn’t be able to leave the group automatically. Check the properties of the distribution group to confirm these requirements by running the following command.

image

2. Create a Custom management scope using the RecipientRestrictionFilter

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.

image

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 the user mailboxes.
  • The above restriction only applies for custom scopes for eDiscovery.

3. Create a new role group

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 Groupscontainer 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

image

Run the following command to view the CustomRecipientWriteScope and the RecipientReadScope associated with the role.

Get-ManagementRoleAssignment "Mailbox Search-Accounting Users eDiscovery Managers" | FL

image

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 Managerswho 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.

4. Create a dedicated discovery mailbox for the Accounting department

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:

  • The discovery mailbox created will have the associated user account disabled.
  • If you want to copy the search results from a search that uses the custom scope, the discovery mailbox has to be a member of the "eDiscovery Accounting Users" distribution group, which was used to create the scope. Run the following command to add the discovery mailbox as a member of the distribution group.

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

  • The reason for creating a discovery mailbox for the dedicated departments is to avoid copying search results to the default discovery mailbox, which can be accessed by other eDiscovery Managers.
  • Creating additional discovery mailboxes for a department to copy the search results reduces the risk of data leak. In our scenario, we only provide access to the required eDiscovery manager who will be performing the eDiscovery searches for the Accounting department.
  • Also for mailboxes such as the discovery mailbox, which may contain sensitive information, consider enabling mailbox audit logging for mailbox owner actions such as message deletion. It’s also a good idea to enable mailbox auditing for user mailboxes that will be searched.
  • The EAC will list the discovery mailbox only when the search results are to be copied to it. This is default behavior.
  • Remember that mailbox audit logging for discovery mailboxes can only be managed using the Exchange Management Shell.

For more information check below:

Test the eDiscovery operation for the Role Group

Perform eDiscovery using the Exchange admin center in Microsoft Exchange 2013

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

What happens when an eDiscovery manager searches mailboxes outside the custom scope

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.

image

Even though you grant Mailbox Search role explicitly to the Role Group you won’t be able to search mailboxes outside the scope

Administrator Audit Logging and eDiscovery

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:

Conclusion

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: https://technet.microsoft.com/en-us/library/dn741464%28v=exchg.150%29.aspx

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 usePowerShellto add users in bulk to a specific distribution group based on department or company.

Note:

  • Dynamic distribution groups won’t work for creating a custom scope for eDiscovery.
  • Nesting of the Distribution groups in the primary distribution group won’t work because the scope will only look at the MemberOfGroup. Nested groups will have user accounts added to it, but will have a different value for the property MemberOfGroup. To work around this, administrators can create single custom scope with multiple distribution groups.
  • You can still create a Role Group with the Organizational Unit Parameter to limit the role group and associate with roles to only specific OU, but this method won't be supported for custom eDiscovery.
  • eDiscovery searches performed by using a custom scope will be visible to other eDiscovery managers. The search can be deleted by unauthorized eDiscovery managers BUT that action will be captured in the administrator audit log.

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.

Siddhesh Dalvi

Support Escalation Engineer - Exchange positions available!

0
0

The Support Escalation Engineer is a technical leader who will have the opportunity to solve technically complex problems for some of the world’s largest companies, as well as smaller companies on the leading edge of their industry.   You will have the opportunity to work with the latest cloud and on-premise technologies.   As a trusted advisor to IT Professionals and Developers you will have influence over a broad range of solutions that create business value for our customers.   Your technical and relationship skills are critical to the success of the customer’s perception of value to the Microsoft solution.

At Microsoft CSS Supporting Engineering, the sentence: “That’s not our problem” doesn’t exist in our lexicon.   With more than 8,000 employees, we deliver world-class assistance around the clock to businesses, partners and developers in 24 languages.

Support Escalation Engineering at Microsoft

The Support Escalation Engineer - You will use advanced troubleshooting methods and tools to solve technically complex problems.   These highly complex escalated problems require broad, in-depth product knowledge and may include support of additional product lines.   You also have the opportunity to assist in the growth of other Engineers through mentoring, training scenarios and collaboration during problem solving. This will allow the freedom to broadly enable customer self-help by creating leveraged resources, automated self-help solutions, and sharing your expertise via social media.   We’ll provide you with abundant resources, including a rich content library, advanced diagnostic tools, and access to other Microsoft experts.

Interested in applying or want to learn about qualifications? Head over here.

Exchange Support Team


Upgrade to Office Configuration Analyzer Tool (OffCAT) version 2

0
0

It has been a little over a year since the OffCAT team shipped a new version, so I am very happy to tell you that we just released the very latest version (v2).

As with any new version, there are new features, diagnostic rules, and fixes in this latest OffCAT version. After reading about all these changes, we hope you will upgrade or install v2 without delay.

New application interface

One of our goals in this version was to simplify the user interface. This is one reason why OffCAT v2 looks and functions very differently from all previous versions of OffCAT (and OCAT).

image

Addition of OneDrive for Business to the list of detected programs

OneDrive for Business is a very popular component of Office. It is installed with Office 2013, but it also can be downloaded and installed to work with earlier Office version programs. So, for OffCAT v2, you can scan OneDrive for Business to check for any known issues that may impact it.

Note There is another Microsoft product that is simply called OneDrive (not OneDrive for Business). OffCAT does not support scanning OneDrive.

Reading pane for detected issues

The Issues Lists displays the description and solution for the selected issue in a more convenient location on the right side of the report in the new reading pane.

image

Details on the selected issue as well as a link to the solution are provided under Issue Description and Solution.

Calendar Issues tile and report

Scans of Outlook include a separate Calendar Issues tile that includes a report of known issues detected in your Calendar folder. The Calendar Issues report, powered by CalCheck, also uses a reading pane to display the issue description and solution link as well as a link to open the item from your calendar.

image

Outlook scan type more discoverable

To help you quickly identify the type of scan (Full or Offline) performed for Outlook, the Scan type value is displayed on the REPORT and MANAGE SCANS pages.

image

image

Additional details and functionality included with each scan

All scans taken on your computer, or imported from other computers, are listed on the MANAGE SCANS page in OffCAT.

image

The MANAGE SCANS page has several new features that will improve your efficiency working with previous scans from your computer or those imported from other computers.

  • Toolbar displayed for each scan provides viewing, exporting and emailing functions

image

  • Tooltip indicating the number of issues identified in the scan

image

  • Sorting and filtering options

Click Application to sort the list, alphabetically by Office program name, or click Filter to select which Office program scans to show in the list.

image

Real-time error and crash detection

The real-time error and crash detection features will help you resolve known issues more quickly than running an after-the-fact OffCAT scan. These real-time features scan errors displayed by Office programs and any crashing events, quickly comparing them against a list of known errors and crashes. If there is a match, a warning is displayed in the form of a notification alert. And, all of this happens in real-time when the OffCAT application isn’t even running.

The following figure shows a common error in Outlook and the real-time error alert which appears seconds after the error appears in Outlook.

image

Similarly, the following figure shows a known crash that was detected by OffCAT.

image

To find the solution to either error, all you have to do is click the alert.

These alerts, and many other important functions in OffCAT, are provided by the new background process OffCAT_RTS.exe that gets installed by OffCAT. Right-click the OffCAT icon in the notification area to access some of the additional functionality provided by this process.

image

OFFCAT ribbon tab in Office programs

One of the biggest new additions to OffCAT v2 is the OFFCAT ribbon that appears in every Office program that supports custom ribbons. For example, the following figure shows how the OFFCAT ribbon appears in Microsoft Outlook.

image

The OFFCAT ribbon provides access to a lot of the information and features in OffCAT without having to leave the Office program.

  • Program update status

When the current program has all the latest updates installed and you have recently scanned the program with OffCAT, there’s no need to take any action.

image

However, if the program is out of date, click the control to get quick access to the needed update(s) for that particular Office program.

image

If your Office program has not been recently scanned by OffCAT, you will need to perform a quick scan of the program so OffCAT can check on your update status for that program.

image

  • Configuration summary

The Configuration Summary control provides a convenient way to display relevant details about Windows, machine, user, Office, the current program, and other components from your computer.

image

Click Configuration summary to see this information displayed in a text file.

image

This text file is created and saved into the folder in which your OffCAT scan files are saved. So, it can be easily shared or emailed.

  • Cached errors and crashes

In the event you are busy when the alert appears or you do not happen to catch the alert while it is displayed for 30 seconds, you can still access solutions using the Errors and Application Failures controls on the OFFCAT ribbon tab.

Simply click the item displayed in the list below the control to open the online article containing the relevant solution.

image

  • Top ‘How To’ Articles

The Top ‘How to’ Articles control on the OffCAT ribbon displays a list of articles determined to be the most frequently accessed ‘How to’ articles for the current program.

image

The list of articles is dynamic, can be updated periodically when new OffCAT detection rule files are downloaded, and varies depending on multiple factors:

  • Office program
  • Program version
  • Office 365 customer

The following figure shows the original article list you see in Outlook 2013 for a customer with an Office 365 account.

image

Click any topic in the list to open the article related to that topic.

  • Specialized logging (Outlook only)

In Outlook, an additional ribbon control called Specialized logging is displayed.

image

Clicking the Specialized logging control in Outlook gives you convenient access to the tools found under Outlook Logging on the ADVANCED TOOLS page in OffCAT.

image

Advanced logging tools for Outlook

On the ADVANCED TOOLS page in OffCAT you will find several tools for advanced diagnosis of Outlook-specific issues or problems with KMS activation for Office.

image

The Outlook Real-Time Logging page provides access to user-friendly logging information for several common scenarios where advanced logging can help bring resolution.

image

Here is an example of logging output for the ‘Junk mail decision process’ scenario:

image

Note, the available logging option scenarios vary, depending on your version of Outlook.

Scenario

Logging available for Outlook version

Message stuck in the outbox

2013

Junk Mail Decision Process

2013, 2010

Offline Address Book Download

2013, 2010

Synchronization Issues

2013

Please always scan Outlook with OffCAT before considering using the Outlook-Real Time Logging feature. There are many detection rules in OffCAT that can identify the root cause of many issues in each of the logging scenarios.

Calendar Checking Tool (CalCheck)

The Calendar Checking Tool component of the ADVANCED TOOLS in OffCAT scans your calendar the same way that’s done with a Full scan of Outlook -- using CalCheck.

image

However, on the ADVANCED TOOLS page you can customize your CalCheck scan results using the Options control on the page.

image

Once you scan your calendar with the Calendar Checking Tool, the report interface is designed to help you quickly identify problematic meetings and find the solutions for them.

image

Additional Information

The OffCAT v2 ReadMe file contains a great deal more information on features, functionality, and administration of OffCAT. This includes, but is not limited to:

  • Installing OffCAT, including system requirements
  • Scanning programs with the command-line version of OffCAT (OffCATcmd.exe)
  • Managing OffCAT through policy settings

We encourage everyone, especially people that use OffCAT in any Help Desk/Support context, to review the ReadMe file so you can take full advantage of everything found in this latest version of the tool.

OffCAT v2 ReadMe

Greg Mansius

Coming soon: A first look at Exchange Server 2016

0
0

Less than three weeks to go until Microsoft Ignite kicks off in Chicago! Based on how many members of the sellout crowd have identified themselves as Microsoft Exchange Conference alumni, it looks like we’ll have an excellent turnout from the Exchange community. We’re excited to talk face-to-face with you about all things Exchange.

At Ignite we’ll give you a first look at Exchange Server 2016, the on-premises release that we plan to ship in the second half of this year. This new version of Exchange includes innovation across a broad set of areas, including individual productivity, team collaboration, and information governance. There are new features, enhancements, and refinements that add up to goodness on the way for end users, IT, and your organization as a whole.

To highlight a few examples:

  • A new approach to document collaboration that makes it easy to send links and collaborate without versioning issues of attachments
  • Faster and more intelligent search, to help users quickly find what they need in their mailboxes and calendars
  • Significant improvements to eDiscovery search performance and reliability
  • Better extensibility, including new REST-based APIs for Mail, Calendar, and Contacts that simplify web and mobile development

If you’ve been keeping tabs on Office 365 since we shipped Exchange Server 2013, many of these new capabilities will be familiar. Most of the new features in Exchange Server 2016 were birthed in the cloud and then refined in a feedback loop that includes millions of mailboxes deployed worldwide. The same is true of back-end improvements to Exchange architecture, high availability, and storage. We are now working to bring these elements to the diverse world of on-premises environments. You can join our on-premises Technology Adoption Program if you want to be a partner in that process.

We still have much to do before Exchange Server 2016 ships, but we’re confident that its simplified architecture, performance improvements, new user experiences, better extensibility, and tight integration with products like SharePoint Server 2016 add up to a solid release.

We look forward to sharing more details with you at Ignite!

P.S. If you didn’t snag a ticket before Ignite sold out, don’t worry. You’ll be able to watch recordings of all sessions—including the Meet Exchange Server 2016 overview and all the Exchange sessions—on the Web within 48 hours after they happen.

The Exchange Team

A better way to collect logs from your Exchange servers

0
0

Do you dislike having to collect diagnostics logs manually from each server in order to troubleshoot an issue or establish a server performance baseline? Did it ever happen to you that you collected the logs, but then found out that you needed more logs from the time the issue was happening, but when you went back to try to collect the needed logs - you found out that they have been over-written?

I have been working on a script that allows you to collect all the Exchange logs that you need and copies them over to a different location. The script can even zip up all the files for you so all you have to do is run it on each server and upload the data once it is done. By default, the script will only collect your App/Sys logs from the server, as we want to specify through switches (please see the download page for a list of them all) what data we want to collect so we are able to collect only the relevant data needed for the issue at hand. If you don’t know which logs you need, you can just use the switch AllPossibleLogs and it will collect everything that you need based off the version of Exchange and the role(s) that you have on the server.

Currently the script only supports Exchange 2010 and 2013, as there isn’t much logging in Exchange 2007 running by default. With Exchange 2010 we by default started to log more information to help us troubleshoot issues (which we then increased again in Exchange 2013), however, all the common logs that Exchange Support does look at in order to troubleshoot issues are collected based on the version of Exchange that you run the script on. One of the major differences in the script run between 2010 and 2013 is the way you need to zip up the logs. In 2010 we don’t have .NET Framework 4.5 installed, so I rely on 7za.exe utility that you can use to have the script zip up your files (or you can also specify that you do not want the files to be zipped up at all). In order to take advantage of this, you would just need to have the 7za.exe file in the same directory as the script, and use the SevenZip switch when executing it. The location of where to download this utility is within the header of the script if you need to download it.

Why was this created?

The reason why I created this script was because when I was troubleshooting a performance issue with a customer, we were collecting GBs of data (from all relevant servers) every day in order to get a baseline of the server’s performance and compare that to the time when we were having issues. Since in this environment the customer had to collect the data manually, sometimes all the data that I requested wasn’t there or was already overwritten by the time they got to collecting the logs. By creating this useful script, we were able to just run it each day and it would collect all the correct information, move it over to another drive on the server and zip it up for us so we didn’t have to worry about logs being over-written. Then all the customer needed to do was upload the data to me once it was finished.

How to run the script

Download the script from here. Place it on your Exchange server and open up an EMS or PowerShell session as an Administrator. If you don’t run it as an Administrator, it will error out:

image

Then you just need to determine the location you would like the data saved to, and what logs you would like collected.

If you don’t specify a location, the script will automatically select “C:\MS_Logs_Collection” as your location to copy the data over to. There is also an automatic check that verifies that the drive letter has at least 15 GB of free space (if you are not zipping up the data, this requirements goes to 25 GB), as we don’t want to fill up any drives on the server.

The data that you want to collect is really dependent on the issue that you are having. If you don’t know then it is just best to collect it all and use the AllPossibleLogs switch. This would be recommended if you ran into an issue and you would like to investigate the root cause of, at a later time. If you do know which logs you would like to collect, you can use the switches for each set of logs. For example if you know you want to collect the IIS logs there is a single switch called IISLogs. This switch is going to go through and collect the IIS and HTTPErr logs based off the role(s) that you have installed on the server. It is a common mistake to not collect both, or that the FE and BE IIS logs get mixed together and those things can cause more delays in getting the data reviewed. As we don’t need to whole directory for the IIS and HTTPErr, the script will only go back X number of days (3 is the default) and you can specify how far you would like to go back with the DaysWorth switch. If you would like to know more about the available switches that are in the script and what they do, please look over the script download page.

Here are a couple of examples of the script working and how it collects the data

.\CollectLogsScript.ps1 -FilePath C:\MyLogs -IISLogs -EWSLogs -DaysWorth 1

image

As you can see, we do have progress bar of where the script is currently at. Keep in mind that for large amounts of data, it can take a while to complete a compression step before it moves on to the next set of logs. After we collect one type of log, we go through and zip up that folder in order to save on drive space, then remove the original folder. This is only done for the original sub folders of the main root folder, which is the name of your server. This root folder will also get zipped up and append the M/dd of when you ran the script so you can just have one .zip file, but the original root folder will not get removed from this location.

Once the run is complete you will have something like the following:

image

Looking inside of the folder:

image

If you are collecting additional data like experfwiz, Netmons, ExtraTrace, etc. and that data is in the same directory, you can include it into the collection as well by using the CustomData switch:

.\CollectLogsScript.ps1 -CustomDataDirectory C:\PerfCollection –CustomData

That example will collect everything in the C:\PerfCollection folder and sub directories. You would use this if you wanted to collect an additional directory of data that Exchange doesn’t log by default, or other types of logs that this script doesn’t collect. However, I would not recommend to use this for very large files like process/memory dumps, as it can take a very long time to copy, compress, and then upload larger files. Experiment with what will work for you!

I also included a switch called IISLogDirectory in the script for those environments where the default location of IIS (C:\inetpub\logs\LogFiles) has been moved. Now all you need to add in this parameter is the Parent directory of “W3SVC1” or “W3SVC2” and the script will automatically add the correct IIS sub directory to collect. Here is an example of how to use this:

.\CollectLogsScript.ps1 –FilePath D:\MS_Logs –IISLogs –IISLogDirectory E:\IISLogs\LogFiles

That would collect the IIS logs from the directory called E:\IISLogs\LogFiles\W3SVC1 and/or E:\IISLogs\LogFiles\W3SVC2 if you are on Exchange 2013, with both roles installed.

In the script there is also a switch that is called DatabaseFailoverIssue, which allows you to collect the correct data from your server that recently had a database failover. It collects the performance data, the clustering event logs, the managed availability logs, as well as the Application and System logs from the Exchange 2013 server that you run it on. If you are on Exchange 2010 then it will collect just the Application, System, and clustering logs. If you are running this switch because you did have a failover issue recently, I would highly recommend that you run this script on all servers within the DAG. This should provide you with enough information to help best determine the cause of the issue, as the database could failover for multiple reasons so by collecting all this information, we are covering all possible areas of default logging.

Conclusion

Hopefully providing a common way for you to collect data from your servers will help reduce the amount of manual work that you would need to do to collect the information needed to troubleshoot various issues or periodically collecting logs to establish baseline server behavior. It should also reduce the amount of times that we didn’t collect the correct information, then go back to try to collect it again and it is already overwritten.

Keep an eye out on the download location for newer versions of the script, as I will continue to fix issues that may come up that are reported to me and continue to improve and add features to the script that are needed to help improve the process of collecting data from the servers.

David Paulson

Larger messages and Enhanced NDRs come to Office 365

Generating user message profiles for use with the Exchange Calculators

0
0

Greetings Exchange Community!

My name is Dan Sheehan, and I work as a Premier Field Engineer for Microsoft, specializing in Microsoft Exchange. As a long time Exchange engineer I am an avid PowerShell scripter, and as such I end up writing a lot of PowerShell scripts.

Today I present to you one of those scripts that assists Exchange administrators/service owners with generating an Exchange “user message profile”. This “user message profile” is a critical part of the information entered into the Exchange Server Role Requirements Calculator and the Exchange Client Network Bandwidth Calculator (more on those below).

The script, which is published here on the TechNet Gallery, is designed to work in environments of all sizes, and has been tested in environments with hundreds of Exchange sites. The current version works with the Management Shell of Exchange 2010 and 2013, and I am working on a version for Exchange 2007. I have a number of scripts published on the TechNet Gallery, both from before I joined Microsoft and after, and I encourage you to check them out as well as the TechNet Gallery in general.

Without any further ado, on to the script.

Background

An Exchange “user message profile” represents the amount of messages a user sends and receives in a day, and the average size of those messages. This critical information is used by the Role Requirements Calculator to determine the typical workload a group of users will place on an Exchange system, which in turn is used to properly size a new Exchange environment design. This information is also used by the Client Bandwidth Calculator to estimate potential bandwidth impact email users will have on the network, depending on their client type and versions used.

Some Exchange service owners “guesstimate” a couple of different user message profiles based on the anticipated workload, while others use data from their existing environment to try and create a messaging profile based on recent user activity. Gathering the necessary information based on recent user activity and creating a user message profile is not an easy task, and quite often service owners turn to third party tools for assistance with this process.

This PowerShell script was created to assist Exchange service owners who want to generate average user message profiles based upon their current environment, but don’t have or want to use a third party tool to gather the necessary information and generate a message profile.

There are other messaging statistics gathering scripts published on the Internet, such as this this one by Mjolinor on the TechNet Gallery and this one by our own Neil Johnson (who BTW is responsible for the Client Bandwidth Calculator). Typically those types of “messagestats” scripts create a per-user report of all messaging activity which takes a long time, includes information beyond what is required to create a user message profile, and the output requires further manipulation to come up with an average user message profile. This script on the other hand focuses on just the messages sent and received by users, which is faster than gathering all messaging activity, and provides a user message profile per Exchange (AD) site versus individual user results.

Functionality

The script uses native Exchange PowerShell cmdlets to extract the mailbox count from mailbox role servers and mailbox messaging activity from the Hub Transport role server message tracking logs for the specified date range. The information is then processed to obtain user/mailbox message profiles consisting of averages for sent messages, received messages, and message sizes.

The script requires a start and end date, and can be run multiple times to accumulate groups/blocks of days into the final output. For instance instead of gathering 30 straight days of data from the Exchange servers, which includes weekend days that generally negatively skew the averages due to reduced user load, the script can be run 4 consecutive times using the 4 groupings of weekdays within that 30 day period which helps keep the averages reflective of a typical work day. The output to a CSV file can then be performed on the 4th and final week.

The script can be run against Exchange servers in specific AD sites, collections of AD sites, or all AD sites, and the generated message profiles that are returned are organized by AD site. The ability to specify a specific collection of AD sites is important for multi-site international Exchange deployments because not every location around the world follows a Monday through Friday work week. This functionality can be combined with the script’s ability to accumulate and combine data from multiple runs into a single report, even if some sites had to be queried using different date ranges.

The script can optionally provide a “total” summary user message profile for users across all collected sites under the site name of “~All Sites” which will show up at the top of the output. The collected data can be exported to a CSV file at the end of each script run, otherwise it will be automatically stored as PowerShell variable for further manipulation.

The script provides detailed output to the screen, including tiered progress bars indicating what site is currently being processed, what server in that site is being processed, and what specific processing activity is occurring. The script output also includes an execution time summary at the end so you can plan for future data gathering time requirements:

clip_image002

Resultant Data

There are a number of script parameters (covered below) that can be used exclude certain types of mailboxes and messages from the data gathering and subsequent output of the script. For example if you exclude all RoomMailboxes from the data gathering, then they won’t be reflected in the script’s output. This means the use of the words “all” and “total” below are in reference to the messages and mailboxes the script was told to gather and process, and not necessarily all of the data available on the servers.

The data in the output is grouped into the following columns per Exchange site (as well as the optional “~All Sites” entry):

image

  1. Site Name– This is the name of the AD site that the Exchange servers live in, as defined in AD Sites and Services.
  2. Mailboxes – This is the count of all mailboxes discovered in the site. This information is used by both Calculators.
  3. AvgTotalMsgs – This is the count of sent and received messages for the mailboxes in the site. This information is used by the Role Requirements Calculator.
  4. AvgTotalKB– This is the average size in KB of all included sent and received messages in the site. This information is used by both Calculators.
  5. AvgSentMsgs– This is the average count of sent messages for the mailboxes in the site. This information is used by the Client Network Bandwidth Calculator.
  6. AvgRcvdMsgs– This is the average count of received messages for the mailboxes in the site. This information is used by the Client Network Bandwidth Calculator.
  7. AvgSentKB– This is the average size in KB of sent messages for the mailboxes in the site.
  8. AvgRcvdKB– This is the average size in KB of received messages for the mailboxes in the site.
  9. SentMsgs– This is the total amount of sent messages for the mailboxes in the site.
  10. RcvdMsgs– This is the total amount of received messages for the mailboxes in the site.
  11. SentKB– This is the total size in KB of all sent messages for the mailboxes in the site.
  12. RcvdKB– This is the total size of KB of all received messages for the mailboxes in the site.
  13. UTCOffset– This is the UTC time zone offset for the AD site. This information is used by the Client Network Bandwidth Calculator.
  14. TimeSpan– This represents the amount of time difference between the clock on the local computer running the script and the clock of the remote server being processed. This is informational only.
  15. TotalDays– This represents the number of days collected for the site. This information is needed by the script when you are using it to combine multiple runs into a single output.

Parameters

The script has a number of parameters to allow administrators control what goes into/is excluded from the user message profile generation process. Most of the parameters are grouped into one of three “parameter sets”, with the exception of one parameter that is in 2 sets and a couple that are not in any set.

Parameter sets group related parameters together, so once a parameter is one set is chosen the only other available parameters are those in that same set and those that aren’t assigned to any set. Furthermore a required parameter is only required within its parameter set, meaning if you are using one parameter set, then the required parameters in other sets don’t apply.

If the concept of parameter sets is a little confusing and you are using Exchange 2013, then you can use the PowerShell 3 (and later) cmdlet Show-Command with the script to create a graphical representation of the parameter sets like this:

Show-Command .\Generate-MessageProfile.ps1

which will pop-up the window:

image

The script also supports the traditional -Verbose and -Debug switches in addition to what’s listed below:

Parameter

Set

Required

Description

ADSites

Gather

Optional

When set to “*” indicates all AD sites with Exchange should be processed. Alternatively explicit site names, site names with wild cards, or any combination thereof can be used to specify multiple AD sites to filter on. If no site is defined, the local AD site will be used. The format for multiple sites is each site name in quotes, separated by a comma with no spaces such as: “Site1”, “Site2”, “AltSite*”, etc…

StartDate

Gather

Required

Specifies the day to start the message tracking log search on, which starts at 12:00AM. The format is MM/DD/YYYY.

EndDate

Gather

Required

Specifies the day to end the message tracking log search on, which ends at 12:00AM. This means that if you want to search Monday through Friday, you need to specify the end date of Saturday so the search stops at 12:00AM Saturday. The format is MM/DD/YYYY.

ExcludePFData

Gather

Optional

Tries to filter out messages sent to or from Exchange 2010 Public Folder databases.

NOTE: This parameter is not recommended because its filter relies on message subject line filtering which could potentially filter out user messages. Additionally this does not filter out all Public Folder messaging data because some Public Folder message subject lines were not included due to the high likelihood that users would use them in their own messages.

ExcludeHealthData

Gather

Optional

Excludes messages sent to and the inclusion of “extest_” mailboxes and Exchange 2013 “HealthMailbox” mailboxes.

NOTE: Because the extest and HealthMailboxes can generate a lot of traffic, it is recommended to use this switch to get a more accurate message profile reflection of your users.

ExcludeRoomMailboxes

Gather

Optional

Excludes message sent to and the inclusion of room mailboxes. By default equipment and discovery mailboxes are excluded from the as they negatively skew the average user message profile. Room mailboxes are included by default because they can send/receive email.

NOTE: This parameter is not recommended if you have active conference room booking in your environment as that means you have active message traffic to and from room mailboxes.

BypassRPCCheck

Gather

Optional

Instructs the script to bypass testing RPC connectivity to the remote computers by using Get-WMIObject. Bypassing the RPC check should not be necessary as long as the account running the script has the appropriate permissions to connect to WMI on the remote computers.

ExcludeSites

Gather

Import

Optional

Specifies which sites should be excluded from data processing. This is useful when you want to use a wild card to gather data from multiple sites, but you want to exclude specific sites that would normally be included in the wild card collection. For data importing, this is useful when you want to exclude sites from a previous collection. The format for multiple sites is each site name in quotes separated by a comma with no spaces such as:

"Site1","Site2", etc...

NOTE: Wild cards are not supported.

InCSVFile

Import

Required

Specifies the path and file name of the CSV to import previously gathered data from.

InMemory

Existing

Required

Instructs the script to only use existing in-memory data. This intended only to be used with the AverageAllSites parameter switch.

AverageAllSites

<None>

Optional

Instructs the script to create an "~All Sites" entry in the collection that represents an average message profile of all sites collected. If an existing "~All Sites" entry already exists, its data is overwritten with the updated data.

OutCSVFile

<None>

Optional

Specifies the path and file name of the CSV to export the gathered data to. If this parameter is omitted then the collected data is saved in the shell variable $MessageProfile.
NOTE: Do not use this parameter if you are collecting multiple weeks of data individual, such as collections of work weeks to avoid weekends, until the last week so only the complete data set exported to a CSV.

NOTE: This list of parameters will be updated on the TechNet Gallery posting as the script is updated.

Examples

The following are just some examples of the script being used:

1. Process Exchange servers in all sites starting on Monday 12/1/2014 through the end of Friday 12/5/2014. Export the data, excluding the message data for Exchange 2013 HealthMailboxes and any extest_ mailboxes, to the AllSites.CSV file.

Generate-MailboxProfile.ps1 -ADSites * -StartDate 12/1/2014 -EndDate 12/6/2014 -OutCSVFile AllSites.CSV -ExcludeHealthData

2. Process Exchange servers in AD sites whose name starts with "East", starting on Monday 12/1/2014 through the end of Monday 12/1/2014. Output the additional Verbose and Debug information to the screen while the script is running. The collected data is made available in the $MessageProfile variable after the script completes.

Generate-MailboxProfile.ps1 -ADSites East* -StartDate 12/1/2014 -EndDate 12/2/2014 –Verbose -Debug

3. Process Exchange servers in the EastDC1 AD site, and any sites that start with the name "West", starting on Monday 12/1/2014 through the end of Tuesday 12/30/2014. Export the data, which should exclude most Public Folder traffic, to the MultiSites.CSV file.

Generate-MailboxProfile.ps1 -ADSites “EastDC1”,”West*” -StartDate 12/1/2014 -EndDate 12/31/2014 -OutCSVFile MultiSites.CSV –ExcludePFData

4. Import the data from the PreviousCollection CSV file in the current working directory into the in-memory data collection $MessageProfile for future use.

Generate-MessageProfile.ps1 -InCSVFile .\PreviousCollection.CSV

5. Process the previously collected data stored in the $MessageProfile variable and add an average for all the sites is to the data collection as the site name “~All Sites”.

Generate-MessageProfile.ps1 -InMemory -AverageAllSites

FAQ

1. Is the output generated by this script an accurate representation of my user’s messaging profile, which I can use in other tools such as the Role Requirements Calculator?

  • This script generates a point in time reflection of your user’s messaging activity. The data is only as good as the date range(s) you selected to run it in, the data you opted to include or exclude, and the information stored on the accessible servers. For example if you ran this script during date range that included a holiday and a lot of users took vacation, then the information is going to reflect a lower average message profile than a more “normal” work period would reflect.
  • Taking into consideration that this script will only reflect the messaging activity of your users during your selected date range, you should use the output as a guideline for formulating the message profile to represent your users in other tools.

2. Should I inflate/enhance the message profile produced by this script to give myself some “elbow room” in my Exchange system design?

  • If you are designing an email system that is going to need to last for multiple years, it’s probably a good idea to increase the numbers slightly to account for future growth of your system and the likelihood that yours will increase their message profile over time. How much you inflate the information is up to you.

3. The messaging profile for my users seems lower than I expected. What are some factors that could attribute to this/how can I increase the values generated by the script?

  • Review the data range(s) you chose when running the script to see if they were periods of time where user activity was expected to be low.
  • If your date range(s) include weekends/non-work days, re-run the script excluding those days. This may require multiple cumulative runs if you want to include multiple work weeks in the average.
  • If you have a lot of resource rooms that are rarely used but you did not exclude them, then try re-running the script with the ExcludeRoomMailboxes parameter to see if the averages increase. Conversely if you used some of the script’s parameters to exclude data, re-running the query without the exclusions may increase the average as well. You will need to test various parameter combinations in your environment until you are happy with the results.
  • If you recently decommissioned any Hub Transport role servers in a site, then the message tracking logs stored on those servers that provide user activity details were removed as well. Therefore it his highly recommended that this script only be run on sites that have not had any Hub Transport role servers decommissioned during the specified time ranges. The script even has a built in warning when it detects a Hub Transport role server was added to a site during the specified date range, to remind you that if another Hub Transport role server was recently removed from that site as well then the user message profile could be negatively affected.

4. Why don’t I see any per-user information? Why is this site based?

  • This script was designed to maximize speed by gathering messaging profile information on a per-site basis to facilitate the use of both the Role Requirements and Client Network Bandwidth Calculators. The Client Bandwidth Calculator wants the message profile information on a per-site basis, and the per-site basis works for the Requirements Calculator as well. Reporting on per-user information is being considered for a future version of this script.
  • Per-user information is not needed for either Calculator. Separate user profiles can be optionally put into each Calculator using the same message profile but reflecting other differences such as larger mailboxes or expected IOPS increases (such as when a group of users also using mobile devices).
  • If you require per-user reporting, please use one of the scripts I referenced in the Background section.

5. Why did I get an alert that one or more sites were skipped or excluded?

  • A site will be skipped if there were connectivity issues to any server in the site. Since a message profile for a site must contain data from all of the servers, missing data from even one server could result in incomplete information. Therefore the script will skip the site if it encounters connectivity issues to even one server versus reporting only partial data.
  • A site will be excluded if there are no mailboxes or messaging activity found in it. Passive Exchange DR sites with no active mailbox databases are an example of a site that will be safely excluded. Even though there may be active Hub Transport servers in those sites, their message tracking data is not needed as they will hand messages off to Hub Transport role servers in the site(s) with the target mailboxes. The logs from those final Hub Transport role servers will in turn be used for the message profile generation.
  • If any sites were skipped for data collection issues, they will be recorded in a $SkippedSites variable which will be available after the script finishes. This allows you to re-run the script and specify the $SkippedSites as the value for the ADSites parameter, which causes the script to focus gathering data only from those skipped sites. This is helpful in cases where server connectivity issues were due to temporary WAN connectivity issues, and another run of the script will process those skipped sites successfully.

6. Why can’t I specify the hours of a day I want to be searched in addition to the days?

  • The script is designed to work with whole/entire days, not fractions of a day, to create the averages. Specifying a time of day would result in a faction of a day which is not supported in creating a “per day” user message profile average.

7. Why does the EndDate need to be the day following the day I want to stop reporting on?

  • When only a date is used for a “DateTime” variable, PowerShell assigns the time for that day as 12:00AM. For the StartDate, that time is exactly what needs to be used as that represents the entire day starting 12:00AM. However for the EndDate this causes the data collection to stop at 12:00AM on the specified day, therefore the EndDate needs to be the day following the last day you want included in the output.
  • The script has logic built in to ensure that the Start date does not occur in the future, that the End date does not occur before the Start date, the Start date is at least on day prior to the current date, and that the End date is no later than the current date.

8. Why would I want to store data in a CSV file and then later import it with the script?

  • Sometimes some sites just can’t be reached over the WAN. This allows for the data collection to be performed locally on server in the remote site, and then the data transferred back to the main site via a CSV file where it can be imported into the main data collection.
  • This functionality also allows you to take data collections from different points in time, such as over the course of several weeks or months, and import it into a single longer term user message profile generation.
  • This functionality also allows you to take the data in-memory and remove sites from the collection by exporting it to a CSV, and then re-importing the data to a new collection and using the ExcludeSites parameter to block the import of the unwanted sites.

9. What is the purpose of the InMemory parameter?

  • The only reason to use this switch is if you already have your data loaded into memory, either through one or more gathering or importing processes, and want to use the AverageAllSites parameter to provide a single global user message profile under the site name of “~All Sites”. Essentially this parameter allows you to bypass gathering or importing data and just use what is already “in memory”.

10. Why do I get an error about “inconsistent number of days” when I try to use the AverageAllSites?

  • The process that generates a single global user message profile requires that the value for TotalDays be the same for all collected sites. Otherwise the aggregated data would be represented incorrectly because the TotalDays value is used to calculate the “per day” average. You need to review your site data, most likely by exporting it to a CSV file and reviewing it manually, to determine which sites have different TotalDays recorded and deal with them accordingly.

11. Why is the information saved to the $MessageProfile variable if I don’t use the –OutToCSV parameter? Also how do I “wipe” the collected data from memory so I can start over?

  • Storing the data inside of PowerShell variable is necessary if you want to run the script multiple times to accumulate data, because the script uses this variable to store the cumulative data in between runs.
  • This also allows you to take the in-memory $MessageProfile variable data and pass it to other PowerShell scripts or commands that you wish.
  • You have the option of using the command “$MessageProfile | Export-CSV ….” to create your own CSV if you decide to later store the collected data in a CSV file.
  • To clear the $MessageProfile data from memory use the following command:

$MessageProfile = $Null

12. Why does the output of the script include a value called “TimeSpan” and also the time zone of the remote site?

  • The time span represents the delta in hours, positive or negative, between the server running the script and the remote server it is connecting to. By default when the Get-MessageTrackingLog cmdlet is executed against a remote server, the DateTime values used for the start and end dates passed to it are always from the perspective of the server running the cmdlet. This means that if the computer running the cmdlet is 5 hours behind the remote server, then the dates (which include a time of day) passed to that remote server by the cmdlet would actually be 5 hours behind your intended date.
  • The script uses this time span to properly offset the DateTime values as they are passed to the Get-MessageTrackingLog cmdlet, so they are always processed by the remote server with the original intended dates (and the 12:00AM time of day). Following the example above, the script will add 5 hours to the date when the cmdlet is run against the remote server. Since this value is crucial to accurate script execution, it is recorded in the output for tracking purposes.
  • The Client Network Bandwidth Calculator wants to know the time zone of the user message profile being specified. To facilitate use of this calculator, the site’s time zone information is recorded in the output of the script.

13. Why did you build in an ExcludePFData parameter switch if it doesn’t exclude all Public Folder traffic?

  • Initial testing of the script showed that dedicated Public Folder servers reflected a large amount of Public Folder replication based Hub Transport messaging activity.
  • Because the most accurate depiction of the user messaging profile was desired, a switch was added to try and filter out some Public Folder replication data. Since the only way to consistently identify the Public Folder traffic was by message subject line keyword matching, a filter was created that strips out messages with Public Folder replication subject phrases not likely to be used by users to try and limit accidentally stripping actual user messages.

14. I see Equipment and Discovery mailboxes are excluded, why aren’t Arbitration Mailboxes excluded?

  • Equipment and Discovery mailboxes do not send and receive email through the Hub Transport service, so including them would only serve to negatively impact the user message profile.
  • Arbitration mailboxes on the other hand are normally limited in number and therefore including them in the mailbox count is not expected to dramatically impact the message profile in a negative way. At the same time messages can be sent to and received from Arbitration mailboxes, depending on the organization’s use of features like moderated Distribution Groups, so including them could positively impact the message profile.

Conclusion

So there you have it, a PowerShell script to assist you with generating an average user message profile for your environment, with a number of options for you to tailor it to your preferences. I hope you find it useful with the two calculators, but also any future troubleshooting efforts of your existing environment.

When I finish the Exchange 2007 version, I will attach it to the TechNet Gallery posting, so if you are looking for that version please check back periodically. Likewise as I make enhancements or other changes to the script, I will be updating the TechNet Gallery posting. So please check back with that posting periodically.

Lastly I am always open to suggestions and ideas, so please feel free to leave a comment here or reach out to me directly.

Thanks and happy PowerShelling!

Dan Sheehan
Senior Premier Field Engineer

Viewing all 607 articles
Browse latest View live




Latest Images