Example of Video Post

/ / /

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce feugiat nibh a erat blandit, eget convallis ligula commodo. Nullam ipsum enim, dictum at laoreet sed, blandit at augue. Proin ac metus sit amet leo gravida dapibus. Ut volutpat, sem non vestibulum consequat, mi sapien semper ante, ut ultrices magna nisl nec lectus.

Read More

Examle of Audio Post

/ / /

Etiam euismod eget lacus quis venenatis. Cras venenatis tellus massa, vitae feugiat enim hendrerit sed. Vestibulum sit amet vestibulum orci. Nam congue, sem ac elementum accumsan, dui mi auctor est, aliquet scelerisque eros sem nec arcu. Praesent eleifend nulla elementum felis porta lacinia. In hac habitasse platea dictumst. Vivamus a congue erat.

Read More

Citrix PVS bootup failure with the Boot Device Management ISO

/ / /

We had an issue recently with some Citrix Provisioning Servers (PVS) that were not getting a DHCP address when booting off of the Boot Device Management ISO (BDM.ISO).  What was happening is the server would just show this:

DHCP Discover ._._._._.

DHCP maximum number of retries reached.

When booting off of PXE or a WinPE CD I was getting DHCP without issues.

When I did a Wireshark of the line I saw the BDM.ISO boot send out DHCPDISCOVER packets but it never received a response.  I then Wiresharked the WinPE and PXE boots and saw the DHCPDISCOVER packet, followed by a DHCPOFFER, and so on.  When I examined the two packets I saw the BDM.ISO DHCPDISCOVER packet actually was a BOOTP unicast whereas the PXE and WinPE packets were BOOTP broadcast.  Thinking we had a DHCP Relay issue we checked our DHCP server (an InfoBlox server) and checked the logs for the MAC Address and here is what we saw when we booted with the BDM.ISO:

BDM.ISO DHCP traffic

The DHCP server was not responding to the DHCPDISCOVER.  This only occurred with the unicast packet and for some reason was “load balance to peer”.  However it’s setup, it appears UNICAST BOOTP packets are setup for load balancing but not sending a response.

PXE/WinPE DHCP traffic

The DHCP server is responding to a BROADCAST BOOTP packet in a very different way.  There is no load balancing going on and the server responds to the DISCOVER packet.

Unfortunately, we did not resolve this issue when I wrote this.  We got our farm to work by pointing the DHCP Relay to the previous DHCP server that is configured in such a way to resolve this DHCP request and present an DHCP OFFER.  Hopefully our network guys will get the DHCP fixed on the proper server.  If you are experiencing similar issues you may have a similar issue where the DHCP at your site is handling unicast DHCPDISCOVER packets differently then broadcast packets.

Read More

Remotely updating AppV 4.6 apps with PSEXEC

/ / /

Just create a script file (flush.cmd) that looks like so:

and you can execute the command with this PSEXEC.exe command:

With list.txt looking like so:


Read More

You receive error code 41495 when you try to start the Microsoft SoftGrid Virtual Application Server service

/ / /

Microsoft has a KB article on this error message:

One of the notes in the KB articles states:
Note: If the SoftGrid Virtual Application Server is version 3.x, the DNS host name must contain the NetBIOS name.

I suspect this note should say:
Note: If the SoftGrid Virtual Application Server is version 3.x or greater, the DNS host name must contain the NetBIOS name.

As when we used the FQDN on our Management Server for the Default group we got this error message.  When we changed it to the NetBIOS name the error was successfully resolved and did not reappear.

I was able to confirm using procmon that when starting the AppV Server Management Service that it queried this registry key:

to set the computer name.  This key contains the NetBIOS name.

Read More

Reboot Server and PVS Streaming Service is started but the console shows the service is down

/ / /

Upon rebooting a server we found the Citrix PVS Console showed the server as down.  When we investigated the server we found the service was started and their were no errors in the logs that we could see.  Restarting the service brought the server as up in the console.  We did see one particular error though, the date was suddenly incorrect in the event viewer.


Further investigation showed EventID 52, the time service resync’ed a offset.

Since this was a virtual machine we checked the VMWare settings to confirm that the time was not being sync’ed

But the time was still getting offset.  Further investigation showed the VMWare hosts time was not set correctly and the server was having it’s time set to the hosts time; even though the above check box was not set.

It appears VMWare has additional time synchronization settings that are enabled by default and must be set to explicitly deny to not have the time synchronize from different scenarios.

Upon VMWare Tools starting on reboot, a “resume”, or the tools being restarted or other scenarios.  To prevent it from happening you must edit the VMX file and set the values as stated in the kb article above.

Read More

AppV 4.6SP2 lies about the registry

/ / /

We recently had an application update and decided we were going to move the registry values outside the AppV bubble into the real world via GPO.

The values existed in the registry here:

When I did the /exe cmd.exe trick for the application and opened the package I could see the registry keys resided in that location.  I then deleted that registry key in the sequencer and set the registry value for Application to “Merge with local keys”.  After doing so we made a GPO at this location:

And I happily launched the application expecting it to see the new server key and be off on its merry way.

It didn’t work.  When I /exe cmd.exe and looked at the registry there was no ServerName key.  Disappointed I resequenced the application on 2008 R2.  Now, in the AppV sequencer I noticed that the keys were located in the HKLM\Software\Wow6432Node.  I then installed the newly sequenced application and launched regedit in the bubble.  Regedit showed me that the path was “HKLM\SOFTWARE\Application”

