AppData location for scripts running under SYSTEM account

Found this answer to my question today:

AppData location when running under System user account

As it took far too much Googling to find this, if you need to access the AppData folder for the System account, go here:

I hit this because we needed to clear the NuGet package cache for a TeamCity build agent which was running as a service under the System account.

Updating LSI Firmware from Running Win10 VM

Updating the Firmware on the LSI 9201-16i

I found this very helpful when flashing my two new LSI 9201-16e HBAs in my servers.  After downloading the update package from here (9201-16e_Package_P20_IT_Firmware_BIOS_for_MSDOS_Windows), I shut down my Win10 VM, went into vCenter and made the LSI 9201 available for passthrough.  I added a new PCI device to the Win10 VM, accepted the memory reservation notice, and started the VM up.

The key piece that I had missed when attempting this several days ago was running the command prompt as Administrator.  Without this, I could not get sas2flash to even find the LSI adapter.

Then I gathered everything together from the update package:

  • \Firmware\HBA_9201_16e_IT\9201-16e.bin
  • \sasbios_rel\mptsas2.rom
  • \sas2flash_win_x64_rel\sas2flash.exe

To verify that sas2flash.exe could see the device, I ran:

And then to flash it:

And it worked! Then I ran the -listall command again to confirm the FW and BIOS versions were updated.

Hope this helps!

Fixing freezes on CentOS / VMware / Firefox

I kept having random freezes on my desktop running CentOS 6.7. I run a win7 guest, as well as Firefox on the host. On many occasions, the system would just hang for over 10 seconds at a time, with the only symptom that the CPU usage would spike for the duration. When it was happening regularly, I fired up top and saw that khugepaged was hitting 100%.

I found this page detailing how to disable khugepaged, and after going through the steps and rebooting the host, I have not seen the problem resurface yet!

How to use, monitor, and disable transparent hugepages in Red Hat Enterprise Linux 6?

Fixing Misbehaving Outlook Search Folders

Every once in a while, I’ll fire up my laptop and open Outlook 2010.  My Today’s Mail search folder will show me messages from last week, or any date / range other than today.  I’d not been able to figure out how to force Outlook to update the search folder’s index, until today:

How to troubleshoot Search Folders in Outlook 2010, Outlook 2007, and Outlook 2003

The relevant section that solved my problem this morning reads:

  • To manually delete all Search Folders from the information store, click Start, click Run, type outlook.exe /cleanfinders in the Open box, and then press ENTER.
  • After you use the /cleanfinders start up switch, your Search Folders will be deleted from the information store the next time that you start Outlook 2010, Outlook 2007, and Outlook 2003. However, the deleted Search Folders will still appear in Outlook 2010, Outlook 2007, and Outlook 2003 as inactive folders. If you want to continue using these Search Folders, click the Search Folder that you want to use. If you do not want to continue using one of the deleted Search Folders, right-click the Search Folder, and then click Delete.

I was a bit unsure of what would happen, as I thought it would possibly require me to recreate my search folders afterwards, but it does exactly as it says in the post.  The command deletes the data from the information store, but leaves the search folders intact.  Once this was completed, I just clicked on my Today’s Mail search folder, which was in light gray italics, and it updated to contain today’s mail!  Amazing!

IBM Mainframe FTP – extended ASCII problem solved

I came across an issue when adding some new data to an existing FTP transfer in one of our nightly batch jobs.  The current functionality is only transferring standard ASCII encoded characters to an IBM mainframe dataset without issue.

The new version of the job, however, will be sending a block of extended-ASCII values in a field that we were not previously using.  The issue started when I had the new field populated and sent some test files to the mainframe.  The new extended-ASCII field was not being properly mapped to EBCDIC during the transfer, and the result consisted mainly of ‘?’ characters.

I tried changing the FTP transfer mode to binary, but that only made the rest of the file unreadable without viewing as hex values.

After searching around for a while, I found this post on technet dealing with Spanish characters not translating through FTP to a mainframe.  The fix for his issue, and mine, was to change the encoding used to call GetBytes with.  Instead of using Encoding.ASCII, I am now using the Windows-1252 encoding, which is providing correct results in the FTP file.

Update: Found out that the Windows-1252 encoding does not map all values from 0-255.  Several characters in my sample data were being encoded as the byte ‘3F’ instead of the correct value.  I found this post on stackoverflow, which pointed me to the true answer to my problem.  I have updated my code to use ISO-8859-1, which retains the original byte value after encoding.  I also changed the FTP connection to binary mode, and no longer have to write the “\r\n” newline bytes after each record.

The code below is using the library System.Net.FtpClient, found on CodePlex.