There are multiple resources that suggest CIDR Notation may be used in an IBM Domino server’s Configuration. For instance, IP address filter for SMTP inbound connection controls and CIDR address not working on AS400. However, in ALL of my testing, I’ve NEVER seen it work.
The ugly work-around is to convert the CIDR into a format that IS accepted. One shortcut is to use this excellent tool to convert CIDR to IP Ranges: CIDR TO IP RANGES CONVERTER.
Once you have the range, you’ll still need to “manually” format it.
For instance, use the values displayed in the IBM column to represent the CIDR in the first column:
While tinkering with Domino Configuration Tuner today, I noticed that it recommends adding Debug_Logger_Buf_Full_No_Wait=1. However, rerunning DCT after adding the entry yields a different recommendation:
One or more settings were found in NOTES.INI that usually should not be set:
Looks like something squeaked by QA.
Another finding worth mentioning is the recommendation to use CREATE_R85_LOG=1. I don’t necessarily have a problem with that recommendation, but the suggested implementation method is atrocious:
Bring down the server. Back up existing transaction logs, then delete them. Set Create_R85_Log=1 in the server NOTES.INI and restart the Domino server to have new logs created using the updated format. The new logs will have properly aligned I/O blocks. There is no need to verify the current block size. Domino will use correctly format the log even if the block size is 512.
Um, don’t do it that way, please. If you want to use, CREATE_R85_LOG=1:
- Set it in the ini (or via the config doc).
- Disable transaction logging for the server via the server doc.
- Restart the server.
- Verify via a “show server” console command that transaction logging is, in fact, disabled.
- Via the OS, delete the transaction log files (including the nlogctrl.lfh file).
- Enable transaction logging for the server via the server doc.
- Restart the server.
After a number of intermittent and unexplainable issues with active user devices not syncing, I see that IBM has issued a fix in IBM Traveler 126.96.36.199 and later releases.
Once a user reports the issue, you can confirm by issuing the following console command:
tell traveler user "john smith/org"
The output will include:
Traveler: Monitoring of the database for changes is disabled.
The temporary workaround is to issue the following console command:
tell traveler push enable "john smith/org"
Now the “tell traveler user” command should return:
Traveler: Monitoring of the database for changes is enabled.
..and the user’s mobile device will begin to receive the backlog of messages again.
To resolve the issue install IBM Traveler 188.8.131.52 or later and cross your fingers.
LO91723: USERS STOP RECEIVING MAIL AFTER MAIL SERVER IS RESTARTED
I encountered a Health Message for my VCSA 184.108.40.206200 Build Number 5326079.
This led me to Increasing the disk space for the VMware vCenter Server Appliance in vSphere 6.0 (2126276) | VMware KB
However, in the process, I noticed a more serious issue with /storage/log (/dev/mapper/log_vg-log). It was at 98% capacity.
According to the KB article and other reliable sources, I needed to increase VMDK5 to resolve the immediate issue with /storage/log. So, I right clicked the vCenter VM, selected “Edit Settings,” clicked “Manage other disks” (on the Virtual Hardware tab), and increased Hard disk 5 from 10GB to 15GB.
Here is the original configuration:
…and here is how it looked after modification (the sizes were grayed out at the time because vCenter was being backed up by a program that utilizes snapshots and you cannot alter disk size when snapshots are present). Anyway, you will see that Hard disk 5 went from 10 to 15 GB.:
Here is the SSH/Shell before and after:
The Wrong Trousers
Notice something unexpected? Apparently, for my implementation, Disk 5 correlates to /storage/db and NOT /storage/log. In fact, based on this result, it appears that Disk 6 is the one that needs to be grown. Again, that does NOT correlate to other documentation as Disk 6 is referenced as /storage/db in those places.
On a whim and a prayer, I repeated the process for Disk 6, hoping to grow the /storage/log VMDK. Disk 6 was initially 10GB. I changed it to 20GB. Annnnd, bingo:
I’ve encountered this problem in a myriad of ESXi host versions and vCenter versions. For unknown reasons, I am able to migrate some VMs and not others. I’ve tried a number of resolutions in various KB articles, but the only approach that has worked thus far is removing the VM from inventory and adding it back.
Symptoms: Migrate, Move To, Remove from Inventory, and Delete from Disk options are greyed out for a powered-on VM.
To resolve this issue, remove the virtual machine from the vCenter Server Inventory and add it back. Note: When removing a virtual machine from the vCenter Server Inventory, the previous performance statistics for the virtual machine are lost.
Caution: Before performing these steps, make a note of the datastore where the virtual machine resides.
- In the vSphere Client, right-click the powered-off virtual machine and click Remove from Inventory.
- Click Yes when prompted to confirm the removal.
- Click Home > Storage
- Open the Datastore and folder where the VM’s vmx file is stored
- Right-click the .vmx file and click Register VM. This might be “Add to Inventory” in earlier versions.
- Follow the steps in the wizard to add the virtual machine back to the Inventory.
- Click Home > Hosts and Clusters.
- Right-click the virtual machine. The migrate option is now available.
I recently encountered an issue where an ESXi host upgrade caused it to lose it’s connection to an iSCSI datastore. I was finally able to get the iSCSI issue resolved, but then I had an issue where I needed to name the newly created connection the same as the previous. The “old” one was still listed as an “inactive” datastore. I couldn’t name it the same as the old one, but there was no option to delete the old datastore reference.
I finally figured out that I had to remove all VMs from inventory that were still dependent on the “old” datastore. As soon as I deleted those VMs from inventory, the “inactive” datastore was automatically removed. Then I could rename my new iSCSI datastore to match the one that the system marked inactive when the original issue happened during the upgrade.
To avoid “Unable to open log file” and “log.nsf: File does not exist” errors remember to always start Powershell in “Run as Administrator” mode.
In newer versions like Microsoft Windows Server 2012 R2, navigate to the Domino binary directory and then prepend “.\” (without the quotes and with now spaces) before the traditional nwhatever.exe
For example, when binaries are at c:\lotus\domino and you want to run a copy-style compact on the entire data directory…
Start Powershell in “Run as Administrator” mode and your command line will look like this:
PS C:\lotus\domino> .\ncompact.exe -c