none
Is it possible to manage Exchange (2010 and 2013) remotely from a machine in different domain? RRS feed

  • Question

  • Hi,

    1. Is it possible to manage an exchange server from a machine in different domain using by opening a remote exchange ps session?

    2. Yes, i do have the credentials information. Is there any specific authentication i need to use - for ex: credssp, basic etc...

    3. Is it mandatory to have trust relationship between domains?

    Please also note that the credentials i am using to open remote session on remote exchange server is its domain administrator account. So the account should have permissions to manage exchange remotely.

    Looks like from this post i should be able to do this: __http://stackoverflow.com/questions/14127050/powershell-remoting-giving-access-is-denied-error?rq=1

    then its back to my original question i guess, what to do to setup my environemnt to make the winrm work?

    __http://social.msdn.microsoft.com/Forums/en-US/exchangesvrdevelopment/thread/3fdf409b-83ad-4717-956c-2a0eede5881c

    Regards,

    Dreamer




    • Edited by DreamerNN Saturday, February 2, 2013 8:56 PM
    Saturday, February 2, 2013 8:31 PM

All replies

  • 1. Yes with remote powershell it doesn't matter if a machine is domain joined or not, or what domain its a member of, as long as you not specifying it to use the currently logged on credentials.

    2. It depends what authentication is set on the destination server, by default you should be connecting via https and using basic auth which is the default config and will work on most servers unless they have changed the configuration. (most examples you see use HTTP which is okay if the machine your trying from is domain connected and you want to use the current credentials, but from a remote machine you should always use HTTPS).

    >>Please also note that the credentials i am using to open remote session on remote exchange server is its domain administrator account. So the account should have permissions to manage exchange remotely.

    While that maybe usually true its an assumption you need to check with the administrator of that Exchange Org that the account your using has been granted Rights to use Remote Powershell and they have been delegated all the RBAC roles for the cmdlets that you wish to use.

    Cheers
    Glen

    Monday, February 4, 2013 12:41 AM
  • Thanks Glen for the reply.

    I have prepreared a private exchange organization (my own DC, exchange servers) as we are trying to provide a solution to our customers. So, i am the administrator of my private org:) and i am using Domain Admin credentials while trying to connect.

    Please note that I am able to create a simple default remote PS session ($s = New-PSSession "fqdn" -Credential $c). Whenever i used a exchange configuration to create a session its failing with winrm configuration errors.


    Below are the cmds i used to establish remote exchange session:


    PS C:\> $connectionUri="__http://{fqdn/powershell?serializationLevel=Full;ExchClientVer=14.3.91.1"

    PS C
    :\> $s = New-PSSession -ConnectionURI $connectionUri -ConfigurationName Microsoft.Exchange
    -SessionOption $so -Credential $c

    OR

     $s = New-PSSession {fqdn} -Credential $c -ConfigurationName
    Microsoft.Exchange

    Please look at __://stackoverflow.com/questions/14666168/unable-to-open-remote-exchange-2010-and-2013-pssession-from-a-different-domain

    or ___://social.msdn.microsoft.com/Forums/en-US/exchangesvrdevelopment/thread/3fdf409b-83ad-4717-956c-2a0eede5881c for more details.

    Regards,

    Dreamer.

    • Edited by DreamerNN Monday, February 4, 2013 2:03 AM
    Monday, February 4, 2013 2:02 AM
  • Can you start a Exchange Management Shell session locally on the actual server your trying to connect to logged on as the user your trying to connect with ?

    Cheers
    Glen


    Monday, February 4, 2013 6:20 AM
  • Thanks Glen for the quick reply. Actually same scripts are working if i exceute them from any machine in the same domain as the exchange server or domain controller. Whenver i try to execute the script to create remote exchange ps-session its failing. For convenience here is the script (PS C:\> $connectionUri="__http://{fqdn/powershell?serializationLevel=Full;ExchClientVer=14.3.91.1" PS C:\> $s = New-PSSession -ConnectionURI $connectionUri -ConfigurationName Microsoft.Exchange -SessionOption $so -Credential $c)

    Now i tried to create remote exchange session with kerberos authentication (courtesy to: __http://technet.microsoft.com/en-us/library/dd297932(v=exchg.141).aspx) and its started working (PS C:\> $s = New-PSSession -ConnectionURI $connectionUri -ConfigurationName Microsoft.Exchange  -SessionOption $so -Authentication kerberos -Credential $c; )

    Not sure why its working? In fact the script i was using without kerberos authentication previously is nothing but an excerpt from Micorosoft Remote Exchange scripts ("C:\Program Files\Microsoft\Exchange Server\V14\Bin\ConnectFunctions.ps1")

    Now i am a little bit concerned about the recommendation? Should i always try to open remote exchange pssession with Kerberos as authenticationtype and if it fails and try to open the session with defualt authentication? Neverthless, i am no longer blocked and i just hope it doesnt happen at customer site:)

    PS C:\Users\administrator.SR5DOM> $s | select name, availability, configurationname

    Name                                                               Availability ConfigurationName
    ----                                                               ------------ -----------------
    Session1                                                              Available Microsoft.Exchange

    Regards,

    Dreamer


    • Edited by DreamerNN Monday, February 4, 2013 8:44 AM
    Monday, February 4, 2013 8:43 AM
  • You should be able to use HTTPS and Basic auth by default on a Exchange 2010 (this is what i use), kerberos is another option but there are things that can cause it to break, if your not connecting from a domain connected machine inside a corporate firewall. But this is a configuration option for an Exchange Administrator so these options can be switched on and off so its something that will always be environment specific.

    Cheers
    Glen

     
    Tuesday, February 5, 2013 5:30 AM
  • Hi Gary,

    Can you elaborate what you mean by HTTPS and Basic auth by default?

    Do you mean to say Basic authentication uses HTTPS protocol? The possible enumeration values for authentication are "Default, Basic, Negotiate, NegotiateWithImplicitCredential, Credssp, Digest, Kerberos".

    New-PSSession : Cannot bind parameter 'Authentication'. Cannot convert value "https" to type "System.Management.Automat
    ion.Runspaces.AuthenticationMechanism" due to invalid enumeration values. Specify one of the following enumeration valu
    es and try again. The possible enumeration values are "Default, Basic, Negotiate, NegotiateWithImplicitCredential, Cred
    ssp, Digest, Kerberos".
    At line:1 char:123

    regards,

    Dreamer

    Wednesday, February 6, 2013 4:42 AM
  • Your URI should be a https URI and auth Basic eg

                    ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
                    String AdminUserName = unUserName;
                    String Password = pnPassword;
    
                    System.Security.SecureString secureString = new System.Security.SecureString();
                    foreach (char c in Password)
                        secureString.AppendChar(c);
                    PSCredential credential = new PSCredential(AdminUserName, secureString);
                    WSManConnectionInfo connectionInfo = new WSManConnectionInfo(new Uri("https://" + snServerName + "/PowerShell"), "http://schemas.microsoft.com/powershell/Microsoft.Exchange", credential);
                    connectionInfo.AuthenticationMechanism = AuthenticationMechanism.Basic;
                    connectionInfo.SkipCACheck = true;
                    connectionInfo.SkipCNCheck = true;
                    connectionInfo.NoEncryption = false;
                    connectionInfo.MaximumConnectionRedirectionCount = 4;
    Cheers
    Glen
    Thursday, February 7, 2013 6:18 AM