none
[E2007/2010/2013][TA][C#][Windows]: How best to install a transport agent in an Exchange version independent manner? RRS feed

  • Question

  • I'm maintaining a transport agent that has a C# custom action installer class to install itself.

    This code invokes powershell commands (Get-TransportServer, Get-ExchangeServer) to determine some things and then invokes the Install-TransportAgent (or Uninstall-TransportAgent for uninstall) command.

    Currently the code detects whether it's installing for Exchange 2007 or 2010 and uses either:

     "Microsoft.Exchange.Management.PowerShell.Admin"
     "Microsoft.Exchange.Management.PowerShell.e2010"

    as the name of the PS snap-in.

    I guess that Exchange 2013 doesn't use either of the same strings, so there's probably going to need more changes in the future to handle that.

    Is there a better (Exchange version independent) way of installing a transport agent?

    Ideally I think I ought to be able to call underlying Exchange interfaces (the things the powershell commands must eventually use) rather than having to do things indirectly via powershell commands.

    Friday, September 14, 2012 9:06 AM

All replies

  • David,

    No - there isn't any other approved way. Microsoft see the Exchange (Power) Shell as the way to do the install/uninstall actions on an agent.

    There is an XML file that contains the list of agents, their paths, factories and current states (enabled / disabled), but the Microsoft wording about not editing this file manually is quite blunt.

    Regards,

    Scott Quinn


    Scott Quinn | C# developer & messaging specialist (for hire). Contact me at http://au.linkedin.com/in/scottquinn

    Monday, September 17, 2012 12:07 AM
  • Thanks Scott,

    Powershell only was what I was fearing as I'd not found any information myself.

    It's a pretty poor state of affairs - especially since it's just the snap-in name that's version dependent.

    Dave

    Monday, September 17, 2012 8:19 AM
  • Dave,

    It's all part of Microsoft's "Exchange Shell can (should) control everything Exchange-related" vision.

    It is kind of neat when it comes to administrators being about to customise / create their own scripts to do management tasks instead of having to rely on standard GUIs.

    However it's crappy when it comes to things like this i.e. you need to make calls to a command shell do to tasks that should be available via an API.

    You know, it wouldn't be so bad if calling Powershell from C# was:

    • Consistent i.e no Admin Vs e2010
    • Not so messy (load arguments ... make the call .. parse results... yuck)
    • Was even half way quick (Zzzzz..)

    Regards,

    Scott Quinn


    Scott Quinn | C# developer & messaging specialist (for hire). Contact me at http://au.linkedin.com/in/scottquinn

    Monday, September 17, 2012 9:30 AM
  • >You know, it wouldn't be so bad if calling Powershell from C# was:

    • Consistent i.e no Admin Vs e2010
    • Not so messy (load arguments ... make the call .. parse results... yuck)
    • Was even half way quick (Zzzzz..)

    <

    Agreed on all points.

    While debugging the installer, the execution of the powershell stuff was by far the slowest thing in the entire setup.

    I presume the Exchange 2013 snap-in is named e2013?

    Monday, September 17, 2012 10:20 AM
  • I've been slack and haven't gotten around to checking that aspect of Exchange 2013 yet (although I will over the next week or so), but I'd expect it will be different to the previous versions along those lines.

    Note that while changing that XML file I mentioned is out for installing an agent there's no reason why you can't use to it get the current installation state (installed or not, enabled or not... and the priority) - it's certainly quicker to read and parse some XML than to call Get-TransportAgent!

    Regards,

    Scott


    Scott Quinn | C# developer & messaging specialist (for hire). Contact me at http://au.linkedin.com/in/scottquinn

    Monday, September 17, 2012 1:42 PM