Using Search-Mailbox to look for items with a specific date


A question from a reader is often a good start to a useful discussion or to probe into a topic. Tim Read contacted me to discuss some problems he had with using the Search-Mailbox cmdlet (available in cloud and on-premises versions of Exchange). In this case, he was using Exchange 2013 CU5 and wanted to be able to search mailboxes for items that matched specific values for the sender, date, and subject attributes.

Apparently it was easy enough to run a search that found items that matched a combination of sender and subject but things got a little tricky when a date was thrown into the mix and not much joy was extracted from examples found on various sites.

Parser errors were reported when a date was specified, which indicated that the date was in a format unacceptable to Search-Mailbox. Some confusion arose on this point as it is natural to assume that search criteria have to be stated in KQL syntax because this is what is used by the Search Foundation, which provides the indexes that Exchange interrogates to perform mailbox searches.

However, the Search Foundation was only introduced in Exchange 2013 and code written for Exchange 2010 has to continue working on Exchange 2013 or in Office 365. The cmdlet therefore masks the change that occurred in the underlying search engines. Dates should be formatted like any other date consumed by Exchange according to the locale installed on the server.  So 1 October 2014 is “1/10/1014” in Ireland or the U.K. or “10/1/2014” in the U.S. Alternatively, you can pass a date like “14-Oct-2014” in either locale.

Now that we understand how to format dates, we can construct a Search-Mailbox command to do the work. This example creates a collection of mailbox objects from a database and searches them for items sent by a user called “Ben Andrews” (the SMTP email address for the user can also be used) on 13-Oct-2014 with “Interesting” in the message subject. Items in the Recoverable Items folder structure are included in the search.

Get-Mailbox –Database VIP –ResultSize Unlimited | Search-Mailbox -TargetMailbox AdminSearchMailbox -TargetFolder “Search Results” -SearchQuery {Subject:"Interesting" AND From:"Ben Andrews" AND Sent:"10/13/2014"} -LogOnly -LogLevel Full –SearchDumpster

This command will create a log of the discovered items in the target folder in the target mailbox. No items are copied unless the –LogOnly switch is removed. If the command is then rerun, Exchange creates a folder named after the searched mailbox and date and time in the target folder and copies the discovered items there, placing them in sub-folders corresponding to the folders in the source mailbox.

Search-Mailbox is often to remove unwanted items that arrive into user mailboxes. This is done by adding the –DeleteContent switch to a command. Clearly you should not rush into removing content from mailboxes until you are absolutely sure that your command targets the correct items, which is one good reason to run a command with the –LogOnly switch before proceeding to delete anything.

Exchange protects administrators against themselves by requiring those who want to delete content to possess the special “Mailbox Import Export” Role-Based Access Control (RBAC) role. As the role name implies, it is designed to allow administrative access to user mailbox data to import data from PSTs or export items to PSTs. In this instance, it’s used because deleting content is obviously something that should be controlled.

If your account does not hold the role, you won’t see the –DeleteContent switch or be able to use it with the Search-Mailbox cmdlet. You can either create a new RBAC role group containing the role and assign it to the appropriate users or add the role to an existing role group, which means that any user that is already part of the group will be able to use the switch. For instance, here’s how to add the role to the Organization Management role group, which is what I did for my Office 365 tenant.

New-ManagementRoleAssignment -Name "Import Export_Organization Management" -SecurityGroup "Organization Management" -Role "Mailbox Import Export"

You have to create a new EMS session to pick up the RBAC amendments because RBAC only evaluates a user’s permissions when EMS initializes. Once EMS is ready, I can run a command like this to remove the offending content.

Get-Mailbox –Database VIP –ResultSize Unlimited | Search-Mailbox -TargetMailbox AdminSearchMailbox -TargetFolder “Search Results” -SearchQuery {Subject:"Interesting" AND From:"Ben Andrews" AND Sent:"10/13/2014"} -DeleteContent -LogLevel Full –SearchDumpster

