Launching the Arc Jumpstart Newsletter: October 2024 Edition
We are excited to kick off this monthly newsletter, where you can get the latest updates on everything happening in the Arc Jumpstart realm. Whether you are new to the community or a regular Jumpstart contributor, this newsletter will keep you informed about new releases, key events, and opportunities to get involved in within the Azure Adaptive Cloud ecosystem. Check back each month for new ways to connect, share your experiences, and learn from others in the Adaptive Cloud community.
Last Exchange Server Shutdown. Exchange Management Shell attempts to connect to old Server
We have migrated all mailboxes to Exchange Online and felt we were in a position to shutdown the last on-prem 2016 Exchange Server. We followed the instructions in the following article to shutdown the last Exchange Server and manage recipients using the Exchange 2019 Management tools. https://learn.microsoft.com/en-us/exchange/manage-hybrid-exchange-recipients-with-management-tools When we open the Exchange Management Shell on the server running the new management tools it attempts to connect to the old Exchange Server. What do we need to do so the Exchange Management Tools stops connecting to the old exchange?Bad actors impersonating Microsoft Billing using rogue on-prem. Exchange > M365 tenants
Everyone should be aware and watch out for these very believable spoofs coming from microsoft-noreply_at_microsoft.com. If you have Threat Explorer (Defender Portal > Email & Collaboration > Explorer) or Advanced Hunting (EmailEvents table) available, you can find these messages by looking for these criteria: - Sender From Address:microsoft-noreply_at_microsoft.com (note the@ / _at_ swap) - Sender MailFrom Domain: Not equal to Microsoft.com (will be <something>.onmicrosoft.com) If you're getting these, you'll notice the MailFrom domain is an ever-changing long list of rogue tenants (e.g., <rogueTenant123>.onmicrosoft.com). The MailFrom address will be starting with "bounces+srs", like this "bounces+srs=<12345567890abcxyz>@<rogueTenant123>.onmicrosoft.com", letting us see that these bad actors are using an on-premises Exchange server, SMTP receive Connector and then a Send Connector up to and out via EXO/EOP. These things pass SPF, DKIM, and DMARC and so only get detected via General/Advanced filter and/or Fingerprint Matching (which only means loose match, there's no specific fingerprint/ID involved). The subject seems to always be "Your Microsoft order on September 23, 2024", and will be for the current date. Some people have raised this on Reddit, for example:email address removed for privacy reasons - Suspicious email : r/DefenderATP (reddit.com) I've been working with MS Support to try and get this addressed. We're seeing a lot of these, and so far it's be many many different rogue tenants, so it seems like the bad actors are working overtime and successfully standing up tenant after tenant to get these things out successfully.
Exchange server transport logs reading tool
Hi Exchange Brain Trust, I need to get rid of any inactive IP addresses out of my SMTP receive connectors in Exchange 2019 server (Hybrid environment). Is there a free tool to monitor/study transport logs which provides a good UI as opposed to notepad readings? Appreciate any suggestions. Thank you!Document Mailbox permissions
We are preparing to start a Microsoft Exchange hybrid migration. I am looking for a tool that documents mailbox/resources permissions. I know I can use the get-mailboxpermissions, but that does not show permissions assigned by a user to another user. Anyone have any suggestions?Generally Available: Transition to WS2012 / R2 ESUs enabled by Azure Arc from Volume Licensing
Customers that have enrolled in WS2012/ R2 ESUs through Volume Licensing for Year 1 can transition to Azure Arc for Year 2 of the program by specifying their Volume Licensing entitlements (Invoice Ids) in provisioning new Azure Arc WS2012/R2 ESU licenses. Extended Security Updates afford customers with critical security patches for end of support Windows Server 2012/R2 machines.
Validate the working of default policy tag in MRM policy
Hi All, We have applied a retention policy to all mailboxes in our environment which also includes a default policy tag that moves all mails older than a year to Archive. Now, i know that the policy is applied and the default tag is doing its job, but, is there a way where i can see whether the mails are moved after the policy was applied ?
