Where is "UseLocalScope" set by PSRemote endpoint

windows-liveuser14 · July 23, 2013, 5:20am

I have created a custom remote session.Â When I try to enter the session from another computer I getÂ the error “Enter-PSSession : UseLocalScope cannot be false when language mode is RestrictedLanguage or NoLanguage”.

Testing seems to isolateÂ the problemÂ to the SessionType parameter.Â If it exists in the session configuration file created by:
New-PSSessionConfigurationFile -Path $sessionConfigFile -Author "Someone"
-CompanyName “Somewhere” -Copyright 2013 -Description $endpointDescription
-SessionType RestrictedRemoteServer

and session configuration is registered including a startup script like:
Register-PSSessionConfiguration -Name $PSSessionName -Path $sessionConfigFile
-MaximumReceivedDataSizePerCommandMB 50 -MaximumReceivedObjectSizeMB 10
-AccessMode Remote -RunAsCredential (Get-Credential -Message "Enter credentials for user that the session endpoint will run as." -UserName $runAsUser)
-SecurityDescriptorSDDL $sddl -StartupScript $scriptToRun
-Force

then I get the error when I try to connect.

If I do not include the path to the session configuration file that has the SessionType in it, the session can be started as expected (and the StartupScript runs).

So, an option I thought would be to move the SessionType RestrictedRemoteServer setting to the Register-PSSessionConfiguration command. However, I get an error when running the Register-PSSessionConfiguration command that looks like a bug (documentation or otherwise). I get: Register-PSSessionConfiguration : Cannot bind parameter ‘SessionType’. Cannot convert value “RestrictedRemoteServer” to type “System.Management.Automation.Runspaces.PSSessionType”. Error: “Unable to match the identifier name RestrictedRemoteServer to a valid enumerator name. Specify one of the following enumerator names and try again: DefaultRemoteShell, Workflow”.Â However, help for Register-PSSessionConfiguration gives the same options for SessionType as New-PSSessionConfigurationFile.

Are SessionType (RestrictedRemoteServer value which causes LanguageMode to default to NoLanguage) and StartupScript incompatible? (Help says they are compatible.)

What else could cause the UseLocalScope message?
Steve

donj · August 6, 2013, 3:14am

The general agreement from the folks I’ve talked to is that once you’ve gone with that language mode, you shouldn’t plan to have a script loaded. The help doesn’t seem to accurately reflect what the product is doing - although the product, in my testing, is a bit inconsistent about it. I need to try this all on v4 to see if it’s different, but I can’t get v3 to CONSISTENTLY fail this way, so… dunno.

windows-liveuser14 · August 6, 2013, 10:54pm

Thanks Don.

Let me step back to my requirements.
I need to have a RestrictedRemoteServer type of environment where only the functions I define are available. Those functions are currently “generated code” based on a template as part of the startup script. That is what is driving the request to use a startup script. I do not need to proxy anything (other than the required minimum cmdlets) for the user. I would like to allow the user to pipe data (like .CSV files) to the functions (that is how I wrote them and I understand there are path issues). I would like to make the session available through both New-Session and Invoke-Command. I have some functions, cmdlets, and scripts that need to have the visibility correct for parts of this process.

Maybe this is my next step.
Do you have a good pointer that would confirm my understanding of the difference between visibility for functions, etc. in different contexts and where to set it? The way I see it I have the following classes of functions, cmdlets, and scripts:

Those that do not need to run at all from anything related to the session. (RestrictedRemoteServer should take care of this.)
Those that need to be accessible to folks running in the session. (-ModulesToImport, -AssembliesToLoad, -VisibleAliases, -VisibleCmdlets (including the [Management.Automation.CommandMetaData]::GetRestrictedCommands(“RemoteServer”).GetEnumerator() set), -VisibleFunctions, -VisibleProviders should define these.)
Those that need to run when called by 2. above. (-AliasDefinitions, -FunctionDefinitions, -VariableDefinitions, -TypesToProcess, -FormatsToProcess should define these. I do have functions that are currently defined in the startup script that are helper functions to the generated code (made available as class 2). These may need to be added to the generated modules that contain the generated functions and i would need to research how to do this.)
Those that need to run to set up the session only. (-StartupScript or -ScriptsToProcess should control this. Though functions defined here do not seem to stay around to be used by 3 unless I add them to class 2.)

Steve

donj · August 7, 2013, 12:46am

That’s kind of a lot to digest - but let’s take the problem more methodically.

First, what you’re doing should, according to the docs, work. It isn’t. So we have a bug, either in the docs or in the product. That means you might not be able to achieve what you want. Be open to that unfortunate possibility.

The problem seems to be combining a startup script with NoLanguage. Have you tried your setup with another language mode? Let’s try changing that one item and see if it changes how this works. If we can narrow down a specific combination that doesn’t work, and we know which bit makes it not work, I can dig a little deeper on it.

windows-liveuser14 · August 7, 2013, 3:12am

I did test without -SessionType set (letting it default). Everything works fine (other than access to too much stuff :>).
I did not try specifically with New-PSSessionConfigurationFile -LanguageMode ConstrainedLanguage. I can test that if that would answer a question.
I did not try pre-generating the code (modules and functions) and managing everything through -ModulesToImport and -VisibleFunctions. That is possible.
I also have some demo code from Aleksandar that shows how to setup the restricted environment by adding code to the script. That is also possible.
There are draw backs to both of those approaches which is why I preferred to let PowerShell do what it says it can do. :>)
Steve

donj · August 7, 2013, 3:18am

We’d all prefer that it work as described… but we don’t know that it isn’t doing so, exactly. We believe it is, but we need to rule out some variations.

The way we determine if it’s you or if it’s PowerShell is to test those variations. If it’s PowerShell, then you’ll know to stop banging your head against the wall and go down another path, like pre-generating the code. So yes, testing with ConstrainedLanguage would be helpful, as would RestrictedLanguage. What we’re trying to figure out is if NoLanguage and a startup script are in fact mutually exclusive, documentation aside (and RestrictedLanguage may also be a problem). If we believe that is the case and can reproduce it in documentable form, then we file a bug and try to get it fixed.

(I’ll ask in hopes that you’ve done this, but if you haven’t you should) - have you checked Connect already to see if this is something someone else has reported as a bug?

windows-liveuser14 · August 12, 2013, 3:35am

On connect.microsoft.com as of last week:
The only item with RestrictedLanguage is https://connect.microsoft.com/PowerShell/feedback/details/770124/constrainedlanguage-mode-is-not-documented-in-the-new-pssessionconfigurationfile-help-topic
New-PSSessionConfigurationFile has 6 entries–all by Aleksandar.
Register-PSSessionConfiguration has 6 entries (3 active)

None address what I am seeing.

This is an outline of some of the tests and what I get. See the full error in the detail test results below.
Using New-PSSessionConfigurationFile with â€“SessionType RestrictedRemoteServer:
No language mode set–“UseLocalScope…” error
-LanguageMode NoLanguage–“UseLocalScope…” error
-LanguageMode RestrictedLanguage–“UseLocalScope…” error
-LanguageMode ConstrainedLanguage–“…not recognized as the name of a cmdlet…” error
-LanguageMode FullLanguage–“…not recognized as the name of a cmdlet…” error

Using New-PSSessionConfigurationFile WITHOUT â€“SessionType RestrictedRemoteServer:
-LanguageMode NoLanguage–“UseLocalScope…” error
-LanguageMode RestrictedLanguage–“UseLocalScope…” error
-LanguageMode ConstrainedLanguage–“…running scripts is disabled on this system…” error (Adding ‘-ExecutionPolicy RemoteSigned’ as a parameter to New-PSSessionConfigurationFile is required even if the local machine execution policy is RemoteSigned)
-LanguageMode FullLanguage–“…running scripts is disabled on this system…” error (Adding ‘-ExecutionPolicy RemoteSigned’ as a parameter to New-PSSessionConfigurationFile is required even if the local machine execution policy is RemoteSigned)

-SessionType RestrictedRemoteServer moved to Register-PSSessionConfiguration:
Using minimal New-PSSessionConfigurationFile parameters–“Cannot bind parameter ‘SessionType’…” error
Without New-PSSessionConfigurationFile at all–“Cannot bind parameter ‘SessionType’…” error

ON REMOTE MACHINE…
PS C:\Scripts> Get-ExecutionPolicy -List | ft -AutoSize
Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Unrestricted (This is for the tests only and is normally RemoteSigned or stricter)

PS C:\Scripts> gci C:\Scripts\Set-*.ps1
Directory: C:\Scripts
Mode LastWriteTime Length Name

-a— 8/2/2013 11:03 AM 50045 Set-ReferenceInfoTemplate-Update-IT.ps1

DETAIL TEST RESULTS FOLLOW

ON REMOTE MACHINE…
New-PSSessionConfigurationFile -Path $sessionConfigFile -Author "someone"
-CompanyName “somewhere” -Copyright 2013 -Description $endpointDescription
-SessionType RestrictedRemoteServer `