So there you are… A reader query that led to some interesting consideration of a very useful command and its various switches. Hopefully this will help others who struggle with similar challenges.

Follow Tony @12Knocksinna

About these ads
Posted in Exchange, Exchange 2010, Exchange 2013 | Tagged , , , , , | 3 Comments

The strange case of the MailboxSentItemsConfiguration cmdlets


Microsoft introduced the rather useful cmdlet set of Set-MailboxSentItemsConfiguration and Get-MailboxSentItemsConfiguration a long time ago (Exchange 2010 SP2 RU4 – August 2012). As you might recall, these cmdlets allow an administrator to exert control over where Exchange stores copies of messages sent by delegates.

What’s surprising and genuinely puzzling is that the cmdlets were not included in Exchange 2013 RTM and have not appeared in any version since, including Exchange 2013 SP1 (where you might have expected them to show up) or even the latest Exchange 2013 RU6 update. The cmdlets have also failed to show up in Office 365, at least not in my tenant domain.

When the cmdlets first appeared in Exchange 2010 SP2 RU4, I thought that they were an elegant solution to the need to mess with registry settings to instruct Outlook how to handle messages sent by a delegate. I content that the right place is in the Sent Items folder of the mailbox belonging to the user for whom the message is sent. Outlook prefers to squirrel the message away in the Sent Items folder of the delegate’s mailbox.

The registry hack involves creating a new DWORD value called DelegateSentItemsStyle, setting its value to 1, and then restarting Outlook. I’m not saying that I dislike a ramble through the registry. Sometimes you have to get down and dirty to convince Windows and various programs to do the right thing. Thankfully, we have to resort to RegEdit far less now than in the past, but the same major problems exist. First, registry hacking is extremely prone to errors. Second, the registry is specific to a single PC and usually, to a specific version of a product. In this case, the new value has to be added in different places depending on the version of Outlook you use.

In short, a registry hack is a great way for a developer to influence the way a product works for demonstration environments. It is an awful way to accomplish a long-term change in product behaviour that can be managed centrally and endures across multiple product versions and service packs. The Office products attempt to mitigate the problem by being able to set registry values through group templates, but that’s a workaround that has its own particular charms and flaws.

Exchange has done an awful lot over the Exchange 2010 and Exchange 2013 releases to permit administrators to be able to control mailbox settings for users through EMS cmdlets such as Set-MailboxAutoReplyConfiguration. The appearance of the *-MailboxSentItemsConfiguration cmdlet pair seemed to be just another step along the path to allowing administrators to script the correct configuration of user mailboxes as they were created and was, in my mind, a very good thing.

So I remain puzzled and bemused why these cmdlets have not appeared in either Office 365 (where they would seem to be perhaps even more valuable than in an on-premises deployment) or Exchange 2013. The code still works and functions well inside Exchange 2010. I’m sure that the Exchange developers have their own reasons for not bringing it forward into the latest products but I don’t know why. Strange!

Follow Tony @12Knocksinna

Posted in Exchange, Exchange 2010, Office 365 | Tagged , , , , , , | 3 Comments

Recoverable Items and Calendar Versioning


Keeping track of calendar items such as meetings to ensure that a definitive version of the item is available is sometimes hard to do, especially when multiple clients or multiple users access a calendar. Exchange 2010 made architectural changes in the server to concentrate processing in a common set of business logic, a step that helped matters because it stopped items being processed differently in various places.

It is still possible for misbehaving clients to wreak havoc with calendars, as in the case of the woes of Apple’s iOS email app, However, better awareness of potential problems within mobile device vendors, new code to protect Exchange against malfunctioning clients, and the introduction of mobile clients that don’t use ActiveSync (like OWA for Devices) have all helped to reduce calendar problems.

