11-09-2007
|
#8 (permalink)
|
|
|
Re: Question about Exchange Management Console and Exchange cmdlet
I believe the first example is more accurate, although I'd consider the EMC
more of a "guided command generator".
"Kirk Munro" wrote: Quote:
> 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 Quote:
> > In message <eUEewgkIIHA.3848@xxxxxx>, Kirk Munro
> > <sorry@xxxxxx> writes 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.
> >
> > True. EMC (Pre Sp1) was like 80% coverage compared with EMS. Sp1 improves
> > things a bit, but there's still mileage in EMS!!
> > Quote:
> >>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.
> >
> > 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.
> > Quote:
> >>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?
> >
> > 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!
> > Quote:
> >>Does that make more sense?
> >
> > Not fully! But that's probably my problem.
> >
> > HTH
> >
> > Thomas
> > --
> > Thomas Lee
> > doctordns@xxxxxx
> > MVP - Admin Frameworks and Security >
>
> |
My System Specs | |