Changing Terminal Server/Citrix User's File Extensions

I recently had an issue where users on a terminal services session (Citrix) could not change their own file extensions. They could "open with" but like typical end users - this is too much work. I set out to find a way to set this in a more reliable fashion. Of course, if you "open with" you often get the "always use the selected program to open this kind of file" but for whatever reason this sometimes doesn't work. Below are instructions for setting the file association on a per user basis, manually. To do this on a per server basis, see the Microsoft instructions on how to accomplish this.

Procedure for changing someone’s file association in Terminal Server:

Most info is here: http://www.brianmadden.com/content/article/Creating-Custom-File-Associations-to-Support-Side-by-Side-Applications
1. Run “ftype > c:\ftype_output.txt”
2. Look in c:\ftype_output.txt for your program, and make note of the associated name, e.g. Word.Document.8
3. Log in as the end-user, and launch regedit.exe
4. Navigate to HKEY_CURRENT_USER\Software\Classes
5. Create a new Key under Classes. Name it whatever your extension is e.g. “.txt”







6. Edit the “(Default)” REG_SZ value under the newly created key and put in the associated name you noted in step 2. In this case it is Word.Document.8









7. You should be able to test the new functionality immediately. No logoff/logon needed. In my example, files with the .txt extension open with Microsoft Word 2003.

VMware Consolidated Backup, Scripted

I was recently tasked with automating the backup of our VirtualCenter and ESX environment. More specifically, we needed to backup our virtual machines (VMs). When you buy ESX and Virtual Center, you automatically get VMware Consolidated Backup, or VCB. There are framework tools you can install on a windows box to script the vcbMounter command, but I luckily found an even better command: vcbSnapAll. This command can be run from any ESX host (we are on version 3.5) and backs up all VMs that are in VirtualCenter. All of our VMs are stored on a single SAN, but we want to backup to a secondary VMFS partition in case the SAN is completely lost. Below is the syntax I used.

vcbSnapAll -u backupuser -p mypass -a any: -r /vmfs/volumes/MY_SECOND_STORE/

This backs up all VMs listed in VirtualCenter, powered on or off. You can check the syntax options for vcbSnapAll to see what else you can do. There aren’t too many options. If you want to get really granular, you’ll need to write a custom script and use vcbMounter. When vcbSnapAll runs, if you check the running processes, you’ll see that the command is just a wrapper for vcbMounter. Anyway, I then wrote a little script to make room for a second backup. You can’t run vcbSnapAll a second time unless you move the backup files it created out of the way:

#!/bin/bash
#Brad Smith 05/07/2008
#
#This is to clear the previous *OLD* backups
rm -rf /vmfs/volumes/MY_SECOND_STORE/previous_backup/*
#
#
#This is to move the previous backups out of the way, but keeping them in case these backups don't work
mv /vmfs/volumes/MY_SECOND_STORE/* /vmfs/volumes/MY_SECOND_STORE/previous_backup/
#
#
#This actually backups the VMs to the secondary storage
vcbSnapAll -u backupuser -p mypass -a any: -r /vmfs/volumes/MY_SECOND_STORE/

The last step is adding the script (which I created in /root/scripts) into crontab. For you who haven’t much experience with cron, check out this link. It isn’t too confusing. Anyway, here is the line I added in /etc/crontab:

01 04 * * 6 root /root/scripts/weeklyVMbackup

This kicks off the backup at 4:01am, on Saturday morning, and runs as root. When the script completes, check /var/log/vmware/ for the result of your backup. Additional scripting should be done to send these log files if they fail! Too lazy for now to do this.

As always, post comments or questions.