Remotely updating AppV 4.6 apps with PSEXEC

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

sftmime delete app:"AppName"
sftmime refresh server:"AppVManagementServer"
sftmime load app:"AppName"
sftmime query obj:package

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

for /f %A IN ('type C:\Users\trententtye\Desktop\list.txt')
 DO P:\PSTools\PsExec.exe \\%A -c C:\Users\trententtye\Desktop\flush.cmd


With list.txt looking like so:

APPSERVER1
APPSERVER2
APPSERVER3
APPSERVER4

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:
http://support.microsoft.com/kb/931165

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:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerName
to set the computer name.  This key contains the NetBIOS name.

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.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1189

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.

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:
HKLM\SOFTWARE\Application /v ServerName /d OLDSERVER

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:

HKLM\SOFTWARE\Application /v ServerName /d NEWSERVER

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.

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

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

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.

=======================EDIT===================

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