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:
Quote:
> 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
>
>
> Quote:
> > 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
> > Quote:
> >> 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
> >>> 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 >
>
>