Gone but not forgotten
Published Nov 08 2006 08:36 AM 4,649 Views

As discussed in the earlier blog post introducing the new Exchange 2007 console, the Exchange Management Console GUI has been completely redesigned in Exchange 2007. While redesigning the Exchange Management Console for Exchange 2007, we used specific ground rules to help guide what features and settings should be exposed in the console and how the console itself should be built. These guidelines allowed us to ensure that we had designed a rich, functional tool that wasn't overwhelming and complex. It also ensured a console where additional feature GUI could be added to respond more effectively to customer requests.

Exchange 2007 GUI Console Goals and Ground Rules

To meet these goals, we developed the following ground rules and reasoning:

  1. Rewrite our Exchange management console GUI to consume cmdlets directly. This means that the GUI shares business logic with the cmdlets (reuses the existing cmdlet business logic, really) and so we can easily add additional GUI in later service packs and releases simply by building on existing cmdlets.
    Note: In previous releases GUI elements had to use embeded business logic which translated to much more time and difficulty in adding GUI. These complications in adding GUI after the initial product release often led to configuration settings being exposed via registry keys or AD attributes that required KBs to be written to explain how to use them.
  2. The most common features & settings used by most of our customers should always be exposed in the console.
    Note: In the past, Exchange 2003/2000, this hasn't been the case. For example, OWA administrators had to download a tool to manage very common settings.

Naturally, when moving from Exchange 2003 to the Exchange 2007 console using the above ground rules, there have been changes in what is exposed in the console. Those changes have led to some features being removed from the console GUI. The reasons for removing some specific GUI generally fall into one of the three following categories:

  1. Feature was an advanced scenario, not commonly used by most customers and thus added to complexity and confusion (and clutter) in the GUI.
    Note: In previous versions of Exchange, features not visible in the GUI were frequently not available through any administrative interface. In Exchange 2007, we have a great mitigation for features not exposed in the console GUI - the Exchange management shell!! The shell provides rich error handling, validation, and discoverability for configuration settings - a feature not found in registry editor or ADSIEdit!
  2. Feature was removed from Exchange 2007 entirely
  3. Feature or setting was replaced by a better solution in Exchange 2007 - for instance it works out of the box without requiring the previously complex configuration.

Exchange 2007 GUI Result

Based on these guidelines, we did an evaluation of all GUI available in Exchange 2003 and also took into consideration any GUI required for new Exchange 2007 features. Then we made some hard choices on what belonged in the new GUI console for Exchange 2007 and where these should be placed. The surprising outcome was that only a handful of features are completely removed from the GUI, and there's actually more (quantity) GUI exposed in Exchange 2007 than there was in Exchange 2003.

Think of it a bit like cleaning out your garage. When you start out, it's a huge mess and there's no room anywhere to hold even the stuff you've already got. But by the time you've reorganized everything more efficiently, you find there's suddenly room to hold the car again!

The table below lists the various GUI features that were removed for Exchange 2007 RTM. Please have a look through the list and let us know your opinion on the decisions we made. In particular, we'd love to know if you think we missed anything critical from Exchange 2003 GUI or if the mitigations seem insufficient to you.

GUI Feature Removed

Reason for Removal

Mitigation

Exchange Extensions to Active Directory Users & Computers

We needed to address the Exchange 2003 challenge of a poor, incomplete automation and provisioning user management story.  To do this we rewrote all of our recipient management logic into cmdlets using PowerShell technology.  Extending the unmanaged code MMC 2.1 Active Directory Users and Computers console with our managed MMC 3.0 cmdlet-based GUI would have left some functionality broken. Additionally, it would have meant continuing to require the use of two different tools for server and recipient management of your Exchange organization.

Recipient management is exposed in the Exchange 2007 Management Console

Exchange Management Shell Cmdlets made available through Powershell.  An overview of the recipient cmdlets can be found here.

