|
Oscar Wilde Bunch posted:I've taken to using BitTitan or Skykick. No goofing with hybrid, no connectors to clean up. Sure it costs, but being able to do on the fly mailbox type remaps (person to shared, shared to resource, person to resource, etc...) plus having a deployable client that does auto Outlook profile switching was worth it. Bittitan is great. Used it to migrate the mailbox contents for ~1400 employees from an acquisition a couple of years ago and it was super easy to use. That was a slightly different use case though as all we were doing was copying the mailbox contents off of the separating company’s exchange, no identity migration. We made another smaller acquisition last year and are in the planning stages of throwing out pretty much all of their IT infrastructure to include their O365 tenant. This one is a bit more complex since we are migrating identities and domain ownership to our tenant. Bittitan licenses just arrived, so it’s time to get to work!
|
#
?
Mar 18, 2021 12:30
|
|
|
|
| # ? Apr 16, 2024 23:16 |
|
|
I like Migrationwiz but *providing your on-prem Exchange is working well* then doing a hybrid would still be my preferred way to do that migration, even if it's just so everything can be done in phases without anybody noticing.
|
|
#
?
Mar 18, 2021 16:09
|
|
|
If this wasn't a one off I may be more inclined to do that. I think I'm going to go bittitan. No need for trusts or rectifying GUIDs or SMPT matching with the 365 tenant.
|
|
#
?
Mar 18, 2021 16:30
|
|
|
https://github.com/cisagov/CHIRP find out how owned yr servers are
|
|
#
?
Mar 18, 2021 21:41
|
|
|
A ticket came in: Allow Access to Outlook Web Access only from US
|
|
#
?
Apr 6, 2021 20:13
|
|
|
Bob Morales posted:A ticket came in: Allow Access to Outlook Web Access only from US And to think, it could be as easy as a click of a button. https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-location
|
|
#
?
Apr 6, 2021 21:04
|
|
|
Internet Explorer posted:And to think, it could be as easy as a click of a button. It's easy in the firewall to do apply incoming GeoIP US-only It's just going to create about 20 tickets to unblock certain things in the future.
|
|
#
?
Apr 6, 2021 21:26
|
|
|
That's a problem for Future You.
|
|
#
?
Apr 13, 2021 14:53
|
|
|
A few months ago I was in a meeting that got zoom-bombed and I was like "I know how to avoid this, I'll just make it so my Zooms can be US-only!" and then I got a call saying "hey so-and-so from Vancouver can't join the meeting" whoopsy-daisy
|
|
#
?
Apr 13, 2021 14:54
|
|
|
get patching boys/girls/x, 4 more critical exploits this month https://techcommunity.microsoft.com/t5/exchange-team-blog/released-april-2021-exchange-server-security-updates/ba-p/2254617
|
|
#
?
Apr 14, 2021 08:31
|
|
|
Performing some thread necromancy here... I have a pretty new (to us) client that has an Exchange 2019 server and needs us to collect a bunch of emails for a legal matter. I've run eDiscovery with Exchange online before but not on-premise. I'm running into a strange issue where it's not returning all emails. If you use the eDiscovery preview it will show, say, 20000 emails but if you export to a discovery mailbox or pst it will only export 1400. Checking the csv that gets exported with the pst shows a really big gap in emails returned. Anyone have any ideas about what might be happening? Having a hard time even figuring out where I'd find an error log for this
|
|
#
?
Jun 28, 2021 19:16
|
|
|
Has anyone ever dealt with cancelled meetings from a shared mailbox calendar being recreated on the attendees' calendars? There are a bunch of bits and pieces of suggestions online for it, but I'm trying to understand the underlying functionality of what's going on here. A user with delegate rights is cancelling a meeting, the recipients all receive cancellation notices, and the invite disappears as normal. The next day, the calendar repair assistant helpfully recreates the meeting with the "Exchange server re-created a meeting that was missing from your calendar" text. I know I can probably do a search and destroy on everyone's calendars and remove the meeting that way, but I was hoping to understand more about what's happening. Is this a sync issue somehow? Or is there something else going on here? Any useful resources on the repair assistant or related topics that I can read?
|
|
#
?
Sep 1, 2021 20:54
|
|
|
We're divesting part of our business and those staff have two email accounts while that is going on (one for us, one for the purchasing company) The new company have set forwards from staff's new accounts to their old ones Does that create an open relay if they get an external email that goes from eg gmail - > them -> us automatically via mail flow rule?
|
|
#
?
Sep 3, 2021 11:48
|
|
|
That's not technically an open relay. An open relay would be a third party connects to your server and is able to send an email to any recipient they wish, not just users at your domain. In your scenario the gmail.com sender would need to be sending specifically to recipients at a domain the other company is configured to accept mail for, and then those are sent to your servers. Depending on how forwarding is done, and the trust relationship established between the two companies, you may run into some DMARC problems though. From your example, when the message arrives at your border it could be from a gmail.com sender, but sent by servers from the other company. This would fail SPF and if the message isn't signed with DKIM or DKIM doesn't align then the message would fail DMARC. Of course if you've safe listed messages coming from the other company then you won't have to worry about that (most likely).
|
|
#
?
Sep 3, 2021 21:15
|
|
|
Is there a way to view the full message headers in 365 Message trace? Would be useful for troubleshooting.
|
|
#
?
Sep 14, 2021 17:14
|
|
|
At a guess you can take the message ID and shove it into eDiscovery and get the message itself, not sure if there's a way to restrict access to just the headers though.
|
|
#
?
Sep 14, 2021 17:26
|
|
|
Afaik there is no method to do this on delivered user messages but you can check the headers of quarantined mail. You have to access the quarantine via the gui and click around until you find a 'preview message' button. Or use Get-QuarantineMessageHeader in powershell with the appropriate message ID. Outside of quarantine, do the Thanks Ants thing. Or, if you don't like the clunkiness of eDiscovery/it's just a small number of messages, you could also ask a user to select it in Outlook and press ctrl+alt+f. A new mail window with the original message attached will appear, they can simply address it to you and send. It retains the headers of the original in attachment. Hard to do large scale, i guess
|
|
#
?
Sep 23, 2021 17:09
|
|
|
A client has asked for a way to block an Exchange Online user from sending emails during specific time windows. Is this possible?
|
|
#
?
Nov 19, 2021 22:15
|
|
|
nvrgrls posted:A client has asked for a way to block an Exchange Online user from sending emails during specific time windows. Is this possible? I guess you could set up a power app (or power automate? i get them confused) to powerhsell disable sending and then enable it on a schedule.
|
|
#
?
Nov 19, 2021 22:40
|
|
|
Countries are writing laws about being contacted outside of work, I'd have assumed companies have sprung up to control access to things on a schedule.
|
|
#
?
Nov 19, 2021 23:41
|
|
|
In the olden days I've seen companies using Windows Logon Hours to control that but I haven't seen a cloud version of that. I suppose you could probably do something crazy with Azure AD Connect and pass through authentication but that kind of makes me shudder and the long auth times for things like activesync would probably get around it.
|
|
#
?
Nov 22, 2021 14:17
|
|
|
Happy 2022 to any suckers like myself still responsible for on-prem exchange, your mail flow is probably down! Fortunately there is a workaround that is easy to do even if you're still drunk. https://borncity.com/win/2022/01/01/exchange-fip-fs-scan-engine-failed-to-load-cant-convert-2201010001-to-long-1-1-2022/ Disable-antimalwarescanning.ps1 as seen here: https://docs.microsoft.com/en-us/exchange/disable-or-bypass-anti-malware-scanning-exchange-2013-help got our mailflow working again.
|
|
#
?
Jan 1, 2022 15:45
|
|
|
J posted:Happy 2022 to any suckers like myself still responsible for on-prem exchange, your mail flow is probably down! Fortunately there is a workaround that is easy to do even if you're still drunk. Seriously wtf. Luckily I discovered the problem early in the evening because of external mail flow monitoring. I'm not even sure if this is something that can be fixed by automated self updating. Its kind of amazing that the cause is the variable they use for the definitions serial number is too small when the year rolled over to 2022, and the failurestate is oops no mail flow.
|
|
#
?
Jan 1, 2022 17:45
|
|
|
J posted:Happy 2022 to any suckers like myself still responsible for on-prem exchange, your mail flow is probably down! Fortunately there is a workaround that is easy to do even if you're still drunk. I'm more in infrastructure so i wasn't involved in the first hour of troubleshooting, but i'm also in charge of making sure our Biztalk-servers do their stuff correctly and they were involved in the flow, so i got involved in the troubleshooting. One of the first things i asked, jokingly, was if the CPR handled dates as int32. Turns out an hour later when the developers checked on their end that it actually did. So now we have an emergency patch on the way, combined with updates to the database because of course the table stores the date as int32. I wonder what Stack overflow-post Microsofts Exchange-team and our CPR supplier might have copied the code from
|
|
#
?
Jan 3, 2022 20:53
|
|
|
We've been migrated to hybrid Exchange Online for years now, but one of my users just had a very strange error. When she accepted meeting invites from her Outlook client, the responses would fail because she didn't have permissions to send on behalf of a user. That user was herself, and looking at her sent items folder showed that her X500 address was trying to send on behalf of... herself? Accepting a meeting invite via OWA worked fine, and a restart of Outlook fixed the issue, but has anyone ever seen that before? https://imgur.com/ySJy1Pj
|
|
#
?
Jan 26, 2022 20:54
|
|
|
This is a longshot but I'm getting desperate to solve this. For the last couple weeks, Win10 profiles on my domain can't autodiscover 365 accounts in Outlook (2016, 2019, and Outlook365). Looking at the autodiscover log, the redirection from our domain is happening, but they get a 401 error (which prompts for password), and then just fails after that with error 0x80040413. It's only happening on: -win10 and server 2016. Win7 is fine. -Domain accounts only. Local accounts are fine. -NEW windows profiles only. Everyone who logged into their PC prior to February can autodiscover just fine, to any 365 account. Which domain profile doesn't matter. 365 account doesn't matter. It also doesn't matter if it's on our own network (Putting a domain PC on a hotspot still fails, but logging into a local account on that same PC succeeds) Example of a failure:  Example of a success:  (same email account, PC, and domain. Only difference is this is from a windows profile that was established on the PC several months ago) The 0x80040413 seems important since it's a fairly uncommon error, but the few results that come up are old posts involving hosting their own exchange servers, and it hasn't helped me get closer to a solution. It's extra frustrating because I don't know a way to work around this, so we have a new person that just started and has to use OWA to access email.
|
|
#
?
Feb 21, 2022 20:50
|
|
|
Is it the Windows profile or the Outlook profile that matters? Not that I have any particular ideas, but it might be worth trying to add a fresh Outlook profile to a working Windows profile to see if that fails too.
|
|
#
?
Feb 21, 2022 21:42
|
|
|
Do you get any errors running an autodiscover/Outlook connectivity check on https://testconnectivity.microsoft.com/ ?
|
|
#
?
Feb 21, 2022 21:52
|
|
|
wa27 posted:For the last couple weeks, Win10 profiles on my domain can't autodiscover 365 accounts in Outlook (2016, 2019, and Outlook365). Looking at the autodiscover log, the redirection from our domain is happening, but they get a 401 error (which prompts for password), and then just fails after that with error 0x80040413.
|
|
#
?
Feb 21, 2022 21:57
|
|
|
nielsm posted:Is it the Windows profile or the Outlook profile that matters? Outlook profile doesn't matter at all. As long as I'm on a "working" windows profile (or off the domain), I can set up any new or old email account I try. As for the windows profiles, it's only fresh logins that are failing. Even if an old domain account logs into a new PC for the first time, it will fail. I assume that means something is cached on all the existing profiles that I'm not realizing, and that's the difference. Bandire posted:Do you get any errors running an autodiscover/Outlook connectivity check on https://testconnectivity.microsoft.com/ ? underlig posted:Apologies if i'm completely off track, but it's no that they've changed authentication methods? https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online  I do wish I could try modern authentication just to see if that works, but as far as I know you can't just enable it for certain users, and I'm really not ready to turn that on for the whole agency at this time.
|
|
#
?
Feb 21, 2022 22:13
|
|
|
Also why are you pointing to on-prem exchange for the auto discover handoff, do you still have resources homed in on-prem mailbox servers? You need to get on modern auth, and fast. It’s not really that big of a deal or impact.
|
|
#
?
Feb 21, 2022 22:15
|
|
|
devmd01 posted:Also why are you pointing to on-prem exchange for the auto discover handoff, do you still have resources homed in on-prem mailbox servers? I think that's just Outlook 2016's preferred order of operations? We haven't had on-prem exchange since we migrated years ago. At that time I set up our DNS as the migration instructions specified, and the DNS check in the admin console seems happy with how we have it set up. When I try with Outlook 2019, it first tries outlook.office365.com/autodiscover/autodiscover.xml, which normally works and skips all the redirection. But even that is failing in the exact same way. I hear you on the modern auth bit. It's on my priorities for the near future now. I'm a bit wary about throwing that switch right this moment though. Will it make everyone log in again? I worry that I'll then be stuck with 60 users unable to access their email instead of just 2 (for now). edit: I'm reading more about enabling modern auth and I didn't realize disabling basic auth was a different process. I am going to read up more on this and may try it out tomorrow and see if that solves the problem in a roundabout way. wa27 fucked around with this message at 23:12 on Feb 21, 2022 |
|
#
?
Feb 21, 2022 22:35
|
|
|
Yep, Enabling modern auth and disabling legacy auth are two distinct steps. We are running modern auth preferred, but haven't gotten the go ahead to turn off basic yet. If this is working for non-domain joined machines, it sounds like it could be something in your provisioning process that changed. Are the affected boxes in the same OUs/SGs/GPOs as the ones that work?
|
|
#
?
Feb 21, 2022 23:18
|
|
|
So you don't have any on-prem Exchange servers, did you ever have on-prem Exchange, how did you decommission it? Where does autodiscover.yourdomain.com resolve to when you're on the network? Do you still have the SCPs in AD for any on-prem infrastructure? I presume you are doing Azure AD sync from your AD to Microsoft 365? Do clients work for SSO if you browse to https://outlook.office.com or do they have to authenticate again?
|
|
#
?
Feb 21, 2022 23:18
|
|
|
Bandire posted:
Thanks Ants posted:So you don't have any on-prem Exchange servers, did you ever have on-prem Exchange, how did you decommission it? Where does autodiscover.yourdomain.com resolve to when you're on the network? Do you still have the SCPs in AD for any on-prem infrastructure? Thanks Ants posted:I presume you are doing Azure AD sync from your AD to Microsoft 365? Do clients work for SSO if you browse to https://outlook.office.com or do they have to authenticate again?
|
|
#
?
Feb 21, 2022 23:53
|
|
|
Maybe get a freshly imaged machine before it is domain joined and test. If that works, then join it to the domain and test both local and domain accounts, and then disjoin it from the domain and test one more time.
|
|
#
?
Feb 22, 2022 00:14
|
|
|
Is there a reason some of a user's meetings are canceling themselves a half hour before they start? I thought it might be a time zone thing, especially since they give out edit permissions to their calendar to a ton of people, but I've been able to confirm everyone is using outlook with Arizona time set at least. User also has "automatically cancel meetings" set to off.
|
|
#
?
Nov 2, 2022 23:03
|
|
|
While working on some tooling for managing our on-prem Exchange 2019, I notice that the mailbox databases (Get-MailboxDatabase) have a property named "CafeEndpoints". I can't find anything about that property anywhere. Do anyone know what it's about? (I'm just curious/confused, it doesn't seem to be anything that matters for what I'm working on.)
|
|
#
?
Nov 14, 2022 14:07
|
|
|
Is there a reference anywhere to the default permissions on the "Organization Management" role group in Exchange Online? Someone has hosed with ours and I've copied the permissions from another tenant but would prefer to be able to compare them to the defaults / run a PS command to reset it if that exists.
|
|
#
?
Nov 22, 2022 19:29
|
|
|
|
| # ? Apr 16, 2024 23:16 |
|
|
Thanks Ants posted:Is there a reference anywhere to the default permissions on the "Organization Management" role group in Exchange Online? Someone has hosed with ours and I've copied the permissions from another tenant but would prefer to be able to compare them to the defaults / run a PS command to reset it if that exists. You'll want to look at reinstalling the canned RBAC roles. I've never had to do this before, but it could help your situation. Disclaimer here is you could end up with redundant groups and more cleanup after. https://everything-powershell.com/exchange-2019-reset-rbac-to-default/
|
|
#
?
Nov 22, 2022 20:14
|
|