During session launch Citrix Profile Management Service identifies if the user should be processed and also determines the path where the User Profile is stored.
If the Policy contains any variables in the User Store profile path, these will be completed at run time. During the logon process a delay occurs for hostname resolution of the profile share during the lookup phase for the user profile path.
Apply the below registry changes on the VDI:
HKCUsoftwaremicrosoft to enable its inheritance (right click -> permissions -> advanced, click ‘Enable inheritance’, click ‘Apply’ and ‘OK’)
This setting have been identified to fix the Office 365 shared licensing activation.
The code fix has already added to LTSR 1912 CU1 & CU2 and later current releases. The issue only exists for profiles that are created by 1912 RTM UPM.
So if we logon a brand new account, there should be no issue for 1912 CU2.
For existing users whose profiles were created using 1912 RTM, we should delete both local profile and userstore profile for problematic accounts and logon again (then those account would be like brand new accounts without profiles) , which will also resolve the issue.
This is due to the discrepancy on how to handle the situation of partial success in enumeration(meaning some sites return success, but some return failures), initially we decided to show end users as much as possible, thus in your customer deployment, the user vdi were enumerated even though the enumeration in other DDCs(where user logon is not allowed) failed. But later we decided to at least prioritize the authentication failures, that’s why it fails the entire enumeration.
So with 3.12 the behavior of adding all DDCs for user to logon is expected, if that’s not acceptable, you can suggest customer to configure user mapping, so enumeration for a particular user shall only contact specified sites/DDCs.
Users logging in with company credentials – commonly referred to as SAML or Single Sign-On – will now have an updated first-time login experience based on the account and user configuration.
If the account or user falls into one of the following 3 configurations, the user(s) will be auto confirmed on creation. This means that instead of going through a user activation flow during their first time logging in to ShareFile, they will be taken directly into the application.
1. If Require SSO Login is set to ‘yes’ within the Single sign-on / SAML 2.0 Configuration section under Admin Settings > Security > Login & Security Policy Page then users that do not have any admin permissions will go directly into the application upon first login and skip the user activation flow. Anyone with an Admin permission within ShareFile will still need to go through the traditional user activation flow.
2. If the following two items are ‘true’ then the end user will go directly into the application and skip the user activation flow:
- Enable SAML is set to yes and the administrator on the account and successfully configured a SAML Identity Provider
- The end user is an employee user and does not have permission to ‘Change his/her password’
3. If the admin has called into ShareFile support and enabled their login page to redirect to their SAML login page, then all users will go directly into the application upon first time logging in and will skip the user activation flow.
- Note, when this is configured, all users will be taken directly to the accounts SAML login page instead of the ShareFile split screen login page – this includes admins and client users which means everyone must be in your Active Directory if you want them to login. Please speak with a ShareFile representative to discuss any draw backs of enabling this login page on your account.
What does this mean for my end user?
This means that if a user falls into any of the above three configurations, either based on the account configuration or how you configured the user’s permissions, then upon first time logging into ShareFile they will skip the user activation flow, as depicted via the screenshots below, and will instead be taken directly into ShareFile.
In the case where the employee is auto confirmed, then they also will not receive a welcome email if created directly via the API or User Management Tool. It is expected that the administrator either sends their own welcome email, or does a bulk welcome email resend from within the ShareFile Web Application. If the user was created from within the ShareFile Web Application, you can still choose to send a welcome email, though the activation link in the email will take the user directly to “https://[subdomain].sharefile.com”, and they will be able to log in with their Active Directory credentials immediately.