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)
I came across this article while I was searching for a solution to an issue we are having with creating email addresses. We have had no trouble in the past creating them, but in the last two months, we’ve run into this issue with a couple of accounts and have not been able to figure out what’s going on. Since it seems like there are a lot of pros here, I’m hoping I can throw this out there and get some good feedback. Whenever I create a user mailbox in the EAC web console, it appears to create the account just fine and is linked to the account in the AD. When you try to send an email though, you get the error “This email mesage cannot be delivered to _________________ because the e-mail address is no longer valid”. However, the email address is there in the EAC and it appears to have all of the same settings as other email accounts. I was able to fix one (it was deleted and recreated due to other issues) by making it a custom email type of X500 and putting in a string that essentially forwards the emails. However, that same method does not work for the accounts that I am currently creating. Any help would be very appreciated.
If you’re deleting/recreating mailboxes, or creating new mailboxes that use previously used SMTP addresses, then the NDR you get is most likely the IMCEAX one. A Google search for “NDR IMCEAX” will bring up the solution for you (which involves adding X500 addresses).
Thank you! I’ve never done administration in Exchange before, so I’m learning and appreciate your response!
Pingback: How to Install Exchange Server 2010 Management Tools on Windows 2012 R2 - Savage Nomads
All of the power shell stuff is great. I hear the soapbox you are on. I have a SMB that lost their one and only Exchange server. Same AD, no changes. New exchange server. Cannot create mailboxes for existing users when they do not show up. Cannot create new ones because they already exist in AD. The Exchange server appears to not see all od AD even though it is looking at the correct DC.
Blogs say to delete the AD account and recreate it. When was the last time you told a CEO you were going to delete their account and recreate it. Probably the last you had a job. You have a real helpful answer, please share it!! Otherwise…
Was the replacement server installed by doing a recovery install of Exchange?
If not, it’s possible there’s some AD permissions issues preventing it from seeing the user objects. Re-running “setup /preparead” would be a start.
If you installed it as a new server into the same AD, then the users are probably already mail-enabled and hence you can’t create another mailbox for them (since they already have one, as far as Exchange can tell, with all the mail attributes already on their AD user object).
Before I can suggest anything else you’ll need to describe what recovery steps you took to get you to this point. Was it a recovery install? Do you still have the mailbox database from the old server? Anything else you’ve done that might be relevant?
I actually like PowerShell.
Personally, I think the whole exercise was clearly a profit generator. Not at the application or it’s fancy new design, but at the training level. They not only broke down the course material into segments, they broke up the qualifications too. So, you end up paying 2-5 times more than you use to. Then there’s all the partner revenue, because a lot of companies have to maintain that to compete. The training course for trainers, roadshows, the junkets and all the other periphery stuff is making them extra cash too. There’s bound to be more I haven’t mentioned.
The way they talk about PowerShell as being the greatest thing ever, is just stupid. It’s just DOS with extra CLI commands/intelligence, that could have been added to the existing DOS. It’s been done before, DRDOS is a good example. Nothing special about that.
As for the excuses for moving away from a unified database, console and process. You can’t tell me that having to use several management consoles to do something you only needed to use one console previously, is better. That’s like telling me I should swap my smart phone for an old school cell phone, a paper notepad, diary, calculator, computer for web stuff (e-mail, http, etc) and an alarm clock. Try carrying that lot around, again.
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.
I agree documenation is important and makes everyone’s job easier and more productive once the documenation process is complete. I think the bigger isssue is that many of IT geeks work in small shops and don’t have the luxary of having siloed job positions where we can focus on 1 or 2 areas. Many times your help desk is your domain admin, backup, anitvirus, firewall, network, and cable monkey guy. That said, PowerShell is useful and I recognoize its value, espically in large organizatoins with hundreds and thousands of servers. It is the small shops that really suffer when new managment tools are introduced. Note I said managment tools, not applications.
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…
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?
Our entire new users creation process is done with Powershell. For my part (Exchange & Lync) I only need to add to find an available phone number hit enter and I’m done. My script even sends out two email notices when its completed. So for what used to take about a half hour for each new user using the GUI, is now completed and email notices sent out in a couple of minutes. You can see it here – http://blogs.technet.com/b/heyscriptingguy/archive/2012/12/10/new-user-exchange-amp-lync-settings.aspx
Nice script…
Question… How long did it take to create that script?
I would love to really learn powershell to that extent but between Life and being forced to wear mulitple IT hats, learning powershell to that ability is more of a pipe dream. Thank you Google, for helping us find knowledge, too bad Bing doesn’t work that well.
I find it funny with Server 2012 you can now issues PowerShell Commands to manage servers via a GUI? To me, that makes more sense than forcing you to learn PowerShell and spending weeks writing these management scripts. I think managment scripts should have been avalaible via the Exchange console…. Prompt Prompt Prompt List: What would like to do: 1. Create user with Mail and moblie on. 2. Create user with Mail and mobile off 3. Create user with NO mail 4. Add Lync to existing user
How on Earth did it take you a half an hour using a GUI? Do you operate your mouse with your feet?
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.
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.
Why 2010? Mailbox management move from adu&c in exchange 2007. They did’t saw consol exchange 2013.
Organizations that migrate from 2003 directly to 2010 don’t see that the change happened in 2007.
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.
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.
“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.
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.
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.
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.
IMHO
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.
Regards,
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.
“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.
Pingback: Review of Z-Hire Employee Provisioning App
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.
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.
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.
very good analysis.thanks
Pingback: How to Install Exchange Server 2010 Management Tools on Windows 7