Apart from consolidating the business logic for calendar processing, Exchange 2010 introduced calendar versioning to improve overall reliability for events like meetings. Calendar versioning means that Exchange keeps track of all the changes that occur to calendar events so that the Calendar Repair Assistant (CRA) can validate that the calendar reflects the most current and accurate state. Sounds good, which is why calendar versioning is enabled by default. Enabling the feature comes with a certain price, which Microsoft’s sizing guidelines for Exchange 2013 puts at an increase of approximately 3% in mailbox size.

If you want to disable calendar versioning for a mailbox, you can run the Set-Mailbox cmdlet as follows:

Set-Mailbox –Identity TRedmond -CalendarVersionStoreDisabled $True

After you’ve disabled calendar versioning, the Managed Folder Assistant will clear out the saved items the next time that it processes the mailbox.

So where does the Recoverable Items folder come into play for calendar versioning? Well, Exchange has to hold the changes made to calendar items somewhere if the CRA is to be able to validate matters. As it happens, the Recoverable Items folder is the place where the changes are held, if only because this location is invisible to clients like Outlook and OWA. You could argue that it would be better to record the data elsewhere, such as another hidden folder, but the Recoverable Items folder is available and it is quota-controlled, as we’ll come to later.

The normal state of affairs is to hold “stripped” versions of calendar items in the root of the Recoverable Items folder for 120 days. Stripped means that only the essential details of the items are retained. Attachments any extraneous information are removed. In essence, sufficient information such as meeting location, time, duration, and so on is kept to allow CRA to do its work, but no more.

But when information needs to be preserved, such as on a short term basis (Single Item Recovery) or longer (litigation or in-place hold), then Exchange retains full copies of changed calendar items in the Recoverable Items\Deletions folder (if the item was first soft-deleted and then changed) or Recoverable Items\Versions folder (if the item is changed in the Calendar folder). A stripped version of an item is also preserved if a hard-delete operation is performed against a calendar item in the Recoverable Items\Deletions folder. All of this is done to make sure that information is preserved in an immutable fashion. In other words, users cannot take actions to remove information when they should not.

Getting back to Recoverable Items quotas, it is possible that a mailbox that hosts a very busy mailbox might accumulate a lot of calendar versioning data in the Recoverable Items structure, especially if it is common practice to include large attachments in meeting requests, as is often used when circulating information that will be discussed during the meeting. Despite steps taken by Microsoft in Exchange 2010 SP2 RU2 and RU3 to restrict the amount of quota consumed by calendar versioning, it is conceivable that a large percentage of the recoverable items quota might be taken up by calendar items with a knock-on effect of excessive database growth and potentially problems moving mailboxes. For very active mailboxes, the space consumed by calendar versioning might even push the mailbox to up its recoverable item quota.

All of this goes to prove that the Recoverable Items folder deserves some tender loving care from Exchange administrators. While you might not need to learn the exact details of what happens under the covers until problems occur, it is worthwhile to keep an eye on the use of the Recoverable Items folder in your organization.

Follow Tony @12Knocksinna

Posted in Email, Exchange, Exchange 2013 | Tagged , , , , , | 3 Comments

Exchange Unwashed Digest – September 2014


September 2014 included Exchange Connections in Las Vegas (all seemed to have a great time) plus some upheaval in Microsoft, so there was plenty to discuss in my “Exchange Unwashed” blog at WindowsITPro.com. Here’s what happened during the month:

The best Exchange documentation update ever? (Sept 30): I received criticism from some Microsoft employees for posting this note about a change made by a technical writer to the Exchange documentation before they lost access to the corporate network. But it was a good change (now reversed) because it recognized the achievements of some who should be acknowledged. And anyway, if you put something on the Internet, it becomes fair game for commentary…

Microsoft layoffs impact Exchange technical writers – where now for documentation? (Sept 25):  Layoffs are horrible exercises in corporate reductions, but some are worse than others. I didn’t like the way that Microsoft cut some of their technical writing talent during round 2 of their current layoffs because I think it weakens their ability to communicate complex technical content to the Exchange community. When Exchange 2016 comes into sight next year, we will realize the full impact of this change.

