Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emails from "external" M365 addresses cause the script to fail #487

Open
BrettMoff opened this issue Nov 26, 2024 · 1 comment
Open

Emails from "external" M365 addresses cause the script to fail #487

BrettMoff opened this issue Nov 26, 2024 · 1 comment
Assignees

Comments

@BrettMoff
Copy link

BrettMoff commented Nov 26, 2024

Describe the bug
When an email comes into the monitored inbox from a user that has an "External" email address within the M365 environment ([email protected]) the script reports that it could not be matched to a user in SCSM and terminates, instead of continuing on. This seems to also happen when users arrive to the inbox with the x500 internal email address rather than the standard smtp address.

This is when the settings are set to NOT create unknown users.

EVENT LOG ERRORS:
INFORMATION - UPDATING-WORKITEM - 0
Updating SR824631
From: /O=COMPANY X CORPORATION LIMITED/OU=EXTERNAL (FYDICOHF16SPDLT)/CN=RECIPIENTS/CN=5F4375ADBC1030479A5BF48BA4D5009C
Title: RE: [SR822581] - USER > Last Name change - Essense Clements to KENNEDY

WARNING - Get-SCSMUserByEmailAddress - 1
Address: /O=COMPANY X CORPORATION LIMITED/OU=EXTERNAL (FYDICOHF16SPDLT)/CN=RECIPIENTS/CN=5F4375ADBC1030479A5BF48BA4D5009C could not be matched to a user in SCSM

Help us reproduce the bug
Version of the connector you are using: v4.1.1
Features/variables you have enabled (i.e. $enableAzureCognitiveServicesForNewWI):

  • Attach email to work item
  • Vote on behalf of AD Groups
  • Update Work Items missing [Work Item] in email subject.....
  • Change Incident status based on Who Replied. (Active, Pending customer, Active)
  • Enforce maximum attachment size.
  • Multiple mailboxes.
  • No other settings set.

Within your test environment, set the email from a user to the out of box OnMicrosoft address and try. Should fail.

Expected behaviour
Like with emails that come in from users that are not in the CMDB, the external email addresses should be ignored, and the process continue on without an Affected User.

Location and Environment
Where are you running this from? Task Scheduler? SMA? Workflow server?: Workflow Server
What SCSM version are you running? (i.e. 2012R2, 2016, 2016 UR3, 1801, etc.): SCSM 2019

Additional context
The email address of the person that is sending the offending email has just had their ENTRA ID name changed and the default email address was not set to the default domain, but rather was left as the onmicrosoft.com address associated with the customer making the email address not appear in the format of [email protected] but rather "/O=COMPANY X CORPORATION LIMITED/OU=EXTERNAL (FYDICOHF16SPDLT)/CN=RECIPIENTS/CN=5F4375ADBC1030479A5BF48BA4D5009C"

The Email headers shows the incoming email address as From: "LASTNAME, Firstname" [email protected]

(See attachments for email headers)

Email Headers.txt

@AdhocAdam AdhocAdam changed the title Emails from "external" M365 addresses cause the script to fail. Emails from "external" M365 addresses cause the script to fail Dec 2, 2024
@AdhocAdam AdhocAdam self-assigned this Dec 2, 2024
@AdhocAdam
Copy link
Owner

I cannot reproduce this behavior. I've used the following:

  • v5.0.4.5 (changes were introduced in v5.x for how certain users are retrieved, read release notes for more info)
  • PowerShell's Send-MailMessage
  • Creating different From addresses that contain .onmicrosoft.com
  • Having "create users in CMDB" enabled or disabled

Work Items are always created in the above scenarios.

If the from address is anything but an actual email address, you would need to investigate Exchange as to why this is happening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants