@wrx7m said in Exchange 2016 - NDR:
@scottalanmiller said in Exchange 2016 - NDR:
@Natchos said in Exchange 2016 - NDR:
@JasGot Awesome, thanks for the input. I'll look into SPF.
SPF is considered a requirement these days. And DKIM is heavily recommended.
People are starting to come around. I have been using DKIM for a few years for all services sending email outside our org. With O365, SPF and DKIM are part of the setup.
Same with Zoho.

@WLS-ITGuy said in Shared Vehicle calendar:
@black3dynamite said in Shared Vehicle calendar:
Something like this won't work because you don't want to have anyone managing it?
https://support.sherweb.com/Faqs/Show/how-to-book-a-resource-equipment-or-room
Then I would need someone to manage it? That would be OK if it has to be done as I can have the buildings and grounds manager handle the requests.
Here's another guide that was created. Looks pretty simple to set up.
http://facilities-intranet.anu.edu.au/__documents/systems-it/how_to_add_shared_calendars_for_vehicles-1.pdf

Also Hybrid Deployments I have only used it for customers that do not care for Exchange onsite to receive emails on mailboxes that are not in the cloud when the Internet is down. Hybrid Configurations a times need to be reconfigured (Meaning just running the wizard to confirm it is still in place)>

You can test the autodiscovery with the Microsoft Connectivity test, you can also check if the SCP lookup is the culprit
http://support.itclinic.london/Knowledgebase/Article/View/4/3/disable-autodiscover-scp-lookup-for-outlook-clients-with-office-365

@brianlittlejohn said in Exchange Shell command not working:
You also need to have export/import permissions granted to your account. They are not granted to anyone by default.
This is what you need.
First assign your user the Mailbox Export Role
New-ManagementRoleAssignment -Role "Mailbox Import Export" -User "<user name or alias>"
Then make sure the Exchange Subsystem has access to that shared folder and then run your export:
MailboxExportRequest -Mailbox username -FilePath "\\server\PST FOlder\username.pst"

@dustinb3403 said in Exchange migrations, scenarios to hope you're never in.:
User abuse is the only bug we can't fix with technology.
Good to know eseutil was able to correct the issue.
Even that was just very weird. The status had stopped updating and processes associated with it quit doing anything for around 20 minutes. We were both wondering what was going on when I was like "I'm going to ctrl+c it." So the cancel current command actually kicked off a whole bunch of activity that went quite quickly compared to what it had been running at before and actually repaired the DB. We were both more than a little confused over that one.