Hi there. New to JIRA and starting the process of setup and putting it through its paces. I'll describe a few variables first to help fill in the context:
So here is my biggest challenge I'm running into. When I'm under | Administration | System | Incoming Email | attempting to test JIRA Service Desk to connect to my Exchange/Office365 data: our email account is a Shared Mailbox in Exchange. This can be tricky for those that don't work in Exchange. This isn't a single user account mailbox and multiple people all access it with the same username/password. It is basically an account that can be accessed by multiple people and does not have a password associated with it. It's accessed based on permissions.
To better understand (in case you need reference): https://technet.microsoft.com/en-us/library/jj150498(v=exchg.150).aspx
Sooooooooooooo, I'm wondering if my failing with JIRA to access this Shared Mailbox is because the variables I can manipulate in Incoming Mail are for standard (normal) type mailboxes. Meaning single user, single username/password type setups. I can't even chose to not have a password in these settings.
Sorry about the TL;DR post. Just trying to be thorough. I'm open to any guidance/reading/links to resolve my challenges.
I'm wondering if in order to make this work I will need to convert my Shared Mailbox back to a Single User style Exchange/Office365 account.
For your JIRA inbox, you shouldn't be using a shared mailbox. You should have a mailbox dedicated to JIRA.
This is what we do here (We use the JEMH plugin to handle our incoming emails because we have more specific needs, but that applies to a Service Desk mail handler too)
In your situation, maybe you would like a forward of these email tickets to your shared mailbox, but I rather think it's unnecessary. Better to rely on JIRA's notifications when the tickets are created to avoid duplicates.
Realise this thread is over a year old but just in case anyone else finds themselves here whilst looking for a way to connect to shared mailboxes.
We used to do it the way that Nicholas did, multiple distributions groups to a single standard mailbox and then handlers to process each email address and route the ticket to the appropriate service desk project. We've now switched so we have a single licensed Office 365 account for outbound and individual shared mailboxes per project / service desk which allows us to use the service desk handler as recommended.
Set up is as follows
That should allow you to download mail from your shared mailbox using the service desk handler. It also means that we only pay for one Office 365 account as the shared mailboxes are free so we can set up as may of these as we need without additional subscription costs.
Hi, what Ian is refering to is have a shared mailbox automatically forward an E-mail to an actual inbox that does have a password (full mailbox account).
And this full mail account should be integrated into Jira.
This way you can still have mail adresses specifically for the client (aliases / shared boxes)
Not sure how point 4 worked for anyone :-)
In the username box set it as jira@[company].com\<Shared Mailbox Alias>
In my case I could authenticate to jira@[company].com but not with \<Shared Mailbox Alias>
What worked for me is resetting the shared mailbox password, and logging in via Shared Mailbox Alias@[company].com
Point 4 is actually pretty straight forward, you're authenticating with the account that's been granted access to the shared mailbox using that accounts details.
MS actually recommend that you block direct sign in on shared mailboxes. To quote the guide on creating shared mailboxes (https://docs.microsoft.com/en-us/office365/admin/email/create-a-shared-mailbox?view=o365-worldwide)
"Every shared mailbox has a corresponding user account. Notice how you weren't asked to provide a password when you created the shared mailbox? The account has a password, but it's system-generated (unknown). You aren't supposed to use the account to log in to the shared mailbox.
But what if an admin simply resets the password of the shared mailbox user account? Or what if an attacker gains access to the shared mailbox account credentials? This would allow the user account to log in to the shared mailbox and send email. To prevent this, you need to block sign-in for the account that's associated with the shared mailbox."
Whilst your method works it's not secure and you're increasing the foot print of accounts that a malicious user can utilise to send email from your organisation. What do you do when someone leaves? change any shared mailbox password they may have had access to and then go round updating anything and everyone that still needs access to that resource? Far better to turn off the ability to log in to it at all and use the access permissions for their intended purpose.
Just to make sure before replying to this I set up a new service desk following my original posts steps to configure the email settings and can confirm it still works, the shared mailbox that SD is pointed at has logon blocked as per MS recommendations. Service Desk wise we're on 4.0.2 some of the earlier version complain when you set this up that the mailbox is not empty (that wasn't the case when I first posted but became an issue with one of the updates) that seems to have been resolved now. (There's a work round for that issue as well but given that it's working now without fiddling and the work around invovles altering the database entries for the service desk it's not worth detailing)
Given that as of today I have 9 desks set up exactly this way I can confirm not only does it work but it's actually straight forward to set up, I've been doing this way since we added the second service desk several years ago.
I'm wondering if we're talking at cross purposes this is purely the set up for the service desk inbound email configured from within the project settings under email requests. This is also a server install of Jira rather than the cloud offering, I have no idea if it applies to the cloud version. Outbound email in the global config is using a licensed O365 account that's been granted full access permissions to each of the specific projects shared mailboxes and the config for each service desks email email requests has been set up exactly as I described.
If it makes a difference we're using secure pop.
Thanks for this post Iain and is much appreciated. Based on your last response, you mentioned you are working with a server installed version of Jira but am wondering if you've worked with configuring O365 with cloud-based Jira?
After reviewing my project's email setup and corresponding with a member of the Atlassian Cloud Team, I've found that Jira Cloud doesn't currently support the ability to utilize SMTP as a mail server protocol.
I'm curious if you've migrated to Jira Cloud since your last post and if you've personally found a workaround to this.
Best regards to you!
The way you mentioned worked before, and I was using shared mailbox in Jira Cloud successfully.
However, I changed the password of company email yesterday because of 90 days rule. When I tried to update the password in setting, I realized Jira Cloud upgraded the email setting page, and removed username box. So there is no way to set up shared mailbox in Jira Cloud now.
I submitted feedback to Jira Team, and hopefully they can help me.
Edmund / Jun,
We're still using Jira Server rather than the cloud version and I've currently no intention of migrating so I'm afraid I can't suggest anything with regards to the changes that have been made to the cloud version.
Might be worth posting a feature request to the Jira team, it would seem not to be an unreasonable request for you to be able to specify the account details on incoming mailboxes.
I got the reply from Jira team, and Jira Cloud won't support shared mailboxes anymore.
Also, the feature request to allow connecting shared mailboxes to service desk projects was closed by development teams with the resolution Won't do, as you can see below.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events