DCT Idiosyncrasies

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: 
DEBUG_LOGGER_BUF_FULL_NO_WAIT=1

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:

Recommendation: 
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:

  1. Set it in the ini (or via the config doc).
  2. Disable transaction logging for the server via the server doc.
  3. Restart the server.
  4. Verify via a “show server” console command that transaction logging is, in fact, disabled.
  5. Via the OS, delete the transaction log files (including the nlogctrl.lfh file).
  6. Enable transaction logging for the server via the server doc.
  7. Restart the server.

IBM Traveler / Verse Device Stops Syncing

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 9.0.1.17 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 9.0.1.17 or later and cross your fingers.

LO91723: USERS STOP RECEIVING MAIL AFTER MAIL SERVER IS RESTARTED

Increasing (The Wrong) VMware vCenter Server Appliance 6.0 VMDK

I encountered a Health Message for my VCSA 6.0.0.30200 Build Number 5326079.2017-04-26_22-03-40

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.2017-04-27_0-29-50

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:2017-04-27_0-36-04

…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.:2017-04-27_0-39-06

Here is the SSH/Shell before and after:2017-04-27_0-41-20

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:2017-04-27_0-15-54

Migrate Option Is Grayed Out

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.

  1. In the vSphere Client, right-click the powered-off virtual machine and click Remove from Inventory.
  2. Click Yes when prompted to confirm the removal.
  3. Click Home > Storage
  4. Open the Datastore and folder where the VM’s vmx file is stored
  5. Right-click the .vmx file and click Register VM. This might be “Add to Inventory” in earlier versions.
  6. Follow the steps in the wizard to add the virtual machine back to the Inventory.
  7. Click Home > Hosts and Clusters.
  8. Right-click the virtual machine. The migrate option is now available.

Can’t Delete Inactive ESXi Datastore

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.

Running Domino Commands in Powershell

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

Unbricking A TP-LINK TL-WR841N Wireless Wi-Fi Router

This procedure is entirely based on the information obtained from this You-Tube video. I simply needed to refer to the procedure multiple times when experimenting with DD-WRT, OpenWRT, and the stock firmware and it is more efficient for me to follow the written form. The procedure works perfectly for my TL-WR841N V11.x. Please follow Richard Lloyd’s YouTube page for this and other useful information in video format. I didn’t do it; nobody saw me do it; there’s no way you can prove anything!

TL-WR841N_back

  1. Download the version-specific firmware for your TL-WR841N from TP-LINK’s website. My TL-WR841N V11 works well with Firmware Version: 3.16.9 Build 150616 Rel.52099n.
  2. Unzip the downloaded firmware.
  3. Rename the extracted file to wr841nv11_tp_recovery.bin (v11 is used because the hardware (and firmware) is for a Version 11 router).
  4. Download and install the 32-Bit version of Tftpd32 found here.
  5. Disable your wireless card(s).
  6. Connect your PC directly to the router’s port #1 using a network cable.
  7. Assign the following static IP information to your PC’s NIC:
    1. IP address: 192.168.0.66
    2. Subnet mask: 255.255.255.0
    3. Leave all other network settings “as is.”
  8. Launch Tftpd32 and set:
    1. Server interfaces: 192.168.0.66 (via the drop-down selection)
    2. Current Directory: The directory where your renamed firmware from step 3 resides. You can click the “Show Dir” button to confirm that the firmware is visible in the chosen directory.
  9. Hold and continue holding the “WPS/RESET” button for three seconds after using the ON/OFF button to power-cycle the router.
  10. You should see the router grab the firmware update from the TPTP Server status window. The router’s peer address during this process is 192.168.0.86:xxxx.
  11. Close Tftpd32 and wait a minute or two for the router to “settle.”
  12. Change your PC’s NIC from static back to “Obtain an IP address automatically.”
  13. Open 192.168.0.1 in a browser and confirm that the TP-LINK firmware loaded correctly.