MMC built-in feature "new window from here" can be used to provide a limited view of Recipient Configuration Node for a custom console (See Tip #8 in this blog post)

IMAP and POP enable/disable on a Mailbox

IMAP and POP Virtual Directory

Not as common to manage as other client access protocols like Outlook Web Access or ActiveSync. This GUI is a good candidate to be added later based on customer request.

Exchange Management Shell Cmdlets:
Get/Set-ImapSettings
Get/Set-PopSettings
Set-CASMailbox (enable/disable IMAP and POP on a mailbox)

Removal of hidden distribution group membership

Completely hidden membership is not supported by the Active Directory, so past implementations have had many issues and bugs.

Scripted approach which leverages Dynamic Distribution Groups and ACLing the custom property to exclude ability to look up membership.

Recovery Storage Group

In Exchange 2003, performing a disaster recovery on databases was a manual, complex process that had little end-to-end guidance for the administrator. 

In Exchange 2007 a database recovery management tool has been added to the toolbox which provides step-by-step guidance and support in disaster recovery scenarios. Therefore, the exposure of the recovery storage group configuration in the main console is no longer required.

Content Indexing Management

Was not a commonly managed feature by most of our customers

Exchange Management Shell Cmdlets:
IndexEnabled parameter on set-mailboxdatabase

Details Tab on property pages which included comments/created/etc.

Was not a commonly used feature by most of our customers

3rd party auditing/change tracking software

Modified time is on general property page

Move Address List GUI (to move the address list to a new position in the address list hierarchy)

Was not a commonly used feature by most of our customers

Exchange Management Shell Cmdlet:
Move-Addresslist

In the GUI the address list can be deleted then recreated in place of move

Mailbox Statistics for an entire database

The Exchange management shell provides a native, rich reporting functionality that is exceedingly powerful and effective; thus it is the chosen method for information gathering in Exchange 2007.

Exchange Management Shell Cmdlet:
Get-mailboxstatistics

General property page of an individual mailbox shows mailbox statistics for that mailbox

3rd party extension of Exchange management console

We first focused on management shell extensibility story before tackling console extensibility.

MMC3.0 has no support for extending context menu.

Build a separate snap-in

Public Folder Referral GUI

Public folder referrals are linked to routing groups which are no longer an Exchange 2007 concept, however there are mitigations for configuring referrals in an environment with mixed Exchange 2003/2000 and Exchange 2007 servers

Exchange Management Shell Cmdlet:
Use the PublicFoldersEnabled parameter on
New-RoutingGroupConnector
Set-RoutingGroupConnector cmdlets to enable public folder referrals

Alternately, for mixed Exchange 2000/2003 and Exchange 2007 environments, use the Exchange 2003 management tools for this purpose.

Public folder statistics

The Exchange management shell provides a native, rich reporting functionality that is exceedingly powerful and effective; thus it is the chosen method for information gathering in Exchange 2007.

Exchange Management Shell Cmdlet:
Get-PublicFolderStatistics

Recipient Update Service GUI

No longer managed by admin, simply an API that is called into by cmdlets

None needed (and see the Goodbye RUS blog post for more details).

Monitoring GUI

The Exchange 2003/2000 monitoring feature was very limited and has been removed.

This has been replaced by monitoring-specific cmdlets used either directly by the administrator or in combination with Microsoft Operations Manager

Export List in GUI

The Exchange management shell provides a native, rich reporting functionality that is exceedingly powerful and effective; thus it is the chosen method for information gathering in Exchange 2007.

Use Exchange Management Shell cmdlets to perform reporting.  Here is an example getting a report (CSV) on all mailbox databases for the server and only reporting on their name, quotas, and retention:
get-mailboxdatabase | select-object name,mailboxretention,prohibitsendreceivequota,prohibitsendquota | export-csv c:\reports\dbquota.csv

ACL Picker (Security Tab)

ACL level permissions are an advanced scenario that are not commonly required by most of our customers.

Exchange Management Shell Cmdlets:
Add/Get/Remove-ADPermission
Add/Get/Remove-MailboxPermission
Add/Get/Remove-PublicFolderClientPermission
Add/Get/Remove-PublicFolderAdministrativePermission

Remove Server GUI

The scenarios for remove server are closely related to the setup experience and due to the highly destructive nature of removing an Exchange server it was removed from the console.

If the server is still operational choosing the uninstall option in setup will be sufficient. However if the server had run into problems and an uninstall will no longer work, an administrator can first use the "recover server" option and then uninstall to remove the server from Active Directory.

Global Address List GUI (new, modify, etc.)

Creating a new Global Address List or modifying the default was not a commonly used feature by most of our customers

Exchange Management Shell Cmdlets:
New-GlobalAddressList
Remove-GlobalAddressList
Set-GlobalAddressList

Complex filtering for Address Lists, dynamic distribution groups, and E-mail Address Policies in GUI

In Exchange 2003/2000 the filter GUI for address lists, e-mail address policies, and dynamic distribution groups was incredibly complex with nested lists having hundreds of properties listed.  In Exchange 2007 the most common filters are defined as "precanned filters" with an extremely simple and intuitive filter control to make this experience much easier for our customers to use. 
For the few companies that have advanced filtering requirements not met by the precanned filters, these "custom filters" can be defined using the OPATH filter syntax in the shell.

Exchange Management Shell Cmdlets for complex and "custom filters":
Use the RecipientFilter parameter on 
new-addresslist
set-addresslist
new-emailaddresspolicy
set-emailaddresspolicy
new-dynamicdistributiongroup
set-dynamicdistributiongroup

Complex & hidden address generation  (firstname.lastname) variables for SMTP address in E-mail Address Policies

In Exchange 2003/2000 administrators had to simply know the correct variables (%s.%g) used to generate the local part of the SMTP address as there was no indication in the GUI as to how to do this.  Exchange 2007 introduces GUI to define address generation using the most common generation variable combinations.  For more advanced requirements, administrators can define the proxy address template directly through the management shell.

Simply prepend the desired variable (%s.%g) as the local part of the SMTP e-mail address template when it is specified using the new-emailaddresspolicy or set-emailaddresspolicy cmdlets.

Public Folder Tree Management GUI

Providing solid bulk management story is crucial to public folders so investing in rewriting all of our public folder management logic as cmdlets was priority.

Exchange Management Shell Cmdlets:
New-PublicFolder
Remove-PublicFolder
Get-PublicFolder
Set-PublicFolder
Resume-PublicFolderReplication
Suspend-PublicFolderReplication
Update-PublicFolder
Update-PublicFolderHierarchy

Exchange 2003 console against an Exchange 2003 public folder server can be used to manage the public folder hierarchy

System Policies

There are good replacement features using Exchange 2007 management shell automation that cover the scenarios for Exchange 2000/2003 system policies

Use Exchange Management Shell cmdlets to perform bulk configuration.  Example of modifying all mailbox databases to have an item retention of 4 days on ServerA:
get-mailboxdatabase -server ServerA | set-mailboxdatabase -itemretention 4.00:00:00

Cloning can be used for new objects by specifying the TemplateInstance parameter

 

If consistent and periodic application of these settings are required, a script to apply these settings can be scheduled using OS scheduling functionality.

Protocol Virtual Server

In Exchange 2003/2000, ESM exposed various IIS specific protocol settings. These inconsistencies caused customer confusion about where to manage virtual server and virtual directory settings.  In Exchange 2007 only Exchange specific settings on a virtual directory are exposed in the console and any virtual server settings required by Exchange are automatically set upon creation of virtual directories for the administrator.

IIS Manager should be used to manage the IIS concept of Virtual server

Delete/Create Outlook Web Access & ActiveSync virtual directories

Creating a new Outlook Web Access or ActiveSync virtual directory (beyond the default ones created by setup) is not a commonly used feature by most of our customers

Exchange Management Shell Cmdlets:
New-OwaVirtualDirectory
New-ActiveSyncVirtualDirectory

End to End SMTP Connector Wizard (Internet Mail Wizard)

By default in Exchange 2007 after setup the correct SMTP connectors are already created with smart defaults. 

SMTP connectors created and configured automatically when Edge server is configured as a "subscribed Edge".

Did we get it right?

If you've made it all the way through that table, you're a trooper and we thank you! We've done lots of usability testing around the new Exchange 2007 console and the use of various Exchange 2007 features, but there's sure to be some folks who disagree with one or more of the items in the list above.

That's where you come in! Now that we have developed a much more flexible GUI architecture (ie - built on cmdlet business logic), it's far more possible than in previous versions of Exchange to correct problems in the GUI or to add in necessary GUI after the initial release of the product.

We'd love to hear from you if there are features you believe are missing from the GUI that should be there. It's our goal to keep the GUI simple and uncluttered - following the ground rules at the top of this blog post, but we definitely want to make sure we haven't overlooked some critical GUI features. Please let us know what you think!

- Evan Dodds and Amanda Langowski

24 Comments
Not applicable
Very nice blog that provides some essential background about the choices that you took in building EMC. I don't agree with all your choices (I think that you should have incorporated PF management as a help for administrators who have to work inside a mixed environment), but at least I understand your logic and desires.
Not applicable
Guys, I love MOST of Exchange 2007. But you have completely lost the plot with removing the snap-in from AD Users & Computers. Most helpdesks I've either seen or managed have a very tight and well defined process for creation of users, which is done purely from AD Users & Computers. This includes placing them in the correct OU, adding them to the correct security and distribution groups, modifying any number of other properties, provisioning them for LCS 2005, and- of course- enabling their Exchange mailbox.

So now you introduce a scenario where NO MATTER WHAT you will force these kinds organisations into using two separate utilities (even if they may be within the same MMC)!!! Seriously - take another look at this because it's not going to be popular and you're doing customers a disservice. Helpdesk needs to be less, not more, complex. My suggestion - fix the plugin. Make it work in the same way as other Exchange 2007 functionality, by providing the equivalent cmdlet syntax afterward- fine, not a problem. It really should not be that hard to do, but you would mitigate a massive retraining issue, not to mention seriously reducing the total wasted time ...


On top of this, but related, the fact that there's no means to automatically propagate Managed Folder and ActiveSync policies makes this a major pain in the neck. In all seriousness - you allow a newly create users to receive an email address by default, and when the policy is changed you make it possible to propagate or re-propagate all users matching the policy. This should definitely, absolutely, positively be the behaviour for all policies.

The comeback for issues such as these is the cmdlets. I have no problem with the cmdlets as such - but don't push it onto customers to create and maintain these for common tasks. They should be integrated and consistent.

After all, you want people to like the product, don't you?
Not applicable
I almost forgot to mention with regard to policies; Help desks and IT in general don't often want to deal with individual user accounts when they could deal with whole teams/departments/organisations. That being said, why wouldn't it make sense to permit policy to be applied to groups and OU's. Department and other attributes are nice - when they can be applied - but really, this would be the ultimate way to ensure the right policy is applied to the right place.



I love OU in particular, since it has implied conflict resolution. If you apply a policy to one OU, and then another to an OU contained within that, the policy closest to the user would win. For example, the Microsoft OU has a Server Activesync policy applied to require a password of 4 characters. Within that, the Redmond OU has another Server ActiveSync policy which specifies 8. The Redmond one wins - except for the user who has an explicit policy assigned that specifies none (the boss, of course).



That seems a fairly neat way to resolve it; of course, there could be configurable behaviour that allows individual organisation to specify this (could be farthest first wins). This could even be a cmdlet to make you guys happy ....




Now with groups, that's more complex. A user could be part of two groups (Development and Production), each with a Server ActiveSync policy applied. Which one wins? Obviously one has to, all the time, in order to maintain consistency.



So given that you've associated policies with groups, you could keep an enumerated list of all groups. The administrator can then select which one has precedence. This is limited, but then you'd want to encourage people to use OU's for flexibility.



Alternatively, have an option to allow administrators to specify whether the most restrictive or the least restrictive wins. Give them a little query tool to test it - bingo!



Finally, and most messy, create a new type of AD group - the "policy group" and users can be assigned to that to determine which policy they get - and they can only be in one policy group at a time. I don't much like that one and feel dirty for writing it.



I'd especially like to see OU's implemented. I think it could really help Exchange administration. If you think about an organisation with OU's for Marketing, IT, Sales, Executive, etc ... each with their own particular requirements for email addresses, mailbox management, Activesync settings - sure, you could set it on a per user basis, and fiddle around with little cmdlets to automate it. Or it could just be built into the product in the first place and make customer think "Oooh, what an amazing feature that just saved me time, effort, and even money. I think I'll make best use of that time to go evaluate a new Microsoft product; I could even make a business case for it using the money we saved." :)



Late in the cycle? Sure, but you have so much of it there already. Why not take the time to put it in and make it good!

Not applicable
I agree with Matt M.

Also you state that 'ACL level permissions are an advanced scenario that are not commonly required by most of our customers.'

So you mean that the Mailbox Rights option (ADUC, tab Exchange Advanced) has been removed from the GUI? As an Exchange consultant I can say that almost all Exchange customers use a lot of shared mailboxes and therefore need to often adjust mailbox rights. Doing this from within the shell is a nice option but in my opinion this should be possible with the GUI.
Not applicable
Matt, I share your point on ADUC & helpdesk.
Very strange decision from Microsoft.
Please change it. Add a way to create MBX from ADUC.

Not applicable
Glad to see a couple of people agree :-)

