Exchange Management Shell in Exchange 2010

Published May 06 2009 05:27 PM 1,089 Views

We've released a new article that talks about some of the improvements and changes to the Exchange Management Shell in Exchange 2010. Introduced in Exchange 2007, the Shell, which is based on Windows PowerShell, is the powerful command line interface that you can use to manage your Exchange organization. We made improvements to the underlying infrastructure in Exchange to give you more flexibility around how and where you use the Shell, and how you define your permissions model.

If you're new to Exchange, read the article to discover what the Exchange Management Shell is, and how to start using it. If you're a Shell veteran, you'll want to read up on Role Based Access control to find out how the Shell makes use of RBAC so you can fully customize the permissions you give out to your administrators and your users. Be sure to read the links provided in the article which take you to more in-depth details about each of the features discussed in the article.

You can find the article here.

-- David Strome

Not applicable
Once again microsoft is fixing their trash with open source and to think people still purchase this stuff. Maybe one day they will go to Linux and stop paying for what was writen for free by someone else that a market steals for their own profit. The butterfly finally shows it is a moth, now we know why there are so many holes.
Not applicable
@ThaMadGreek - Care to elaborate? - How are Microsoft fixing things with open-source? - In fact, I don't see anything as being broken in the first place. Have you read the article?

@msexchangeteam keep up the great work!

Not applicable
Why are they still using the Shell?  I started in IT in 1998, so I don't have a history of growing up with dos prompts that my older colleagues do.  Administrators that started in IT in the late 90s or early 00s are at a disadvantage when it comes to the shell.  What if there were some sort of user interface with graphics that emulated the Shell? Like, a GUI?  Like in every version of Exchange before 2007, and pretty much every version of any business software made since 1994?
Not applicable
@Brandon What do you mean?  There is a GUI for Ex2007.  I'm sure there will be one for Ex2010, too.  Maybe I'm missing some sarcasm here.

I don't care what kind of IT admin work you do.  Learning to script is only going to make your life easier in the long run.  

I'm a converted VBS scripter. PowerShell is where it is at.  Today I just converted a 56 line VBS script that read from a CSV and added those users to a group and boiled it down to 6 PS lines - only because I wanted spaces between lines for it to look clean.

My point is it is as efficient and fast of a scripting language you'll get for Windows. I can't speak on other OS's.
Not applicable

Yeah there was a little sarcasm.  I understand there is a GUI, but it is limited.  You must use the Shell to do so many other, simple things that could easily be integrated into a clickable application.  It seems that they had to quickly integrate a low-level GUI to go along with the Shell so the Shell would be 10% less confusing.  The Shell is how you do things, the impression to me is that the GUI came after the shell, in hindsight.  

The reason I became a server administrator, and then an Exchange administrator is because I'm not a programmer.  I'm not a scripter or developer..I know how to do things that I learn by interacting with a visual interface that I can look at.  I've been looking at visual graphical interfaces for years.  I don't have the memory for commands that a programmer does.  It's like I spent my life learning how to repair gasoline car engines, and then the entire auto industry switches to hamster wheels instead of gas power.

No one ever was working on Exchange 2003 and said, "You know what this needs?  More command prompts like my dad used to use."

Not applicable
PS is a creat tool or add-ins to Exchange, but making that as a only tool for world wide is a bit strange idea. Like, would you like to do your day-to-day operations using the scripts only? E.g. rename single user? What is the benefit to use PS for that? Before you shoot me because of "...a only tool...", keep in mind that there are tasks which are available only for PS.

And when you step one step back and look your environment more wide, do you really say to your helpdesk people: "This the power shell, this is your tool.."

Or think about your user admins, to create a new user you could ask them to use: Exchange GUI, Exchange Shell or ADUC. But:
- To create mailbox you have to use 1 or 2, not 3 at all
- To enable OCS service, you have only 3 (with OCS add-ins to ADUC),  ok 2 might work as well, but it is far away from "efficient and fast" -way.
- Modify user, you have to use 1 for exchange stuff and some basic user attributes, 2 for most of the attributes but you have to remember quite much to do and again "efficient and fast" is a question, 3 when you need to modify some other attributes from 3rd parties.

So as I told, PS is great help in case where you need to create 100s objects at one time, but I doubt that there are many people who have to do this weekly. Also it is great help for creating new databases, but still I'm not sure would I do so e.g. if I have setup server early 2008 and I have to create new database in late 2009, I feel GUI -way is more simple to remember, personally.

And I feel that memory is one issue as well. The commands which you are not using monthly you might forget and you have to put extra effort to find the way to run it. On the GUI even you don't perform some tasks daily or even monthly, you can still see them on the list and find them much more easily.

And personally the worst problem is programming, have you ever tried to write code for managing the objects (create a new user with mailbox by C# or VB). Why to do so... you must re-read my comment and find the reason ;)

On here I can say I'm a bit old fashion....or as others might say: lazy to learn new stuff? :D
Not applicable
Exchange seems to be focusing more on the enterprise space, where there will likely be dedicated Messaging admins who can afford to specialize a bit more.  For smaller shops there's always hosted Exchange Online :)

The RBAC looks good and seems like an easier way of delegating permissions out to IT staff in charge of their own sites.  Hopefully it also sets the required ACLs on the various parts of AD and doesn't just filter out cmdlets.  
Not applicable
I fell in love with Exchange because of it's GUI-based management, when I was first introduced to 5.5.  The convenience and intelligence of Exchange administration via the GUI continued to grow with each version through 2003.  Microsoft's unfortunate decision to reverse years of progress in the GUI and force Exchange admins to de-evolve back to a command line interface killed my dreams of upgrading to 2007.

The Windows world left DOS behind as the primary interface in favor of an easier and more intuitive GUI-based Windows OS.  Why, then, is Microsoft forcing SMB Exchange admins to type out lengthy piped commands that could previously be performed in seconds with a few mouse clicks?  (Examples: enabling SSL for IIS & RPC/HTTP, view size of individual mailboxes)

Is Exchange 2010 following this same pattern, or will I finally be able to perform all the same functions available through the 2003 ESM in the 2010 mgmt GUI?
Not applicable
If you think from an admin point of view that Microsoft is devolving by over-emphasizing PowerHell, then try spending some time in an ISV's shoes that supports an application that has to integrate with Exchange.  5.5 was hard, but not impossible.  2000/2003 had an interface through CDOEXM that could be used to create mailboxes and such and you could extend AD with documented interfaces for context menus and property sheets, which is why you could create one property sheet for a user object in ADU&C.  With Exchange 2007, Microsoft ripped the entire guts out of any property sheet integration in AD, plus removed the only API to create or delete a mailbox.  

I think the idea of having a general purpose scripting tool is great, IF you want to use it.  But have an underlying interface that the scripting tool is using and let developers create applications that can make it better.  The end result is better options for customers.  I'm one ISV that wonders why I am a 'partner' with Microsoft at all.  And I have to pay for this privilege.
Version history
Last update:
‎Jul 01 2019 03:43 PM
Updated by: