Advice on using a module/function to remotely connect to domain controller

Hi all PowerShell masters,

I really need some PowerShell advice here. I am practicing toolmaking in PowerShell after reading Don Jones “Learn PowerShell toolmaking in a month of lunches” and I have managed to confuse myself here I think a bit.

In any case :wink: I had this idea that if I make a tool that depends on Exchange and Active Directory commands but the users using my tool does not necessarily have either Exchange Management Tools or RSAT for Windows X installed. Now what do I do?

So I thought I would create a function/tool to connect to the Exchange server and also another function/tool to connect to a AD domain controller.

so here is really my first question. Is this a stupid idea?
My 2nd question, how do I work around the scope problem? the second my functions stops running the commands etc from Exchange and AD are now gone.

Need some advice, hope some kind soul can help me understand this better :slight_smile:

“so here is really my first question. Is this a stupid idea?
My 2nd question, how do I work around the scope problem? the second my functions stops running the commands etc from Exchange and AD are now gone.”

Scope probably makes this something of a problem. The way PowerShell would probably work best is if you made a Connect-ExchangeADSession command, or something. It would return a session object. So you’d…

$session = Connect-ExchangeADSession

And the remaining commands would accept that $session object on one parameter. Really, just like New-PSSession and Invoke-Command would work.

Hi Don,

Thank you for replying :slight_smile:

So is what I am trying to do perhaps just a bit odd? Perhaps I am better off connecting to AD and Exchange from somewhere else? A few places I can think of

  1. Add the functions to people’s powershell profile?
  2. dot source it into the controller script?
  3. inside the controller script?

If you have a controller script that’s depending on the functionality, then I’d just perform the connection within that script. We’re literally talking two or three commands to make this happen; it’s not really something you specifically need to modularize. You’re going to end up running New-PSSession a couple of times, and Import-PSSession a couple of times.

Hi Don,

Yeah i think i will choose between either in the script or . source it. at least with .source into my script i can use it in there to my hearts contends :slight_smile:

If i . source it seems to work really well and then put that script on a UNC share.

function Connect-ARWActiveDirectory {

[CmdLetBinding()]
Param(
    [Parameter(
        Mandatory=$false)]

    [string]$ConnectTo = "UKVHGTDC001P.local"
)

$session = New-PSSession -ComputerName $ConnectTo -Credential (Get-Credential)
Invoke-Command $session -Scriptblock { Import-Module ActiveDirectory }
Import-PSSession $Session -CommandName *-AD*

}

If you’re running it from other computers on the domain that have a network connection to the domain controller, then you could utilize the ADSI adapter in Powershell to negate needing the AD module and it’s cmdlet’s. I have it running for a logon script for my userbase, since we aren’t going to roll-out RSAT to the org.

Might end up being more work, but that really depends on how detailed and/or predictable your AD OU structure is.

Unfortunately, not too sure about the Exchange side of the equation since that’s not my normal territory.