I posted a second comment which may have been filtered since it followed the first one not long afterward.

Essentially it had to do with additional options for policies; in addition to making them consistent with all types (email address, managed folders, server activesync, etc), I would like to see the ability to apply them based on group membership or OU. I had some ideas on how this would be implemented, but since the original comment might reappear I won't repeat it verbatim.

This had applications for situations where different teams, departments, divisions, or perhaps companies had differing requirements; the example was in Server ActiveSync where one group needs a 4 digit pin, one needs an 8 digit password, and the boss needs none (because he's the boss). I love the fact that multiple ActiveSync policies will be possible, but it needs to have the ability to stretch to groups of users rather than individuals.

I think it's a valid idea and certainly do-able.
Not applicable
I have concerns about the Recovery Storage Group being embedded in a wizard, instead of manually configured.

The only thing I routinely use the Recovery Storage Group for is for discovery requests (e.g. "give me 'x' users mailbox as it existed on September 8th).  I restore the database to the RSG, extract the users mailbox using Exmerge (more complicated if the user is gone) and then delete the RSG.

I do not use the RSG for "disaster recovery" - that is what backups are for.

I am concerned that I will not have this level of granularity if the feature is part of a wizard.  
Not applicable
As has been the case over the last year there have been some very strange decisions on E12 which are still in existence from the above list.
1) Public Folder Tree Management - you are removing a very userful tool that was perfected in EX2003sp2.  You are essentially forcing companies to retain Ex2003 servers to managed that function.  whilst the aim is to remove need for public folders I work with companies that have on average 3-4Gb Hierarchies (the biggest being 7) and this will not be popular as a full move to sharepoint isn't going to be a quick affair.
2) Snap-ins for DSA.msc - you could essentially get lynched for this or it opens the door for third party vendors products such as Active Roles to support PSH in their GUI - but thats not a product for all companies.
3) Failure of PSH to support the AD schema 100%- whilst this is not listed the PSH doesn't reference attribute properties in the AD schema and will causes issues with custom applications on invalid recipients in some instances.
4) The reliance of PSH scripting is going to prove challenging to update existing scripts mostly on the grounds that attributes in AD have a different name through PSH.  There was supposed to be a attribute mapping document provided but this hasn't seen the light of day yet.

