Fileattachment "message.eml" has always the same name and if you open this in console it crashes

[JanSchulz]

In the function "function Attach-EmailToWorkItem ($message, $workItemID)" there is the name of the message set. And this name is always message.eml. If you open the attachment in the scsm console the first time it works. In the temp folder the message will be created. But if you want to open the attachment a second time the console give a error. for example the file which the console creates is pk2w5p4k.13feml. So there is no program in windows to open such a file with this extension. We use the SCSM 2016 Version with UR8 and the SMletexchangeconnector in Version 2.4.0

[AdhocAdam]

🤔

[AdhocAdam]

Well the bad news is that I can't repro the crash as the message.eml file in my temp folder just overwrites itself. BUT!

• The fact I can overwrite the file, suggests you/SCSM can't (which you essentially spell out above)
• In a somewhat related way, this came up in #200 and it appears I incorrectly spoke when I said this was "original Microsoft Exchange Connector" functionality. The stock connector functionality does in fact timestamp the name to keep it unique.

I would have to imagine this uniqueness is the key to addressing the issue you've raised here. If you're open to testing, here's the 1 line of PowerShell you can use to modify the Attach-EmailToWorkItem function for some uniqueness.

$emailAttachment.Item($fileAttachmentClass, "DisplayName").Value = "message.eml" + "-" + ([DateTime]::Now.ToUniversalTime()).toshortdatestring().replace("/","-") + " " + ([DateTime]::Now.ToUniversalTime()).tostring("HH:mm:ss").replace(":","-")

The output would then look like: message.eml-1-19-2021 01-14-36

Assuming this solves the issue, the next step would be to determine the current locale/region so as to obtain the datetime formatting. For example:

$culture = Get-Culture
$dateFormat = $culture.DateTimeFormat.ShortDatePattern
$timeFormat = $culture.DateTimeFormat.LongTimePattern

$emailAttachment.Item($fileAttachmentClass, "DisplayName").Value = "message.eml" + "-" + ([DateTime]::Now.ToUniversalTime()).ToString($dateFormat).replace("/","-") + " " + ([DateTime]::Now.ToUniversalTime()).ToString($timeFormat).replace(":","-")

[JanSchulz]

Thank you for the information, but i found the problem. its not the identical message.eml name which creates the problem. The process from the console generates the name of the file and add the extension string. so a file looks like [asfewwx.wdh] and then adds the extension [eml]. So the filename is asfewwx.wdheml. But this Extension dont exist. If i changed the extension in the script to [$emailAttachment.Item($fileAttachmentClass, "Extension").Value =   ".eml"] then the dot do the trick. now the filename is generated right for example [1cvp4uts.3ix.eml] and now if you open a file with the same name multiple times the right extension gives you the opportunity to open the file. I am wondering that you cannot repro the problem. Or is our Connector script older and has this bug? Can you proof if you can change this in the script?

[AdhocAdam]

Without looking through the history of all the commits to that function, I'm pretty confident that function has never changed the Extension property. So I don't think it's version specific issue, but then I'm not sure what it is other than something environmental. Which of course, could be anything if that's the case and lead down a lot of rabbit holes.

Never the less - your logic feels rather sound because now as I'm looking at the Attach-FileToWorkItem function I noticed that I do in fact use a "." when setting the Extension property (e.g. ".png" or ".jpg"). Not to mention, it looks like the stock connector uses ".eml" as the Extension. I just changed to ".eml" in my lab and everything continues to work as expected.

That said, would you mind raising a Pull Request again the Dev branch and correcting the Extension property in the Attach-EmailToWorkItem function? That way you can get credit for this fantastic observation you've made. 😄

[JanSchulz]

ok, thanks for that :-) This was my first pull request on Github i hope i do it the right way.

[AdhocAdam]

Nailed it @JanSchulz!

[AdhocAdam]

Completed pull request into dev. Will ship with next release via #257