Domino 8.5.1 Update of Policy Settings is broken

Detlev Poettgen  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 [2]