Dieses Problem lässt sich mit einem notes.ini Eintrag auf Serverseite lösen. Der Eintrag
iNotes_WA_FirefoxSignedScript=0löst zumindest dieses Problem, und mit einem aktuellen Firefox kann wieder Mail versandt werden.
Archive for: ‘April 2013’
Firefox 20 vs iNotes 8.5.x
Domino 8.5.x unterstützt aktuelle Versionen des Firefox offiziell leider nicht. Versucht man trotzdem mit Firefox 20 "gegen" iNotes von Domino 8.5.x zu arbeiten, funktioniert leider der Senden Button nicht. Beim Klick erfolgt keine Aktion.
Dieses Problem lässt sich mit einem notes.ini Eintrag auf Serverseite lösen. Der Eintrag
Dieses Problem lässt sich mit einem notes.ini Eintrag auf Serverseite lösen. Der Eintrag
Firefox 20 vs iNotes 8.5.x
Domino 8.5.x unterstützt aktuelle Versionen des Firefox offiziell leider nicht. Versucht man trotzdem mit Firefox 20 "gegen" iNotes von Domino 8.5.x zu arbeiten, funktioniert leider der Senden Button nicht. Beim Klick erfolgt keine Aktion.
Dieses Problem lässt sich mit einem notes.ini Eintrag auf Serverseite lösen. Der Eintrag
Dieses Problem lässt sich mit einem notes.ini Eintrag auf Serverseite lösen. Der Eintrag
iNotes_WA_FirefoxSignedScript=0löst zumindest dieses Problem, und mit einem aktuellen Firefox kann wieder Mail versandt werden.
Verwaltung des ID Vaults
Seit Domino 8.5 stellt IBM zur Verwaltung von Benutzer-IDs sowie zur Unterstützung von Roaming Usern den ID Vault zur Verfügung. Diese Komponente ist grundsätzlich fast ohne Pflegeaufwand zu betreiben und auch deshalb nahezu in jeder aktuellen Infrastruktur eingerichtet. Welche Pflegewerkzeuge werden in dieser Anwendung abgebildet und wie sind diese anzuwenden?
Aufnahme neuer Benutzer in den Vault:
Die Aufnahme von neu registrierten Benutzer-IDs in den Vault ist einfach: Durch Zuordnung der registrierten Benutzer-ID durch eine Sicherheitsrichtlinie zu einem Vault werden diese bereits bei der Registrierung durch den Administrator in den Vault aufgenommen.
Diese aktiven Benutzer erscheinen dann in der Ansicht "Vault Users":
Deaktivierung von Benutzern im Vault
Werden Benutzer-IDs z.B. durch die Ansichtsaktion "Mark ID Inactive" deaktiviert, so werden die User IDs anschließend in der Ansicht "Inactive User IDs " geführt.
Die so deaktivierten Benutzer können mit ihren in Betrieb befindlichen Lotus Notes Clients weiter arbeiten (sich erfolgreich authentifizieren und auf Serverressourcen zugreifen), solange sie über entsprechende Server- und Datenbankberechtigungen verfügen. Werden Änderungen an lokalen IDs vorgenommen (z.B. Kennwortänderungen), wird eine im Vault deaktivierte ID nicht mehr über diesen synchronisiert. Weiter können keine neuen Lotus Notes Installationen in Betrieb genommen werden, indem automatisch die erforderliche Benutzer-ID aus dem Vault geladen wird.
Um einen Benutzer aus dem System zu löschen, ist dringend zu empfehlen, die Löschung eines Benutzers mit dem Domino Administrator Client durchzuführen. Hierbei wird ein Benutzer vollständig aus dem System entfernt (kein Mailempfang mehr möglich), Berechtigungen entzogen (Entzug der Server-, Datenbank- und Dokumentberechtigungen, optionale Aufnahme in Negativgruppen), sowie Löschung oder Deaktivierung der Benutzer-IDs im Vault (für ggf. spätere Reaktivierung oder Ablösung für den Zugang zu den in den IDs gespeicherten Benutzerschlüsseln).
Im oben dargestellten Fall bleiben Benutzer-IDs im Vault erhalten (lediglich deaktiviert). Dieses funktioniert auch, wenn der ausführende Domino Administrator zwar ausreichende Berechtigungen auf das Domino Directory besitzt, ohne das er Vault-Administrator sein muss. Der Grund liegt darin, dass die eigentliche Deaktivierung durch den AdminP auf Vault-Server erfolgt.
Wenn der Domino Administrator jedoch die Option "im Vault löschen" auswählt, ohne als Vault Administrator konfiguriert zu sein, erhält man zwar neben dem Hinweis auf mangelnde Rechte
im Ergebnis einen deaktivierten Benutzer mit einem "Bombe"-Symbol.
Dieses soll ausdrücken, dass diese Benutzer-ID eigentlich gelöscht werden sollte. Wenn die Benutzer niemals mehr reaktiviert werden sollen, können diese Einträge durch einen berechtigten Adminstrator gelöscht werden.
Reaktivierung von Benutzern
Dieses Merkmal bleibt leider unverändert erhalten, wenn man diesen Benutzer über die Ansichtsaktion "Restore ID" reaktiviert und die Ansichtsaktion "Mark ID Inactive" wieder deaktiviert (je nach Sicherheitseinschätzung an könnte man dieses als Fehler bezeichnen oder auch nicht).
Sollen Benutzer "reaktiviert" werden, welche keine Benutzer-ID mehr im Vault haben, so bietet sich lediglich die Vorgehensweise Gelöschte Benutzer wieder reaktivieren an.
Aufnahme neuer Benutzer in den Vault:
Die Aufnahme von neu registrierten Benutzer-IDs in den Vault ist einfach: Durch Zuordnung der registrierten Benutzer-ID durch eine Sicherheitsrichtlinie zu einem Vault werden diese bereits bei der Registrierung durch den Administrator in den Vault aufgenommen.
Diese aktiven Benutzer erscheinen dann in der Ansicht "Vault Users":
Deaktivierung von Benutzern im Vault
Werden Benutzer-IDs z.B. durch die Ansichtsaktion "Mark ID Inactive" deaktiviert, so werden die User IDs anschließend in der Ansicht "Inactive User IDs " geführt.
Die so deaktivierten Benutzer können mit ihren in Betrieb befindlichen Lotus Notes Clients weiter arbeiten (sich erfolgreich authentifizieren und auf Serverressourcen zugreifen), solange sie über entsprechende Server- und Datenbankberechtigungen verfügen. Werden Änderungen an lokalen IDs vorgenommen (z.B. Kennwortänderungen), wird eine im Vault deaktivierte ID nicht mehr über diesen synchronisiert. Weiter können keine neuen Lotus Notes Installationen in Betrieb genommen werden, indem automatisch die erforderliche Benutzer-ID aus dem Vault geladen wird.
Um einen Benutzer aus dem System zu löschen, ist dringend zu empfehlen, die Löschung eines Benutzers mit dem Domino Administrator Client durchzuführen. Hierbei wird ein Benutzer vollständig aus dem System entfernt (kein Mailempfang mehr möglich), Berechtigungen entzogen (Entzug der Server-, Datenbank- und Dokumentberechtigungen, optionale Aufnahme in Negativgruppen), sowie Löschung oder Deaktivierung der Benutzer-IDs im Vault (für ggf. spätere Reaktivierung oder Ablösung für den Zugang zu den in den IDs gespeicherten Benutzerschlüsseln).
Im oben dargestellten Fall bleiben Benutzer-IDs im Vault erhalten (lediglich deaktiviert). Dieses funktioniert auch, wenn der ausführende Domino Administrator zwar ausreichende Berechtigungen auf das Domino Directory besitzt, ohne das er Vault-Administrator sein muss. Der Grund liegt darin, dass die eigentliche Deaktivierung durch den AdminP auf Vault-Server erfolgt.
Wenn der Domino Administrator jedoch die Option "im Vault löschen" auswählt, ohne als Vault Administrator konfiguriert zu sein, erhält man zwar neben dem Hinweis auf mangelnde Rechte
im Ergebnis einen deaktivierten Benutzer mit einem "Bombe"-Symbol.
Dieses soll ausdrücken, dass diese Benutzer-ID eigentlich gelöscht werden sollte. Wenn die Benutzer niemals mehr reaktiviert werden sollen, können diese Einträge durch einen berechtigten Adminstrator gelöscht werden.
Reaktivierung von Benutzern
Dieses Merkmal bleibt leider unverändert erhalten, wenn man diesen Benutzer über die Ansichtsaktion "Restore ID" reaktiviert und die Ansichtsaktion "Mark ID Inactive" wieder deaktiviert (je nach Sicherheitseinschätzung an könnte man dieses als Fehler bezeichnen oder auch nicht).
Sollen Benutzer "reaktiviert" werden, welche keine Benutzer-ID mehr im Vault haben, so bietet sich lediglich die Vorgehensweise Gelöschte Benutzer wieder reaktivieren an.
Verwaltung des ID Vaults
Seit Domino 8.5 stellt IBM zur Verwaltung von Benutzer-IDs sowie zur Unterstützung von Roaming Usern den ID Vault zur Verfügung. Diese Komponente ist grundsätzlich fast ohne Pflegeaufwand zu betreiben und auch deshalb nahezu in jeder aktuellen Infrastruktur eingerichtet. Welche Pflegewerkzeuge werden in dieser Anwendung abgebildet und wie sind diese anzuwenden?
Aufnahme neuer Benutzer in den Vault:
Die Aufnahme von neu registrierten Benutzer-IDs in den Vault ist einfach: Durch Zuordnung der registrierten Benutzer-ID durch eine Sicherheitsrichtlinie zu einem Vault werden diese bereits bei der Registrierung durch den Administrator in den Vault aufgenommen.
Diese aktiven Benutzer erscheinen dann in der Ansicht "Vault Users":
Deaktivierung von Benutzern im Vault
Werden Benutzer-IDs z.B. durch die Ansichtsaktion "Mark ID Inactive" deaktiviert, so werden die User IDs anschlieĂźend in der Ansicht "Inactive User IDs " gefĂĽhrt.
Die so deaktivierten Benutzer können mit ihren in Betrieb befindlichen Lotus Notes Clients weiter arbeiten (sich erfolgreich authentifizieren und auf Serverressourcen zugreifen), solange sie über entsprechende Server- und Datenbankberechtigungen verfügen. Werden Änderungen an lokalen IDs vorgenommen (z.B. Kennwortänderungen), wird eine im Vault deaktivierte ID nicht mehr über diesen synchronisiert. Weiter können keine neuen Lotus Notes Installationen in Betrieb genommen werden, indem automatisch die erforderliche Benutzer-ID aus dem Vault geladen wird.
Um einen Benutzer aus dem System zu löschen, ist dringend zu empfehlen, die Löschung eines Benutzers mit dem Domino Administrator Client durchzuführen. Hierbei wird ein Benutzer vollständig aus dem System entfernt (kein Mailempfang mehr möglich), Berechtigungen entzogen (Entzug der Server-, Datenbank- und Dokumentberechtigungen, optionale Aufnahme in Negativgruppen), sowie Löschung oder Deaktivierung der Benutzer-IDs im Vault (für ggf. spätere Reaktivierung oder Ablösung für den Zugang zu den in den IDs gespeicherten Benutzerschlüsseln).
Im oben dargestellten Fall bleiben Benutzer-IDs im Vault erhalten (lediglich deaktiviert). Dieses funktioniert auch, wenn der ausfĂĽhrende Domino Administrator zwar ausreichende Berechtigungen auf das Domino Directory besitzt, ohne das er Vault-Administrator sein muss. Der Grund liegt darin, dass die eigentliche Deaktivierung durch den AdminP auf Vault-Server erfolgt.
Wenn der Domino Administrator jedoch die Option "im Vault löschen" auswählt, ohne als Vault Administrator konfiguriert zu sein, erhält man zwar neben dem Hinweis auf mangelnde Rechte
im Ergebnis einen deaktivierten Benutzer mit einem "Bombe"-Symbol.
Dieses soll ausdrücken, dass diese Benutzer-ID eigentlich gelöscht werden sollte. Wenn die Benutzer niemals mehr reaktiviert werden sollen, können diese Einträge durch einen berechtigten Adminstrator gelöscht werden.
Reaktivierung von Benutzern
Dieses Merkmal bleibt leider unverändert erhalten, wenn man diesen Benutzer über die Ansichtsaktion "Restore ID" reaktiviert und die Ansichtsaktion "Mark ID Inactive" wieder deaktiviert (je nach Sicherheitseinschätzung an könnte man dieses als Fehler bezeichnen oder auch nicht).
Sollen Benutzer "reaktiviert" werden, welche keine Benutzer-ID mehr im Vault haben, so bietet sich lediglich die Vorgehensweise Gelöschte Benutzer wieder reaktivieren an.
Aufnahme neuer Benutzer in den Vault:
Die Aufnahme von neu registrierten Benutzer-IDs in den Vault ist einfach: Durch Zuordnung der registrierten Benutzer-ID durch eine Sicherheitsrichtlinie zu einem Vault werden diese bereits bei der Registrierung durch den Administrator in den Vault aufgenommen.
Diese aktiven Benutzer erscheinen dann in der Ansicht "Vault Users":
Deaktivierung von Benutzern im Vault
Werden Benutzer-IDs z.B. durch die Ansichtsaktion "Mark ID Inactive" deaktiviert, so werden die User IDs anschlieĂźend in der Ansicht "Inactive User IDs " gefĂĽhrt.
Die so deaktivierten Benutzer können mit ihren in Betrieb befindlichen Lotus Notes Clients weiter arbeiten (sich erfolgreich authentifizieren und auf Serverressourcen zugreifen), solange sie über entsprechende Server- und Datenbankberechtigungen verfügen. Werden Änderungen an lokalen IDs vorgenommen (z.B. Kennwortänderungen), wird eine im Vault deaktivierte ID nicht mehr über diesen synchronisiert. Weiter können keine neuen Lotus Notes Installationen in Betrieb genommen werden, indem automatisch die erforderliche Benutzer-ID aus dem Vault geladen wird.
Um einen Benutzer aus dem System zu löschen, ist dringend zu empfehlen, die Löschung eines Benutzers mit dem Domino Administrator Client durchzuführen. Hierbei wird ein Benutzer vollständig aus dem System entfernt (kein Mailempfang mehr möglich), Berechtigungen entzogen (Entzug der Server-, Datenbank- und Dokumentberechtigungen, optionale Aufnahme in Negativgruppen), sowie Löschung oder Deaktivierung der Benutzer-IDs im Vault (für ggf. spätere Reaktivierung oder Ablösung für den Zugang zu den in den IDs gespeicherten Benutzerschlüsseln).
Im oben dargestellten Fall bleiben Benutzer-IDs im Vault erhalten (lediglich deaktiviert). Dieses funktioniert auch, wenn der ausfĂĽhrende Domino Administrator zwar ausreichende Berechtigungen auf das Domino Directory besitzt, ohne das er Vault-Administrator sein muss. Der Grund liegt darin, dass die eigentliche Deaktivierung durch den AdminP auf Vault-Server erfolgt.
Wenn der Domino Administrator jedoch die Option "im Vault löschen" auswählt, ohne als Vault Administrator konfiguriert zu sein, erhält man zwar neben dem Hinweis auf mangelnde Rechte
im Ergebnis einen deaktivierten Benutzer mit einem "Bombe"-Symbol.
Dieses soll ausdrücken, dass diese Benutzer-ID eigentlich gelöscht werden sollte. Wenn die Benutzer niemals mehr reaktiviert werden sollen, können diese Einträge durch einen berechtigten Adminstrator gelöscht werden.
Reaktivierung von Benutzern
Dieses Merkmal bleibt leider unverändert erhalten, wenn man diesen Benutzer über die Ansichtsaktion "Restore ID" reaktiviert und die Ansichtsaktion "Mark ID Inactive" wieder deaktiviert (je nach Sicherheitseinschätzung an könnte man dieses als Fehler bezeichnen oder auch nicht).
Sollen Benutzer "reaktiviert" werden, welche keine Benutzer-ID mehr im Vault haben, so bietet sich lediglich die Vorgehensweise Gelöschte Benutzer wieder reaktivieren an.
Verwaltung des ID Vaults
Seit Domino 8.5 stellt IBM zur Verwaltung von Benutzer-IDs sowie zur Unterstützung von Roaming Usern den ID Vault zur Verfügung. Diese Komponente ist grundsätzlich fast ohne Pflegeaufwand zu betreiben und auch deshalb nahezu in jeder aktuellen Infrastruktur eingerichtet. Welche Pflegewerkzeuge werden in dieser Anwendung abgebildet und wie sind diese anzuwenden?
Aufnahme neuer Benutzer in den Vault:
Die Aufnahme von neu registrierten Benutzer-IDs in den Vault ist einfach: Durch Zuordnung der registrierten Benutzer-ID durch eine Sicherheitsrichtlinie zu einem Vault werden diese bereits bei der Registrierung durch den Administrator in den Vault aufgenommen.
Diese aktiven Benutzer erscheinen dann in der Ansicht "Vault Users":
Deaktivierung von Benutzern im Vault
Werden Benutzer-IDs z.B. durch die Ansichtsaktion "Mark ID Inactive" deaktiviert, so werden die User IDs anschließend in der Ansicht "Inactive User IDs " geführt.
Die so deaktivierten Benutzer können mit ihren in Betrieb befindlichen Lotus Notes Clients weiter arbeiten (sich erfolgreich authentifizieren und auf Serverressourcen zugreifen), solange sie über entsprechende Server- und Datenbankberechtigungen verfügen. Werden Änderungen an lokalen IDs vorgenommen (z.B. Kennwortänderungen), wird eine im Vault deaktivierte ID nicht mehr über diesen synchronisiert. Weiter können keine neuen Lotus Notes Installationen in Betrieb genommen werden, indem automatisch die erforderliche Benutzer-ID aus dem Vault geladen wird.
Um einen Benutzer aus dem System zu löschen, ist dringend zu empfehlen, die Löschung eines Benutzers mit dem Domino Administrator Client durchzuführen. Hierbei wird ein Benutzer vollständig aus dem System entfernt (kein Mailempfang mehr möglich), Berechtigungen entzogen (Entzug der Server-, Datenbank- und Dokumentberechtigungen, optionale Aufnahme in Negativgruppen), sowie Löschung oder Deaktivierung der Benutzer-IDs im Vault (für ggf. spätere Reaktivierung oder Ablösung für den Zugang zu den in den IDs gespeicherten Benutzerschlüsseln).
Im oben dargestellten Fall bleiben Benutzer-IDs im Vault erhalten (lediglich deaktiviert). Dieses funktioniert auch, wenn der ausführende Domino Administrator zwar ausreichende Berechtigungen auf das Domino Directory besitzt, ohne das er Vault-Administrator sein muss. Der Grund liegt darin, dass die eigentliche Deaktivierung durch den AdminP auf Vault-Server erfolgt.
Wenn der Domino Administrator jedoch die Option "im Vault löschen" auswählt, ohne als Vault Administrator konfiguriert zu sein, erhält man zwar neben dem Hinweis auf mangelnde Rechte
im Ergebnis einen deaktivierten Benutzer mit einem "Bombe"-Symbol.
Dieses soll ausdrücken, dass diese Benutzer-ID eigentlich gelöscht werden sollte. Wenn die Benutzer niemals mehr reaktiviert werden sollen, können diese Einträge durch einen berechtigten Adminstrator gelöscht werden.
Reaktivierung von Benutzern
Dieses Merkmal bleibt leider unverändert erhalten, wenn man diesen Benutzer über die Ansichtsaktion "Restore ID" reaktiviert und die Ansichtsaktion "Mark ID Inactive" wieder deaktiviert (je nach Sicherheitseinschätzung an könnte man dieses als Fehler bezeichnen oder auch nicht).
Sollen Benutzer "reaktiviert" werden, welche keine Benutzer-ID mehr im Vault haben, so bietet sich lediglich die Vorgehensweise Gelöschte Benutzer wieder reaktivieren an.
Aufnahme neuer Benutzer in den Vault:
Die Aufnahme von neu registrierten Benutzer-IDs in den Vault ist einfach: Durch Zuordnung der registrierten Benutzer-ID durch eine Sicherheitsrichtlinie zu einem Vault werden diese bereits bei der Registrierung durch den Administrator in den Vault aufgenommen.
Diese aktiven Benutzer erscheinen dann in der Ansicht "Vault Users":
Deaktivierung von Benutzern im Vault
Werden Benutzer-IDs z.B. durch die Ansichtsaktion "Mark ID Inactive" deaktiviert, so werden die User IDs anschließend in der Ansicht "Inactive User IDs " geführt.
Die so deaktivierten Benutzer können mit ihren in Betrieb befindlichen Lotus Notes Clients weiter arbeiten (sich erfolgreich authentifizieren und auf Serverressourcen zugreifen), solange sie über entsprechende Server- und Datenbankberechtigungen verfügen. Werden Änderungen an lokalen IDs vorgenommen (z.B. Kennwortänderungen), wird eine im Vault deaktivierte ID nicht mehr über diesen synchronisiert. Weiter können keine neuen Lotus Notes Installationen in Betrieb genommen werden, indem automatisch die erforderliche Benutzer-ID aus dem Vault geladen wird.
Um einen Benutzer aus dem System zu löschen, ist dringend zu empfehlen, die Löschung eines Benutzers mit dem Domino Administrator Client durchzuführen. Hierbei wird ein Benutzer vollständig aus dem System entfernt (kein Mailempfang mehr möglich), Berechtigungen entzogen (Entzug der Server-, Datenbank- und Dokumentberechtigungen, optionale Aufnahme in Negativgruppen), sowie Löschung oder Deaktivierung der Benutzer-IDs im Vault (für ggf. spätere Reaktivierung oder Ablösung für den Zugang zu den in den IDs gespeicherten Benutzerschlüsseln).
Im oben dargestellten Fall bleiben Benutzer-IDs im Vault erhalten (lediglich deaktiviert). Dieses funktioniert auch, wenn der ausführende Domino Administrator zwar ausreichende Berechtigungen auf das Domino Directory besitzt, ohne das er Vault-Administrator sein muss. Der Grund liegt darin, dass die eigentliche Deaktivierung durch den AdminP auf Vault-Server erfolgt.
Wenn der Domino Administrator jedoch die Option "im Vault löschen" auswählt, ohne als Vault Administrator konfiguriert zu sein, erhält man zwar neben dem Hinweis auf mangelnde Rechte
im Ergebnis einen deaktivierten Benutzer mit einem "Bombe"-Symbol.
Dieses soll ausdrücken, dass diese Benutzer-ID eigentlich gelöscht werden sollte. Wenn die Benutzer niemals mehr reaktiviert werden sollen, können diese Einträge durch einen berechtigten Adminstrator gelöscht werden.
Reaktivierung von Benutzern
Dieses Merkmal bleibt leider unverändert erhalten, wenn man diesen Benutzer über die Ansichtsaktion "Restore ID" reaktiviert und die Ansichtsaktion "Mark ID Inactive" wieder deaktiviert (je nach Sicherheitseinschätzung an könnte man dieses als Fehler bezeichnen oder auch nicht).
Sollen Benutzer "reaktiviert" werden, welche keine Benutzer-ID mehr im Vault haben, so bietet sich lediglich die Vorgehensweise Gelöschte Benutzer wieder reaktivieren an.
Verwaltung des ID Vaults
Seit Domino 8.5 stellt IBM zur Verwaltung von Benutzer-IDs sowie zur Unterstützung von Roaming Usern den ID Vault zur Verfügung. Diese Komponente ist grundsätzlich fast ohne Pflegeaufwand zu betreiben und auch deshalb nahezu in jeder aktuellen Infrastruktur eingerichtet. Welche Pflegewerkzeuge werden in dieser Anwendung abgebildet und wie sind diese anzuwenden?
Aufnahme neuer Benutzer in den Vault:
Die Aufnahme von neu registrierten Benutzer-IDs in den Vault ist einfach: Durch Zuordnung der registrierten Benutzer-ID durch eine Sicherheitsrichtlinie zu einem Vault werden diese bereits bei der Registrierung durch den Administrator in den Vault aufgenommen.
Diese aktiven Benutzer erscheinen dann in der Ansicht "Vault Users":
Deaktivierung von Benutzern im Vault
Werden Benutzer-IDs z.B. durch die Ansichtsaktion "Mark ID Inactive" deaktiviert, so werden die User IDs anschließend in der Ansicht "Inactive User IDs " geführt.
Die so deaktivierten Benutzer können mit ihren in Betrieb befindlichen Lotus Notes Clients weiter arbeiten (sich erfolgreich authentifizieren und auf Serverressourcen zugreifen), solange sie über entsprechende Server- und Datenbankberechtigungen verfügen. Werden Änderungen an lokalen IDs vorgenommen (z.B. Kennwortänderungen), wird eine im Vault deaktivierte ID nicht mehr über diesen synchronisiert. Weiter können keine neuen Lotus Notes Installationen in Betrieb genommen werden, indem automatisch die erforderliche Benutzer-ID aus dem Vault geladen wird.
Um einen Benutzer aus dem System zu löschen, ist dringend zu empfehlen, die Löschung eines Benutzers mit dem Domino Administrator Client durchzuführen. Hierbei wird ein Benutzer vollständig aus dem System entfernt (kein Mailempfang mehr möglich), Berechtigungen entzogen (Entzug der Server-, Datenbank- und Dokumentberechtigungen, optionale Aufnahme in Negativgruppen), sowie Löschung oder Deaktivierung der Benutzer-IDs im Vault (für ggf. spätere Reaktivierung oder Ablösung für den Zugang zu den in den IDs gespeicherten Benutzerschlüsseln).
Im oben dargestellten Fall bleiben Benutzer-IDs im Vault erhalten (lediglich deaktiviert). Dieses funktioniert auch, wenn der ausführende Domino Administrator zwar ausreichende Berechtigungen auf das Domino Directory besitzt, ohne das er Vault-Administrator sein muss. Der Grund liegt darin, dass die eigentliche Deaktivierung durch den AdminP auf Vault-Server erfolgt.
Wenn der Domino Administrator jedoch die Option "im Vault löschen" auswählt, ohne als Vault Administrator konfiguriert zu sein, erhält man zwar neben dem Hinweis auf mangelnde Rechte
im Ergebnis einen deaktivierten Benutzer mit einem "Bombe"-Symbol.
Dieses soll ausdrücken, dass diese Benutzer-ID eigentlich gelöscht werden sollte. Wenn die Benutzer niemals mehr reaktiviert werden sollen, können diese Einträge durch einen berechtigten Adminstrator gelöscht werden.
Reaktivierung von Benutzern
Dieses Merkmal bleibt leider unverändert erhalten, wenn man diesen Benutzer über die Ansichtsaktion "Restore ID" reaktiviert und die Ansichtsaktion "Mark ID Inactive" wieder deaktiviert (je nach Sicherheitseinschätzung an könnte man dieses als Fehler bezeichnen oder auch nicht).
Sollen Benutzer "reaktiviert" werden, welche keine Benutzer-ID mehr im Vault haben, so bietet sich lediglich die Vorgehensweise Gelöschte Benutzer wieder reaktivieren an.
Aufnahme neuer Benutzer in den Vault:
Die Aufnahme von neu registrierten Benutzer-IDs in den Vault ist einfach: Durch Zuordnung der registrierten Benutzer-ID durch eine Sicherheitsrichtlinie zu einem Vault werden diese bereits bei der Registrierung durch den Administrator in den Vault aufgenommen.
Diese aktiven Benutzer erscheinen dann in der Ansicht "Vault Users":
Deaktivierung von Benutzern im Vault
Werden Benutzer-IDs z.B. durch die Ansichtsaktion "Mark ID Inactive" deaktiviert, so werden die User IDs anschließend in der Ansicht "Inactive User IDs " geführt.
Die so deaktivierten Benutzer können mit ihren in Betrieb befindlichen Lotus Notes Clients weiter arbeiten (sich erfolgreich authentifizieren und auf Serverressourcen zugreifen), solange sie über entsprechende Server- und Datenbankberechtigungen verfügen. Werden Änderungen an lokalen IDs vorgenommen (z.B. Kennwortänderungen), wird eine im Vault deaktivierte ID nicht mehr über diesen synchronisiert. Weiter können keine neuen Lotus Notes Installationen in Betrieb genommen werden, indem automatisch die erforderliche Benutzer-ID aus dem Vault geladen wird.
Um einen Benutzer aus dem System zu löschen, ist dringend zu empfehlen, die Löschung eines Benutzers mit dem Domino Administrator Client durchzuführen. Hierbei wird ein Benutzer vollständig aus dem System entfernt (kein Mailempfang mehr möglich), Berechtigungen entzogen (Entzug der Server-, Datenbank- und Dokumentberechtigungen, optionale Aufnahme in Negativgruppen), sowie Löschung oder Deaktivierung der Benutzer-IDs im Vault (für ggf. spätere Reaktivierung oder Ablösung für den Zugang zu den in den IDs gespeicherten Benutzerschlüsseln).
Im oben dargestellten Fall bleiben Benutzer-IDs im Vault erhalten (lediglich deaktiviert). Dieses funktioniert auch, wenn der ausführende Domino Administrator zwar ausreichende Berechtigungen auf das Domino Directory besitzt, ohne das er Vault-Administrator sein muss. Der Grund liegt darin, dass die eigentliche Deaktivierung durch den AdminP auf Vault-Server erfolgt.
Wenn der Domino Administrator jedoch die Option "im Vault löschen" auswählt, ohne als Vault Administrator konfiguriert zu sein, erhält man zwar neben dem Hinweis auf mangelnde Rechte
im Ergebnis einen deaktivierten Benutzer mit einem "Bombe"-Symbol.
Dieses soll ausdrücken, dass diese Benutzer-ID eigentlich gelöscht werden sollte. Wenn die Benutzer niemals mehr reaktiviert werden sollen, können diese Einträge durch einen berechtigten Adminstrator gelöscht werden.
Reaktivierung von Benutzern
Dieses Merkmal bleibt leider unverändert erhalten, wenn man diesen Benutzer über die Ansichtsaktion "Restore ID" reaktiviert und die Ansichtsaktion "Mark ID Inactive" wieder deaktiviert (je nach Sicherheitseinschätzung an könnte man dieses als Fehler bezeichnen oder auch nicht).
Sollen Benutzer "reaktiviert" werden, welche keine Benutzer-ID mehr im Vault haben, so bietet sich lediglich die Vorgehensweise Gelöschte Benutzer wieder reaktivieren an.
Steuertipp aktuell: Empfängerortprinzip bei der Umsatzsteuer
Seit dem 1. Januar 2010 gilt das Empfängerortprinzip bei sonstigen Leistungen. Betroffen sind nicht nur im Ausland tätige Unternehmer – auch deutsche Leistungsempfänger müssen neue Melde- und Aufzeichnungspflichten erfüllen. Das neue Empfängerortprinzip hat die Umsatzbesteuerung in der betrieblichen Praxis allerdings nicht leichter gemacht. Mit gleich zwei im Dezember 2012 veröffentlichten Verwaltungsvorschriften wollen die Finanzbehörden drohende Doppelbesteuerungen vermeiden und Rechtssicherheit schaffen.
Ob eine unternehmerische Leistung der deutschen Umsatzsteuer unterliegt, hängt entscheidend vom Leistungsort ab. Bei einfachen Lieferungen fällt die Ortsbestimmung leicht: Sofern die Ware befördert oder versendet wird, gilt die Lieferung im Regelfall bereits dort als ausgeführt, wo der Warentransport an den Abnehmer oder in dessen Auftrag an einen Dritten beginnt. Anderenfalls zählt als für die Umsatzbesteuerung maßgeblicher Leistungsort der Ort, wo dem Kunden Verfügungsmacht verschafft wird.
Schwieriger gestaltet sich die Ortsbestimmung und damit die Steuerbarkeit des jeweiligen Umsatzes bei den sogenannten „sonstigen Leistungen“. Denn mit EU-weiter Einführung des Empfängerortprinzips bleibt es seit dem 1. Januar 2010 nur noch für sonstige Leistungen an Nichtunternehmer bei dem Ort, von dem aus der leistende Unternehmer sein Unternehmen betreibt.
Leistungen an andere Unternehmer für deren Unternehmen werden von einigen Ausnahmen abgesehen dagegen seither dort ausgeführt, wo der Leistungsempfänger sein Unternehmen betreibt. Gleiches gilt für sonstige Leistungen an juristische Personen, die bei der Auftragsvergabe mit einer Umsatzsteuer-Identifikationsnummer (USt-IdNr.) auftreten. Werden sonstige Leistungen davon abweichend an eine Betriebsstätte des Leistungsempfängers ausgeführt, ist stattdessen deren Belegenheit maßgebend. Zur Verhinderung von Gestaltungsmissbräuchen akzeptieren die Finanzbehörden jedoch ausschließlich feste Geschäftseinrichtungen oder Anlagen, die darüber hinaus über einen ausreichenden Mindestbestand an Personal- und Sachmitteln verfügen müssen.
Der vollständige Artikel für DNUG Mitglieder
[EN] From Mass Marketing to Person-2-Person-Marketing – Dialogue and Real Communication
Last week I had the pleasure to speak at the next Conference in Berlin. My presentation had the title Marketing needs to change to be successful: Put your customer in the center! As a child of the Email Age – and of email newsletters and email SPAM – I tried to explain, that today’s marketing has to change dramatically. People get more and more bored by email. Rigid laws demanding explicit Opt-In from recipients limit the reach Marketers are having. What is the solution? Of course Social Media, Twitter and Facebook, the new social channels we are using like email … As in email we are spamming people with our boring marketing messages instead of understanding the core of Social Media (and Social Business). And this core is dialogue, real communication, not pre-written Tweets and event promos.
Don’t get me wrong. There is still a need for email newsletters, for web sites with Marketing messages, for Direct Mail and Advertising, all the nice elements of the Marketing Mix, the owned and paid part of our Marketing. But the social side of the Marketing house, what is called earned media is over-shining paid and owned media. Customers rely more and more on word-of-mouth. They trust their peers and not the nice, glossy web sites and messages. They even quite often make their buying (pre)decisions based on earned media even before they talk to us. We need to much better integrate our tactics, personalize, what we deliver to our customers, deliver relevant and interesting content and we need to be willing to engage with our customers in 1:1 communication or communication in a small group.
This means that we as Marketers have to change our behavior, need to become more Sellers and Influencers. And it means that Sales has to change, too, and become Brand advocates, listeners and communicators out there in the social space, in relevant communities, on Twitter and wherever their potential buyer is hanging around online.
Here is the link to my presentation:
Filed under: English Tagged: CustomerExperience, Marketing, SocBiz, SocialMedia, WebExperience
IBM Notes Traveler Android Client ab heute auch im Google Play Store
Seit heute ist der Android Client für IBM Notes Traveler im Google Play Store verfügbar. Ich bin noch ein wenig unentschlossen, ob ich mich darüber freuen soll. Vorteil: Bisher mußte der Androi ...
Traveler für Android jetzt im Google Play Shop
Seit heute gibt es den Android-Client für Traveler hier im Google Play Shop. Die Installation von dort hat den Vorteil, dass der Benutzer den Android-Sicherheitsmechanismus nicht deaktivieren muss, der die Installation von Apps fremder Quellen verhindert.
Ein Admin kann dem Benutzer per Mail, SMS oder sonstwie eine URL zur halbautomatischen Konfiguration des Clients auf das Gerät schicken.
(via Mitch Cohen)
Law of Software Envelopment
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
~ Law of Software Envelopment (by Jamie Zawinski)
Dynamic Client Configuration (DCC) hinterlegt keine Versionsinformationen im Personendokument
Für einen Administrator kann es hilfreich sein, einen aktuellen Überblick über die zur Zeit eingesetzten Lotus Notes Client Versionen zu erhalten. Die Personendokumente der Benutzer enthalten hierzu entsprechende Informationen:
Leider enthält diese Versionstabelle auch historische Werte. Um den aktuellen Stand der eingesetzten Versionen zu ermitteln habe ich mittels eines kleinen Agenten Versionstabelle in Personendokumenten löschen und neu aufbauen die bisher erfassten Daten in den Personendokumenten des Domino Directory gelöscht.
Leider füllten sich in diesen Tagen nicht bei allen aktiven Benutzern die Personendokumente mit aktuellen Daten. Die bislang in diesen Fällen verwendete Vorgehensweise, in der Notes.ini des Clients die
DYNINFOCR_ - Zeile zu löschen führt mit aktuellen Clients (8.5.3 und 9.0) nicht dazu, dass diese erneut "Update Client Information in Person Record" Aufträge in die Admin4.nsf stellen. Durch debugging von DCC auf Client-Seite stieß ich darauf, dass die Dyncfg.exe auf eine Fehlersituation stößt und keine Aktualisierungsaufforderung schreibt (siehe IBM APAR).
Bevor ich frustiert aufgeben wollte, erinnerte ich mich daran, dass der Lotus Notes Client der aktuellen Versionen nicht mehr nur einmal täglich beim Start sondern bei jeder Serverauthentifiezierung DCC anstößt und ggf. Clientinformatioen aktualisieren sollte. Zur Steuerung dient ein zusätzliches Profildokument "DYNCRINFO" in der Kontakte Anwendung.
Nachdem ich sowohl die entsprechende Notes.ini Variable, als auch das Profildokument gelöscht hatte, stellt der Client auch wieder Aktualisierungsaufträge in die Admin4.nsf sodaß ich nunmehr den gewünschten aktuellen Versionsstand im Personendokument eines Benutzers finde.
Leider enthält diese Versionstabelle auch historische Werte. Um den aktuellen Stand der eingesetzten Versionen zu ermitteln habe ich mittels eines kleinen Agenten Versionstabelle in Personendokumenten löschen und neu aufbauen die bisher erfassten Daten in den Personendokumenten des Domino Directory gelöscht.
Leider füllten sich in diesen Tagen nicht bei allen aktiven Benutzern die Personendokumente mit aktuellen Daten. Die bislang in diesen Fällen verwendete Vorgehensweise, in der Notes.ini des Clients die
DYNINFOCR_ - Zeile zu löschen führt mit aktuellen Clients (8.5.3 und 9.0) nicht dazu, dass diese erneut "Update Client Information in Person Record" Aufträge in die Admin4.nsf stellen. Durch debugging von DCC auf Client-Seite stieß ich darauf, dass die Dyncfg.exe auf eine Fehlersituation stößt und keine Aktualisierungsaufforderung schreibt (siehe IBM APAR).
Bevor ich frustiert aufgeben wollte, erinnerte ich mich daran, dass der Lotus Notes Client der aktuellen Versionen nicht mehr nur einmal täglich beim Start sondern bei jeder Serverauthentifiezierung DCC anstößt und ggf. Clientinformatioen aktualisieren sollte. Zur Steuerung dient ein zusätzliches Profildokument "DYNCRINFO" in der Kontakte Anwendung.
Nachdem ich sowohl die entsprechende Notes.ini Variable, als auch das Profildokument gelöscht hatte, stellt der Client auch wieder Aktualisierungsaufträge in die Admin4.nsf sodaß ich nunmehr den gewünschten aktuellen Versionsstand im Personendokument eines Benutzers finde.
Dynamic Client Configuration (DCC) hinterlegt keine Versionsinformationen im Personendokument
Für einen Administrator kann es hilfreich sein, einen aktuellen Überblick über die zur Zeit eingesetzten Lotus Notes Client Versionen zu erhalten. Die Personendokumente der Benutzer enthalten hierzu entsprechende Informationen:
Leider enthält diese Versionstabelle auch historische Werte. Um den aktuellen Stand der eingesetzten Versionen zu ermitteln habe ich mittels eines kleinen Agenten Versionstabelle in Personendokumenten löschen und neu aufbauen die bisher erfassten Daten in den Personendokumenten des Domino Directory gelöscht.
Leider füllten sich in diesen Tagen nicht bei allen aktiven Benutzern die Personendokumente mit aktuellen Daten. Die bislang in diesen Fällen verwendete Vorgehensweise, in der Notes.ini des Clients die
DYNINFOCR_ - Zeile zu löschen führt mit aktuellen Clients (8.5.3 und 9.0) nicht dazu, dass diese erneut "Update Client Information in Person Record" Aufträge in die Admin4.nsf stellen. Durch debugging von DCC auf Client-Seite stieß ich darauf, dass die Dyncfg.exe auf eine Fehlersituation stößt und keine Aktualisierungsaufforderung schreibt (siehe IBM APAR).
Bevor ich frustiert aufgeben wollte, erinnerte ich mich daran, dass der Lotus Notes Client der aktuellen Versionen nicht mehr nur einmal täglich beim Start sondern bei jeder Serverauthentifiezierung DCC anstößt und ggf. Clientinformatioen aktualisieren sollte. Zur Steuerung dient ein zusätzliches Profildokument "DYNCRINFO" in der Kontakte Anwendung.
Nachdem ich sowohl die entsprechende Notes.ini Variable, als auch das Profildokument gelöscht hatte, stellt der Client auch wieder Aktualisierungsaufträge in die Admin4.nsf sodaß ich nunmehr den gewünschten aktuellen Versionsstand im Personendokument eines Benutzers finde.
Leider enthält diese Versionstabelle auch historische Werte. Um den aktuellen Stand der eingesetzten Versionen zu ermitteln habe ich mittels eines kleinen Agenten Versionstabelle in Personendokumenten löschen und neu aufbauen die bisher erfassten Daten in den Personendokumenten des Domino Directory gelöscht.
Leider füllten sich in diesen Tagen nicht bei allen aktiven Benutzern die Personendokumente mit aktuellen Daten. Die bislang in diesen Fällen verwendete Vorgehensweise, in der Notes.ini des Clients die
DYNINFOCR_ - Zeile zu löschen führt mit aktuellen Clients (8.5.3 und 9.0) nicht dazu, dass diese erneut "Update Client Information in Person Record" Aufträge in die Admin4.nsf stellen. Durch debugging von DCC auf Client-Seite stieß ich darauf, dass die Dyncfg.exe auf eine Fehlersituation stößt und keine Aktualisierungsaufforderung schreibt (siehe IBM APAR).
Bevor ich frustiert aufgeben wollte, erinnerte ich mich daran, dass der Lotus Notes Client der aktuellen Versionen nicht mehr nur einmal täglich beim Start sondern bei jeder Serverauthentifiezierung DCC anstößt und ggf. Clientinformatioen aktualisieren sollte. Zur Steuerung dient ein zusätzliches Profildokument "DYNCRINFO" in der Kontakte Anwendung.
Nachdem ich sowohl die entsprechende Notes.ini Variable, als auch das Profildokument gelöscht hatte, stellt der Client auch wieder Aktualisierungsaufträge in die Admin4.nsf sodaß ich nunmehr den gewünschten aktuellen Versionsstand im Personendokument eines Benutzers finde.
Dynamic Client Configuration (DCC) hinterlegt keine Versionsinformationen im Personendokument
FĂĽr einen Administrator kann es hilfreich sein, einen aktuellen Ăśberblick ĂĽber die zur Zeit eingesetzten Lotus Notes Client Versionen zu erhalten. Die Personendokumente der Benutzer enthalten hierzu entsprechende Informationen:
Leider enthält diese Versionstabelle auch historische Werte. Um den aktuellen Stand der eingesetzten Versionen zu ermitteln habe ich mittels eines kleinen Agenten Versionstabelle in Personendokumenten löschen und neu aufbauen die bisher erfassten Daten in den Personendokumenten des Domino Directory gelöscht.
Leider füllten sich in diesen Tagen nicht bei allen aktiven Benutzern die Personendokumente mit aktuellen Daten. Die bislang in diesen Fällen verwendete Vorgehensweise, in der Notes.ini des Clients die
DYNINFOCR_ - Zeile zu löschen führt mit aktuellen Clients (8.5.3 und 9.0) nicht dazu, dass diese erneut "Update Client Information in Person Record" Aufträge in die Admin4.nsf stellen. Durch debugging von DCC auf Client-Seite stieß ich darauf, dass die Dyncfg.exe auf eine Fehlersituation stößt und keine Aktualisierungsaufforderung schreibt (siehe IBM APAR).
Bevor ich frustiert aufgeben wollte, erinnerte ich mich daran, dass der Lotus Notes Client der aktuellen Versionen nicht mehr nur einmal täglich beim Start sondern bei jeder Serverauthentifiezierung DCC anstößt und ggf. Clientinformatioen aktualisieren sollte. Zur Steuerung dient ein zusätzliches Profildokument "DYNCRINFO" in der Kontakte Anwendung.
Nachdem ich sowohl die entsprechende Notes.ini Variable, als auch das Profildokument gelöscht hatte, stellt der Client auch wieder Aktualisierungsaufträge in die Admin4.nsf sodaß ich nunmehr den gewünschten aktuellen Versionsstand im Personendokument eines Benutzers finde.
Leider enthält diese Versionstabelle auch historische Werte. Um den aktuellen Stand der eingesetzten Versionen zu ermitteln habe ich mittels eines kleinen Agenten Versionstabelle in Personendokumenten löschen und neu aufbauen die bisher erfassten Daten in den Personendokumenten des Domino Directory gelöscht.
Leider füllten sich in diesen Tagen nicht bei allen aktiven Benutzern die Personendokumente mit aktuellen Daten. Die bislang in diesen Fällen verwendete Vorgehensweise, in der Notes.ini des Clients die
DYNINFOCR_ - Zeile zu löschen führt mit aktuellen Clients (8.5.3 und 9.0) nicht dazu, dass diese erneut "Update Client Information in Person Record" Aufträge in die Admin4.nsf stellen. Durch debugging von DCC auf Client-Seite stieß ich darauf, dass die Dyncfg.exe auf eine Fehlersituation stößt und keine Aktualisierungsaufforderung schreibt (siehe IBM APAR).
Bevor ich frustiert aufgeben wollte, erinnerte ich mich daran, dass der Lotus Notes Client der aktuellen Versionen nicht mehr nur einmal täglich beim Start sondern bei jeder Serverauthentifiezierung DCC anstößt und ggf. Clientinformatioen aktualisieren sollte. Zur Steuerung dient ein zusätzliches Profildokument "DYNCRINFO" in der Kontakte Anwendung.
Nachdem ich sowohl die entsprechende Notes.ini Variable, als auch das Profildokument gelöscht hatte, stellt der Client auch wieder Aktualisierungsaufträge in die Admin4.nsf sodaß ich nunmehr den gewünschten aktuellen Versionsstand im Personendokument eines Benutzers finde.
Dynamic Client Configuration (DCC) hinterlegt keine Versionsinformationen im Personendokument
Für einen Administrator kann es hilfreich sein, einen aktuellen Überblick über die zur Zeit eingesetzten Lotus Notes Client Versionen zu erhalten. Die Personendokumente der Benutzer enthalten hierzu entsprechende Informationen:
Leider enthält diese Versionstabelle auch historische Werte. Um den aktuellen Stand der eingesetzten Versionen zu ermitteln habe ich mittels eines kleinen Agenten Versionstabelle in Personendokumenten löschen und neu aufbauen die bisher erfassten Daten in den Personendokumenten des Domino Directory gelöscht.
Leider füllten sich in diesen Tagen nicht bei allen aktiven Benutzern die Personendokumente mit aktuellen Daten. Die bislang in diesen Fällen verwendete Vorgehensweise, in der Notes.ini des Clients die
DYNINFOCR_ - Zeile zu löschen führt mit aktuellen Clients (8.5.3 und 9.0) nicht dazu, dass diese erneut "Update Client Information in Person Record" Aufträge in die Admin4.nsf stellen. Durch debugging von DCC auf Client-Seite stieß ich darauf, dass die Dyncfg.exe auf eine Fehlersituation stößt und keine Aktualisierungsaufforderung schreibt (siehe IBM APAR).
Bevor ich frustiert aufgeben wollte, erinnerte ich mich daran, dass der Lotus Notes Client der aktuellen Versionen nicht mehr nur einmal täglich beim Start sondern bei jeder Serverauthentifiezierung DCC anstößt und ggf. Clientinformatioen aktualisieren sollte. Zur Steuerung dient ein zusätzliches Profildokument "DYNCRINFO" in der Kontakte Anwendung.
Nachdem ich sowohl die entsprechende Notes.ini Variable, als auch das Profildokument gelöscht hatte, stellt der Client auch wieder Aktualisierungsaufträge in die Admin4.nsf sodaß ich nunmehr den gewünschten aktuellen Versionsstand im Personendokument eines Benutzers finde.
Leider enthält diese Versionstabelle auch historische Werte. Um den aktuellen Stand der eingesetzten Versionen zu ermitteln habe ich mittels eines kleinen Agenten Versionstabelle in Personendokumenten löschen und neu aufbauen die bisher erfassten Daten in den Personendokumenten des Domino Directory gelöscht.
Leider füllten sich in diesen Tagen nicht bei allen aktiven Benutzern die Personendokumente mit aktuellen Daten. Die bislang in diesen Fällen verwendete Vorgehensweise, in der Notes.ini des Clients die
DYNINFOCR_ - Zeile zu löschen führt mit aktuellen Clients (8.5.3 und 9.0) nicht dazu, dass diese erneut "Update Client Information in Person Record" Aufträge in die Admin4.nsf stellen. Durch debugging von DCC auf Client-Seite stieß ich darauf, dass die Dyncfg.exe auf eine Fehlersituation stößt und keine Aktualisierungsaufforderung schreibt (siehe IBM APAR).
Bevor ich frustiert aufgeben wollte, erinnerte ich mich daran, dass der Lotus Notes Client der aktuellen Versionen nicht mehr nur einmal täglich beim Start sondern bei jeder Serverauthentifiezierung DCC anstößt und ggf. Clientinformatioen aktualisieren sollte. Zur Steuerung dient ein zusätzliches Profildokument "DYNCRINFO" in der Kontakte Anwendung.
Nachdem ich sowohl die entsprechende Notes.ini Variable, als auch das Profildokument gelöscht hatte, stellt der Client auch wieder Aktualisierungsaufträge in die Admin4.nsf sodaß ich nunmehr den gewünschten aktuellen Versionsstand im Personendokument eines Benutzers finde.