Interface Views in Microsoft 365 Admin Center
1. Simplified View Purpose: Designed for small businesses or organizations with limited IT resources. Features: Streamlined dashboard with essential tasks like user management, license assignment, and password resets. Minimal configuration options to reduce complexity. Quick access to support and basic service health info. Use Case: Ideal for admins who need to perform routine tasks without diving into advanced settings. 2. Dashboard View (Advanced View) Purpose: Tailored for medium to large enterprises with complex IT environments. Features: Full access to all admin centers (Exchange, SharePoint, Teams, etc.). Advanced analytics, reporting, and configuration tools. Role-based access control and security management. Customizable widgets and navigation for personalized workflows. Use Case: Suitable for IT teams managing multiple services, users, and compliance requirements. Customization Needs Are there specific tasks we perform frequently that can be automated in the dashboard?
Org Explorer - Issues
Hi, I have a weird issue, We have a user that has gone crazy on Org Explorer. Basically this person is showing that she has 926 Reports, and 7 Direct. Our company only has 120 Users. Also a every couple of seconds this users Reports keeps increasing :s I have checked on Exchange, this user has only 1 Manager and 7 Direct, same data is also showing on Entra. Anyone have a clue ?MTO and access to on premises file system
Let me preface this by saying I'm still fairly new to 365 Admin (it's been a steep learning curve) and haven't even got my feet wet with on premises stuff as yet. Also, I think some of the admin decisions made previously by others may have been based on just repeating what was found to work the first time rather than necessarily a deep understanding of the best solution. The situation when I arrived on the scene was this (actually it was a bit more complex and messy than this, but this simplified description covers the salient points at this stage) One tenant, with two domains, call them old-domain and new-domain. Two types of user, who I will refer to operations and corporate. An on premises Active Directory system running a file server. Well to be more precise on three premises with mirroring of data and a DFS, but from the user perspective when you're one of the office locations and connect to the network the same folders are available to you. Everyone was using Azure Joined Company Laptops to do this, so their laptop logins were also their network logins. Outside of the offices people connected to the DFS using a VPN (with three gateways in different countries). Operations Users had one account, @old-domain, this was licensed for 365 and had a mailbox associated with it. It was also synched to their on premises AD account Corporate Users had two accounts, one @old-domain with no license, synched to an on premises AD account. The second was new-domain with a 365 license and mailbox. If you're scratching your head wondering why two accounts rather than assigning the new-domain email address to the same account, I can't give you a definitive answer as I've never been given one, but for whatever reason when new domains were brought into play on corporate name changes the admins gave them new mailboxes rather than simply aliasing email addresses to the same mailbox (some people had three accounts as a result). What I did note was that when a new Corporate user was added the admins gave them both of the above accounts, I was told that the unlicensed old-domain one was required for the access to the DFS. Now for reasons not worth getting into here, a decision was made to move the Corporate users to a new tenant, along with new-domain and then to link the two tenants in a multi-tenant organization. It was also decided to leverage BYOD for Corporate users, so their devices will only be Azure registered. This has been done, there was some pain thanks to the reluctance of Microsoft applications to switch to the new account locations rather than redirecting back to the old tenant, but that's been sorted. So right now Corporate users still have two accounts, but on two tenants. On the Old Tenant they have their @old-domain account, no license, no mailbox, synched to the on premises AD (as before) On the New Tenant they have their new-domain account. This is where they actually do their work, and is the only account anyone should be communicating with internally or externally. Access to the DFS is being done using the VPN with the on premises credentials associated with the old-domain account. In terms of functionality, this works perfectly well, people across the two tenants appear in each other's address lists, they can chat and share information etc. Everybody also has access to the folders they should have access to on the DFS. However there are two issues. The first, and most detrimental in terms of just getting work done is that users in one of the overseas offices have found their access to the DFS has slowed considerably, despite being in physically the same location as the data. I believe the problem is that although the data is on-premises, the VPN gateway is not, therefore data does a round trip from the server, through that gateway IP address at the ISP and back to the user. Since they are in a remote location with poor internet this slows things considerably. So the first question is, how do we take that loop out of the equation so that when they are in the office they connect more directly to the servers on site? Ideally without having to revert to needing an Azure AD joined device. The second issue is that those remaining old-domain accounts (the ones for the Corporate users who are now working on the new tenant) on the old tenant are messy, in two ways 1) From an admin perspective, because every one of those corporate users still has two accounts, their local one that is synched to On Premises AD, and the the external account shared from the new tenant as part of the MTO 2) From a user's perspective. For reasons that I cannot fathom (but this is coming direct from Microsoft after many attempts on my part to find a way) it seems that while you can control which licensed accounts appear on Teams search by controlling whether they are in the GAL and setting the appropriate switch in Teams Admin, all the unlicensed users appear whether you like it or not. The net result is that when someone on the old tenant starts typing in a name of someone in Corporate, they get two suggestions coming up. So the second question is, are those accounts actually necessary?
O365 SSPR require users to register when signing in
Hi Everyone Can someone please shed some light on this. In Azure SSPR under password reset>registration> require users to register when signing in Yes or No. Below is MS website explanation. Does that mean if I set it to Yes, if users go to office.com they are prompted to register in SSPR? What are the down side of choosing no, You can enable the option to require a user to complete the SSPR registration if they use modern authentication or web browser to sign in to any applications using Microsoft Entra ID. This workflow includes the following applications: Microsoft 365 Microsoft Entra admin center Access Panel Federated applications Custom applications using Microsoft Entra ID When you don't require registration, users aren't prompted during sign-in, but they can manually registerEntra ID Allows People to Update their User Principal Names
Entra ID allows unprivileged users to update the user principal name for their accounts via the admin center or PowerShell. It seems silly because no justification for allowing people to update such a fundamental property is evident. Perhaps Microsoft has some excellent logic for allowing such updates to occur, but blocking access seems like the right thing to do. https://office365itpros.com/2025/01/24/update-user-principal-names/Force change password at next login on-premise and MS online
Hi Currently, I have a hybrid environment with AD on-premise, Azure AD sync (with password hash & SSPR), and Exchange Online. My goal is to force change the password at the next login from on-premise AD to MS online and vice versa. It's working. When I change the password on-premise AD, MS Online prompts me to change the password. It is not working when I set the account from the Admin center to force the password change at the next login; it does not sync to on-premise AD. The domain computer will not prompt to change password. Thanks in advance MS recommend to try this Install-Module -Name Microsoft.Graph Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All" Then run this command. $OnPremSync = Get-MgDirectoryOnPremiseSynchronization $OnPremSync.Features.UserForcePasswordChangeOnLogonEnabled = $true Update-MgDirectoryOnPremiseSynchronization -OnPremisesDirectorySynchronizationId $OnPremSync.Id -Features $OnPremSync.FeaturesSelf Service Reset password (SSPR)
Hi I have an odd situation with random users. When SSPR is enabled for them, they cannot login email on their iPhone corporate Intune device, is pushing the login to conditional access trusted locations blocked. Email works just fine with SSPR disabled. Anyone experience something similar.ForcePasswordChangeOnLogOn
Hi, I have a Hybrid environment, AD on-premises, Azure AD connect and Exchange Online. Currently using SSPR. Are there any risks enabling ForcePasswordChangeOnLogOn? This won't impact the current accounts to change password? get-adsyncaadcompanyfeature PasswordHashSync : True ForcePasswordChangeOnLogOn : False UserWriteback : False DeviceWriteback : False UnifiedGroupWriteback : False GroupWritebackV2 : FalseSSPR at the windows sign-in screen by creating a device policy in Intune
Hi We are gradually deploying SSPR at the windows sign-in screen by creating a device policy in Intune. Option B mentioned in this article is to deploy a registry. My question is, does the registry get deployed with the Intune device policy? Because I have the registry below and I did not add it. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount "AllowPasswordReset"=dword:00000001
