/build/static/layout/Breadcrumb_cap_w.png

KACE Product Support Question


Popping Into Office 365 HTML special characters and a K1000 ticket rule

04/22/2013 6313 views

Hello,

I have setup an e-mail account for our IT Helpdesk in Office 365. This is how end users submit support requests. When the KACE helpdesk appliance pop's in and grabs the e-mail, it brings it down in HTML format. I have used powershell to set the the mime format for popping into the Office 365 account as TextOnly and also Tried HtmlAndTextAlternatives.

 

Here are the commands that I used, the e-mail account has been modified for this forum:

 

 

Set-CASMailbox helpdesk@company.com -PopMessagesRetrievalMimeFormat TextOnly

Set-CASMailbox helpdesk@company.com -PopMessagesRetrievalMimeFormat HtmlAndTextAlternative

 

 

I had a ticket open with KACE to help make sure that pop and e-mail traffic was working with the helpdesk appliance and Office 365. I asked them about the issue and they suggested to setup a ticket rule to remove the HTML characters. I asked for assistance with that and they mentioned IT Ninja or if I wanted them to do it, it would be at a cost.

So here I am asking for help on setting up a ticket rule to remove the special character such as   .

 

Thanks

Matt

0 Comments   [ + ] Show comments

Comments



Community Chosen Answer

1
Set-CASMailbox -Identity <email of account> -PopMessagesRetrievalMimeFormat 0
Set-CASMailbox -Identity <email of account> -ImapMessagesRetrievalMimeFormat 0
Set-CASMailbox -Identity <email of account> -PopUseProtocolDefaults $False

Please note the third command:
Set-CASMailbox -Identity <email of account> -PopUseProtocolDefaults $False

You can find the help link regarding this command in the link below:

https://technet.microsoft.com/en-us/library/bb125264(v=exchg.150).aspx

Answered 09/21/2015 by: karuna_kumar
White Belt

All Answers

0

I have found that this works for us with the latest update for KACE.  THe odd "&nbsp; " still comes in for some reason but it is way better.

Connecting to powershell for Office 365

Link:http://help.outlook.com/en-us/140/cc952755.aspx

Then use the folloing commands.

set-casmailbox -Identity <email of account> -PopMessagesRetrievalMimeFormat 0
set-casmailbox -Identity <email of account> -ImapMessagesRetrievalMimeFormat 0
Answered 04/10/2014 by: smalls
Senior Yellow Belt

  • A more up to date link for documentation on this procedure from Microsoft: https://technet.microsoft.com/en-us/library/aa997869(v=exchg.150).aspx
0

What version of the K1000 are you on?  I believe there was a version of 5.3 that had an issue with "&nbsp" in emails.  If you aren't on version 5.4.76847, I'd suggest upgrading.

Where was the powershell script run? Text only would be a setting in the Office 365 set up in my mind.

Another option might be to use a SMTP relay server between Office 365 and the K1000.

Answered 04/24/2013 by: jknox
Red Belt

  • We are running the following Currently Installed Server Version: 5.4.70402

    We setup a relay for the appliance to send emails. I didn't think that would be used for receiving e-mails. We are using a barracuda e-mail filter. It was used before we switched to o365 so I figured instead of setting up a new relay, use what we have.

    Should I upgrade to the latest version?

    Thanks
    Matt
    • I would. 5.4.76847 has some bug fixes from 70402, though I don't believe there's anything specific for the issue you are currently seeing.
      • If that doesn't fix, how would I setup a ticket rule to remove it. Or would popping through the relay be recommended.
  • Just as a follow up. I have updated the K1000 to the latest build and it still brings down the HTML characters. I also setup the barracuda as a remote pop and had the K1000 pop into it to retrieve the messages and it still passed down the HTML special characters. Does anyone have a fix for this (short of everyone sending e-mails in plain text)?

    Thanks
    Matt
  • I am curious as to a final resolve of this as well as we too, are having the exact same issue.
    • We have not been able to come up with a solution. We have been having to deal with it. Hopefully something will change and an update fixes this issue.
      Sorry I couldn't be of any more help than that.
      • Is this still an issue for you? I have found that even making a comment inside of the web gui has issues. An example is a \\fileshare\path with or without quotes. It cuts the slashes out. A http link inserted looks like this http://<a href="advisory?ID=02">Address</a>_dev instead or http://Address_dev

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