Lotus Notes Profile document management and troubleshooting with scanEZ

Though scanEZ is very much a general purpose Lotus Notes and Domino database toolkit, folks often tell us that Profile document issues were what compelled them to download and try the software in the first place. This post will briefly go over the basics of Profile document management with scanEZ; plus show you how to spot Profile conflicts; and finally explain how to deal with ‘enumeration pool is full’-type errors.

One of scanEZ most basic features is its Selection Tree, which gives you the ability to explore all the Profiles in a Lotus Notes database—along with anything and everything else inside an NSF file (e.g. Documents, Designs, Conflicts, Deletion stubs etc.). This explorer gives you a fast and very convenient way to see all your Profiles and spot any problems.

When you click on a Profile in the Selection Tree, you’ll see all its fields and their values in a sortable item list. The Profile’s Note Info (e.g. UNID, Note ID, Creation dates, etc.) is also shown.

Editing Profile docs in scanEZ is an equally simple point-and-click affair. There are options for adding and deleting items. And you can click any field to edit its contents (either manually or by formula) or type.

Please note that Profile caches in Notes are extremely ‘sticky’ (and we’ve subjectively observed that they’ve become even more ‘sticky’ in recent Notes versions). For example, changes made to a Profile by one user might take a while to be seen by another user of the database; and the server itself might take a while to ‘see’ changes. So if you edit a Profile in scanEZ and you have the database open in your Notes client, don’t be alarmed if the changes don’t appear right away.

Just a quick note: If you ever notice a Profile document has a response (shown in a response tab in scanEZ), it means that it has a conflict—Profiles should never have responses. We came across this (thankfully uncommon) issue when doing some troubleshooting with scanEZ ourselves: we had noticed that changes made to a Profile on a database were not being applied to a replica. So we opened the Profile in scanEZ and saw something similar to the screen below.

When you double-click the response document to open it and look at its fields, you’ll notice that there is a $Conflict item. These Profile conflicts can cause problems with database functionality as one Replica might use the ‘parent’ Profile while another Replica uses the response/conflict Profile.

Basic Profile doc viewing and editing is probably old hat for veteran users, but one common issue would confound even scanEZ in the past is now easily solvable—the ‘Profile document enumeration pool is full’ error. This error occurs when Notes reaches a 6000-ish profile document ceiling (described in IBM Technote). Functionally speaking, this won’t break the Profiles themselves but it does prevents the getProfileDocCollection from working (and it also prevents scanEZ from building the Profiles category in the Selection Tree).

It’s pretty easy to reach this ceiling when a widely-used database makes use of personal Profiles (e.g. a shared calendar). Additionally, if you search for a non-existent Profile using the getProfileDocument Lotusscript method, a blank one will be generated. Similarly, a blank profile will also be created if you cancel (or close without saving) a form which makes use of the @Command([EditProfile]). All of these things can really run up your Profile document tally to an extent that you’ll trigger the enumeration pool error. (Aside: these cases where blank Profile documents are created can be double trouble when users have Author access to the database: Since the required Authors field hasn’t been created, users are likely to see error messages the next time they try update the profile. Naturally, scanEZ is helpful in finding and troubleshooting these types of Profiles issues).

Our solution for dealing with ‘enumeration pool is full’ errors is included in the scanEZ Extension Database, which includes a feature called ‘Lotusscript-based Note Retrieval.’ This feature neatly sidesteps the enumeration pool error and places all your profiles in a My Section Virtual folder. Here’s how it works:

1) Open the scanEZ Extension Database (download it here if you don’t already have it).

2) Select the database with the enumeration pool error.

3) Make sure to check the box for ‘Profiles’ then click the Open in scanEZ button. Once the retrieval is complete, it will display the number of Profiles found and ask if you’d like to continue; click ‘Yes.’

4) Now scanEZ should launch. You’ll be prompted to choose your preferences for displayed titles, just click ‘OK’ to use the default.

5) All the databases Profiles will now be listed in the Section Tree in a ‘My Selection‘ virtual folder. From here you can analyze, edit, or delete the Profiles.

Please note that this method of gathering a list of Profiles is considerably less efficient that the normal way that they’re shown in the scanEZ Selection Tree, so it should only be used in cases where the ‘enumeration pool is full’ error is triggered. If you don’t need to see all the Profiles, you can always use the Document>New/Get Profile option to see any specific Profile as long as you know its key (document name and username if applicable).