The logic behind the back bone technology of 2007 is great and will be popular but a few of the decisions above i perceive have been taken from a technology point of view and not from operations management.  bottomline is there is going to be a heavy reliance on third party vendors or Scripters to make administrative tools to support not only for the small shops but for SI's who have a 'C' team admin model.
Not applicable
Hi! I have a quesiton:

I there any possibility that Outlook/Exchange in the future will support right mouse dbl click to close windows?

Thanks /Patrix
Not applicable
Hi, What happened to the Message Tracking Center under Tools? Can I save the results of the Trace?  Something better than a print screen?
Not applicable
Messagetracking in 2007 appears to be a thin part of the gene pool for E12 dev. i know some adopter build customers haven't been impressed.  The lack of Hierarchical visual display made something easy - very hard.
Not applicable
Matt and Martijn Westera i totally agree with you. As an Exchange admin i have to look at the mailbox rights almost every day since we use it allot. Also we use allot of the security tab since i have to allow some users to "send e-mail as". I've configure this in Exchange 2007 Beta 2 on Exchange Management Shell but still didn't figure out how i can easily see witch users have the "send as" permission on mailbox A.
This is a must have in the Exchange 2007 GUI, it will be hard for my team to recommend a software that will make our simples tasks take much longer.
Best Regards
Nuno
Not applicable
Thanks for all the feedback so far! We're definitely reading through each of these replies and they will help to shape our future GUI decisions.