Chrome problem for Exchange due to Google haste and Microsoft inattention (Sept 23): The problem caused by Chrome 37 revealed an interesting lack of communication and attentiveness on the part of both Google and Microsoft. I don’t think Google quite realized the impact of the change on enterprise applications (like OWA and EAC) and Microsoft definitely didn’t track the thinking that Google expressed in various forums. So we came to a point where Chrome 37 appeared and everyone had a problem. Not good.

Wrapping up Exchange Connections 2014 (Sept 19): There really is a role for independent technology conferences that focus on real-world problems. At least, that’s what the folks who attended Exchange Connections seem to say after hearing great sessions delivered by great speakers in a great location (the Aria Hotel in Las Vegas). It was nice to avoid lashings of corporate marketing too. I hope that you’ll consider joining us next year.

Product quality and functionality gaps top-of-mind issues at Exchange Connections (Sept 17): The folks who come to Exchange Connections tend to be IT professionals who are responsible for running servers, so when they were asked about current concerns, they reflected on some recent quality problems experienced by Exchange 2013 (CU6 specifically) and a gap that seems to be growing between the functionality available in cloud versions when compared to on-premises software.

Google kills showModalDialog API in Chrome 37 and does evil to Exchange (Sept 15): Google shipped Chrome 37 in late August but it took a little time for software updates to make their way onto user PCs, at which time people started to notice that some of the user interface components in OWA and EAC just didn’t work any more. The problem affected Exchange 2010, Exchange 2013, and Exchange Online and it’s all due to a decision Google took to deprecate the showModalDialog API. After all, it’s old and tired – a bit like me, really. For more details on just how this problem developed, see my September 23 post above.

Office Delve debuts to help Office 365 users find information again (Sept 11): I really like Office Delve, the new Office 365 launched by Microsoft to exploit the power of the underlying “Office Graph” technology. I like Delve because I think it’s an interesting new approach to exposing and eradicating the information silos that develop all so rapidly inside large organizations. Of course, it’s early days yet, but I like what I see…

Yet another co-existence bug in Exchange 2013 CU6 causes ActiveSync failures for Exchange 2007 users (Sept 6): Just when you thought it was safe to start deploying Exchange 2013 CU6 (which really works very well in many circumstances), along came yet another co-existence bug, this time to afflict ActiveSync users whose mailboxes were still on an Exchange 2007 mailbox server. Maybe they should be using a more modern server? Or perhaps these bugs shouldn’t happen…

Sad death of Exchange expert Andrew Ehrensing (Sept 4): This was a really sad note to write, but so many people had experienced the wit and expertise of Andrew Ehrensing that his passing had to be acknowledged. Sad…

Why Exchange 2016 will be coming to you soon (Sept 2): The month opened with a discussion about the next major release of Exchange, expected to appear in late 2015 alongside the rest of Office Wave 16. Will this release include all the functionality now appearing in Office 365? We’ll just have to wait and see.

On to October. Every month brings its own surprises and developments! I’ll try to keep up to speed with what’s happening in the world of Exchange and bring it to you here or in “Exchange Unwashed.” Or you can hear what Paul Robichaux and I have to say about the world of Exchange in the “Exchange Exposed” quarterly podcast, the first episode of which is called “Searching for Stability” and is now available for your download delight.

Follow Tony @12Knocksinna

Posted in Cloud, Exchange, Exchange 2013 | Tagged , , , , , , , , , | 3 Comments

Exchange 2013 workload management controls how the Mailbox Replication service uses system resources


One of the more important changes for the Mailbox Replication service (MRS) in Exchange 2013 that I discovered when researching content for “Microsoft Exchange 2013 Inside Out: Mailbox and High Availability” is how the function of the MRS configuration file has changed. As you might recall from the steps taken to tweak MRS processing in Exchange 2010, the MRS configuration file dictates parameters such as how many concurrent mailbox moves can be performed to a single target database or single target server. It also dictates how many move reports are stored for a mailbox.

