In my previous posts I showed some functions for finding an AD DC and run LDAP query’s against those DC`s. The following function “Connect-Exchangeservice” builds on top of the Get-LDAPobject function. This new function will connect you to the PowerShell management session of an exchange server. This way you do not have to install the exchange management tools to manage exchange via PowerShell. The big advantage of this function is that if your computer is domain joined you don’t need to know the name of the exchange servers to connect. The function will discover an exchange server for you and try to connect. The function has support to connect to multiple exchange sessions / domains or forests at the same time making management in multi forest environments easy. You can load this module together with the “Get-LDAPobject” function in any of your scripts or you PowerShell profile and enjoy the simplicity of connecting to exchange.

You can find the script in the TechNet gallery or under the script section of this site.

The Help content of the script:

Lets see the function in action from a domain joined computer:

First we load the functions “Get-LDAPobject” and “Connect-Exchangeservice” via pasting it in the current PowerShell or have it loaded somewhere in your scripts function region. Then we verify that the function is present by calling “Get-command Get-LDAPobject”. PowerShell should return the command as shown below.

Because our first client is Active Directory joined to a domain in the Forest where exchange is installed the “Connect-Exchangeservice” will automatically search for an exchange server in the site where the client is located. If one or more servers have been found it will try to connect to a random server. Due to this behavior multiple connections will automatically load balance over the available servers. If all goes well, we should see the exchange commands being imported in the local run space.

We now have all commands available that are assigned to the logged on users RBAC role.

So let`s say we are in a coexistence scenario where we have multiple version of exchange in the forest. ( Every body knows the fun in managing exchange if you are connected to a lower or higher version then the server you want to manage right ??!). The function supports the switch “-version” to indicated what version of exchange the script should look for when searching for available exchange servers. Currently the following versions are supported: 2007, 2010, 2013 and 2016. Let`s look at an example:

In my test environment there are only exchange 2016 servers but as you can see the function nicely reports that it cannot find any server of version 2007 in the current site. If use the parameter “-Version” with the exchange version “2016” it will connect and import the commands again. ( Do note that the “-prefix” parameter will come in handy as explained later).

The parameter “-ADsite” can be used to connect to a specific AD site if you have multiple exchange sites.

The parameter “-Domain” can be used to connect to a specific Domain if you have multiple forests with a thrust between the forests. One of the best use cases here is when you are running a cross forest migration you can now connect from within a single script to both source and target domain exchange servers.

The parameter “-cred” can be used to connect to exchange using a different account than the one you logged on with.

When you connecting to multiple servers from the same run space you will normally get the warning message “No command proxies have been created, because all of the requested remote commands would shadow existing local commands”. This is because the same commands are getting imported twice and PowerShell won`t know to which server it needs to send the command. The function “Connect-Exchangeservice” provides you with the option to prefix command`s. When you use the “-prefix” option all imported commands get the parameter added after the “-” sign.

For example, if you want to connect to 2 AD sites Site1 and Site3 you can use the site names as prefixes. This would result in commands like get-site1exchangecertificate. This is shown in the example below: (notice the server names)

You can use these prefixes for all kind of use cases.

• Different domains
• Different forests
• Multiple AD sites
• Multiple version of exchange
• any mix of the above

Let`s see the function in action from Non domain joined computer:

A non-domain joined computer has an authentication disadvantage of not being able to use Kerberos authentication. Due to this the only way to authenticate is basic or digest (preferred because it uses password hashes ). Exchange PowerShell has both of these authentication types disabled for security reasons. Enable them at your own risk !.

Because your computer is not domain joined discovering the servers automatically is not possible without invoking the hole autodiscover protocol. So we use the “-exchangeurl”, “-cred” and “-Authenticationtype” to provide the url, credentials and authentication type.

As you can see below the computer is a standalone machine loading the exchange shell.

Leave any comment here and rate the script if you like it on the TechNet gallery.

Cheers

Martijn ( Scriptkiddie ) van Geffen