Upgrading the design of the NAB, replication and designer gotchas.

I’m writing this post to help some soul out there. There are lots of organizations that get themselves into multiple Domino point release upgrades and avoid upgrading the design of their NAB because it’s too much work, or they’ve forgotten the design changes they’ve made and don’t want to break anything, or too busy, or….

Our organization was in that state, and I’ve been working for the last 2 weeks to find the changes, customize a clean 6.5.6 template and roll it out. It’s actually been a pretty large chunk of work getting it right.

I found a big gotcha today when I tried to roll it out to my production environment.

Here’s the list of items I presented to my team after I was sure that I had all the customizations in a new template on a test server that I was working on.

First, I used Team Studio Delta to compare what we had with the default 6.5.6 pubnames.ntf. I also looked through the directory itself to make sure that there weren’t any design elements that had “prohibit design replace or refresh” checked.

I also created a test server in our domain without any connection documents to / from it. I made a database copy of our production NAB so that if anything wrong with the design, I couldn’t accidentally replicate the design from the test server to the production environment inadvertently with my admin client.

Here was my little plan:


  • NAB customizations documented in the MIS Messaging team database.
  • Template has a different replica ID than the old ngpubnames.ntf
  • Template’s new filename is ngpubnames656.ntf
  • Template name changed to NobleDD656
  • Field added for NGMailSerial (so that we don’t forget about it – a custom field we use for AXSOne Archiving)
  • Field added for OnNet extension (our voice over IP extensions)
  • LDAP attributes updated to include City and Country (previously only City).
  • LDAP queries will now be authenticated
  • People view display column has been corrected so that there is now a space between middle and last name if a person has a middle name. This affects view sorting slightly. Previously, David Wayne Killingsworth was at the top of the David’s, now David Wayne Killingsworth is sorted properly in alphabetical order. Example: John Kennedy Stewart is listed after John Barcy, but before John Larkin.
    Rollout Process:

  • Backup existing ngpubnames.ntf in MIS Messaging team database prior to making any changes to the template (done).
  • Sign ngpubnames656.ntf with Notes Admin/Noblegroup (done)
  • Disable replication of NABTest/Noblegroup
  • Delete ngpubnames.ntf from hub2 using the admin client and select “Also delete replicas of this database on all other servers” so that adminp removes the old template from the domain.
    Verify that it has been removed from all servers after adminp processes and replicates (takes about 1 hour).
  • Administrators should double check that they do not have a local replica (48257307:0039A20B)
  • Disable replication between hubs and Directory/Noblegroup
  • Create new replica of ngpubnames656.ntf on Directory/Noblegroup
  • Update \\directory\names.nsf so that it inherits it’s design from NobleDD656 instead of NobleDD as an additional safety precaution that designer task and an old template could pollute the design.
  • “load design -f names.nsf” on Directory/Noblegroup
  • Verify design looks correct
  • Enable replication between hubs and Directory/Noblegroup
  • Backup ngpubnames656.ntf in MIS Messaging team database.

From this point forward the template will only exist on Directory/Noblegroup with a backup in the team database. Any changes can be made in one location without fear of the designer task on one of the various servers updating the NAB with an out-of-date replica.

All this went off without a hitch. I was able to isolate my administration / LDAP / Registration server by disabling replication from the Hubs. I moved the new template from our test server to the administration server. I signed the template with our signor ID just before refreshing the design of our production NAB on our administration server.

All worked fantastically.

Then I enabled the connection document from one of the hubs to the administration server. A few of the custom agents replicated, but not the views or person form.

I double checked the ACL, I made sure that my admin ID or the server ID wasn’t in a group or sub group inadvertently that were listed in the ACL. no luck.

I double checked the replication settings. I double checked that “prohibit design replace or refresh” design property wasn’t set. I double checked that each individual design element were not ineheriting their design from another template. no luck.

I deleted the replication history of the NAB on the hubs. no luck.

I read a few posts on the Lotus Notes 6 and 7 discussion forum at ibm.com about copying and pasting design elements and how that can cause design IDs that are lower than the production one. I did copy and paste some of the elements, but those elements were the agents that were already replicating correctly. I started to panic. I found this post and created a new template from the NAB on my administration server which seemed to be looking correctly. I refreshed the NAB on the administration server from the template that I had just created from it. No luck.

I refreshed the design on the hubs from the template on the administration server. that worked, but then the design would not replicate from the hubs to the other spoke servers.

I then noticed that the person form was signed with my signor ID on August 15th, but all other forms were signed with the signor ID on the 18th(yesterday). I thought that was weird.

So I went in and tried to sign the template again and refresh the design. I got an notification in the status bar that 1 database was processed with no errors. I looked at the person form in the template again with the designer only to see that it was still signed on the 15th and the other elements were signed on the 18th (yesterday). What in the world??

I read a couple of posts about this on the IBM/Lotus forums about not being able to sign a database, so I followed the advice I found there and closed all my notes, admin, designer clients and deleted cache.ndk.

I re-opened them, and tried to sign the template again. No change!!!!

I then took another admin ID signed the template. Tadaaaaa. Success.
I then re-signed it with my signor ID and Tadaaa. Double success.

I then refreshed the design on my administration server, and replicated from the hubs to the administration server and the hub started replicating the changes for the administration server and then to all of the spoke servers without any problems.

I will have to say that I was very frustrated for a few hours there. I’m glad it’s all behind me now, we have documented NAB template, we have a controlled NAB template, and any future changes that need to be made can be done so easily with a good understanding of what we need to change.

Over and out…

2 Responses to “Upgrading the design of the NAB, replication and designer gotchas.”

  • I’m curious David…. after going through all this trouble, why didn’t you just locally install a Domino 8.0.1 server and take the pubnames.ntf from it, and use THAT as your basis? The NAB template has always been diligently backwards compatible. And that way you would have future-proofed your new template all the way to 8.0.1. And you wouldn’t have to go through this process again until you jumped past that version.

    I look at the list of changes you’ve made, and I see 5 actual design changes…

    1) Field added for NGMailSerial

    Does this actually need to be in the design? You can create and maintain the field on the backend without modifiying the form.

    But if you absolutely MUST have it on the form, why not put it in the $PersonExtensibleSchema subform? The contract for the subform is that Lotus will never ever change it, but will always include it in the Person form. So it’s designed specifically for you to add your own fields.

    2) Field added for OnNet extension

    Ditto above.

    3) LDAP attributes updated to include City and Country

    Why did this require a design change? Can’t you adjust your schema instead? That’s maintained in data-only.

    4) LDAP queries will now be authenticated

    This can be done with an ACL setting. We do it in the Bleedyellow environment today.

    5) People view display column has been corrected so that there is now a space between middle and last name if a person has a middle name.

    I would categorize that as a bug, and I bet IBM would as well. In fact, if it’s been reported at all, I bet it’s been fixed in the newest rev of the template.

    Just looked on an 8.0.1 server, and here’s the MiddleInitial part of the column formula….

    @If(MiddleInitial !=”";” “+@Trim(@Subset(MiddleInitial;1));”")

    So yep.

  • Dan Soares says:


    Thanks for mentioning that lil tidbit about ‘$PersonExtensibleSchema subform’ . I had no idea.

    That is very useful t know.


Leave a Reply


I'm currently available
for Lotus Notes / Domino consulting engagements.


Connect with me: