Issues with iControl.dll on network?

If an exception occurs during the initialize call in the iControl.Interfaces class, any internally caught exception is stored in the m_lastException private member that is accessible with the LastException() accessor.

boolean success = _interfaces.initialize(bigip, user, pass);

if ( ! success ) {
   Exception ex = _interfaces.LastException();
   Console.WriteLine(ex.Message.ToString());
}

The only thing I can think of is that the user context that the cmdlet is running under in your situation doesn't have the required ACLs to access the network.

I am curious though about what you mean by "imported from the network". Does that mean you are using a tool to pull the cmdlet's from a network share or that you are trying to run them from a server based context of some sort?

-Joe

Hi Joe,

 

 

Thanks for the quick response. It'd indeed be great if I could get a handle on the last exception. However, I cannot find interfaces.LastException on the iControl.dll that I am using. It is versioned 9.4.2.0 -- is that too old a version perhaps?

 

 

What I mean by imported from the network is that my Cmdlet DLL and iControl.dll are both living on a network share when I call import-module on my Cmdlet dll, which in turn calls iControl.dll.

 

 

Thanks,

 

Omer

 

Joe, this was quite helpful. I downloaded v10 and it does indeed have LastException property.

 

 

A follow up question, if I get this exception, what does that mean?

 

 

Unhandled Exception: System.Net.WebException: The remote server returned an error: (403) Forbidden.

 

 

The issue is that this request is succeeding from one machine but failing on another. This time around, I wrote a small App and executed that from within local machine directly to help debug the issue.

 

 

Thanks!

Ok, this is bizarre as a 403 error indicates the calling application is attempting to access a resource on the server that isn't allowed (ie, trying to browse a directory or hit a resource that doesn't have access on it). I have no clue why running the assembly from one location would effect the URL it's trying to access. Internally the assembly is building a URL like this

 

 

https:///iControl/iControlPortal.cgi

 

 

with the only variable being the bigip_address value.

 

 

You might want to attempt to look in the apache error_log on the LTM to see if you can figure out what's causing the 403 error to be thrown. That's probably the only debugging step you can do here as the .net client doesn't have a useful trace facility.

 

 

The iControl assembly does use an optional proxy server if you passed info in for it in one of the secondary initialize methods and that could theoretically be the one throwing the error, but that's all guessing on my part.

 

 

I'll play around with this a bit and see if I can reproduce it on my end. If so, I'll let you know. Please let me know if you figure things out on your side and I can try to document this for others that might have the same problem.

 

 

-Joe

 

I'll let you know once I figure it out -- thanks for this information and help! I'll try to debug on the server side too and see if the connection is even attempted on the server or not.

Turned out to be a pretty easy issue -- IE proxy was set up to automatically detect settings, removing that resolved this issue -- perhaps something related to how the local server is set up. Now the network drive issue has resurfaced, but with the exception log available now, it is much easier to see what's happening. When the DLL is loaded from the network, iControl is apparently unable to bind to System.dll and since initialize probably catches all exceptions, it was only returning false which was making it harder to root cause the issue.

 

 

The exception in LastException is:

 

System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

 

 

Thanks!

I did some searching on this error and it seems it has to do with the trust level the application is running under. I've got some solutions for ASP or native apps with a main routine, but PowerShell isn't using the same model so I'm not quite sure how to tackle this one. I'll keep digging.

 

 

-Joe

 

This one might help... http://social.technet.microsoft.com...eeb7fd4019 -Joe

And another...

http://pscx.codeplex.com/discussions/215223

It looks like anything pre-.NET4, all network shares are untrusted and you must explicitly grant trust to the share with the caspol.exe tool.

Set-Alias CasPol "$([Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory())CasPol.exe"
CasPol -polchgprompt off -machine -addgroup 1.2 -url file://\\YourServer\Modules\* FullTrust

Hopefully this one will do it for you!

At least we now know what the problem is. This is going to be a good tech tip. Thanks for the feedback and help with the solution (hopefully this solves it).

-Joe

Hi Joe,

Yes, indeed that solved the problem! Thanks.

Another solution that also worked for me is using [System.Reflection.Assembly]::LoadFrom to get the iControl.dll from network share providing the evidence of the current assembly. For instance:

$dllFullPath = '\\SomeServer\Share\iControl.dll'
$evidence = [System.Reflection.Assembly]::GetExecutingAssembly().Evidence
[System.Reflection.Assembly]::LoadFrom($dllFullPath,$evidence)

In the end, I prefer this approach because I do not have to mess around with trust level on the machine with ramifications that I may not know about.

Thanks,

Omer