Scenario: Anyone using MCAS, Conditional Access, Window 10 Endpoints and Google Chrome.
Challenge: How do you get Google Chrome to be recognised by Azure Conditional Access policies.
Issue : Azure Sign In’s, by default will not see Google Chrome as Azure AD Joined.
Browser = Chrome & Joined Type = [Blank]
However, by default Microsoft Edge does report as Azure AD Joined
Browser = Edge & Joined Type = Azure AD Joined
Solution : chrome://extensions/
Conditions in Conditional Access policy – Azure Active Directory | Microsoft Docs
“For Chrome support in Windows 10 Creators Update (version 1703) or later, install the Windows 10 Accounts extension. This extension is required when a Conditional Access policy requires device-specific details.
To automatically deploy this extension to Chrome browsers, create the following registry key:”
Type REG_SZ (String)
Or Add manually
Extension now appears for Windows 10 Accounts show below
Then the next Azure/265 Sign in with show Azure AD Joined using Google Chrome
We have and RDS cluster everythings is working fine.
We use roaming profiles, redirection to a share is working as well.
When a user logs on to any RDS node we can see a user folder appear in E:\Users\ of the RDS Server.
When I checked the registry, and i can see 2 keys about profiles :
– you can see that the redirection is OK : Centralprofile (in my exemple \\Sharename\…)
– you can see a ProfileImagePath to E:\Users
So what is :
– A ProfileImagePath ?
– A CentralProfile ?
E:\Users\<username> is the local cache of the roaming profile. I’ve never seen a setting to avoid caching of the profile on the local system entirely.
There is a group policy setting to automatically delete the cached copy upon user logout. It’s under Computer Configuation->Policies->Administrative Templates->System->UserProfiles->Delete cached copies of roaming profiles.
Plus side : This avoids disk space from caching the users profiles
It will probably increase the logon time as the full profile will have to copy every time.
When testing, this also cleared out the cache from a custom application which didnt right back to the roaming profile.
Tested on Windows 2008 R2
Create a GPO – “Add the Administrator security group to roaming users profiles”
Computer Configuration > Policies > Administrative Templates > System > User Profiles” and applied to Windows XP / 2003 or later.
This setting adds the administrator ACL to the users roaming profile path on the server when it is first created.
Administrator are able to view users profiles without the need to take ownership
Enable this option as soon as possible as this setting does NOT apply retrospectively to existing users profiles as it only applied the administrators group to the profile when the roaming profile when it is created on the server for the first time.
Original detail posted by Alan Burchill