none
The term 'Add-ADPermission' is not recognized as the name of a cmdlet, function, script file, or operable program.

    Question

  • We're trying to set the Send-As ExtendedRight to a user for a shared mailbox.  We're on Exchange2010, so everything needs to use remote powershell.  We are also using c# to execute the powershell.

    We are able to add AccessRights using Add-MailboxPermission, but SendAs is now required to be set using Add-ADPermission.  Unfortunately, when executing Add-ADPermission, an exception is thrown (the exception message is the title of the post).  The part that baffles me, is I can run this command locally on the exchange server in which we're connecting to with remote powershell.  So it's definitely loaded, and the fact that the server we're connecting to is an exchange server makes that a given.  I get this same error when trying to run Remove-ADPermission.  However, Get-ADPermission works fine, and returns the values I expect.

    What am I missing to make Add/Remove-ADPermission to work over remote powershell?

    Wednesday, September 12, 2012 1:48 PM

Answers

  • Add-PSSnapin is unsupported for Exchange 2010 management. It's not designed to be used that way, the cmdlets need to be run through the PowerShell Virtual Directory , remoting endpoint, (just like the 2012 Server Manager or Exchange 2010 Management Console). Even when you open up the Exchange management shell on the console, you are still using remoting.

    If you are trying to manage Exchange 2010 remotely, your best bet is to install the Exchange 2010 management tools. ALL the cmdlets work if you are doing things the way they were intended (and documented) to be done.

    http://technet.microsoft.com/en-us/library/dd297932.aspx

    If that won't work for you, maybe you could write some C# to interface with the Exchange Active Directory Driver or an Active Directory API directly? That's outside the scope of this forum but it may be possible.

    What version of AD are you running? Maybe you could set the Send-As permission using an Active Directory cmdlet instead?

    Good Luck!

    -Dan


    Please click "Vote as Helpful" if this post was helpful to you. Thanks!

    Wednesday, September 12, 2012 7:23 PM

