Initial Setup Trouble

[ghost]

I'm trying to setup the newest release of the connector in my dev environment. I was using an older version of the connector with impersonation. When I run the connector manually via the ISE I get this error:

Method invocation failed because [Microsoft.Exchange.WebServices.Data.ImpersonatedUserId] does not contain a method named 'new'.
At E:\PowerShell\Libraries\smletsexchangeconnector-3.3.1.21\smletsExchangeConnector.ps1:4163 char:9
+         $exchangeService.ImpersonatedUserId = [Microsoft.Exchange.WebServices.Da ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : MethodNotFound

Also, this is the error in Event Viewer:

System.Management.Automation.MethodInvocationException: Exception calling "Bind" with "2" argument(s): "The request failed. The remote server returned an error: (401) Unauthorized." ---> Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The remote server returned an error: (401) Unauthorized. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(HttpWebRequest request)
   --- End of inner exception stack trace ---
   at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(HttpWebRequest request)
   at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
   at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder(FolderId folderId, PropertySet propertySet)
   at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet)
   at CallSite.Target(Closure , CallSite , Type , Object , Object )
   --- End of inner exception stack trace ---
   at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
   at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

If I turn off impersonation the script runs in the ISE without error but I still get the error above in event viewer.

[AdhocAdam]

I was never able to reproduce this, but this IDENTICAL error has come up before on this discussion.

Per the author:

Update I have continued working though out the day and I was able to narrow down the first issue (Impersonation) to either a bad password on a run-as account or the use of impersonation. I created a new run-as account for the new mailbox and have been able to successful get new connector to work.

Unfortunately I don't have much in the way of troubleshooting as EWS v1.2 and v2.2 both offer the "new" method per the ISE screenshot in that thread. So the only assumption I can make here is it's either the password of the account OR the Run As Account you are using doesn't have Exchange Impersonation rights. But I am certainly open to working through this together and discovering a third possibility!

[ghost]

When I use the code on that other thread to look for the new method, this is what I get.

[AdhocAdam]

[ghost]

Should I see an option for Exchange at this point:

[AdhocAdam]

So the testing script works but the connector + run as accounts dont. Hrmmmm...

Is the Run As Account's username formatted as domain.tld\username ? and/or how were you starting PowerShell with the tester script that it worked?

[ghost]

In the run as account the username is just 'username' the domain is defined lower down:

In the test script it is the same, just 'username' with the domain defined separately:

The 1.4.4 script works fine using impersonation and the account defined in the script:

[AdhocAdam]

I'm still trying to figure out a way to reproduce this in v3 but haven't been successful so far. I should add that if I choose Impersonation, the error I get cites an inability to Impersonate rather than Authenticate.

Impersonation Error:
"The account does not have permission to impersonate the requested user." ---> Microsoft.Exchange.WebServices.Data.ServiceResponseException: The account does not have permission to impersonate the requested user.

[AdhocAdam]

The only way I've managed to reproduce this is:

• The workflow is turned off
• I'm running the script manually (the account does not matter)
• I've manually edited $exchangeAuthenticationType to equal "impersonation"

Essentially, the ELSE -> SWITCH in the primary Exchange Authentication logic is engaged and is expecting credentials but since they aren't defined anywhere they all evaluate to null.

smletsexchangeconnector/smletsExchangeConnector.ps1

Lines 4166 to 4205 in 4740de6

	else
	{
	#the workflow either doesn't exist or it's not enabled, determine how to connect to Exchange
	if ($UseExchangeOnline)
	{
	#validate the Run As Account format to ensure it is an email address
	if (!(($username + "@" + $password) -match "^([0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*@([0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,9})$"))
	{
	New-SMEXCOEvent -Source "General" -EventId 4 -LogMessage "The address/SCSM Run As Account used to sign into 365 is not a valid email address and is currently entered as $($username + "@" + $password). This will prevent a successful connection. To fix this, go to the Run As account in SCSM and for the username enter it as an email address like [email protected]" -Severity "Error"
	}
	#request an access token from Azure
	$ReqTokenBody = @{
	Grant_Type = "Password"
	client_Id = $AzureClientID
	Username = $username
	Password = $password
	Scope = "https://outlook.office.com/EWS.AccessAsUser.All"
	}
	$response = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$AzureTenantID/oauth2/v2.0/token" -Method "POST" -Body $ReqTokenBody
	#instead of a username/password, use the OAuth access_token as the means to authenticate to Exchange
	$exchangeService.Url = [System.Uri]$ExchangeEndpoint
	$exchangeService.Credentials = [Microsoft.Exchange.WebServices.Data.OAuthCredentials]($response.Access_Token)
	}
	else
	{
	#local exchange server
	switch ($exchangeAuthenticationType)
	{
	"impersonation" {$exchangeService.Credentials = New-Object Net.NetworkCredential($username, $password, $domain)}
	"windows" {$exchangeService.UseDefaultCredentials = $true}
	}
	if ($UseAutoDiscover -eq $true) {
	$exchangeService.AutodiscoverUrl($workflowEmailAddress)
	}
	else {
	$exchangeService.Url = [System.Uri]$ExchangeEndpoint
	}
	}
	}

The attempt to authenticate is made with null credentials, an error is thrown and then written to the log.

smletsexchangeconnector/smletsExchangeConnector.ps1

Lines 4219 to 4227 in 4740de6

	catch
	{
	#couldn't retrieve the Inbox, log an error and exit the connector
	if ($loggingLevel -ge 3)
	{
	New-SMEXCOEvent -Source "General" -EventId 1 -LogMessage $_.Exception -Severity "Error"
	}
	break
	}

But the moment the Workflow is turned on (and thus SCSM is running this automatically) it's resolved.

[ghost]

@AdhocAdam - Thank you for helping me with the custom script path and enabling the workflow. That cleared this up for me.