You can find the MRS configuration file (MSExchangeMailboxReplication.exe.config) in the \Exchange\V15\Bin directory on multi-role or mailbox servers (for Exchange 2010, the configuration file is in the \V14\bin directory on multirole or CAS servers). The file remains text-based so it can be opened with Notepad. The information that controlled MRS behavior in Exchange 2010 is in the section shown below:

Mailbox Replication Service configurationSetting Name - Default, MinValue, MaxValue

MaxRetries - 60, 0, 1000
MaxCleanupRetries - 480, 0, 600
RetryDelay - 00:00:30, 00:00:10, 00:30:00
MaxMoveHistoryLength - 5, 0, 100
MaxActiveMovesPerSourceMDB - 20, 0, 100
MaxActiveMovesPerTargetMDB - 20, 0, 100
MaxActiveMovesPerSourceServer - 100, 0, 1000
MaxActiveMovesPerTargetServer - 100, 0, 1000

Many of the values for settings like MaxMoveHistoryLength (the number of move reports stored for a mailbox) are increased in Exchange 2013. Most interestingly, the values for MaxActiveMovesPerTargetMDB (maximum number of concurrent moves to a single target database) increases from 2 to 20 while MaxActiveMovesPerTargetServer (maximum concurrent moves to an individual target server) increases from 20 to 100.

You might conclude that the increase is evidence of either radically improved efficiency on the part of MRS in terms of its ability to process mailbox moves or that the newly rewritten managed Store in Exchange 2013 is so much better at dealing with I/O. Some improvements have been made in I/O but the real reason why the new limits exist is that they now act as a backstop for MRS processing.

Instead of being constrained by hard limits, the Exchange 2013 version of MRS is flexible and uses a technique called dynamic throttling to note what’s happening on a server by reference to Exchange’s workload management system. When MRS starts to process mailbox moves, it observes the amount of system resources that it uses and the overall level of system health. If mailbox moves flow well and system resources are not limited, MRS will increase the number of mailbox moves that it processes concurrently. On the other hand, if system resources begin to become scarce, MRS throttles back and processes less work until availability of resources improves.  Although it is unlikely that MRS will ever hit the maximum values defined in its configuration file when processing mailbox moves on production servers, it’s possible that it might on test servers or when systems are running in periods of ultra-low demand.

From Exchange 2013 CU3 onward, you can force MRS to revert to using the limits set in its configuration file by adding a line to the MRS configuration file to disable dynamic throttling. The line is:

DisableDynamicThrottling = “true”

I wouldn’t be in a rush to disable dynamic throttling as, in effect, you then allow MRS to move mailboxes with little real regard for the other workload running on a server. Some more mailboxes might be moved in a shorter period. However, those moves might degrade the responsiveness of the server to client connections. Workload management is designed to arbitrate between competing workloads, favoring critical demands such as those needed to serve users and giving less to background system processes, like mailbox moves. Moving mailboxes is important, but delivering good response to users is even more important.

Workload management exerts a very big influence over Exchange components. This is a good development because it means that the work done by components like MRS can flex in line with available resources instead of being constrained by rigid limits that are acceptable in periods of peak demand but take no account of the valleys that also occur in resource demand.

Follow Tony @12Knocksinna

Posted in Email, Exchange, Exchange 2013 | Tagged , , , , | 2 Comments

Setting server diagnostic levels in Exchange 2013


The ability to set diagnostics at different levels for the various components that function on an Exchange server has always existed. From Exchange 4.0 to Exchange 2003 you set diagnostic levels through the management console by selecting the component (for example, ActiveSync) and the level that you wanted to apply. Once a new level is set, Exchange complies by outputting more or less detail about its operations as events written into the Application Event Log. This mechanism worked well until Exchange 2007 appeared and administrators discovered that the new Exchange 2007 management console included no GUI to deal with diagnostics, meaning that they had to set diagnostic levels through EMS.

