Client 8.5 / Servers 6.5.6+8.0.2+8.5
we updated our organisational policies, mostly just added a new mail settings entry to the existing policy. we locked a couple of settings, and these seemed to work the first time around but if we make changes to the policy they’re not getting applied (or at least 99% of the time they aren’t, every now and then they seem to kick in).
the policies come down correctly, i can check the document properties fields and they match the values in the current polices. policy synopsis shows the correct values (although it never seems to show locked items).
i cleared the $DPLocked field from the CalendarProfile profile and the settings unlock but the values themselves still wont update from the policy.
i deleted all documents in the ($Policies) view and let them download again, the values in them are correct but still wont apply. i’ve run ndyncfg manually while notes is open - does nothing, doesn’t even pull down the polices (server access seems to fix that though)
i’ve tried the above against a 6.5.6 server (current production), an 8.0 and 8.5 (test) servers by changing my home server both in my person document and location and it won’t update. the mail template is 8.5 (i’ve tried 6.5.6, 8.0 and 8.5) with no difference seen.
are there other fields/profile documents that can be cleared/deleted to get this to actually update? ie there must be some way to reset the dynamic client config so it thinks everything is new and will apply the settings? or a way to force the application of policies?
i’ve also tried this against a newly created explicit policy assigned to myself with the same end result, values are not updated.
Subject: Adminp
Hello Raymond,
Mail policies are stored in the user's mail file by adminp. Adminp will do this periodically or you can force the issue via the server command "tell adminp process mail".
This is covered in the Pocliy FAQ: http://www-10.lotus.com/ldd/dominowiki.nsf/dx/domino-policies-faq
See the section entitled: How often are mail and Traveller settings applied?
Let me know if this fixes your issue.
Regards,
Mark
Subject: all settings not being applied, not just the mail ones
i’ll reset myself back to an 8.0.2 server (i presume 6.5.6 cant update mail policies) and retest by forcing adminp to run (we only have about 20 pilot users atm so it shouldnt be an issue)
in regards to the other policies though, none of those settings are being applied any more, eg the desktop policy has a LocAllDirectoryServer set, which i can see the value in the effective policy documents in the personal address book but that is not being applied, nor locked anymore.
i’m not sure if i screwed something up during the testing when trying to figure out why they werent working and got them out of sync but there must be some way to reset the entire dcc/policy thing from a client perspective - without doing a new install.
update: focusing just on the mail settings was causing my issues, one of those forest/tree things.
i had enforced some settings in org policies which was why they werent updating from the explicit. i’ve re-saved all the settings documents and running adminp it seems to have reset whatever the other issue was and the client is picking up and applying all the policies, including mail, correctly now. with settings being lockable/unlockable and changeable.
Subject: So then you’re all OK now? (EOM)
Subject: no
we were but then we tried on another users while were in our team meeting, just to show everyone how it all worked.
we setup the policy with a 96 hour soft deletion, deleted all the clients policy documents (from the $Policies view) and got it to download again (tried manually running ndyncfg but if was not helpful, had to restart the client to get them to come down), once they were down the document properties showed the 96 hour value. we then ran the adminp task to apply the mail policy tot he users mail file (this is an 8.5 server with an 8.5 client, 8,5 nab and 8.5 mailfile) and replicated.
value was locked and set to 96 so all looked ok.
we then went back and changed the policy to 72 hours and ran adminp again to apply, replicated and checked - still at 96 hours. we tried several times with different values but they never updated from 96. it’s like it can sometimes somehow get stuck once its applied the first value.
we’ve raised a pmr so i presume they’ll look at it from there but if any of the above was incorrect or we missed something please let me know.