none
EWS Version 2.0 Exception: There is no Runspace available to run scripts in this thread. RRS feed

  • Question

  • I've seen many threads on here that point to a fix for this issues like:

    DotNetMethodException error on $mail.SendAndSaveCopy() (link below:  I'm too new and can't be trusted with a real link yet.)

    (http://social.technet.microsoft.com/Forums/en-US/ad493b72-6465-450b-bd49-8f15675d7f53/dotnetmethodexception-error-on-mailsendandsavecopy?forum=exchangesvrdevelopment)

    They all seem to address the issue for version 1.2, but we're on version 2.0.

    What changed?

    Here is the text from the $error[0] | fl -force dump:

    Exception             : System.Management.Automation.MethodInvocationException: Exception calling "FindItems" with "2" argument(s): "The request failed. The
                            underlying connection was closed: An unexpected error occurred on a send." ---> Microsoft.Exchange.WebServices.Data.ServiceRequestExc
                            eption: The request failed. The underlying connection was closed: An unexpected error occurred on a send. ---> System.Net.WebExceptio
                            n: The underlying connection was closed: An unexpected error occurred on a send. ---> System.Management.Automation.PSInvalidOperation
                            Exception: There is no Runspace available to run scripts in this thread. You can provide one in the DefaultRunspace property of the S
                            ystem.Management.Automation.Runspaces.Runspace type. The script block you attempted to invoke was: $true

    Here is the script:

    ## Choose to ignore any SSL Warning issues caused by Self Signed Certificates  
     
    ## Code From http://poshcode.org/624
    ## Create a compilation environment
    $Provider=New-Object Microsoft.CSharp.CSharpCodeProvider
    $Compiler=$Provider.CreateCompiler()
    $Params=New-Object System.CodeDom.Compiler.CompilerParameters
    $Params.GenerateExecutable=$False
    $Params.GenerateInMemory=$True
    $Params.IncludeDebugInformation=$False
    $Params.ReferencedAssemblies.Add("System.DLL") | Out-Null
    
    $TASource=@'
      namespace Local.ToolkitExtensions.Net.CertificatePolicy{
        public class TrustAll : System.Net.ICertificatePolicy {
          public TrustAll() {
          }
          public bool CheckValidationResult(System.Net.ServicePoint sp,
            System.Security.Cryptography.X509Certificates.X509Certificate cert,
            System.Net.WebRequest req, int problem) {
            return true;
          }
        }
      }
    '@
    $TAResults=$Provider.CompileAssemblyFromSource($Params,$TASource)
    $TAAssembly=$TAResults.CompiledAssembly
    
    ## We now create an instance of the TrustAll and attach it to the ServicePointManager
    $TrustAll=$TAAssembly.CreateInstance("Local.ToolkitExtensions.Net.CertificatePolicy.TrustAll")
    [System.Net.ServicePointManager]::CertificatePolicy=$TrustAll
    
    ## end code from http://poshcode.org/624
    
    $ewsPath = "F:\Program Files\Microsoft\Exchange\Web Services\2.0\Microsoft.Exchange.WebServices.dll"
    Add-Type -Path $ewsPath
    
    $ews = new-object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::"Exchange2010_SP3")
    
    $cred = (Get-Credential).GetNetworkCredential()
    $ews.Credentials = New-Object System.Net.NetworkCredential -ArgumentList $cred.UserName, $cred.Password, $cred.Domain
    
    $ews.AutodiscoverUrl( "user@dummydomain.com" )
    
    Write-Debug $ews.url -debug
    
    $results = $ews.FindItems(
        "Inbox",
        ( New-Object Microsoft.Exchange.WebServices.Data.ItemView -ArgumentList 10 )
    )
    $results.Items | ForEach-Object { $_.Subject }
    
    $error[0] | fl -force

    The debug DID yield the proper URL for the EWS services.

    Any ideas?  Do I need to create a Runspace?  How is this done?

    Friday, November 8, 2013 10:44 PM

Answers

  • Hi Danoj,

    another thing you could do in this case, is wrap the thing into a function (Like 'Get-EWSInbox' or something like that) that returns $result. Then launch the PowerShell console, import the script file (Import-Module C:\examplefolder\Get-EWSInbox.ps1). Thereafter you can use the function and directly inspect the result using cmdlets like 'Get-Member' or 'FL *'.

    That 'might' yield some more information (For example, exceptions sometimes have nested Exceptions that clarify the root cause).

    Cheers and good luck,
    Fred


    There's no place like 127.0.0.1

    • Marked as answer by DanoJ Tuesday, November 12, 2013 6:32 PM
    Tuesday, November 12, 2013 7:58 AM

All replies

  • Hi Danoj,

    Don't know whether it's the cause of your trouble, but according to the EWS MA 2.0 documentation, there is no Exchange 2010_SP3 in the ExchangeVersion Enumeration, so that might be a problem:

    # Replace this
    $ews = new-object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::"Exchange2010_SP3")
    
    # With this
    $ews = new-object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP2)

    Requesting an SP2 response should not hurt you in terms of functionality.

    If that's not it, you can narrow down your problem by dumping the error log inbetween each step you take. That way you can isolate it to the individual call that caused it.

    Another last thing that may or may not help is the usual recommendation to check your client side patch level, especially your .NET.

    If neither helps, I'm all out of ideas what might be causing this.

    Cheers and good luck,
    Fred


    There's no place like 127.0.0.1

    Saturday, November 9, 2013 6:20 PM
  • Unfortunately, I have tried the Exchange 2010_SP2 as well--same result.

    The error occurs on the last statement in the script:

    $results.Items | ForEach-Object { $_.Subject }

    Up until that point, it's not invoking any exception.  The Debug line shows the correct AutoDiscovery server address.

    I'm going to look at the client-side things to see if this is the culprit.  Thanks!

    Monday, November 11, 2013 4:41 PM
  • Hi Danoj,

    another thing you could do in this case, is wrap the thing into a function (Like 'Get-EWSInbox' or something like that) that returns $result. Then launch the PowerShell console, import the script file (Import-Module C:\examplefolder\Get-EWSInbox.ps1). Thereafter you can use the function and directly inspect the result using cmdlets like 'Get-Member' or 'FL *'.

    That 'might' yield some more information (For example, exceptions sometimes have nested Exceptions that clarify the root cause).

    Cheers and good luck,
    Fred


    There's no place like 127.0.0.1

    • Marked as answer by DanoJ Tuesday, November 12, 2013 6:32 PM
    Tuesday, November 12, 2013 7:58 AM
  • This was helpful in that there was a BUNCH going on.  I decremented to version 1.2 and all of a sudden things started working.  Thanks for the suggestions.  They helped!
    Tuesday, November 12, 2013 6:34 PM