I'd love to hear how others approach a common task for PowerShell admins.
I'm building a user provisioning tool, New-CADUser, which accepts input from the HR database, CSV file etc, does a few validation checks and then runs a bunch of sub-functions: New-ADUser, New-CADHomeFolder, Enable-CADMailbox and Set-CADMsolLicense.
Since the sub-functions require MS Exchange, MSOL and Office 365, would the best approach be to add "#requires" for these PS Modules/SnapIns in the parent function, in the child functions, or to use Invoke-Command?
If cost is not an issue, why not use FIM (old version) or MIM (Microsoft Identity Manager)? It does exactly what you just described or more. You can import the details from HR database or CSV. You will need to set up some rules.
@Don: Maybe I'm misunderstanding what Requires does.
E.g. would the server running these functions need the Exchange Server management tools installed locally (in which case "#Requires -pssnapin ..."), or would it be more appropriate to set up a PSSession with a nearby Exchange server, and use Invoke-Command instead? I'm mostly interested in what is PowerShell best practice.
@Naw – this is more of a professional development exercise. We already have working scripts that achieve everything above, but not in a modular, reusable way.
#requires is a declarative statement indicating the modules you expect to be locally available. If they're not, the script won't run and will fail with an error. Using this is certainly a good practice.
But that's completely aside from, 'the module might not be local and rather than installing it I'd like to consume it from a remote computer.' That's also completely viable.
Neither one is better than the other, though. They're entirely different approaches, like cars and bikes.