Question about Exchange Management Console and Exchange cmdlets

Does anyone know whether the Exchange Management Console hosts PowerShell
and calls the Exchange cmdlets directly or whether the cmdlets are just
another interface to do everything you can do in the Exchange Management
Console (and more)? I know they say the Exchange Management Console was
supposedly built on top of PowerShell, but I guess what I'm wondering is
this: Is it really using the Exchange cmdlets as it's only access into the
underlying .NET objects to work with Exchange or are we dealing with two
interfaces into .NET objects here? If it is only using the Exchange
cmdlets, what is the impact on performance with the extra overhead of going
through PowerShell?

--
Kirk Munro
Poshoholic
http://poshoholic.com

IMO they are the same only the EMS adds some more Exchange related functions
(tip of the day) on top of the PowerShell environment
such as get-excommand which will list Exchange cmdlets only. The regular
get-command will list a full list of cmdlets.
As for performance, in my environment I'm using regular PowerShell and when
I need access to exchange cmdlets
I load it via a custom function in my profile that loads Exchange snapin.

-----
Shay Levi
$cript Fanatic
http://scriptolog.blogspot.com

Hi Shay,

That's not quite what I'm looking for.

Exchange 2007 can be administered through either the Exchange Management
Console (EMC) or through the Exchange PowerShell cmdlets that come with the
EMC. I've heard Microsoft state that there isn't anything that you can do
in the EMC that you can't to using the Exchange PowerShell cmdlets. It's
actually the opposite: that there are things you can do using the Exchange
PowerShell cmdlets that you can't do using the EMC.

So given that information, I need to know two things:

1. Does the EMC presentation layer sit on top of:
a) the Exchange PowerShell cmdlets
or
b) the .NET classes that are used to administer Exchange, in which case
there would be two direct interfaces to those objects: EMC presentation
layer and Exchange PowerShell cmdlets.

2. If the EMC is a presentation layer that sits on top of the Exchange
PowerShell cmdlets and that doesn't interact directly with the .NET classes
that are used to administer Exchange 2007, what performance impact does this
extra layer incur when compared to interacting with the .NET classes that
are used to administer Exchange 2007 directly?

Does that make more sense?

--
Kirk Munro
Poshoholic
http://poshoholic.com

"Shay Levi" <no@xxxxxx> wrote in message
news:8766a944d11d8c9f06aaf7bd716@xxxxxx

There are things you can't do with EMC because they are not implemented yet
in the GUI (such as Public Folders stuff, prior to SP1, etc).
You can do a lot more using EMS (Exchange Management Shell) than you can
do with EMC. IMO there are no two interfaces but I may be wrong.

-----
Shay Levi
$cript Fanatic
http://scriptolog.blogspot.com

The way I heard it explained was that the cmdlets were built first and the
the EMC was built to use them
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Shay Levi" wrote:

In message <eUEewgkIIHA.3848@xxxxxx>, Kirk Munro
<sorry@xxxxxx> writes True. EMC (Pre Sp1) was like 80% coverage compared with EMS. Sp1
improves things a bit, but there's still mileage in EMS!!
The EMC snapin is just another snapin. You could run powershell and add
the snapin, or modify the various profile files to add in additional
snap-ins when using EMS (eg powergadgets, PSCX, etx).

If you look carefully at the shortcut created when Exchange is
installed, invoking EMS is just a call to Powershell using a saved
console and running a sort of start-up a script (Exchange.PS1).
Personally, I've re-built the Exchange.ps1 script on my Exchange boxes,
and have changed the profiles to load the other add-ins, add some
aliases and functions, etc.
No idea. The EMC is a layer on top of Powershell. This, in turn sits on
..NET. I'm not clear on the question however.

I suggest you play a bit with EMS!
Not fully! But that's probably my problem.

HTH

Thomas
--
Thomas Lee
doctordns@xxxxxx
MVP - Admin Frameworks and Security

Ok, a diagram is clearly in order here because some people aren't
understanding what I'm trying to ask here (although that may be my fault).

I understand the EMC, how it doesn't provide all of the functionality
available in the cmdlets, etc. I also understand the Exchange Management
Shell, and that it is just loading a profile to pre-configure PowerShell
with the Exchange snapin loaded. I only mentioned these things because I
wanted to set up the question.

I've also heard (and Richard as well) that the EMC was built on top of the
Exchange PowerShell cmdlets. But is that accurate, or are they saying that
it is using the same functionality that the cmdlets use and trying to convey
how anything you can do in EMC you can do in PowerShell?

Is the architecture something like this:

EMC presentation layer
------------------------
Exchange PoSh cmdlets
------------------------
..NET Exchange classes

or is it more like this:

EMC presentation layer Exchange PoSh cmdlets
------------------------ ------------------------
..NET Exchange classes .NET Exchange classes

where they've made sure that everything you can do in EMC you can do in the
Exchange cmdlets as well, but where technically the EMC presentation layer
doesn't call the Exchange PoSh cmdlets directly?

I thought it was the former up until recently, so I thought I should raise
the question to find out one way or the other. Here's why I'd like to know
this. I've spoken with some product teams debating between taking the
double interface approach (presentation layer and PoSh cmdlets) instead of
the layered interface approach (presentation layer on top of PoSh cmdlets)
because of performance concerns, and I'm trying to find out how valid those
performance concerns are. Clearly having an extra layer to go through will
add some overhead, but is it significant enough to be concerned about it?

I've used the EMC quite a bit and haven't had any complaints about
performance in that console yet, but in recent tests I can see that it
retrieves information from AD faster than I get it using PowerShell cmdlets
directly so I would like to know if it's actually going through PowerShell
or not.

Does that clarify the question?

--
Kirk Munro
Poshoholic
http://poshoholic.com


"Thomas Lee" <tfl@xxxxxx> wrote in message
news:vTvj+cJWXDNHFAre@xxxxxx

I believe the first example is more accurate, although I'd consider the EMC
more of a "guided command generator".

"Kirk Munro" wrote: