Exception calling "Put" with "0" argument(s): "" on Win32_TerminalServiceSetting

Question

I have created a Powershell function to enable or disable session logons remotely on a server. It is basically the Powershell equivalent of "change logon /enable".

It works on most machines, but for some reason I don't understand, for some it returns the following error :

Exception             : System.Management.Automation.MethodInvocationException: Exception calling "Put" with "0" argument(s): "" ---> System.IO.FileNotFoundException
                           at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
                           at System.Management.ManagementObject.Put(PutOptions options)
                           at System.Management.ManagementObject.Put()
                           at Put(Object , Object[] )
                           at System.Management.Automation.MethodInformation.Invoke(Object target, Object[] arguments)
                           at System.Management.Automation.DotNetAdapter.AuxiliaryMethodInvoke(Object target, Object[] arguments, MethodInformation methodInformation, Object[] 
                        originalArguments)
                           --- End of inner exception stack trace ---
                           at System.Management.Automation.DotNetAdapter.AuxiliaryMethodInvoke(Object target, Object[] arguments, MethodInformation methodInformation, Object[] 
                        originalArguments)
                           at System.Management.Automation.DotNetAdapter.MethodInvokeDotNet(String methodName, Object target, MethodInformation[] methodInformation, 
                        PSMethodInvocationConstraints invocationConstraints, Object[] arguments)
                           at System.Management.Automation.DotNetAdapter.MethodInvoke(PSMethod method, PSMethodInvocationConstraints invocationConstraints, Object[] arguments)
                           at System.Management.Automation.Adapter.BaseMethodInvoke(PSMethod method, PSMethodInvocationConstraints invocationConstraints, Object[] arguments)
                           at System.Management.Automation.PSMethod.Invoke(PSMethodInvocationConstraints invocationConstraints, Object[] arguments)
                           at System.Management.Automation.PSMethod.Invoke(Object[] arguments)
                           at System.Management.Automation.Language.PSInvokeMemberBinder.InvokeAdaptedMember(Object obj, String methodName, Object[] args)
                           at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
                           at System.Management.Automation.Interpreter.DynamicInstruction`2.Run(InterpretedFrame frame)
                           at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
TargetObject          : 
CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
FullyQualifiedErrorId : DotNetMethodException
ErrorDetails          : 
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}

The error stack trace doesn't help me.

I'm running the same code with the same local admin user on all machines.

Here is the actual code snippet :

$TSConnector = Get-WmiObject -Class Win32_TerminalServiceSetting -Namespace "root/cimv2/terminalservices" -Authentication PacketPrivacy
$TSConnector.Logons = 0
$TSConnector.Put()

Any idea ?

Answer 1

So it turns out that, on Windows Server 2008R2, if the Remote Desktop Session Host role is not installed, the server is configured for "Remote Desktop for Administration".

As explained on this technet article :

The following are limitations of Remote Desktop for Administration:

1. The default connection (RDP-Tcp) only allows a maximum of two simultaneous remote connections.

2. Licensing settings cannot be configured.

3. RD Connection Broker settings cannot be configured.

4. User logon mode cannot be configured.

So in the end I had to catch that exception and revert back to using change logon /disable in that particular case.

Kudos to @GrigorySergeev for pointing me in the right direction!