Recently a few users had the following bounce backs from Office 365 to an On-Prem Mailserver with the error
‘550 5.4.316 Message expired, connection refused(Socket error code 10061)
Checking the logs in 365 of this, this was due to the Fortigate adding some 365 SMTP servers to the IPS Quantarine List
Removing these servers from the Quarantine and also removing IPS checking in the Policy of 365 servers to on-prem via SMTP resolved this
Trying to setup a subdomain for iManage communication server in 365. I created a Connection from 365 to OnPrem server
Create a Connector
What I needed to do was also add the domain to 365 and change it to Internal Relay
Add the domain in below
Change the accepted Domain Type for the subdomain to internal relay
Azure Single Sign-On
Identifier (Entity ID): https://imanage.domain.com
Reply URL (Assertion Consumer Service URL): https://imanage.domain.com/api/v1/session/saml-login
Download Certificate file (.cer) and store on iManage server e.g. C:\SSL\
HIVE: HKLM\SOFTWARE\Interwoven\WorkSite\imDmsSvc
SAML Attribute: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
SAML Endpoint: https://myapps.microsoft.com/signin/iManage%20SAML/xxxxxxx-xxxxxx-xxxx
SAML Key File: C:\SSL\iManageSAML.cer
SAML Logout Endpoint: https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0
SAML Web RP: https://imanage.domain.com
How to save existing Document library as Template
Login to Sharepoint then navigate to the Document Library
Go to Library Settings
Save template ( with or without the content )
Next go to the Site where you want to create the new Library and create a new App ( NOT Document library )
Search for your new Template
And Add this with the new Name
Recently had a user who when outside the office could not connect to 365. Per below her Outlook would just sit on “Trying to Connect”
They used OAuth for Outlook and 2fa which means when outside of a “trusted IP” the box should come up asking for the 2fa code , however this prompt was not coming up ever after restart (usually fixes a stuck Oauth box ) .
Fix
Go into credential manager and delete all the ADAL for the user , then restart Outlook
Recently I tried to setup a 365 Send connector to relay it through another third party Mimecast ( https://community.mimecast.com/docs/DOC-1623 ) . Mimecast confirmed they had enabled the Tenant domains to relay through Mimecast.
The send connector was Failing as the last Step, however I was receiving the email. After numerous calls with office 365 support they came back with the reply “We don’t support technical help with Third Party SMTP Servers”
Checking the headers on the email that came through showed the validator wasn’t even relaying through Mimecast.
Enabling the Send Connector and trying again resolved the issue , however it’s a flawed design , because after enabling it during the validation if any user tries to send out and it doesn’t work they will produce an NDR
With an account that has full access to the Shared Mailbox , login to Webmail and Choose “Open Another Mailbox”
Enter the Shared Maibox and Click OK
Next Click on the settings Icon and Choose “Publish Calendar”
Next Change the Details Below
Next Send the External party the HTML or ICS file
Had a ticket regarding 3 different sent emails to 3 different third parties which were getting duplicated into an IT mailbox on Office 365.
I double checked the “rules” under Mail flow to make sure there were no BCC rules for the users sending which there were not.
In MailTrace the emails came up as Status “Expanded”. This means the email has been sent to a group, however the original email was sent to a Single External Email address?
Why was the external email being displayed as a group in 365?
Turns Out the Outbound Spam Preferences had been turned on! And for whatever reason, these items were triggering the BCC of suspicious messages!
Recently we swapped a users UPN on a local domain controller ( which syncs to 365 via AAdconnect) to another domain and SMTP alias, all worked well however she could not login to Skype for Business.
Resetting Windows Credentials, Caches and registry items still would not fix this.
Most of the time this is due to the SIP Address not being correct. Little did we know this user had Lync before migrating to 365 so they had a SIP address in the attribute editor
Changing this resolved the issue
When they initially onboarded, there was no filtering or security in any form:
Running a simple audit against Azure AD>Sign-ins showed the extent, even more when you export a CSV.
2000+ failed attempts within 24 hours:
Step 1) Sort or filter the CSV to find common trends (specific user account/IP/Country:
In this case, the client doesn’t have staff in China, nor should anyone be accessing from there
Step 2) Create a Blacklist – AzureAD>Conditional Access.
Make sure it works as intended!
End result:
