We are rolling out Windows 10 1709 to our end user community. But we are running into some issues with some users where when they run outlook (v2013) for the first time they are prompted to choose a profile even though they have never logged into these computers (physical boxes before). They were previously on Windows 10 1607 computers before. I am pretty sure that EM is pulling in this outlook email profile data from personalization. Because if I do a personalization analysis and clear their profile data or office data it mitigates the issue. That being said I would prefer to automate something that will runonce on windows 10 1709 (brand new pc) that will remove all their Personalization data as some logon action in the config. Does anyone have an Idea if this is doable? We are on EM v10 fr 4.
stebo There's not really a way to do exactly what you're asking. There are some potential options, but I'm a little confused. First, if they already have a personalization profile, why wouldn't you want the users' settings to follow them to the new endpoints? That's kind of the point of personalization. Second, is the Outlook profile issue the only issue? If so, check out the following articles:
Hello Randy ...thanks for the reply. To add some context to your questions. #1 why wouldn't we want the settings to follow if they already exist? That would be great but in this particular use case for a reason I have not figured out yet. If (some users) in our environment go from windows 10 v1607 with office 2013 to windows 10 v1709 (new image on the same pc) they login to outlook first time and outlook prompts them to choose a profile and that setting has never been configured by them....and in some cases they choose the profile that is available and get an error that says Outlook Cant start. In that event I clear the office settings from the personalization database and the are ok to fire up outlook. #2 Is Outlook the only issue in this case? the answer is yes. I am looking at the articles you sent the second one with the ps script might have some potential but my concern is that it might not work because the issue occurs at application start of outlook. Is appears Application Personalization kicks in and presents the issue. I can tell this because I can also mitigate the issue (sort of) by stopping the user virtualization server prior to starting outlook. But as soon as I close outlook and restart it the next time the user starts outlook the issue is back
stebo This sounds like the EXACT issue I had with another customer. Below I'm sharing some of the case notes from that incident. Check to see if this is what you're experiencing. There are suggested resolutions for the issue, but if you don't feel comfortable with doing those on your own, I would recommend opening up a support ticket and reference this information.
----- SUPPORT INCIDENT NOTES -----
Further to our conversation, it appears that you are seeing the following known issue:
Essentially the problem occurs as follows:
- The DefaultProfile value was at some point included in the application group.
- While included, the value was deleted, causing an 'R.I.P.' value to be created within the FBR file.
- This marks the value as ready for cleanup.
- The value is excluded from the application group before the RIP value is cleaned up.
- After this point, when personalized Outlook launches it is unable to read the DefaultProfile value from the real registry (which is managed by the 'Mail Profile and Signatures' Windows Personalization group).
There are a number of potential solutions to this issue:
- As the DefaultProfile value is now excluded, we would not expect to see any new RIP values get created, so the simplest solution would be to clear up the RIP values manually from each of the affected users (I believe there are less than 10 at present).
This can be done either through Personalization Analysis, or by installing FBR explorer on the endpoint and opening the file found here:
NOTE: Another way to do this is using the PersInfo tool, which can be found here:
Simply run PersInfo in the affected users' session, right-click the PersInfo systray icon and select "Manage Applications". Once you are in here right-click the Office 2016 group and select "Force Cleanup", which will clean up any data which resides in an excluded path.
- It is possible to manually set the "DefaultProfile" value to a specific string using a 'Set Value' EM policy action.
When a set value action is configured under a 'Process Started' node for office, it will by default also set the value in the virtualized (FBR) registry.
NOTE: Unfortunately there is a known issue that means this feature does not work until 10.1 FR2, so this may not be suitable without upgrading:
- This issue should no longer occur when utilizing the new Native Hiving feature of v10.
This is a global change (which will apply to all users who connect to the Personalization server) which cannot be reverted without rolling-back your database to a previous backup, so we would not recommend implementing this without thorough testing and a rollback plan.
Randy thank you for this information. I have forwarded it to our TAM. We will start taking a look into it this week! Thank you again!!