Unable to access our Microsoft Entra admin center
We cannot create a support request from the admin center because we cannot sign in Dear Microsoft Support Team, We are unable to access our Microsoft Entra admin center because even our administrator account, email address removed for privacy reasons, is being prompted for MFA, and we do not currently have access to the Microsoft Authenticator method required to complete the sign-in. As a result, we cannot access Entra ID / Microsoft 365 admin settings to reset MFA methods, issue a Temporary Access Pass, or re-register authentication methods for the affected users. Tenant/domain: itieurope.com Affected admin account: email address removed for privacy reasons Issue: MFA is required to sign in, but the Authenticator method is unavailable Impact: We are locked out of the tenant administration portal and cannot manage users or authentication methods We request assistance with one of the following recovery actions: Reset MFA methods for the administrator account email address removed for privacy reasons; or Enable re-registration of MFA for this account; or Provide a Temporary Access Pass or another Microsoft-approved recovery method so that we can regain administrative access to the tenant. We had force majeure, the only authenticator was on the phone, which was destroyed due to an unforeseen situation. (crashed) We are ready to verify domain ownership, provide billing information, tenant details, proof of identity, or any other information required to confirm that we are the legitimate owners/administrators of this Microsoft 365 tenant. Please escalate this as an urgent tenant lockout / admin access recovery issue. Kind regards, itieurope.com email address removed for privacy reasons
Looking for Microsoft 365 best practices for a large dynamic company group
Looking for Microsoft 365 best practices for a large dynamic company group I'm a Microsoft 365 admin trying to figure out the best architecture for a company-wide group (100+ users) and I'm wondering if there's a better approach than what I'm currently doing. What I need I want a single company group that can: Automatically include users through dynamic membership Share SharePoint sites, files, OneDrive content, Teams resources, etc. Allow sending company-wide emails Allow sending required Outlook meeting invitations (not optional) Have moderation/approval for announcements, meeting invites, or posts Allow certain trusted users to bypass approval while everyone else requires approval Scale as employees are hired/terminated automatically Current setup Dynamic Distribution List Used for company-wide emails and Outlook meeting invites. Membership is dynamic using an Exchange recipient filter based on US users. Private Microsoft 365 Group Used for SharePoint, file sharing, and collaboration. Membership is dynamic through an Entra ID Dynamic Membership Rule. I had to use PowerShell to configure some permissions because the portal didn't support everything I needed. Problems I'm running into I now have two separate groups that should always contain the same people. The Dynamic Distribution List works well for email/meetings but doesn't provide SharePoint, Teams, or file collaboration. The Microsoft 365 Group provides collaboration but doesn't seem to support everything I need for company-wide communication. I haven't found a clean way to have approvers/moderators, while allowing a few designated people to post or send meeting invites without requiring approval. I also haven't found a good way to make Outlook meeting requests "required" from the sender side other than relying on attendees not changing their RSVP. My questions Is there a better Microsoft 365 architecture for this? Should I be using a Dynamic Distribution List, a Microsoft 365 Group, a Mail-enabled Security Group, Teams, Viva Engage, or something else? Is there a supported way to have dynamic membership + SharePoint + company email + moderated announcements/meeting invites all in one solution? How do large organizations typically handle company-wide communications while keeping membership automatic? Is maintaining two dynamic groups (one for collaboration and one for email) simply the recommended approach? I'd love to hear how other Microsoft 365 admins have solved this in production. Thanks!
Extend M365 Archive Quota capacity
In my organization, we are currently on the O365 E5 License with default 100GB mailbox size per user and 1.5TB archive quota. However, due to organizational policy and regulatory requirements, we are expected to keep all the data from inception. Hence, the requirement for a solution to extend our archive size from 1.5TB. From the official Microsoft documentation, https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-archiving-service-description/exchange-online-archiving-service-description#archive-storage-quota the maximum expansion of the archive mailbox is 1.5TB. Is it possible to extend the archive storage to an Azure blob? Like an automated script that moves the data from the Archive mailbox for each user to the Azure blob or any other storage service that does not have storage size limitation. I am open to suggestions. Thanks
Mismatch between exchange recipients list and mailboxes set up in 365 Admin?
I'm a little new to 365 administration, so please excuse me if I am being a little thick here. I am looking at a 365 Tenant, there are around 100 licensed users (and therefore around 100 mailboxes allocated), but if I go to exchange admin and look at recipients, there are only 40, including shared mailboxes. My first thought was that perhaps only mailboxes that had actually been used were listed, but I checked one of the "missing" mailboxes in the 365 admin centre and apparently they have 8 Gigabytes of emails in that mailbox. Indeed the same user has three accounts, each with their own license and mailbox (don't ask why, I didn't set this up), I see two of them in the recipients list in Exchange admin. What am I missing?Can I hide user accounts from contact lists?
I'm dealing with a Tenant where for unknown historical reasons users have been given multiple accounts under the same name, but with different mailboxes and different email addresses (same name, different domain). I'm merging the mailboxes together, and aliasing the various email addresses onto the one account, so they only have to deal with one account going forwards. Until the users (and myself) are confident that everything that needs to be transferred from the now defunct mailboxes has been copied correctly I need to keep them there, but effectively inactive, so I gave them another email address which has never been publicised (actually using a spare domain already allocated to the tenant) thinking that it would be safe as noone would be sending emails to an address that never existed before. This all seemed to go swimmingly, until people said they had not received email and I saw they had been sent to the "secret" addresses. What I didn't count on was Microsoft 365 "helpfully" adding these addresses to people's contacts (I'm guessing through the global address book?), so when people (at least people within the tenant) send a new email and look up the details of that person they may get the entry which has the email address I don't want any new emails going to. I've set up forwarding to make sure people receive all their emails in their current mailbox, but I'd really rather they weren't ever sent to the "secret" mailbox in the first place. So is there a way to hide these defunct mailboxes? They are not supposed to be used to send or receive emails at this point, they're just being kept as a backup until we can verify the contents have been merged successfully into the current mailboxes.Exchange changes not propagating back to 365, but only for one account
So, I have a Tenant where, for reasons known only to previous admins, when company rebranding occurred, rather than setting up the new email addresses as aliases on the existing user mailboxes, a new mailbox for the new domain was created each time. As a number of people have multiple accounts with multiple mailboxes which I am currently merging together (using BitTitan MigrationWiz, which seems to be doing its part just fine). Now, for the purposes of this discussion there are three domains olddomain.com (the email domain before the rebranding, emails still get sent to that address daily) newdomain.com (the current preferred email domain) other.com (a domain they purchased and added to the Tenant but are not using, I am using it to park the older mailboxes after their contents have been merged into the current one). My procedure has been 1) set mailto:email address removed for privacy reasons as an alias on the olddomain.com account (for convenience in setting up migrationwiz) 2) Do a pre-stage merge of most of the olddomain.com mailbox into the newdomain.com mailbox 3) In 365 Admin, change the primary email of the olddomain.com account to be otherdomain.com 4) In Exchange, go to what is now the otherdomain.com mailbox and delete the olddomain.com alias from it 5) In 365 Admin, add olddomain.com as an alias to the newdomain.com 6) Finish the merge with MigrationWiz Now this worked apparently flawlessly for 7 people, then I encountered a problem with the 8th Everything went fine up until step 5, when I discovered that despite deleting the olddomain.com alias in Exchange, it still exists as an email alias in the email address removed for privacy reasons account (the one attached to the old maibox) in 365 Admin, so I cannot assign it as an alias to the mailto:email address removed for privacy reasons account Putting things back seems to work fine, changes I make in 365 admin seem to propagate pretty much instantaneously to Exchange, but the opposite is not the case. But so far only with this one account, not only have I executed the above procedure successfully with 7 previous users on this tenant, but I've done it with one more since this problem case popped up (and I've tried the problem case again since that successful operation, thinking it might just have been a glitch) but it still doesn't work. Does anybody have any ideas?Sender Rewrite
Hi, I'm looking at a scenario where a company has two Microsoft 365 tenants for different divisions in different countries. The issue is that they need to be able to have external email addresses with the same domain. Apparently this is a fairly common requirement when a corporate acquisition occurs (though most commonly for a short period until migrations can be done), so it seems it should be possible. There are various options for incoming email that seem to work such as email forwarding between tenants or an external forwarding service like improvMX (though it seems from what I'm reading there may be some DMARC issues associated with this approach?), the issue is giving outgoing email the correct "from" domain. Searching on the subject seems to touch on various possibilities, Exchange Edge Transport Server, SRS in Office 365, and even postfix, but it's all a bit unclear what is current, what is built into Microsoft 365 itself (obviously not postfix) or indeed what actually does what I'm looking for. So I'm hoping to avoid going down too many rabbit holes and dead ends by asking here.
outlook 365 set categories in admin center possible?
Hello, We're using Office 365 we have problems on multiple iMacs with the Outlook app. The colors of the categories sometimes disappear en sometimes different colors are suddenly popping up. It's happening on older iMac as on new ones as well. After a fresh install sometimes it works again for a while but then they'll start disappearing again. Very annoying and more people seem to have the same problem. Now I want to set the categories in the office or exchange admin center, but I cannot find out where I could do this. Hopefully when we set the categories for the whole company, hopefully the problems won't come back again. I think it might have something do also with delegated mailboxes but all people using them have all the rights. We're using the legacy Outlook while the new Outlook does show only a very few of our IMAP folders Hopefull you can help us out here, thanks!
