Will the exchange functions be returning to ADUC? Or did I miss a setup option? I find the lack of them incredibly inconvenient. Whilst I do appreciate the ability to add users in the Exchange System Manager, I really do miss the ability to create, change, users mailbox settings from ADUC.

No, the ADUC extentions have been removed from Exchange 2007. There are several reasons behind this change. One of the reasons is to support split permissions in organizations that have Exchange Administrators and Active Directory administrators as seperate entities. Another key factor in this decision was automation. In Exchange 2007 the model is to be able to script everything from the Exchange Management Shell using simple, easy to understand commands. The exchange team built a great infrastructure for supporting automation which will hopefully lower the cost of administration. However there was a tradeoff becasue that infrastructure does not support working with ADUC extentions. The benifit of this model is that all Exchange Actions can be found in one place. I understand it will take a little getting used to, but please take some time to try out of the console. You can perform most of the actions necessary for managing Exchange recipients from that console - creating mailboxes (and user accounts with mailboxes), mail-enabling users, creating other recipient types, setting user attributes, etc. Change is always difficult in the initial stages. I am confident that in a little time you will find recipient management better in the Exchange 2007 management console than it was in Exchange 2003 with ADUC. -jim

If one of the reasons is "to support split permissions in organizations that have Exchange Administrators and Active Directory administrators as seperate entities", why on earth can Exchange Administrators create and manage users from EMS? Be consistent. I've been working with E2K7 since pre-beta 1, so I understand how the console and EMS work. I still see this as a HUGE step backwards. Low level admins should not have to learn a CLI or use two different tools to provision users.

Exchange admins cannot create users by default in EMC in 2007. Org admins, Recipient Admins do not have permissions to create users out of the box. If you are running as Domain Admin or Enterprise Admin, you have permissions to do everything, but if you are in one of the Exchange Admin roles you will not have permissions. The cmdlets are provided for companies and 3rd parties that build self provisioning tools (no Admins involved), we need to give them a solution to automate provisioning end-to-end. For example, one major trend we've seen is reducing cost by elimintating manual user creation---user goes to a web page to request a mail account etc. For these scenarios we provide the cmdlets (as the cmdlets are really the platform for extension of system management by customers, MS and 3rd parties). Thanks, ~vivek

Another significant benefit of putting the recipient management tools into the Exchange management console and Exchange management shell is that it can provide a scoped view of your organization that exceeds the scope of a single domain. ADUC is limited to a view of your organization that is per domain, but the Exchange 2007 recipient management tools allow a "forest mode" that will provide you the ability to filter, sort, and take other actions on recipients from the full GAL-scope of your organization.

Hi, I have worked on a number of projects where the limitation of scriptable Exchange mailbox creation has been a significant frustration, so the cmdlets are a great step forward from that perspective. However, I do think that there will need to be a central admin tool to enable help/service desk staff the ability to provision users and their mailboxes from a single interface. I agree with the previous poster who suggested that this is a step backwards in many respects. You are expecting one of two things to occur, either the provisioning process is encapsulated in a script, or the helpdesk staff will need to use two sets of tools to create and configure the user account. There certainly should be a midground here. I expect that a third party will probably release tools to address this, however it is not unreasonable to expect such a tool to be part of the Exchange 2007 release from MS.

I have only begun to look at 2007 Beta2 so please forgive me if this is a fairly basic question. One of the frustrating aspects of Exchange 2000/3 administration was the need to install the ESM through the full server install wizard. Will there be a discreet ESM client installable from a seperate MSI? Cheers

There is a separate option for installing the Management Tools role only (Exchange Management Console and Exchange Management Shell). Note that you still need the dependencies, such as .NET Framework 2.0, MMC 3.0, and for Beta 2, RC0 of the Microsoft Command Shell (now called the Windows Powershell). Note: do not use the very latest version of the Windows Powershell; Beta 2 requires RC0, which you can get from http://download.microsoft.com/download/c/8/5/c85bbb2f-d854-43df-aaaf-73db3c41162a/monad_rc0_50727_x86.zip. Once the dependencies have been installed, the Management Tools can be installed using either the GUI version of Setup (Setup.exe) or the command-line version of Setup (Setup, or Setup.com). Hope this helps.

So you still run setup from the full Exchange server install CD? I was asking whether there was a seperate client install package.

You run Exchange Setup from the CD, and one of the options is to only install Management Tools.

I agree with the comments about a few steps back, 1) Is there a split between service and data management? 2)With the new interface I dont see how I can delegate permissions for a set of Administrators to control certain users? 3) I dont want Exchange administrators controlling certain fields like logon names etc how do you control that? 4) What happens to my clients where i have used native delgation in AD when they upgrade to 2007 will those roles continue to work? 5) Domain Admims in Exchange 2003 had by default certain rights in exchange, do they still have rights to exchange even if they do not belong to any exchange related group? 6) An Admin tools package is desperatly needed, I am not going to inject a whole dvd into SMS, the Exchange 2000/3 cd and Sp was too much already.

Did you get a chance to read the help documentation? Probably the deployment section and operations sections will be most useful, if the sections there are not detailed enough let us know---the documentation team actively monitors these forums and will take your feedback. http://www.microsoft.com/technet/prodtechnol/exchange/E2k7Help/a313c016-0e51-466e-a3de-953e1e0d347d.mspx?mfr=true For #6, the Exchange Management Tools share the same setup as the rest of Exchange.