Adding Registry keys to HKLM\SOFTWARE\WOW6432Node\Application allowed them to be seen properly in the bubble.

Read More

(OS 10061)No connection could be made because the target machine actively refused it. : Unable to connect to the CGP tunnel destination (

/ / /

(OS 10061)No connection could be made because the target machine actively refused it.  : Unable to connect to the CGP tunnel destination (

We got this error on a XenApp 6.5 provisioning server

We utilize Citrix PVS for our XenApp servers.  After updating our XenApp vDisk using our usual method and rebooting the server we got the above error.  Since we versioned it we had our usual servers working without issue, and a couple of “test” versions failing.  I started troubleshooting this using the google method of shotgun trying the first 5 error/solutions.  This included, disabling re-enabling ICA listener, setting the listener on only one NIC interface (which it was, I toggled it for all then just one), deleting the ICA listener and recreating it.  None of them worked so I started troubleshooting.

I encountered this error today and started troubleshooting.  The first step I did was trace the path to the error using Procmon.exe.  This, unfortunately, did not reveal anything of substance.  What I found with this error is the network process is almost exactly the same for both.  I can see XTE.exe communicating via 2598, I can see, what appears to be it handing it off to IMASrv.exe.  At this point is when it causes that error message to be displayed on the bad machine, but IMASrv.exe continues on the good machine.

At this point I’m thinking that maybe the IMA settings for session reliability have become corrupted.  It was suggested to me to disable session reliability and see if it works by a colleague of mine.

The odd thing about resetting the IMA policy is that it isn’t even set in the first place.

“Add” means it is not set

But I disabled it anyways in the IMA policy in AppCenter, NOT in group policy.  After setting session reliability to disabled I restarted the IMA Service on the server and the XTE service.  The XTE service refused to start, I assume because we disabled it, and the IMA service came up.  I then connected to the application via 1494 without issue.  At this point I removed the session reliability setting again.

Click “Remove”

And then waited a minute or so and restarted the IMA Service and XTE Service.  The XTE service came up cleanly, running netstat -a only showed 2598 was listening and I retried the application hosted on the troublesome server.

BANG, it worked like a charm.  I wish I knew why it was happening with more detail, unfortunately, this is as far as I got and I cannot make the error occur again.

The next time this occurs I would like to try stopping the IMA Service and removing this file:
C:\Program Files (x86)\Citrix\FarmGpo\FarmGpo.bin

I think that contains the local IMA policy that may have been corrupted and causing my issue.


I believe I have fixed the issue here.  It appears it may be a NIC binding issue.

Read More

Citrix HDX Engine has encountered a problem and needs to close we are sorry for the inconvenience.

/ / /

The scourage of many a Citrix tech.

Citrix HDX Engine has encountered a problem and needs to close we are sorry for the inconvenience.

Numerous forum posts that I’ve seen without a solution.  I have encountered this across two companies and have encountered the same solution both times.


1) When you click Debug you get this information

AppName: wifca32.exe
ModName: msvcr80.dll

2) Event viewer shows “Faulting application wfica32.exe…” “faulting module msvcr80.dll…”

3) The error dialog occurs after an application is launched (maybe between 10 seconds to 120 seconds afterwards).  The user can move the dialog out of the way and continue working without issue, however clicking the “Close” button will terminate the application.  Sometimes though, the error occurs before the application is fully launched.


The Citrix client opens virtual channels as it connects to the server.

Overview of client-server data exchange using a virtual channel.
1. The client connects to the XenApp Server. The client passes information about the virtual channels it supports to the server.
2. The server-side application starts, obtains a handle to the virtual channel, and optionally queries for additional information about the channel.
3. The client virtual driver and server-side application pass data using the following two methods:
If the server application has data to send to the client, the data is sent to the client immediately. When the data is received by the client, the WinStation driver de-multiplexes the virtual channel data from the ICA stream and immediately passes it to the client virtual driver.
If the client virtual driver has data to send to the server, the data is sent the next time the WinStation driver polls it. When the data is received by the server, it is queued until the virtual channel application reads it. There is no way to alert the server virtual channel application that data was received.
4. When the server virtual channel application is finished, it closes the virtual channel and frees any allocated resources.

If your application starts and the dialog box appears afterwards; we can conclude one of the virtual channels has crashed.  Usually, if this scenario appears it’s because your application has “Don’t wait for printers”.  If your application does not have this checkbox then sometimes the application will crash before the application is loaded.  With this knowledge we have narrowed down our culprit.  Printers.  An example of a printer list with a client that was having this issue:

We have a Citrix policy to only map the default printer, but during the virtual channel creation, all printers become connected to the server.  I was able to verify this with procmon; watching as it iterated through the registry keys for each printer.

A simple test to determine if a bad printer is causing your issue is to disable the Print Spooler service:

Click Stop

After stopping the service and terminating any existing sessions, relaunch the application.  If you no longer get an error (as in my case) then the issue is during the virtual channel creation of one of the faulty printers.  I cleaned up the printers that the user had, removing all non-needed ones and they did not encounter the error message afterwards.  There issue was resolved.  I have seen that cleaning up a printer queue is sometimes not enough and the printers need to be deleted and recreated.  I’ve yet to encounter a printer that I’ve recreated that has caused the issue to persist, but I guess it’s possible.

In the example above after deleting the users printers and restarting the print spooler the printers came back.  The user did not have permission to delete the printers from the HKLM so I needed to do so manually.

So ensure you test restarting the printer spooler and see if the printer comes back to the user to ensure the user has appropriate rights to remove the printer.

Read More