fighting for truth, justice, and a kick-butt lotus notes experience.

Domino 8.5.1 Update of Policy Settings is broken

 April 25 2010 04:08:55 PM
Wie ich in dem letzten Post bereits geschrieben habe, gibt es bei Verwendung von 8.5.1 ein Problem, was die Aktualisierung von Policy Einträgen auf dem Client betrifft.

Nach dem Update auf 8.5.1 (Anfang diesen Jahres) hat ein Kunde festgestellt, das User immer noch alte Policy Settings benutzen. Ein Blick in die versteckte ($Policies)-View im privaten Adreßbuch auf den Clients bestätigte dies. Zum Teil waren hier noch seit Wochen veraltet Settings aktiv.

Die bekannten Workarounds wie zum Beispiel sämtliche Dokumente der $Policies View auf dem Client zu löschen, führen zu keinem Ergebnis. Die Clients bekommen keine neuen Settings. Eine Änderung der Policy oder von Settings im Domino Directory führt ebenfalls zu keinem Update der Settings auf dem Client. Erst die Bearbeitung & Speicherung des Personendokuments führt zu einer Aktualisierung der Policys auf den Clients.

In einer neuinstallierten Testumgebung Domino 8.5.1 FP2 und Notes Client 8.5.1 FP2 ist dies reproduzierbar.

Es gibt einen sehr informativen Domino Wiki Eintrag, der beschreibt wie das Update der Policy Settings funktioniert:

"How do policies get pulled and applied on the client?

When the client authenticates with the users home server, it sends over a hashed value that indicates what policy information it thinks it has stored locally.  The server calculates a similar hashed value for what it thinks the client should have.  If those values do not match, then the server tells the client that it need to refresh it's policies.  At this point, the client launches the dynamic configuration process, Dyncfg.exe, passing it flags on the command line that tell it to pull policies.  Dyncfg uses the NAMEGetPolicy API, which asks the server to calculate the effective policy for the user, and then stores the effective policies locally in the clients NAMES.NSF database.  You can see your locally cached policy documents by opening the hidden $Policies view (via Ctrl-Shift View\Go To).  After pulling and applying the policies to the client, Dyncfg stores off the new hashed value that it got from the server, to be sent back to the server during the next authentication, which starts this whole process over again. 

So what info is encoded in this hashed value?  Previous to R8.5 and dynamic policies, it was simply the last modified time of the $Policies view in the server's NAB.  With the introduction of dynamic policies, the hash was expanded to include any group or user names that caused a policy to be assigned to the user, as well as the last modified time of the $Policies view.  So, if any policy info changes on the server, or the user is assigned to any new groups that cause a policy to be assigned to them, then the hash will change which will trigger the client to pull new policies.  Note that on the Domino server, we rely on the Update task to update the views in the NAB once per minute.  If this doesn't happen, then the $Policies view won't get updated, the code won't know anything has changed, and no policy changes will get pulled to the client.  This is a very common cause of policy problems on test machines. "

(http://www-10.lotus.com/ldd/dominowiki.nsf/dx/domino-policies-faq)

Mit 8.5.1 scheint der Domino Server den Hashwert nicht mehr korrekt zu berechnen. Bedingt durch die Einführung der dynamischen Policys ist es notwendig das der Hashwert Serverseitig pro Benutzer berechnet werden muß, da die Gruppenzugehörigkeiten für dynamische Policys mit berücksichtigt werden müssen. Der Server scheint nun diesen Hashwert pro Benutzer zu cachen. Nach einem Server Restart griffen nämlich sofort die geänderten Policy Settings auf dem Client.
Nun kann man natürlich nicht immer den Server restarten, damit die Policy Settings auch wirklich greifen. Abhilfe schafft die Ausführung eines manuellen Updall-Befehls auf die $Policies View.

Wird nämlich

load updall names.nsf -T "($Policies)" -R

ausgeführt, wird als Nebeneffekt der Hashwert serverseitig neu berechnet und die Clients erhalten sofort die neuen Policy Settings.

Meine Empfehlung ist es periodisch über ein Server Programmdokument einmal in der Nacht die $Policies View neu aufbauen zu lassen, und somit sicherzustellen das alle Clients spätestens am nächsten Tag aktuelle Policy Settings erhalten.

Update 25.05.2010: Wird mit 8.5.2 gefixt sein.
Kommentare

1Hans-Josef Paffenholz  01/14/2011 10:19:39 AM  Domino 8.5.1 Update of Policy Settings is broken

Hallo Herr Poettgen,

welches 8.5.2 Version ist gemeint, das diesen Fehler fixen soll? Das für den Server oder für den Client? Unser Domino läuft auf 8.5.2 aber irgendwie zieht er sich nicht die Richtlinie, wenn etwas geändert wird, nicht. Und da die names.nsf der Clients im Home-Share liegen, ist ein Neuaufbau der $Plolicies View sehr mühsam. Zudem wurde auch nach der Durchführung des oben genannten Befehls "updall" mit einem Testaccount die Richtlinie nicht gezogen. Ich frage mich, wann er die Richtlinie zieht bzw. was muss bei Änderung einer Richtlinie beachtet oder abgearbeitet werden, damit alle Benutzer, die an die Richtlinie gebunden sind, diese auch nochmals neu zugewiesen bekommen. Für eine Rat wäre ich Ihnen dankbar. Lieben Gruß

Hans-Josef Paffenholz

  •  
  • Hinweis zum Datenschutz und Datennutzung:
    Bitte lesen Sie unseren Hinweis zum Datenschutz bevor Sie hier einen Kommentar erstellen.
    Zur Erstellung eines Kommentar werden folgende Daten benötigt:
    - Name
    - Mailadresse
    Der Name kann auch ein Nickname/Pseudonym sein und wird hier auf diesem Blog zu Ihrem Kommentar angezeigt. Die Email-Adresse dient im Fall einer inhaltlichen Unklarheit Ihres Kommentars für persönliche Rückfragen durch mich, Detlev Pöttgen.
    Sowohl Ihr Name als auch Ihre Mailadresse werden nicht für andere Zwecke (Stichwort: Werbung) verwendet und auch nicht an Dritte übermittelt.
    Ihr Kommentar inkl. Ihrer übermittelten Kontaktdaten kann jederzeit auf Ihren Wunsch hin wieder gelöscht werden. Senden Sie in diesem Fall bitte eine Mail an blog(a)poettgen(punkt)eu

  • Note on data protection and data usage:
    Please read our Notes on Data Protection before posting a comment here.
    The following data is required to create a comment:
    - Name
    - Mail address
    The name can also be a nickname/pseudonym and will be displayed here on this blog with your comment. The email address will be used for personal questions by me, Detlev Pöttgen, in the event that the content of your comment is unclear.
    Neither your name nor your e-mail address will be used for any other purposes (like advertising) and will not be passed on to third parties.
    Your comment including your transmitted contact data can be deleted at any time on your request. In this case please send an email to blog(a)poettgen(dot)eu

Archive