Cloud Services Thread, O365: Transport Rules not working when recipient is a security group in Technical; I've tried asking this on the O365 forums but not had an answer as yet, figured it was worth a ...
O365: Transport Rules not working when recipient is a security group
I've tried asking this on the O365 forums but not had an answer as yet, figured it was worth a punt here as well.
We always used to prevent students spamming All Staff and All Students with a fairly straightforward transport rule: if sender is a member of All Students; if recipient is All Staff or All Students; redirect to ITHelpdesk; except if sender is Head Girls. Worked fine in Exchange 2007 when we had on-premises, migrated over, but wasn't applying.
In trying to recreate from scratch and work out why it wasn't applying, I've narrowed the problem down to, specifically, the recipient being a security group. Doesn't matter how I target it: directly with "recipient is", with regular expressions against the email and displayName, with "contains word" against the email and displayName... if the recipient is a security group, the rule won't apply. Every method I've tried, I could amend my input to match my mailbox address and it takes immediate effect. The problem is specifically when the recipient is a group.
All groups are security groups synced from AD. Creating a new group and syncing up made no difference (as requested on the O365 forum).
Has anyone else got this working at the moment, or is it a bug in Exchange Online?
Update from the Office 365 thread: The MS support guy can recreate the issue. He's suggested a workaround that I can't implement because the groups in question are synced from on-site AD. The attributes in question are authOrig and unauthOrig, but ADSIEdit complains it doesn't have an editor capable of handling the attributes. Anyone know a way I can get at them without having to pull out the old Exchange server and start faffing around in that?
Whilst waiting for MS....try creating an email account called 'insert desired name' and set it to forward to the 'all staff' mail group, then add the rules to the 'insert desired name' email account to filter out the SPAM.
@Arthur - AD Explorer was next on the list, but I tend to try built in tools first, cheers anyway
Joe @CPLTD - if I was setting up from scratch and for the long term, it'd be worth a crack, I reckon, but given how much hassle cached group addresses have been through the migration anyway (more or less the only teething problem, in fact) and that I'm hoping MS can fix the bug so I can apply a rule as normal (as, ideally, I'd still like to redirect the messages instead of bounce with an error message) the less disruptive I can be with the fix, the better. Cheers still!