Remote Exchange AD Process

Summary…

I need advice on how to implement a workflow for a Exchange/Ad script for a small I.T. staff to use.

Details…

I created a module which encompasses functions that will create Exchange mailboxes and associated AD accounts, with Group memberships along with AD fields. This module resides on the Exchange server itself and from the Exchanger server desktop, it works like a charm.

However, after completing this project, the I.T. helpdesk admin wants his users to be able to run it from either either local powershell console or from the Exchange management Tools Shell.

I installed the Exchange 2010 Exchange management tools but I am having some problems running commands. I can however remote to their Exchange server via ‘New-PSession’ with appropriate ‘connectionURI’ and ‘Authentication’ arguments.

But, I am not sure how to launch my script that resides on this server which then imports my module and does its thing with AD. I am fairly new to the ‘double-hop’ situation and not sure if that applies to this scenario.

So basically I have a controller script and module on exchange server and trying to run my controller script which imports my module and does its import from a CSV file that also resides on the server.

Exchange server

Controller Script -> Mandatory CSVFile parameter. Imports AD Module and imports Custom module which contains custom functions

Custom Module -> Functions in module will process CSV File and write output to the screen on status as well as a prompt to continue if it fails to validate the data.

 

Local PC

Need to be able to invoke the controller script and specify the CSVFile.

Would I just create a session and then use invoke-command and reference the local controller script with the appropriate arguments?

Would it be better to use ‘Enter-pssession’ which would require enabling winrm on exchange. I am not sure of the security implications of that.

Any advice would be helpful.

 

 

 

 

 

 

 

 

Are you sure you are in a double hop scenario?
That usually means crossing untrusted domains, are you are running a script on one remote machine and trying to run a child script to another remote machine from the first hop.

Look at Invoke-Command and using remote variables.

Invoke-Command
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/invoke-command?view=powershell-6

Access Local Variables in a Remote Session with PowerShell
https://mikefrobbins.com/2017/11/09/access-local-variables-in-a-remote-session-with-powershell

You don’t need to install any Exchange stuff, if you are using Implicit PSRemoting, since that means all commands are running on the Exchange server, though you are running a script on a local machine.

Connect to Exchange servers using remote PowerShell
https://docs.microsoft.com/en-us/powershell/exchange/exchange-server/connect-to-exchange-servers-using-remote-powershell?view=exchange-ps

Single Seat Administration of Exchange 2010 using PowerShell Implicit Remoting
https://blogs.technet.microsoft.com/ptsblog/2011/09/02/single-seat-administration-of-exchange-2010-using-powershell-implicit-remoting

Now, I do have to say, to do this, the person running the script must ad admin on that Exchange server, and I find it very difficult to believe that your security / risk management folks will buy off on that.

You can also look to ‘PowerShell Constrained endpoint configuration’
https://blogs.technet.microsoft.com/heyscriptingguy/2014/04/02/build-constrained-powershell-endpoint-using-configuration-file/

to limit users doing this sort of thing and leveraging ‘PowerShell Just Enough Admin’
https://docs.microsoft.com/en-us/powershell/jea/overview configuration.

I made this a lot harder than what it needed to be.

I can make the code available via a share and since the code is running on the same domain, I just need to import AD and Exchange modules into the script and then run the AD and Exchange cmdlets where needed.