To answer a couple of the specific questions made in the comments so far:

Tony - You can still do advanced RSG actions at a granular configuration level (ie - without the step-by-step wizard) by using the New-StorageGroup and New-MailboxDatabase cmdlets in powershell (there are Recovery parameters available).

HighDiver_2000 - "message tracking" functionality has moved to a troubleshooting wizard in the Toolbox Workcenter.
Not applicable
In principle, I agree in most arguments for the removed features. It makes the GUI much more clearer to use.

But I cannot accept the removal of mailbox rights tab. We make heavily use of granting send-as rights to functional mailboxes. For the guys in our accounts management team, the new shell (which I like) is not adequate.

Also missing is the public folder management option. Although you are going to phase out public folders, there are still a lot of customers who had applications built on them. Until they migrated public folder to something else, public folder have to be managed.

Whats about the ability to monitor current logon connections to mailboxes; I didn't find anything to do this task, neither in the new GUI nor in the shell.
Not applicable
I agree that the mailbox rights tab and public folder management are must-haves. We have no desire to move to Sharepoint.

I think the "Complex filtering for address lists, etc." should be kept also.  Constructing a complex LDAP query is difficult, so why would you throw out something that's already written that makes it easy?

Supposedly content indexing is much better in Exchange 2007, so the management interface might get used if you left it in.
Not applicable
   I agree with Chris M, there is a need for single point administration for user accounts.   I recall at one point someone mentioned that the decision to remove this feature was due to customer feedback.  I was at Exchange Connections 2006 and most of the other admins I spoke with would prefer to have a single point of management, albeit it was only a dozen or so.  For meduim  (<1000 users) size companies such as mine this is going to create an addtional load on our already overburdened IT staff.  


