5

I have created a module for my admin group with some functions that automate some procedures we commonly perform (add administrators to remote machines, C drive cleanup, etc...)

One of the prerequisites for these functions is the generation of a series of 7 credentials, one for each domain we work in.

Is there a way to get a scriptblock to run when you import a module, or is this something I should add to each persons profile?

A commenter mentioned I could just add it to the module.psm1 file, but that didn't work. Here is the code I am trying to run.

$creds = Import-Csv [csvfile]
$key = Get-Content [keyfile]
foreach ($cred in $creds) {
    $user = $cred.User
    $password = $cred.Hash | ConvertTo-SecureString -Key $key
    $i = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $user,$password
    New-Variable -Name ($cred.Domain + "_Cred") -Value $i -Force
    }

Running this manually works fine, but it isn't creating the credentials when run from the Import-Module command.

Acerbity
  • 417
  • 1
  • 11
  • 29

2 Answers2

7

Any code that's not a function will run when you import the module.

briantist
  • 45,546
  • 6
  • 82
  • 127
  • So I can just slap it in the .psm1 file and it'll run? – Acerbity Nov 23 '15 at 20:43
  • Yes. Consider that that is what's happening when you use `Export-ModuleMember` in the module. Try it out with a test module if you need to see behavior or something. – briantist Nov 23 '15 at 20:45
  • See above. It doesn't seem to have worked. Added the code I am trying to execute. – Acerbity Nov 23 '15 at 21:08
  • @Acerbity do you get any kind of error message? In what way is it not working? – briantist Nov 23 '15 at 21:16
  • Well, the code should generate a series of objects. For instance, $USA_Cred, $DEVSUB_Cred When I import the module, it doesn't. No error. – Acerbity Nov 23 '15 at 21:17
  • @Acerbity oh I see what's happening. Those variables are in module scope. They won't be visible outside the module. You could try to export them with `Export-ModuleMember -Variable` ([beware of this though](http://stackoverflow.com/questions/8001496/variables-imported-from-the-module-becomes-null-after-the-same-module-imported)) or you could make them use global scope, like `$Global:creds = whatever`. – briantist Nov 23 '15 at 21:25
  • So, can I just create a global variable using that syntax? Can you think of an easier way to accomplish what I am trying to? I was considering just putting all of my prequisite code in a script, then having everyone run that script in their profile. – Acerbity Nov 23 '15 at 21:27
  • @Acerbity I think so yes, it may still not extend outside of the module though. In that case, you have to export, or use an exported function to return the variable. – briantist Nov 23 '15 at 21:28
  • Copy that. Thanks for your help. – Acerbity Nov 23 '15 at 21:47
  • 1
    A handy tip when working with modules: & and . have what may be undocumented functionality. With either you can give two arguments, the first is a module reference (from get-module or similar) and second is a script. With the module reference parameter the script will run in the context of the module. So for example: `& $myMod {$usa_cred}` will output the value of $use_cred even if it hasn't been exported. This is useful for debugging scripts. Also modules can have embedded modules and `& $myMod {gmo}` will list those sub modules. By nesting & or . you can access sub-modules context. – Χpẘ Nov 23 '15 at 22:03
  • @user2460798 that's fantastic; deserving of its own answer I think (I'd certainly vote it up). – briantist Nov 23 '15 at 22:04
  • @briantist Thanks. I followed your suggestion. – Χpẘ Nov 23 '15 at 22:05
5

A handy tip when working with modules: & and . have what may be undocumented functionality. With either you can give two arguments, the first is a module reference (from get-module or similar) and second is a script. With the module reference parameter the script will run in the context of the module. So for example:

& $myMod {$usa_cred} 

will output the value of $use_cred even if it hasn't been exported. This is useful for debugging scripts. Also modules can have embedded modules and & $myMod {gmo} will list those sub modules. By nesting & or . you can access sub-modules context.

briantist
  • 45,546
  • 6
  • 82
  • 127
Χpẘ
  • 3,403
  • 1
  • 13
  • 22