Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
@Thomas: Oops, I was referring to you oldest post. sorry :)
@Thomas: Basically a good idea. But include a warning, that many settings are also already set by dedicated entries in the configuration or server documents document already. If you set both the opion in the config doc and as a managed notes.ini setting in the same document, this will mess up the document and can lead to weird behaviour. Sometimes the ini setting simply overrides the previously set value, sometimes not. You would have to include a dedicated checkbox for each and every possible notes.ini value, which would overload the document structure. And while changes to configuration documents are typically dynamic and come effective without restarting the server or server tasks, not all notes.ini settings behave like this.
For reference ( has been posted in this thread earlier) https://www.NotesCamp.de/notesini
A notes.ini database wold be very helpful. This would solve many related issues as well.
I mostly liked DCT, and I did find it useful for these kinds of things where you just don't know that you should used x ini setting anymore. Or that someone added a debug ini and it's still there 3 months later.
I also like the repository database of notes.ini. This brings us back to the days, where on Notes.net, we could create replicas of the discussionR.nsf app, and never leave our Notes client. It was one of the two times we had our highest participation in the peer-to-peer support discussions we all had.
This notes.ini library would be a small library app, that would not pose any significant load or security risks by having it in our more "general" Domino servers. We'd have to individually cross-certify or Notes clients, our O, or our server(s) with "notes.net" again, though. I remember it being a very quick "onboard".
yes, that could be an option as well @thomas, has DCT been updated lately?
What if DCT would be update to provide you with information on which Notes.ini is obsolete and which new variables are recommend to be set? https://domino-ideas.hcltechsw.com/ideas/DOMINO-I-73
I recently opened a Support Case with HCL, and asked them to update the technote.
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0032795
The update was the addition of a line that states: "Note: Obsolete notes.ini settings have not been formally tracked since V9.0.1. If we become aware of any new obsolete settings, we will post them in this article."
I'm preparing for the V12 upgrade and came across this link.
Please update the TN What notes.ini variables have become obsolete in Notes & Domino?
"How about removing interaction with notes.ini altogether and having all the settings built out on the server document, with recommendations/etc listed right alongside?" +1
How about removing interaction with notes.ini altogether and having all the settings built out on the server document, with recommendations/etc listed right alongside?
why not using a similar function to update the notes.ini Parameter documents like updating pubic Holiday schedules.
Once the new template is set to names.nsf design tab in the Database properties you could use an Action to Import/update Holiday from Template.
This should also work with notes.ini Settings.
Everything in the notes.ini should be able to be set via a policy setting on the domino server.
Old, deprecated settings should be separated to their own section so people realize these are no longer the way you should do things and can move towards the new ways. For each replaced parameter in the deprecated Tab the recommended replacement options should be noted beside the old deprecated setting so that users can easily see where they need to go to update their old settings.
The idea of a server console log print to show deprecated parameters would be helpful. I noticed WebSphere logs do this for certain settings. Also one of the things that I like about a Traveler SystemDump is the listing of all non-standard or non-default ini parameters, what the defaults are and what the setting is configured to on the particular server. I think it would be helpful to do the same for Domino servers and print that in the NSD.
I like the idea of a notes.ini database with documentation of all the whys, when to use, and effects/affects for each.
add the information to DCT and make sure it's updated regularly/automatically
Just update DCT regularly.
A beginning has been made and around for years, open to new ini variables and free. Can be replicated and is maintained by me.
https://www.NotesCamp.de/notesini
please allow in such a tool also the automatic reorganization of the notes.ini parameters in sections for easier reading and finding values. Something similar had been done by an online tool called INIGEN by Darren R Crocker, tool which is not maintained any more, afaik...
Make it a Notes application that is hosted by IBM/HCL and can be replicated by everybody.