Additional Microsoft 365 users not showing as registered users on an Entra ID joined device.
Most of our clients are on M365 these days, and they consist of the following variations in how they integrate: On-prem AD with no Entra ID sync to M365. On-prem AD with Entra ID sync to M365 but no hybrid connection for devices. On-prem AD with Entra ID sync and hybrid connection for devices with Intune. No on-prem AD with all devices connected directly to Entra ID and Intune. For clients using integration methods 1 and 2, we always see multiple device registrations in Entra ID, and for clients using integration method 3, we see a primary user that was used to hybrid join the device, along with additional users showing up as registered in Entra ID. However, we have just recently discovered that clients that use method 4, i.e. they are 100% Entra ID with no on-prem AD, the only user that shows in Entra ID is the user that joined the device. Any other use that logs in and creates a profile on one of these machines is not recorded as a registered user in Entra ID for that device. So, for clients that use integration methods 1-3, if we want to remotely block access on a particular device for a specific user, we just need to delete their Entra ID registration for that device. However, for clients using method 4, we have no visibility for the additional user, nor can we remotely block a user in this scenario. Is this behaviour a current bug in the Entra ID join/register process? Or is this the expected behaviour? If the latter, then this seems to be a flaw in the join/register process.
Entra hybrid join and devices in dual state
Hello, to test hybrid join, I created a lab that reproduces what we have as resources, like domain controller, notebooks and Microsoft 365 accounts and software; initially, we have all our notebooks registered as Entra registered because users have installed and configured the Office and Teams apps on their devices; with Connect agent in advanced mode, I then synced the various notebooks I had in the OUs and therefore obtained the various Entra hybrid joined devices; doing this way, I have the classic case of devices in dual state: I waited a few days as was suggested in the documentation, but nothing happened: in this case, how can I proceed? read other posts and did some tests, for example deleting the Entra registered device: in this case by restarting the notebook, when I try to launch Teams or an Office app I am asked to enter the user, or the user is incorrect and I have to sign out from the app and then sign in; Could I have problems with Outlook and all the mail I have on my devices? Is there any other solution? Another thing I noticed is this: the Entra registered device still presents some data such as the Owner, the User principal name which instead on the device in Hybrid join have as values, N/A and None respectively: in these cases, the the first is seen as a personal device and therefore this data is there and the second is seen as Corporate? Any suggestion is appreciated. -- Regards
O365 Email Migration to Another Tenant while Deferring Migration of Sharepoint files
Hi, This is the context: ChildCompany has O365 and it has an Azure AD in hybrid mode synchronizing to a on-prem AD server. They have an internal domain ChildCompany.com, and an external domain ChildCompany.com where they also receive and send email using O365. ParentCompany is going absorb the ChildCompany some time in next year, and I was asked about the integration options. According to this https://download.microsoft.com/download/b/a/1/ba19dfe7-96e2-4983-8783-4dcff9cebe7b/microsoft-365-tenant-to-tenant-migration.pdf I could do a phased migration, where the end state is that they decomm their onprem AD and that they only use our ParentCompany systems. The business requirement is to start their integration with Email, and then in later phases do the Sharepoint integration as that requires way more analysis on their data sources, as they also have wikis and many other on prem legacy stuff. They are less than 50 users, so I can use Quest migration tools for the email part, but I wonder what needs to happen in what order. This is what I have in mind: Migrate their current O365 into our ParentCompany Office 365 subscription, so that they can continue logging in into their domain joined windows machines using childCompany.co, so they start using ParentCompany.com email addresses, but the problem then is how can they continue using their sharepoint and onedrive resources associated with the Azure and local domain at ChildCompany.com? This is more or less what I have in mind, for the intermediate step, the cutover: Child Company ParentCompany --------------------- ---------------- On-Prem | MS Cloud: | MS Cloud: ---------------|----------------------|-------------- Local AD (ADFS)| Azure Subscription | Azure Sub | Azure AD | Azure AD |--------------------- |--------------------- | O365 Sub -> | O365 Sub | Exchange mailboxes-> | Exchange mailboxes | Sharepoint? -> | ??? | -------------------- |--------------------- I wonder how could it be possible to defer the sharepoint and onedrive migration, so that the child company users can still work on their sharepoint files using their normal auth methods, while disabling childcompany.com as MX so they start using ParentCompany.com mailboxes.Is that even possible? Would make more sense to try to migrate everything at once? That is way more work, but I'm weighting my options.Outlook Modern Auth not working
I am still being affected by this and I have a mix of users with the reg key and without https://techcommunity.microsoft.com/t5/identity-authentication/modern-auth-looping-with-outlook-2016-when-outside-corporate/m-p/280804 We are a 300 person Firm all working remote and the last thing I need is for Outlook to act all screwy. Has anyone fixed this? is this a bug? Has Microsoft stated what the actual fix for this is? WIndows Build 1903 18362.657: Outlook for O365 16.0.11929.20586 Just to recap I have user with and without the reg key in the post above and were still having the issue. Has anyone solved this?
M365 Apps for Enterprise - Shared Activation
Hello all, I'm hoping someone can share some insight to help me out here. Recently we started receiving calls that users who log in to our conference room PCs, and Office files from OneDrive are read-only and there is a warning icon near their name at the top of the window. In looking at this we realized that Shared Activation was not enabled for these machines. We have since gone ahead and enabled Shared Activation via group policy. Now that Shared Activation is configured, it seems like every user who logs in to those conference room PCs is asked to sign in to authenticate to activate. This is a cumbersome process for our end users. We've got Azure AD Connect configured in our environment with Password Hash Sync and the Enable SSO checkbox checked. My expectation is that with Azure AD SSO enabled, the Office Apps would just SSO to activate similar to the way all of the other (non-shared) PCs do it. Is there something I am missing? Thanks SteveIf ADFS service is down, Azure Traffic Manager does not respond about it
We have configured ADFS Farm. There are 2 ADFS Servers. There are 2 WAP Servers. There is 1 Azure Traffic Manager which interacts with WAP servers through endpoints. If WAP service is down in any WAP Servers, Azure Traffic Manager responds about it. But If ADFS service is down in any ADFS Servers, Azure Traffic Manager does not respond about it. How to make it respond if any ADFS Service is down? I will appriciate your response. Thanks.Please provide Production Support Guidelines for ADFS and SSO with Office 365
Hi Team, Please provide Production Support Guidelines for On-Premises ADFS Farm (windows 2016 servers) and SSO with Office 365 to prevent downtime. What should be some standard measures need to be performed to manage ADFS, WAP Servers and SSO with Office 365? We are using 4 VMs of version windows server 2016 for ADFS Farm and WID database. What should be backed up and frequency of backups? Thanks a lotAdd Support for Multiple Domains for federation with O365
Hi Team, We currently have ADFS (ADFS is running on Windows 2016) in place for around 100 users auth to 365 using a single domain 'domain1.com', we have federated it and enabled SSO. We now need to federate additional domains - 'domain2.com and domain3.com' The new domains have been added and verified in 365 so now show as managed domains The original domain1.com did not have the -supportmultipldomains switch used when it was converted to a federated domain. What do we need to do here? Should we remove the Microsoft Online trust from AD FS federation server Management Console? and then update original domain . Though, i assume it will be done during non-business hours. Password synch is enabled and we do not want to change passwords of users. What will be the Impact on 100 or more current users of The original domain1.com, if we delete the Microsoft Office 365 Identity Platform entry from our AD FS federation server Management Console? Please explain the impact on the Production Users. Thanks!
On-prem Exchange needed for Azure AD Connected MS365 users with a mailbox?
We have an on-prem active directory with users synced to MS365 for their Office 365 logins. Works great. We used to use Zimbra for email, so no Exchange server in sight. We now want to add mailboxes to the users MS365 accounts, and want to confirm if we NEED a full-blown on-prem Exchange 2016 server with a free hybrid config license just to manage things like email addresses, aliases, and other user attributes that are sourced from active directory? I have done this a few times for sites that already had Exchange, but what about MS365 tenants that never had an Exchange server? I guess it's close to Scenario 2 in this article, just want to confirm what is the absolute minimum we should be trying to get away with when adding this to a site with no history of Exchange? Windows 10 and Exchange Management Tools looked like a plan, but that doesn't include Exchange Admin Centre, only EMS and Exchange Toolbox. Is this article still the current situation: https://docs.microsoft.com/en-us/exchange/decommission-on-premises-exchange Best, Kevin
