Brief Review of DDM
DDM was introduced in Domino 7. You
configure it in the events4.nsf database where you setup probes, filters
and server collections.
The data that is generated by DDM goes
into DDM.NSF. This is a new database with workflow to help you assign issues
to people. Once the issue is resolved then you can close the event leaving
comments if you want. The system will also track multiple occurences of
issues and suggest possible causes and solutions. Some of these solutions
can be automatically applied to the issue or if that is not possible then
it can bring you to the correct place. These are configurable so
you can add your own or adjust the supplied ones.
Introducing DDM into your domain
One important note. Server Collections
are implemented as outlines so anybody editing them must have at least
design access to events4.nsf. The first server that you upgrade to
Domino7 should be your admin server. When you do your first upgrade then
events4.nsf will add in the new probes and filters from the template. Design
Refresh will not do this for you. DDM will also try to remove invalid documents
from events4.nsf.
DDM is self initialising. When the event
task loads up it will create the ddm.nsf. You should now check the ACL.
Some information may start appearing in the ddm.nsf due to existing legacy
events probes. By default the DDM filter will exclude simple events and
all probe configurations documents are turned off.
When your upgrading other servers you
should add the servers to the server collections in events4.nsf on the
hub and then replice it out, upgrade the server and the system will replicate
over the ddm.nsf rather then create a new copy. For new servers you should
point the install to an existing server with DDM for it to pull over a
replica.
If upgrading from 7.x to a higher maint
release then default probe config docs may get disabled when events4.nsf
gets upgraded.
Reports from DDM
Two ways to enable probes, The first
is slow and steady. enable a few probes, review the output and tweak them
and then repeat for the next batch. The second method is the Buckshot approach
where you just enable everything at once.
DDM will detect things like agents in
databases that are not running due to bad signatures or agents taking too
long to run etc. IBM found quite a lot of out of office agents that were
not completing within the specified time in their domain. It can also detect
if an agent was disable due to the design task running on the server.
Messaging probes can detect things like
improperlyu addressed emails. This could be an agent that may be
triggering mail sends.The messaging probes can also detect if multiple
names exist in the NAB for a single user, normally caused by cascaded addressbooks.
Security probes can detect is users
have tried to access servers or databases where they don’t have the correct
access.
The replication probes can detect replication
issues like not being able to replicate due to enforced acl’s
Managing the amount of event reports
Once the probes are turned on you will
start getting a lot of data in ddm.nsf. The first thing to do is start
looking at all the reports and try figure out what might be causing the
issue. One trick is to check to see if there are any other issues in relation
to the same database, this may provide a different solution.
By using filters you can stop documents
from being reported in ddm.nsf. when a filter is turned on then new
events will not be generated and existing event reports will be ‘hidden’
from the views.
You can also adjust the severities of
incoming event reports, either to have to suppressed by a filter or to
make it more important. You can also set a suppression time to stop the
event being reported too often.
If you have scheduled downtime then
it may be a good idea to disable the replicataion probes, this is avoid
getting hundreds of reports of databases that didn’t replicate.
DDM can also correlate events from multiple
servers where the same event is generated by multiple servers. One
little gotcha is never clcik CTRL-A in an embedded view as it will select
more then what’s displayed in the embedded view.
You can use the assign feature to inform
the correct person about an issue. if you change the status yourself
then it is automatically assigned to you.
Events in DDM can have a status of Open,
Closed and Permanently Closed. Closed events can be automatically
reopened by DDM is a change in severity is detected. If an event is permanently
closed then it can never be automatically reopened.
Server collections can have multiple
levels meaning less information for the right people to look at. The messaging
admin may only need to see the data from a small group of messaging servers.
Advanced Concepts
You may want to add a ‘By Database’
view to the ddm.nsf
Views in DDM.nsf are set for manual
updates so they open faster. You may need to hit F9 to get the latest data.
You may want to make a local replica
for faster access.
DDM automatically disables cluster replication
for DDM.nsf
You can also integrate event generators
into DDM.nsf like monitoring stats or ACl changes. The older iSpy probes
from R5/6 can also monitor old servers and report into ddm.nsf
In the Message Documents you can add
in extra causes and solutions. These may get over written with upgrades
but the custom comment will not be over written. In teh correctove
actions you can write your own actions using either formula or lotusscript.
Check out the $Messages hidden view.
You can also create your own message documents for third party applications
that report to the console ( detect if you AV package failed to update
or something )
DEBUG_DDM=1 on the notes CLIENT will
expose a hidden subform at the bottom of event reports to assist in creating
your own probes etc.
Dec's Dom Blog 