I have to agree with the posters above that this is a huge step backwards. While being a scripter myself I really do appreciate the added features that the CLI offers we have some pretty low level staff that are responsible for creating the user accounts. They typically create a lot of these accounts based off of templates that we have created for them so that they can just copy a user in ADUC and change the user ID, name etc. I guess I based my ROI and promises that moving to Exchamge (from Groupwise) was going to be wonderful for everyone involved but they will view this (having to do things in 2 diff consoles) to be adding more work to their lives versus just checking a box to create a mailbox account while creating the user as they do now and could do in 2003 had we went that route.The way I see it is that now I have a worse situation where instead of giving Exchange Admins (typically higher in cell count) access to ADUC I now have to give people that are one step up from end users (typically lower in cell count) access to my Exchange Console....Not good, not good at all............

Jim Edelen - MSFT wrote:No, the ADUC extentions have been removed from Exchange 2007. There are several reasons behind this change. One of the reasons is to support split permissions in organizations that have Exchange Administrators and Active Directory administrators as seperate entities. Another key factor in this decision was automation. In Exchange 2007 the model is to be able to script everything from the Exchange Management Shell using simple, easy to understand commands. The exchange team built a great infrastructure for supporting automation which will hopefully lower the cost of administration. However there was a tradeoff becasue that infrastructure does not support working with ADUC extentions. The benifit of this model is that all Exchange Actions can be found in one place. I understand it will take a little getting used to, but please take some time to try out of the console. You can perform most of the actions necessary for managing Exchange recipients from that console - creating mailboxes (and user accounts with mailboxes), mail-enabling users, creating other recipient types, setting user attributes, etc. Change is always difficult in the initial stages. I am confident that in a little time you will find recipient management better in the Exchange 2007 management console than it was in Exchange 2003 with ADUC. -jim

Hi Jim Edelen Thanks for pointing out that the ADUC extention has removed from Exchange 2007.For testing purposes, i created 1000 users by scripts under separate OUs in ADUC.I want to create separate mailboxes for each users such that each OUs resides in a separate mailbox storeunder a separate storage group.Is this can be done through Exchange 2007 command shell or console ?

I couldn't agree more. Creating users by selecting 'copy user' was foolproof. You could give the task of creating users to just about anyone.Considering you need to useADUC to copy the users anyway, anything more than a checkbox to create the mailbox is a huge step backward. I would gladly settle for having the 'copy user' function built into the 2007 Exchange Management Console.

This has created a real problem for Administration. Your Exchange Commands do NOT change the "email" field in the Active Directory Users & Computers. This is a real problem BECAUSEthe ridiculous implementaiton does not account for that in the Offline Address Book Generation. If the Reply TO SMTP address does NOT match the value in Acitive Directory Users & Computers then The OAB Generator Skips the entry because of a "bad" SMTP Address which is in fact not necessarily bad. If Microsoftis going to be so smart as to tell us how we are to usetheir stuff, then please make it work right. -Barry Adkins

I have a question for anyone willing to provide an answer: Why is it when quering AD using ADUC out-dated information is presented if you've unchecked the 'Automatically update email address based on the email address policy' and modified the primary email address using EMC. To replicate this try performing the below steps: Uncheck the 'Automatically update email address based on the email address policy', set a secondary email address as the primary using EMC, and finallysearch for the user using ADUC. NoticeADUCDOESN'T reflect the change in the Email Address attribute on theGeneral tab. This is strange behavior especially since I've verified using ADSI editthe change is definitely made in the Domain partition. Now modify this same users 'User Information (i.e First Name)', then check the 'Automatically update email address based on the email address policy' (which automatically resets the email address to primary based on my Email address policy) using EMC,and finally search for the user using ADUC. Notice ADUC DOES reflect this change in the Email Address attribute on theGeneral tab. Thanks in advance.

How does Microsoft propose then that permissions to a given mailbox are expanded / altered as needed? Let's say we have a user that is long-term sick and the manager needs access to the respective mailbox's content? What about additional mailboxes for the same user? I don't have a problem with learning new ways of doing things, as long as that doesn't impact daily performance and that there is documentation "out there" to support daily maintenance tasks.

This idea of removing ADUC compatibility is really frustrating. You just made life more difficult for the majority of small organizations. I don't understand Microsoft's recent actions of replacing friendly user interfaces with scripting actions. While I completely understand the point of having scriptable admin tools, this should not be at the expense of a quality GUI. I, for one, am very frustrated by this move and the associated loss of obvious-as-the-nose-on-your-face functionality.

My perspective is from a educational institution where we have a lot of users who have a relatively short life cycle. We use a lot of AD/Exchange automation to provision accounts. Our primary means of managing users is via vb.net or C# because of the complexity involved. In order to manage Exchange accounts in our programs we have to drop down to a shell command to run the power commands and then come back. PowerShell takes awhile to load so errors are encountered occasionally and we have to employ a second program to do cleanup. We also do not get consistent errors back if something goes awry in the process. If I summarize this setup we have a program based upon the .net framework that needs to call a shell command to execute another program also based upon the .net framework. (Can I say "not good" here?) I would like to see an API exposed for the exchange Cmdlets so that I could call them directly from a .net program. This would be similar to the .net managed APIs for Active Directory. Another option would be to open up user provisioning within Exchange Web Services. Obviously security would have to be paramount but the functionality would be awesome and we could do exceptional things with the Exchange platform.