Exchange 2010 FAQ: Why Can’t I Manage Mailboxes in AD Users & Computers Any More?

Question: Why can’t I manage Exchange 2010 mailboxes in AD Users & Computers any more?

One of the first things my customers notice when I demonstrate Exchange Server 2010 management to them is that mailboxes are no longer created or managed in the Active Directory Users & Computers console.

This is sometimes alarming for them because it means that migrating to Exchange 2010 forces a change in their administrative habits and workflows, for example creating a user account and a mailbox now requires two different management tools instead of just one.

I usually explain a few or all of the following reasons for this change:

  • AD Users & Computers used to integrate nicely with the Exchange 2003 System Manager tools
  • AD Users & Computers uses a different MMC version than the Exchange Management Console
  • The Exchange Management Console is now built on top of PowerShell, which AD Users & Computers is not
  • The change re-unites Exchange mailbox management with organization and server management in a single console
  • The sheer number of management tasks available in the Exchange Management Console would make the AD Users & Computers interface too crowded and confusing
  • Separating the two is important for organizations that separate the roles of user and Exchange management into different teams with different levels of administrative rights

Personally I’m in favor of the change and have enjoyed having dedicated management tools for Exchange Server 2007 and 2010.

Since the main impact tends to be on new user creation workflow I demonstrate to customers that they can change to one of three approaches:

  • Create the user account as part of the mailbox creation process in the Exchange Management Console, and then switch to AD Users & Computers to finish the job (eg configure group membership, home drive and profile paths, etc)
  • Create the user account in AD Users & Computers first, and then switch to the Exchange Management Console to mailbox-enable the account
  • Use scripting and automation to enable mailboxes for newly created user accounts (eg have a script that checks AD every hour for new user accounts within a certain OU structure and enable a mailbox for them on the appropriate mailbox server)