Also I was told that Exmerge will be not supported under Exchange 2007, can you provide addtional details and also maybe blog about the cmdlets that will replace the functionality of Exmerge.
Not applicable
Evan,Amanda, could you please post a comment on what MattM is pointing at? I also don't get it why you should remove the perfectly fine working AD integration. Needing 2 tools for something that can be done in step. This is a step back to 5.5 in my opinion.
Not applicable
Addy -

MattM makes a lot of points, way too many to address with comment replies! Some of these points are things we are considering how best to improve for future updates; some of them are things that were considered and rejected for the RTM because we believed them to be less important (this constitutes some portion of the list provided in the blog post).

There were a number of reasons to remove the AD integration. Some of them involved usability, and some were technical in nature. Due to the change to powershell infrastructure, the old extensions could not simply have been ported forward, of course (plus there are a number of old things removed and new things added to Exchange 2007 that would have to be handled). And please also consider that even if it was somehow just as simple as bringing forward the old ADUC extensions unchanged, you'd lose the ability to do the cmdlet-based recipient management using powershell. We decided that we could cover a LOT more of the customer requirements for a LOT more of the customers if we instrumented recipient management with powershell to match the rest of the management infrastructure and integrated recipient management into the shell and console directly.

Thanks to all for the continuing comments and please keep them coming! If you'd prefer to email your comments to me directly, you're welcome to pass along your comments that way also: evand-at@-microsoft.com