Microsoft addressed the problem in Exchange 2007 SP2 when they included the ability for EMC to set server diagnostics as properties of a server in addition to manipulation through PowerShell. The same behavior exists in Exchange 2010 but the transition from the old MMC-based console architecture to the browser-based Exchange Administration Center (EAC) in Exchange 2013 has resulted in the disappearance of the UI to manipulate server diagnostic levels. Or, possibly more correctly, the developers who created the new browser-based administration console simply ran out of time to include what might be considered to be a “nice to have” rather than “essential” feature. Frustratingly, this omission has not been addressed in any cumulative update since.

Another development for event logging in Exchange 2013 arose from work such as the rewrite of the Store into managed code and the introduction of modern public folders. A side effect of these projects is that a large number of previously well-known event logging categories have been either removed from Exchange 2013, replaced with a new logging category, or subsumed into yet another category. The upshot is that administrators who have created diagnostic scripts that depend on event logging categories to help them debug a problematic Exchange server have some work to do to review their code and potentially adjust calls to work with Exchange 2013.

The lack of UI to set server diagnostics means that we have returned to manipulating diagnostic levels through EMS. For example, to set the logging level to “High” for the operations performed through EAC (which still uses the old Control Panel name for diagnostic purposes), you type:

Set-EventLogLevel –Identity “MSExchange Control Panel\General” –Level High

Microsoft’s documentation on the available event logging categories is sparse to non-existent. However, there’s an easy way to retrieve a full set of current event logging categories by interrogating a server. To do this, use the Get-EventLogLevel cmdlet to return a list of the current diagnostic levels for a server. The list can also be used to verify that the correct settings are in place for each category. The cmdlet doesn’t support a filter function to allow you to specify that you only want details of event categories for the Store or transport, but as we want a full list, we can simply capture the output into a text file for easier examination. For example:

Get-EventLogLevel –Server ExServer1 > C:\Temp\EventLevels.txt

The list of event categories is roughly organized into areas of functionality such as Autodiscover, RBAC, replication, and so on. A little trial and error is therefore necessary to figure out exactly what is the best event category for which you should increase logging level when debugging a particular area of functionality.

As shown in the table below,  Exchange supports five levels of diagnostic logging based on the level assigned to events recorded by the application. Critical events and those assigned a level of zero are always written into the event log. Events with a higher level are captured if an elevated diagnostic level is chosen.

Level Description
Expert Highly verbose: Essentially Exchange documents everything it does
High Quite verbose: Exchange logs any event with a level of five or lower
Medium Fairly detailed: Exchange logs any event with a level of three or lower
Low Reasonable detail: Exchange logs any event with a level of one or lower
Lowest Only critical events or errors with a logging level of zero are captured; this is the default level used for most Exchange event categories.

Be careful about setting diagnostic levels to Medium or higher. Exchange is quite happy to provide a vast amount of diagnostic information by writing events into the Application Event Log, but you run the risk that you won’t be able to see the forest for the trees and some essential piece of information will be overlooked simply because so much data are available. To prevent the Application Event Log from being clogged up with an excessive number of events, make sure that you reset the diagnostic level to Lowest when you’ve completed troubleshooting the problem that caused you to elevate the level.

Change is wonderful (usually). I am sure that EAC will fill the gap over time. But for now, the more that I work with EAC, the more gaps I find. It’s a bit like Exchange 2000 all over again…

Follow Tony @12Knocksinna

Posted in Email, Exchange 2013 | Tagged , , , , | 1 Comment

Exchange 2013 improves USG management through EAC and OWA


Exchange 2010 SP1 made a change to limit the ability to make changes to universal security groups (USGs) via the Exchange Management Console (EMC), which meant that administrators were no longer able to use EMC to amend USG membership, a side-effect of the introduction of support for a split permissions model. The problem was subsequently addressed in KB2487852 and administrators could once again use EMC to modify USG membership.