All replies

  • When you remotely connect to PoSh (enter-pssession, invoke-command), unless you specify otherwise, it loads the default PowerShell shell with no added modules.  When you run the command from your Exchange 2010 server, you're probably running the commands from the Exchange Management Shell (EMS) that preloads a bunch of cmdlets in the background -- that's how you get the tip-of-the-day and such.  Try adding the modules manually in your PoSh file or alter the connection type of your session to load them for you:

    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ea SilentlyContinue

    or

    PS C:\>$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange 2010 server>/PowerShell -Authentication Kerberos
    PS C:\>Import-PSSession $Session

    Wednesday, September 12, 2012 2:44 PM
  • I follow what you're saying, but I'm confused where you're going with this. If I load the E2010 snap-in on the source server (this is how we did it in Exchange2007, where all the calls were local to that server), how does the remote call force the loading of the E2010 snap-in on the destination server, especially since it's not passed into the connection object? If that's the case, why does Enable-Mailbox, Set-Mailbox, Add-MailboxPermission, Get-MailboxDatabase, Get-ADPermission all work?
    Wednesday, September 12, 2012 3:04 PM
  • If I understood your post correctly, you said that your script using Add-ADPermission works when run locally from your Exchange server and not when run remotely, is that correct?
    Wednesday, September 12, 2012 3:07 PM
  • When local, I am running the Add-ADPermission command itself, through the Windows PowerShell Modules.

    When running it in c#, I pass the Command object into the runspace pipeline, and invoke it.

    Wednesday, September 12, 2012 3:15 PM
  • so you're calling the powershell binary with arguments from csharp?  e.g.:

    powershell.exe -Command { # Insert PoSh Here }

    ...is that what you're saying?  if so, you need to either use the -PSConsoleFile parameter to specify a pre-built PowerShell console you've created ( that loads the Exchange cmdlets) or you need to do something like the following:

    powershell.exe -Command { Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ea SilentlyContinue; # Insert PoSh Here }

    • Proposed as answer by Bigteddy Wednesday, September 12, 2012 3:54 PM
    Wednesday, September 12, 2012 3:23 PM
  • For Exchange2007 we had to add the Snapin to the RunspaceConfiguration, which is passed to the RunspaceFactory method to create the runspace.

    Giving your suggestion a try, I've run into the same problem.

    var addPSSnapinCmd = new Command("Add-PSSnapin");
    addPSSnapinCmd.Parameters.Add("Name", "Microsoft.Exchange.Management.PowerShell.E2010");
    addPSSnapinCmd.Parameters.Add("ErrorAction", "SilentlyContinue");

    Throws --> The term 'Add-PSSnapin' is not recognized as the name of a cmdlet, function, script file, or operable program.

    Another thing we've noticed.  If we change the case of the command to "add-pssnapin", the exception still returns the correctly cased error, that states the "Add-PSSnapin" cmdlet doesn't exist.  If it doesn't exist, how does it know the correct case?  We saw this on "Add-ADPermission" as well.  Another thing to note, when using remote powershell, if the case of a parameter is wrong, it throws the cmdlet doesn't exist error...  We've verified all of our parameters match exactly as displayed on MSDN.


    • Edited by Wussah Wednesday, September 12, 2012 4:53 PM
    Wednesday, September 12, 2012 3:54 PM
  • Since you're literally using CSharp objects to execute PowerShell commands, I'm afraid I'd have to defer to the CSharp community or a smarter guy on PowerShell.  I'm sorry I couldn't be help.
    Wednesday, September 12, 2012 5:14 PM
  • If you are usig C# then you would not use remote PowerSHell.  Use teh Exchange Web administration tools from C#.  It is much easier.

    http://msdn.microsoft.com/en-us/library/exchange/bb409286(v=exchg.140)

    Here is the guide on how to access the Exchange Management Shell directly using C# or other languages.
    http://msdn.microsoft.com/en-us/library/ff326155.aspx

    You will need to post all issues into the Exchange developer forum.


    ¯\_(ツ)_/¯


    • Edited by jrv Wednesday, September 12, 2012 5:27 PM
    Wednesday, September 12, 2012 5:23 PM
  • I'd be more than happy to let Exchange handle the remoting, not to mention the 25-30 seconds it takes to open the runspace for the first time, which is pretty much unacceptable...  The reason we've gone this route, is because the Exchange Web Toolkit for Exchange2010 no longer provides all necessary functionality.

    Some cmdlets work, while others return the following error:

    PS C:> Get-MailboxDatabase -Status | select Name

    WARNING: An unexpected error has occurred and a Watson dump is being generated: Unable to find an entry point named 'IUnknown_Release' in DLL 'exrpc32.dll'
    Get-MailboxDatabase : Unable to find an entry point name 'IUnknown_Release' in DLL 'exrpc32.dll'.
    At line:1 char:20
    + Get-MailboxDatabase <<<<  -Status | select Name
            + CategoryInfo                 : NotSpecified: (:) [Get-MailboxDatabase], EntryPointNotFoundException
            + FullyQualifiedErrorId      : System.EntryPointNotFoundException,Microsoft.Exchange.Management.SystemConfigurationTasks.GetMailboxDatabase

    I haven't been able to find any help on this error.  The interwebs say the toolkit is installed incorrectly.  Unfortunately, installation is a click/click process...

    Now if I run just --> Get-MailboxDatabase, it'll work.  Also things such as Enable-Mailbox throw the same error.

    Everything we need to do works using remote powershell, except the call to Add-ADPermission/Remove-ADPermission.  But it's useless to us if we can't set Send-As...

    Wednesday, September 12, 2012 6:42 PM
  • What is the OS and OS revision level and what is the Exch2010 revision level you're currently running?  2008 R2 SP1 and Exchange 2010 SP1, SP2?  What rollup level?
    Wednesday, September 12, 2012 6:51 PM
  • Add-PSSnapin is unsupported for Exchange 2010 management. It's not designed to be used that way, the cmdlets need to be run through the PowerShell Virtual Directory , remoting endpoint, (just like the 2012 Server Manager or Exchange 2010 Management Console). Even when you open up the Exchange management shell on the console, you are still using remoting.

    If you are trying to manage Exchange 2010 remotely, your best bet is to install the Exchange 2010 management tools. ALL the cmdlets work if you are doing things the way they were intended (and documented) to be done.

    http://technet.microsoft.com/en-us/library/dd297932.aspx

    If that won't work for you, maybe you could write some C# to interface with the Exchange Active Directory Driver or an Active Directory API directly? That's outside the scope of this forum but it may be possible.

    What version of AD are you running? Maybe you could set the Send-As permission using an Active Directory cmdlet instead?

    Good Luck!

    -Dan


    Please click "Vote as Helpful" if this post was helpful to you. Thanks!

    Wednesday, September 12, 2012 7:23 PM
  • As per Danial I would use teh AD direct method if all you want to do is change the SendAs.

    This is an permision in AD anyway and is only created ther by teh Exchneg AD extensions.

    The AD properties are redily available without any SDK or other addtions and do not require PowerSHell at all.  Just use the AD management classes which are always available on any host in a domain.

    Again - The Exhange forums would be a better place to post for Exchange technical issues using C#.


    ¯\_(ツ)_/¯

    Wednesday, September 12, 2012 7:32 PM
  • Daniel, I'm doing exactly as Microsoft has told us to do:

    const string SHELL_URI = @"http://schemas.microsoft.com/powershell/Microsoft.Exchange";
    
    var credential = (PSCredential)null; //Use Windows Authentication
    
    var connectionInfo =
         new WSManConnectionInfo(new Uri("http://exchangeServer/PowerShell/serializationLevel=Full"), SHELL_URI, credential)
                                            {
                                                AuthenticationMechanism = AuthenticationMechanism.Kerberos
                                            };
    
    return RunspaceFactory.CreateRunspace(connectionInfo);

    Again, all commands are working except for Add/Remove-ADPermission.

    Unfortunately Exchange2010 no longer supports managing Mailbox Rights through AD.  Which is why we're in this predicament.

    I'll move this thread to the correct forum.  Thank you all for your time and consideration!

    • Edited by Wussah Wednesday, September 12, 2012 7:48 PM
    Wednesday, September 12, 2012 7:40 PM
  • After talking with Microsoft, we have determined that this was a permissions problem.  The fact I could run the command made me believe it wasn't a permissions issue.  Unfortunately, the reason Windows PowerShell Modules allowed me to run the commands was because Windows PowerShell loads the ActiveDirectory SnapIn.  Verification was passing because the AD account was a Domain Admin, so PowerShell allowed me to run the command.

    The lesson to learn here is to use the Exchange Management Shell when trying to run commands, instead of the Windows PowerShell Modules.

    Friday, September 14, 2012 8:04 PM