About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Connect with Paul on Twitter and Google+.


  1. very good analysis.thanks

  2. One tool says:

    Two now have to use two tools instead of one is a pain. Just because MS is too lazy to design an interface that would allow one tool to complete the task of user creation and mailbox creation in one place makes no sense.

  3. And I’ll add this: Our service desk employees are the ones that always created and edited users and their mailboxes. When a request comes in to create a new user with a mailbox for a new employee, we never hear about it because service desk does it. So, what? Am I supposed to give service desk access to the whole exchange management console? Seriously? Is there a way to only show them the recipient config section? If not, this is totally completely unsafe.

    • Hi Chris, how is it unsafe? The service desk can only do what you give them permissions to do. Exchange has a robust administrative permissions model with good builtin/default groups and the ability to define custom roles and access.

  4. If you want to manage Active Directory Accounts ant their mailbox attributes and properties with one tool, please have a look at our software ADO++. It does, what formerly the ADUC with the Exchange extensions did, and some more, like restore deleted objects in a GUI, RBAC GUI, manage mailbox delegates and other usefull tasks in the Exchange/Active Directory environment.

  5. They really dropped the ball with this one. As an administrator and IT Director, I can honestly say that Microsoft has taken (and keeps taking) a step back when they introduce new systems. The smarter thing would be to build upon what is already stable, adding new features to an already solid foundation.

    This principle should apply to nearly everything in any production system. Since the introduction of Windows 7 and Windows 2008, IT production has slowed down significantly due to these constant obstacles and capricious changes they keep making.


    • It has been 6 years since Microsoft split Exchange back out to its own management toolset with Exchange 2007, and added PowerShell to the mix. Frankly I’m surprised anyone is still upset about it, but everyone is welcome to their opinion.

      Keeping everything locked into ADUC integration and MMC-based consoles stifles innovation and prevents any real progress in our abilities to efficiently manage IT environments *at scale*.

      PowerShell has given us the ability to efficiently manage environments that would be slow and cumbersome to manage only with GUI tools. What we’re able to achieve now with scripting and automation thanks to PowerShell not only saves us time, it saves our employers *money*. As an IT Director I would have thought you would find that appealing.

      PowerShell is here to stay. It is being baked into every new Microsoft platform and extended more and more with each release. If you decide not to embrace it then you’ll simply be left behind.

      • David Risbridger says:

        “If you decide not to embrace it then you’ll be simply left behind”

        Resistance is futile…? Surely it would make sense to have Exchange mailboxes integrated into AD management, as has been the case previously though?

        • Separate admin tools was also the case previously (Exchange 5.5 was a separate admin tool).

          All of the products have a common management framework (PowerShell) and their own administration front end where necessary (AD, Exchange, Lync, SharePoint, Office 365, etc etc). The more they integrate front ends the more they constrain the progress of each.

          One of the best things about the new Exchange 2013 EAC is there is no longer a need to maintain a whole bunch of admin tools on mgmt servers and workstations to keep them up to date with the Exchange SPs and URs.

      • I would be interested in a way to provide delegation via scripting so my non technical HR group can create the users and mailboxes.

        • Chris, this is often part of an IAM solution. There are many out there from various companies.

  6. Microsoft’s mistake was integrating Exchange management into ADUC in the first place, and waiting too long to develop a decent management shell.

    They created a bunch of “right-click Admins”, and now they’re not happy about having to learn something new.


  7. Mike Hutchison says:

    As a long-time admin, at first I wasn’t terribly happy about the split but after 18 months or so of experience with it, I don’t mind it at all. It’s not that much more effort to have two management consoles open instead of one (when the situation warrants), and the benefits of Powershell scripts far outweigh the inconveniences.

    Spending some time learning Exchange 2010′s RBAC is preferable to giving the help desk escalated permissions, IMHO.

  8. Working more with Exchange 2010 in a large environment shows, that beside splitting, other important features are missing in the Exchange management console. Linked account can’t really be handled very well, changing the external account is not really possible without powershell. Also changing the mailbox type is not possible. And more worse, in large environments, again and again the Exchange-MMC starts enumerating the users, and it does not do this very fast. Mailboxpermissions are not really shown completely (no inherited rights). Permissions from trusted forests can’t be added. So Microsoft has left somethig to do for third party products. I don’t expect the management to become more powerfull with the Exchange 2013 Administrative Center, normally transforming an application to a Web Application does not increase its performance.

  9. Doktor McNasty says:

    Ok so like the thing is see we have a 20 user environment and I don’t have the time to take hours of training with powershell so that I can forget what arcane commands to use it every single time I have to set up a new user because it’s done so infrequently here.

    Being forced to learn doing something in a more complex fashion is fine if you’re doing it often enough you don’t have to relearn it every single time you need to do it but it seems like I’ll lose a lot of productivity having to learn this thing over and over again every infrequent time I want to do something.

    • Powershell is Powershell. The same Powershell skills you learn for Exchange can be put to use managing your AD users, your servers, your computers…

      If you don’t see the value in it, not just for your current role but for your future career prospects, then don’t learn anything about it, no big deal.

      If you’re only rarely doing user/mailbox admin anyway then the splitting of the admin tools shouldn’t be a major inconvenience anyway.

      • Doktor McNasty says:

        “If you’re only rarely doing user/mailbox admin anyway then the splitting of the admin tools shouldn’t be a major inconvenience anyway.”

        I suppose that depends on your definition of ‘major’. While we only have about twenty users at any given moment the turnover can be from 4 to 6 staff changes a year and now it takes twice as long now to set up each new user as it used to and I don’t see the point of it.

        There’s nothing wrong with Powershell for power users but I don’t see why integration can’t be left in for those that have simpler environments which don’t need to deal with complicated domain structures which would actually warrant the use of a more complex tool.

        The administrative results I need haven’t changed – but the amount of work required to do it has now increased and unnecessarily in my opinion.

  10. bothsidesofthecoin says:

    From being a consultant deploying new technologies in the past to my current role in a small environment with less than 100 users I always find it funny when I see “IT Administrators” complaining about having to adapt to new technology. I for one thank God that we have progressed from where we came. And all of you that dont want to find a way to at least stay somewhat current, there are plenty of consultants waiting to take your money, and eventually force you to change anyway, right?

    It’s like I tell my internal customers (users), I didn’t write the software and I dont have any idea how these new changes are supposed to help this product with improved performance or integration, but it is what it is. We either have to use it or find a replacement period application (or a new job I guess is another option).

    Powershell – learning it probably one of the best pieces of advice I could give a “small environment” IT Admin to help him keep his job or find his next one.

  11. Why 2010? Mailbox management move from adu&c in exchange 2007. They did’t saw consol exchange 2013.

  12. Socrates Fuertes says:

    I agree with Darwin. Microsoft spends more time thinking about how to make things more convoluted then fixing the things that are broken.
    it’s ridiculous! The notion that a GUI cannot effectively handle all the functionality needed is outrageous. Other software developers seem to be able to get it done.

    • Paul Lemonidis says:

      I agree. Not being able to create a user account from beginning in one console, like you could in Exchange 2003 is simply ridiculous and is a step backwards. Suggesting a long powerhsell command just to create one mailbox is ridiculous. At this rate I might as well go back to sendmail. After all the whole purpose for Window is the GUI, which replaced DOS in the first place, so if we are now going to back to the command prompt MS have negated the whole reason for the very existence of Windows in the first place. There are plenty of free products that don’t have a GUI why am I goig to pay MS for one that also doesn’t. The idea behind MS products is to make them. easy to use and support. So by ramming powershell down our throats is effectivelly letting programmers decide what end users get and will scare off many potential customers. Give me one reason when only running one or two servers why I should not use a free sendmail solution in preference to Exchange if either way i end up at a command prompt and having to modify config .files? Peronsally I have learnt to get on with PS but many people do not like it. At the last count 45% of customers said they prefer a GUI to Poweshell. If I were MS I would try listening to my customers.

  13. Paul, perhaps you would be better off working in a new environment. As they say, learn Powershell or learn that the square ones are fish and the round ones are burgers…

    • Paul Lemonidis says:

      I have learn’t to get on with Powershell as I stated but when 45% of users say the prefer a GUI if I were MS I would take note, not ignore them. I have successfully managed and setup SCC in Exchange 2007 and such like so it is possible. What i find stupid about creating users in the EMC is the following. You can do everythiong except add them to AD Groups at which point you then have to jump to another console, namely ADUC, to continue. I’m sorry but I can find no logical reason for that to be so. Why have a tool that can only do half the job?

  14. Advice for those of you who say that you use PS commands so rarely that you forget them every time: either note them down or better – write a script. Exchange console can even show you exact commands including parameters and their values. Copy it, substitute arguments with Read-Host and off you go. And Get-Help cmdlet -examples is your friend too.

Leave a Comment


We are an Authorized DigiCert™ SSL Partner.