Exchange 2013 replaces EMC with the browser-based Exchange Administration Center (EAC), which builds off the Exchange Control Panel (ECP) used by Exchange 2010 for some administrative purposes and to set user options in Outlook Web App (OWA). Like many transitions, the switchover from EMC to EAC was bumpy in places. EAC has steadily improved as Microsoft has released cumulative updates, and it seems that some recent updates in Exchange 2013 CU6 have improved the ability to assign the ability to work with USGs to users who are not administrators.

As I documented in “Microsoft Exchange 2013 Inside Out: Mailbox and High Availability” (page 284-5), Exchange 2013 RTM would only allow users to create USGs through OWA if they were a member of the all-powerful Organization Management RBAC role group. Users who were members of the Recipient Management role group could create USGs through EAC, but a disconnection existed in the ability of the two role groups to interact with USGs through OWA and EAC.

Prompted by a recent question from a reader, I went back to look at the current situation as implemented in Exchange 2013 CU6 and found some improvements. The scenario that many are interested in involving giving permissions to help desk personnel to manage USGs without having to include those users in the Organization Management role group.

To test what can be done today, I created a role group called Help Desk Level 2 and assigned it the kind of management roles that I think you’d expect to find given to people who provide second-level support. The set of roles included the Security Group Creation and Membership role. As you’ll recall, an RBAC role is composed of a set of cmdlets and parameters that can be executed by users who are assigned the role through their membership of a role group.

HelpDeskLevel2

By the way, if you’re at Exchange Connections in Las Vegas next week, be sure to check out the session on “Role Based Access Control and You” given by Bharghav Shukla (2:45pm on Wednesday). It’s just one of the in-depth technical sessions given by independent experts that you’ll get at Connections.

I then added some users to the role group. The next time the users log in and authenticate to Exchange, the RBAC evaluation that is part of this process will detect their membership of the Help Desk Level 2 role group and assign them the roles covered by the group. In effect, all of the cmdlets and parameters defined for each of the roles will then be available to the users. This is what happens when you start an EMS session with Exchange 2013 or Exchange Online and you see the message saying that command information is being got for the remote (PowerShell) session and that a certain number of commands have been loaded. Each one of those commands is described in a role assigned to the user.

An EMS session reports as it loads commands

An EMS session reports as it loads commands

The next step was to log into OWA using one of the user accounts that held the Security Group Creation and Membership role. OWA and EAC share the same “slab-based” user interface, which means that user interface components are only loaded if the user has the permission to interact with an object. For example, if your user does not hold the permission to work with public folders, you won’t see the public folders UI through EAC.

OWAUSG

Through OWA options, I was able to create and edit USGs. The important caveat here is that you can only edit USGs if your account is listed as a group owner, presumably because USGs hold security principals that might be used to protect confidential information and you don’t want to create the potential for that information to be compromised by a change made by someone other than a group owner. The same behavior now extends across both EAC and OWA. It would be good if this fact was clearly called out in the TechNet article that documents the Security Group Creation and Management role as I can see how confusion might arise when a user who holds the role attempts to edit the membership of a USG that they don’t own.

However, there is a workaround. The Update-DistributionGroupMember cmdlet is used to update group membership of both USGs and (normal) mail-enabled groups. This cmdlet supports a BypassSecurityGroupManagerCheck switch that allows any user who holds the Security Group Creation and Management role through membership of a role group like Recipient Management to update the membership of a USG without being a group manager. Thus, it is possible to use this workaround in a scenario where you want to allow administrators to update USGs without having to add every administrator to the ownership of every group.

EAC command logging reveals how it runs Update-DistributionGroupMember

EAC command logging reveals how it runs Update-DistributionGroupMember

As can be verified with command logging, EAC never passes the BypassSecurityGroupManagerCheck switch when it calls the Update-DistributionGroupMember cmdlet. This is to ensure that the same behaviour exists across EAC and OWA, which is a good thing. It’s also good that some of the restrictions that existed in older versions of Exchange 2013 have now been addressed!

Follow Tony @12Knocksinna

Posted in Email, Exchange, Exchange 2013 | Tagged , , , , , , , , | 3 Comments