Evan
Not applicable
  Is it possible that AD intergration part will change when Longhorn ships?  I would assume that there are plans to introduce Powershell for AD tasks in Longhorn which would allow for easier tie in from ADUC to Exchange, is this assumption correct?  
Not applicable
Sounds much more like a development resourcing issue than an actual attempt to provide a beneficial feature as is implied by this blog post and previous ones.

Let's be serious here. The Exchange attributes are still stored in Active Directory. So ADUC could still be handled, with or without powershell. I don't see how supporting one obviates the other - that's broken logic if I ever saw it. The biggest difference is possibly increased support load- but for something as commonly used as this, if that's what it takes to make customers happy, it's usually worth it.

Evan, I have a lot of respect for you and the team, but when you make a comment like "We decided that we could cover a LOT more of the customer requirements for a LOT more of the customers if we instrumented recipient management with powershell to match the rest of the management infrastructure and integrated recipient management into the shell and console directly" - that's where you lose me.

I can agree with everything in your statement, with qualification. You dropped out the part where you break important and commonly-utilised functionality in the process, and try to justify it with half-baked excuses that only serve to illustrate how short-sighted and ill-advised this type of decision is.
Not applicable
Microsoft products are famous for GUI and its been replaced completely from Exchange server 2007 which not easy to digest for Administrators.
For e.g troubleshooting PF replication is one of the complicated problem and we have go around and check each and every components like check SMTP VS settings, PF store address, create test PF, force hierarcy..etc but we have to do this using comlets which will take huge amount of time. Instead of that it should be both GUI and comlets and later on remove the GUI. If we still use ESM to manage PF then what the user of E2K7. This is one of the e.g, we have think twice before investing in Exchange server 2007.
Not applicable
I have been a primary support engineer for Exchange data recovery for one of our comapanies data protection products for quite a while. I am very concerned going forward about supporting our customers who need to use the Recovery Storage Group functionality with Exchange 2007. I appreciate moving the RSG functionality out of the GUI but I am having a hard time once I have created a RSG and I want to go back and see:

1. Whether or not a RSG exists
2. What path is set for the RSG
3. Whether or not any particular stores have already been added to the RSG
4. What path was specified for the Store files
5. Whether or not a Store that was added to the RSG is mounted or not

Personally, I am dismayed that this functionality was removed from the GUI. I think it is going to create quite a few headaches for support, both for Microsoft as well as all the third party vendors who have to support Exchange database issues. Of course, we will learn to deal with it, but I don't agree with the decision to remove it entirely from the GUI.

If you could at least provide more information regarding how to view the RSG configuration after the fact that would be very helpful.
Not applicable

Policies in Exchange are designed to enable flexible administration of large numbers of Exchange objects....
Not applicable
I have previously listed the progress we've been making in posting ITPro focused Systems Management blog
Version history
Last update:
‎Jul 01 2019 03:20 PM
Updated by: