Wednesday, February 25, 2015

Setting up Citrix Receiver on Ubuntu

The goal of this project is to make use of the old laptops so that we can run Citrix Receiver on it, minus the headache of Windows patching, and antivirus.

So here is what I have to get it started.
  1. an old laptop
  2. Ubuntu 14.04 LTS 32-bit
  3. Citrix Receiver version 13.1.0

The reason that the 32-bit Ubuntu was chosen was mainly the compatibility issue of 64 bit Citrix Receiver. I started with 64 bit, but the errors were horrible. It seems that the 64-bit Citrix Receiver was trying to use some 32-bit library in a 64-bit Ubuntu OS. So I reinstalled with Ubuntu 32-bit, and the installation process of 32-bit Citrix Receiver was so smooth that I was thrilled to see it.

And the .dev version of the Citrix Receiver failed with an error during installation as well. But the .tar.gz file went very smooth, so I am going to stick with the tar.gz file.

Here are the commands that I used to run to install Citrix Receiver 13.1.0.

cd /tmp/citrixclient

tar xzvf linuxx86-

sudo ./tmp/citrixclient/setupwfc

sudo ln -s /usr/share/ca-certificates/mozilla/* /opt/Citrix/ICAClient/keystore/cacerts/
sudo c_rehash /opt/Citrix/ICAClient/keystore/cacerts/

That is all for Citrix Receiver installation. In Firefox, before you can use the Citrix Receiver for the first time, you will have to activate it in Firefox.
  1. Open the Firefox broswer, go to Tools->Add-ons
  2. Change the option for Citrix Receiver for Linux from Ask to Activate to Always Activate. (Ask to Activate never works, because it never ask to activate). This needs to be done in each user account in Ubuntu, unless you set it in the skel profile, and all the new user created upon it will have the Always Activate set.

And that is it. You will be able to use this laptop to connect to Citrix sessions.

Next time I will show how to create a live Ubuntu image with Citrix Receiver installed, that can run from a USB.

Wednesday, January 08, 2014

How we separated our two office’s AD and Exchange

Our company sold off a branch office last year, and we have been working on the separation of our business and our IT infrastructure. We are a Windows environment. Each office used to be a redundancy of each other, which means that each office has a full Active Directory forest, which contains domains controllers for root domain and all of its sub domains. Users in each office are in its dedicated site sub domain, with its own Exchange servers(in mix environment of Exchange 2007 and Exchange 2003). From the very beginning we came to an agreement with passive cleanup by having an identical AD forest and Exchange organization on each site, and when the cutoff time comes, we turn off the VPN network completely and start to clean up AD and Exchange by removing the objects in the other sites. It needs to be done at Exchange level, Domain level, and User level. We will use these names to in our case. I know, Microsoft doesn't support these type of removal, but to us, it is cheaper, less time, and sounded more straight forward. During the separation, we did learn a lot in a hard way.

root of the domain:
Site North: NorthDC, NorthEX(Exchange server), external email domain is
Site South: SouthDC, SouthEX(Exchange server), external email domain is

We are in the south, so I will state the steps that I took from the point of SouthEX, SouthDC’s view. But in Site North, it needs to have the same things done to the SouthDC and SouthEX objects.

  1. Before the disconnection, make sure you have redundant domain controllers in your forest. For example, if you have a single root domain controller in your site, you might want to create a second one before the disconnection. Never have a single domain controller in your organization.

  1. After the disconnection, the first issue we found was that users in each sites won’t be able to email each other, and all the emails will get stuck in the unreachable queue. This should be expected, since and are still under the same Exchang organization.
    1. Exchange Level: We will need to remove the orphaned Exchange objects that is meant for NorthDC and NorthEX
      1. Remove Recipient Policies. Remove any policies that has anything to do with the other office’s domains. In SouthEX, we removed policies that applied to NorthEX. Otherwise it won’t let you remove from Accepted domains in SouthEX Exchange server.
      2. Removed from Accepted Domains in SouthEX Exchange server,
      3. Remove any connectors and routes to NorthEX
      4. Remove NorthEX Exchange servers in SouthDC via ADSIEDIT.msc.
        1. Exchange servers are under:
      1. Remove Exchange attributes for users in NorthDC
        1. How to Use the Remove Exchange Attributes Option
      2. There might be some emails already got stuck in an unreachable queue. You may issue the retry-queue PowerShell command to resubmit those emails:
        1. retry-Queue -Identity "ServerName\Destination" -Resubmit $true

    1. Domain Level: We need to remove the orphaned Domain Controller completely
      1. Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
      2. You may need to configure a new authoritative timerver in the domain.
      3. Remove old computer account by using "Active Directory Sites and Services" tool.
      4. Remove old DNS and WINS records of the orphaned Domain Controller.
      5. Use "ADSIEdit" to remove old computer records from the Active Directory:
        1. OU=Domain Controllers,DC=domain,DC=local
        2. CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
        3. CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=domain,DC=local
      6. Force Active Directory replication by using "Repadmin.exe" tool:
    2. User level: Most of the users are ok at this time, however, certain users might see a NDR when sending emails to with the following error:
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

This happens when Outlook use email address auto-complete cache for, which was stored with X.500 address format when under the same Exchange organization. This old X.500 address was causing Exchange to reject the emails. Since Exchange 2000, the X.500 address has been stored in the leGacyExchangeDN attribute in AD. This value was set when a mailbox was created in Exchange 2003, includes the name of the Exchange administrative group where the mailbox belongs. The fix to it is either create a X.500 proxy address for users, or clear the Outlook email address auto-complete cache.

It has been a month after the separations of two offices, we haven’t seen other issues yet. Drinking a cup of coffee, and crossing my fingers now ...

Wednesday, June 27, 2012

ESX fails to boot error: Error 15: Could not find file

Recently when I used VMware Update Manager to patch a newly rebuilt vSphere 4.1, it couldn’t boot up when it was rebooting. Using DRAC to login into its console and found this error.

I did a search and found this in VMware forum communities. VMware KB1004574 kind of mentioned the reason behind this: /boot/partition ran out of space. My /boot/ at that time had 16 MB, and during patching it needs at least 24MB to boot properly, which is the size of the new initrd-2.6.18-xxx.ESX.img. When space is less than 24MB, the new initrd-2.6.18-xxx.ESX.img file (in my case, it was initrd-2.6.18-274.ESX.img) can’t be created, which causes initrd has a broken link to a non-existing file. 
If you are able to login into Troubleshooting Mode, it would be an easy fix. In /boot, with command ls -l, you will able to see the red broken link. All you need to do is relink it to a valid existed initrd-2.6.18-xxx.ESX.img by using ln -sf initrd-2.6.18-238.ESX.img. Reboot the server now and it should come back up. However, in my case when I try to enter into Troubleshooting mode, it ran into an infinite loop of signature mismatch error.

Then I found this VMware KB1007908, and I chose the second option for me, which worked perfectly well. It uses a live CD to boot the server into Linux, and fixes the host’s grub.conf from a chroot environment to point to a valid img file. The main concept here is to have initrd file linked to a valid img file to make the host bootable. After the host is able to boot up, we will have to clean up the /boot/ partition, and run esxcfg-boot -b to fix the normal boot image and esxcfg-boot -t to fix the troubleshooting mode image. Here are the command I used when I boot into the live CD:
fdisk -l | more  
mkdir /mnt/esx  
mount /dev/sda2 /mnt/esx  
mount /dev/sda1 /mnt/esx/boot  
mount /dev/sda5 /mnt/esx/var/log  
chroot /mnt/esx  
ln -sf initrd-2.6.18-238.ESX.img initrd.img

After the host booted up, I ran the following commands.  
mv /boot/initrd-2.6.18-194.ESX.img /tmp/  
esxcfg-boot -b #this will create initrd-2.6.18-274.ESX.img  
ln -sf initrd-2.6.18-274.ESX.img initrd.img  
mv /boot/initrd-2.6.18-238.ESX.img /tmp/

Now, everything is back to normal.

Wednesday, November 02, 2011

How to make DRACT run in a 64-bit system

Dell™ Remote Access Configuration Tool (DRACT) is a tool that provides a central console to discover and configure Dell Remote Access Controller (DRAC) for all the servers in your network. It automates some of the common repetitive tasks, such as firmware upgrade, and AD authentication configuration.

As of Nov 2011, the latest version of DRACT is 1.0, which can be run in 32-bit Windows systems only. Nowadays, 64-bit systems are commonly used everywhere. Setting up a system just DRACT is kind of wasting resource. After some research, I found out that we CAN make it run in 64-bit environment.

You can have DRACT installed into a 64-bit system without problems. The symptom showing it is not working is that it can not discover any DRAC in your network. Here is what you need to do to make it work.
1) You need a file: corflags.exe in Microsoft SDK. You can install Microsoft SDK, or you can just copy corflags.exe from a system that has Microsoft SDK installed. Corflags.exe is a Conversion tool allows you to configure the CorFlags section of the header of a portable executable image.
2) Run the following command of the ract.exe executable file: 
corflags.exe /32bit+ “D:\Program Files (x86)\Dell\RACT\RACT.exe”
The /32bit+ sets the 32-bit flag, so that the executable file always runs under WOW64 in a 64-bit system. (WOW64 is a compatibility environment that enables a 32-bit application to run on a 64-bit system. WOW64 is included in the system.)

That is it. Now DRACT will be able to discover the DRAC with the IPs that you provide in your network.

Wednesday, November 17, 2010

How to Cancel a Stuck VMware Tools Install

Some co-worker ran into a problem with not able to VMotion a VM off a vSphere host. The error is “The virtual machine is installing VMware Tools and cannot initiate a migration operation.” Right click to “End VMware tools install” won’t help. After some digging, we found it can be resolved in two ways.
1) Click on the VM, go to the toolbar on the top in vSphere client, click on the CD/DVD icon -> CD/DVD Drive 1-> disconnect. This should resolve the issue and you should be able to VMotion this VM after this. This mostly happens to a Linux VM after it upgrades its VMware tools.

2) Found this in Bob Plankers’ The Lone Sysadmin blog. It works great too.
First, you need the ID of the VM (all on one line if it wraps):
/usr/bin/vmware-cmd /vmfs/volumes/datastore-name/vm-folder/vmx-file.vmx getid
Then you can do a:
/usr/bin/vmware-vim-cmd vmsvc/tools.cancelinstall idnumber

Wednesday, September 08, 2010

P2V fails at 94% after finished cloning disks

Physical server rebooted itself when VMware Converter reached 94% or 98%. By the time of its crash, it had already finished cloning its disks, and failed while it was trying to connect to the VM or reconfigure the VM. And the VM always goes to BSOD when it boots up.

The cause the reboot of the physical server is unknown. It involves the physical hardware, the OS, and the application, and none of them can pinpoint where the failure comes from.
The cause of the BSOD in the VM is the virtual disk controller driver isn’t in place and the VM isn’t configured to be ready to run in a virtual environment.

In the VMware Converter, run “Configure Machine” and use the wizard to configure the VM. After it is finished, we should be able to power on the VM into Windows.

Thursday, November 19, 2009

VMware Update Manager 4.0

Can't download patchs via VMware Update Manager 4.0

My environment is known for having complex firewalls and proxy. Lots of time it takes lots of effort and time to make application works. This time is no exception for VMware Update Manager 4.0.

The installation process for VUM 4 was very straight forward. Then it comes to the hard part. It can't download any patches for ESX hosts nor for VMs. After lots of testing, and some help from VMware's communities forum, finally I made it work. Here is what I have done.

1) Have proxy server opened up HTTP/HTTPS to the following 3 domains: *, *, and * The last domain is not for downloading patches, but for Test Connection since that is one of the websites that it use to test connectivity.

2) Set up proxy setting. Do not put http in front of your proxy server name in the box. Make sure you have the right authentication information in it if it is required.

If you are seeing some errors like this, it could be caused by your proxy setting.

httpDownload, 730 Error 12007 from WinHttpSendRequest for url                


'httpDownload' 4284 ERROR [httpDownload, 726] Error 12029 from WinHttpSendRequest for url

Please check out the following KB for more information.