Painless spring cleaning of your ACLs, NAB groups, orphan mail files, agent signatures & more!

There are several topics that frequently come up during conversations with our customers because of various combinations of end-user and administrator turnover, poor initial configuration & setup, etc.

A few such examples are database ACLs containing irrelevant entries, groups full of users who left the organization years ago, and design elements signed by administrators who no longer work for the company. Most people only deal with this “junk” when it’s already had an impact on their work process. With this blogpost, we’d like to help you get your Notes spring cleaning underway smoothly so that you can enjoy an issue-free summer.

We’ve recently implemented a new feature in aclEZ, agentEZ, databaseEZ, signEZ and scanEZ called the NAB Presence Checker. This functionality offers a way to run a background check on names displayed in various grid panels across these tools, you can find out more about where to access the NAB Presence Checker in each tool here.

In this post, we’ll examine these new features across our products in the context of solutions to some of the most common and challenging problems. We’ll cover the following subjects:

• Examining all ACLs on your server for old, irrelevant ACL entries
• Finding and removing all outdated person entries in your NAB groups
• Identifying all ‘orphan’ mailboxes (mail files whose owner has been deleted from the NAB)
• Finding and correcting all outdated agent signatures on a server

Since our tools work with names when it comes to ACLs, signatures, group memberships, etc., we thought: “How cool would it be to run a background check on these names to determine whether we can find them in the NAB (or NABs in the case of utilizing the Directory Assistance)?”

Thus, we implemented the NAB Presence Checker feature in aclEZ, agentEZ, databaseEZ and signEZ. By default this feature will run a lookup in the NAB to determine if a given name displayed in our grids is found in your NAB. It will then mark all faulty entries in red and will provide a flag-type column that indicates if the entry wasn’t found in the NAB. You can then use this column for grouping to quickly find all faulty or irrelevant entries at once.

Note that you can disable the feature at any time using the Options menu. Once disabled in one product, this setting will be transparent and stay disabled in all the other tools as well.

Having old ACL entries (whether person, group or server type) in your database ACLs is a scenario that comes up quite frequently in conversations with our customers. These entries make it tougher to oversee your Domino ACL setup.
The NAB Presence Checker feature in aclEZ comes in handy when dealing with this situation. All you need to do is load all ACLs on your server with the NAB presence checker enabled, and group your ACL entries using the “Is name in NAB” column. Once the grouping is applied and you expand the “Unchecked” category (=name was NOT found in NAB), you’ll find all ACL entries that should not be part of your ACLs.
For a more accurate analysis, you might want to apply some additional layers of groupings using the “Type” and “Name” columns. This will allow you to differentiate between the types of ACL entries in question. The screenshot below shows how we can find all old / decommissioned server entries in ACLs.

Once you’ve identified these entries, removing them from all the database ACLs in question can be done easily. Just select them and choose the “delete” action from the right click menu. Note that you’ll need to confirm your actions using the Server \ Apply Changes option.

Tip: If you have consultants or other external users who’ve been cross-certified and added to your ACLs, but do not have a record in your NAB, these NAB entries will be marked as non-existent. For various reasons, you may not want to remove these. In order to get an accurate picture of the state of your NAB, we suggest using the grid filtering options, and making sure that you are only looking at ACL entries with the “/ACME” certifier (in our case). You can activate this by entering the string to include in the filtering options for the “Name” column.

Another situation that’s quite common, especially if you are working with ACL Groups and some sort of key user concept, is when your ACL type groups are supposed to be managed by the application owner. Eventually you’ll end up with groups that contain a bunch of members who do not work for the company anymore, have been deleted from the NAB or changed departments, etc.
We’re going to look at how to find ALL of these faulty groups and remove the irrelevant group members all at once.
In order to oversee all your groups and their members, you’ll need to use the NAB Group navigator tool in aclEZ. This tool will let you exhaustively resolve ALL NAB Groups and give you a list of all users and the groups they belong to. Having enabled the NAB Checker feature, aclEZ will run a background check on each of these member entries to determine whether the actual group member has a record in the NAB or not.

In the tree layout, all members (as well as their parent groups) that haven’t been found in the NAB will be color coded, so you’ll get an idea of the overall status with a quick overview of your group documents.

In the Grid layout (the standard Ytria grid), all members with no NAB record are marked with the “[X]” characters before their names. If you apply a filter on the Members column in this grid to ONLY display entries that start with the “[X]” characters, you can narrow down the entire grid to only look at faulty member entries.

Once you’ve applied the filters and grouped the information displayed in this grid using the Members column, you can examine the faulty names aclEZ found. Then, having made sure that they are indeed irrelevant, expand the grid, select all entries and use the “Remove Member(s) from Groups” feature.

This will let you automatically loop through all the groups in question and remove all selected members without having to do so in the NAB directly.

Orphan mailboxes mean mail files that belong to users who left the company. These mailboxes can eat up a significant amount of space on the server, and identifying them is quite tricky because you would need to compare the list of mailboxes, as well as the person documents that point to each of them.
We’ll use databaseEZ to clean this up, and we’ll use the fact that databaseEZ actually handles the “Mail Owner” information where it applies. If there is a CalendarProfile present, it’ll show the “Owner” field value. Since the value shown here is going to be a name, it has been included in the NAB Presence Checker feature. Then databaseEZ runs a background check to find out whether the Mail owner has a valid record in the NAB.

After the complete database information has been loaded, you can apply a grouping using the “Is ‘Mail Owner’ in NAB” column. The category “Unchecked” will give you all mail files where the Mail owner has no valid record in the NAB. Note that this could also be a result of the fact that the Mail Owner info is incorrect, and this is also something you’d want to be aware of.

Once these orphan mailboxes have been identified, databaseEZ will let you delete them by right-clicking the selection of entries in the main grid and choosing the “Delete” function. Note that you’ll need to confirm those changes using the Server \ Apply Changes feature.

Another application of the NAB Presence Checker feature is in ensuring that your agent signers are in order by using agentEZ.
After loading all the agents (though for this scenario, you would probably want to examine scheduled agents only) and enabling the NAB Presence Checker feature, look at the “Agent Signer” column in the agentEZ interface. Here, the usual color coding applies.

You can use the “Is Signer in NAB” column for grouping, which will let you immediately spot all agents with signatures by users who are not part of your NAB.

In case you use a specific signer ID for agent signatures in your environment (and hold a signEZ license), another great way to solve this problem is to use the built-in signEZ bridge to pass selected agents onto signEZ for processing (option B in screenshot above).

Save any changes you made, then select the agents. Right-click them and select “Sign using another ID”. This action will pass the selection of agents onto signEZ and give you the ability to select a signer ID either from your local machine or the backend signEZ database. Read more on this here.

If you would just like to resign those agents with your current ID file, all you need to do is select the faulty agents and re-save them (thereby actually re-signing them) using the “Sign & Save Selected” function from the right-click menu (option A in screenshot below).

We’ll follow up on these practices with a blogpost on two additional scenarios that will guide you on how to use signEZ and the signEZ batch database to audit and re-sign design elements in your databases across multiple servers. The bottom line is that Ytria tools can help you clean up your Notes environment quickly and easily, and will likely get rid of some issues you’ve always wanted to tackle but never had the time…and it’s much less painful than cleaning out the garage!