Otter Remote Execution

darkbasics_6739

I've just starting playing around with Otter to 'sell' the configuration drift feature towards our server infrastructure.

However when trying to execute the sample Powershell (verify-hotfix-installed) on a remote server I'm having the errors seen below.

I've already validated if MWI is enabled and if anti-virus is causing issues.
Target System is a Windows Server 2019.

Collecting current configuration from server...
Unhandled exception: System.IO.FileNotFoundException: Could not load file or assembly 'Scripting' or one of its dependencies. The system cannot find the file specified.
File name: 'Scripting'
   at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName, ObjectHandleOnStack type)
   at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName)
   at System.Type.GetType(String typeName, Boolean throwOnError)
   at Inedo.Agents.Commands.JobStartCommand.Deserialize(Stream stream)
   at Inedo.Agents.AgentCommand.DeserializeInternal(Stream stream)
   at Inedo.Agents.Hosting.HostedAgentProcess.<MessageLoop>d__24.MoveNext()
=== Pre-bind state information ===
LOG: DisplayName = Scripting
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: Scripting | Domain ID: 1
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/TEMP/HostedAgent/bin/sha256_e99df154cb350d4dbba8b67c4d71c72e64b62587f2999474cb042e74ddf85b0f/
LOG: Initial PrivatePath = NULL
Calling assembly : Inedo.Agents.Client, Version=1000.0.0.0, Culture=neutral, PublicKeyToken=9de986a2f8db80fc.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\TEMP\HostedAgent\bin\sha256_e99df154cb350d4dbba8b67c4d71c72e64b62587f2999474cb042e74ddf85b0f\Otter.Agent.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/TEMP/HostedAgent/bin/sha256_e99df154cb350d4dbba8b67c4d71c72e64b62587f2999474cb042e74ddf85b0f/Scripting.DLL.
LOG: Attempting download of new URL file:///C:/TEMP/HostedAgent/bin/sha256_e99df154cb350d4dbba8b67c4d71c72e64b62587f2999474cb042e74ddf85b0f/Scripting/Scripting.DLL.
LOG: Attempting download of new URL file:///C:/TEMP/HostedAgent/bin/sha256_e99df154cb350d4dbba8b67c4d71c72e64b62587f2999474cb042e74ddf85b0f/Scripting.EXE.
LOG: Attempting download of new URL file:///C:/TEMP/HostedAgent/bin/sha256_e99df154cb350d4dbba8b67c4d71c72e64b62587f2999474cb042e74ddf85b0f/Scripting/Scripting.EXE.

Dan_Woolf

Hi @darkbasics_6739,

What version of Otter are you running? Also, do you have it installed on Linux (Docker) or Windows? We had this issue with an older version of Otter when running on Linux (Docker), but it was fixed in Otter 3.0.14.

Thanks,
Dan

darkbasics_6739

Hi Dan,

Running Otter on a Windows host. Otter version is the one pushed via the web installer - 3.0.16 (Build 3).

Kr,
D#B

Dan_Woolf

Hi @darkbasics_6739,

Thanks for verifying that for us. Are you using the InedoAgent on the remote server or the PowerShell Agent? If you are running the InedoAgent, what version do you have installed? Also, could you try running it again? I have seen in some instances the download of the Scripting extension on the remote machine takes a bit longer and causes a similar error. I have found that typically this is resolved by the second Server check.

One last check, can you please verify what version of the Scripting extension you have installed? You can find that by navigating to Administration -> Extensions (Plug-ins)

Thanks,
Dan

darkbasics_6739

Hi Dan,

No I'm not using the InedoAgent but the PowerShell agent and I"ve ran it multiple times already (~12x). Scripting Extension is version 1.10.6.

Seems that 'Scripting.upack' is not included in the HostedAgent\extensions folder which is causing it to break. Manually putting the upack in the HostedAgent\extensions folder fixes the issue. Once this has been manually copied to target-server /extensions/ I'm getting an error as seen below.

Cleaning up temporary files on PowerShell...
Unable to delete temporary directory "C:\TEMP\Temp\_E2134" on PowerShell: At line:11 char:2
+ }
+  ~
The Try statement is missing its Catch or Finally block.

At line:12 char:1
+ } Finally {
+ ~
Unexpected token '}' in expression or statement.

So i believe there are currently two issues:

Scripting.upack is not copied/included in the Powershell Agent
Temp-folder is not cleaned up properly.

Kr,
D#B

atripp

Hi @darkbasics_6739 ,

That's really weird, but I can see how that error might happen now. It's been addressed as OT-446, and will be fixed in the next maintenance release.

We're still not sure why the SCripting extension isn't coming over. We're thinking, it might be due to a time out of sorts, since the file is now pretty large. Obviously that should throw a different error.... is there a lot of bandwidth between servers?

Cheers,
Alana

darkbasics_6739

@atripp Servers have a 10Gbps back-end infrastructure.

atripp

@darkbasics_6739 thanks, of course that's not the problem then

We're still investigating this, and it's quite odd why the extension isn't getting transfered. The workaround you're doing is fine to at least evaluate/test, but we'll most certainly get this fixed ASAP

Dan_Woolf

Hi @darkbasics_6739,

We found the issue and the fix will be released on Friday in Otter 3.0.17. This looks to be a regression from our .NET 5 conversion for our Docker image and tends to only affect specific operations. It just so happens that our demo PowerShell script and our Verify Hotfix example uses the features that this affects.

Thanks for catching this for us!

Thanks,
Dan

darkbasics_6739

@Dan_Woolf Cool, glad I could help!