Make module availability network-discoverable
Votes from Connect: 10
Original Date Submitted: 4/21/2012 9:43:26 PM
Site Name: PowerShell
Feedback ID: 738071
Frequency: Always Happens
Regression: No, this is new to the most recent version
I suggest a Register-Module cmdlet, which can be used to register a given module, on a given machine, optionally within a given AD site, as being publicly available. Registration would be in DNS, likely as SRV records (much like an AD domain controller).
"Get-Module -List" would then list local modules as well as modules advertised in DNS *for the user's current site* (or modules advertised with no site preference). Module auto discovery would not be expected to work with these DNS-registered modules. However, Import-Module, when given just a module name (vs a path), would implicitly remote DNS-registered modules if the specified module was not installed locally.
Because this would probably expose the remoting "second hop" problem more frequently, remoting error messages should ideally be changed to identify situations where the second hop has not worked, and to suggest reading up on CredSSP.
The intent is to let senior administrators designate machines from which specified modules should be implicitly remoted - rather than having to locally install modules, and rather than letting other administrators decide for themselves where to remote modules from.
The SRV records used to advertise a module could also, potentially, advertise a specific port for Remoting, specify whether SSL was required, specify an endpoint (session configuration) name, etc - everything Import-Module would need to implicitly spin up a PSSession and import the module.
Product Studio item created by Connect Synchronizer due to creation of feedback ID 738071 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=738071).
Internal BugId: 3540