"Multilingual Internet Mail Format" policy not applying "UTF-8"

Hello,

We have a couple of basic policies configure for the organisation, most of which are working fine. However we have configured the “Multilingual Internet Mail Format” to enforce “Use Unicode (UTF-8)”, however this does not actually apply, it prevents changes by the user, and always sets it to “Use Unicode and prompt”, which I find annoying when it prompts me, as to other users.

All clients are now 8.5, we were previously running an 7.0.3 Domino server, and have also upgraded to an 8.5 server (this was one of the issues I was hoping would be fixed), and the problem persists. We have tried both Explicit policies and organisational policies, but it is determined to set it to “Use unicode and prompt”. Since the 8.5 upgrade we have also tried deleting the settings documents and re-creating etc etc, but it just does not want to work.

I have tried to look for logs etc, but not found anything. If some one can point me in the direction of where there maybe logs or any info that could help diagnose the issue, that would be great.

Cheers.

Subject: A couple of questions…

Hi - Are you seeing other desktop settings going into effect correctly? Problem is only with ‘multilingual internet mail’? I tried this in 8.51 and in 8.5, and it worked correctly for me in both environments. I was able to repeatedly lock and unlock this setting, and to change its value between the various selections. So a few questions…

Can you confirm whether or not this works in isolation in a clean test – with an explicit policy where the user is confirmed (through admin client’s policy synopsis) not to have any other explicit policies, and having first deleted all the contents of $Policies view in the user’s local names.nsf.

Then, when you use the policy to set this to ‘use Unicode (UTF-8)’ – as ‘set value and prevent changes’, and without checking the inherit/enforce checkboxes – you see the setting get locked, but its value isn’t updated correctly? Does it remain unchanged, or get incorrectly set to ‘use Unicode and prompt’? E.g., if you start with the setting unlocked in user’s prefs, and set to ‘use best match’, does it get stuck on that, or change over to ‘use Unicode and prompt’?

Note that this setting should write the following two lines to the user’s notes.ini:

MIMEPromptMultilingual=0

MIMEMultilingualMode=1

Subject: Policies unstable

HiI have a simular experience. I am right now troubleshooting an administrator who only reads some policies. I have locked down some desktop settings and he used to have the settings locked dowm, but now only mail policies have effect on him.

Server is 8.5 HF460, client 8.5 FP1, Policy synopsis tells me he inherits correct organisational policies. We have /O and /OU/OU/O policies. Policy synopsis states he is under both. The /OU/OU/O inherits all settings from /O except a few things.

Deleting policies from the hidden view in personal address book clears them, and shortly after they appear again.

But settings in his client are not locked down.

Mail setting take effect, but desktop does not.

I have locked down “Compress TCPIP” and “Use best match”. But he can change them as he feels.

Restart of client and PC has no effect.

He has role “PolicyReader” in Domino directory - all looks fine, but does not work.

Ideas?

Subject: Some answers… And more questions…

Hi - Are you seeing other desktop settings going into effect correctly? Yes - other settings appear to be OK. I have been testing with the “Internet News Format”. and both the setting and the “How to apply this setting” have been working.

Problem is only with ‘multilingual internet mail’?

“How to apply this setting” for the “Multilingual internet mail format” works fine, it is just the actual value that does not.

I tried this in 8.51 and in 8.5, and it worked correctly for me in both environments. I was able to repeatedly lock and unlock this setting, and to change its value between the various selections. So a few questions…

Can you confirm whether or not this works in isolation in a clean test – with an explicit policy where the user is confirmed (through admin client’s policy synopsis) not to have any other explicit policies, and having first deleted all the contents of $Policies view in the user’s local names.nsf.

We have an organisational policy, I have removed the “Desktop Settings” for this, and created a new policy and Desktop Settings document with just these settings in them, and ensured they are the only policies that are applying to the user.

(What is the best way to access the $Policies view? The only way I could figure it out was to open it up in the designer, then “Preview in Notes”, I’m sure there is a better way I am missing).

Then, when you use the policy to set this to ‘use Unicode (UTF-8)’ – as ‘set value and prevent changes’, and without checking the inherit/enforce checkboxes – you see the setting get locked, but its value isn’t updated correctly?

That is correct.

Does it remain unchanged, or get incorrectly set to ‘use Unicode and prompt’? E.g., if you start with the setting unlocked in user’s prefs, and set to ‘use best match’, does it get stuck on that, or change over to ‘use Unicode and prompt’?

It changes back to Unicode and prompt.

Note that this setting should write the following two lines to the user’s notes.ini:

  MIMEPromptMultilingual=0

  MIMEMultilingualMode=1

With the above information I have figured out the following:

Before starting notes I looked in the notes.ini and the settings were there as you have mentioned. After starting notes, the 2 option were deleted - ie: not blank/changed, the options were no longer in the ini file.

When sending a multilingual email, it prompts me, and I say UTF-8 and check “don’t prompt me again”. At this time the setting in notes.ini is updated.

I exit notes, and the setting is deleted during the next load of notes.

Running “ndyncfg.exe” while notes is active (to update the policy) does not appear to change the ini at that point in time. However the status bar does say “Notes configuration settings have been refreshed”.

It does not appear to be an issue for all users, just some. I can’t see a common factor at this point (it maybe ones who have upgraded the client, but not 100% sure).

Not sure if any of that helps???

Thanks very much.