PowerShell: Get command definition.

With 5.0 being so PowerShell friendly, if you spend a decent amount of time in the shell you probably noticed that the definition of commands tends to get truncated when you, say Get-Command Test-LegacyAppVPackage. Which returns something like this (apologies for the horrible formatting to follow):

CommandType	Name					Definition
-----------	----					----------
Cmdlet		Test-LegacyAppvPackage	Test-LegacyAppvPackage [-Source] <String[]> [-Ve...

CommandType	Name					Definition
-----------	----					----------
Cmdlet		Test-LegacyAppvPackage	Test-LegacyAppvPackage [-Source] <String[]> [-Ve...

You might find this trick handy (and for more than just this if you are clever).

$(Get-Command Test-LegacyAppVPackage).Definition

Which returns something like this:

Test-LegacyAppvPackage [-Source] <String[]> [-Verbose] [-Debug] [-ErrorAction <ActionPreference>] [-WarningAction <Acti

onPreference>] [-ErrorVariable <String>] [-WarningVariable <String>] [-OutVariable <String>] [-OutBuffer <Int32>]

Much better...

App-V: Excel 2010, DDE, and variations on installation type.

Here is a fun one.

If you  are like me you've had some VERY sketchy results with Office and DDE. There are several bits of information floating around about this and here is my updated current understanding of the issue.

During installation of App-V 4.6 (in this case SP1, not sure if the same applies to RTM) the following keys are written with different values based on, apparently, the type of method used to deploy the client.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface\DDELaunchCommand

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface\DDELaunchMSICommand

When delivered via SCCM as part of a task sequence during an SD deployment DDELaunchCommand points to sfftray.exe and not sftdde.exe, and there is a different string for the MSI launch command as well.

Strangely, taking office 2010 as an example, word used to require ADDING DDE or it would present a "problem sending command to program" error, then at some point it stopped being broken.

Then, Excel stopped working with DDE, the most common search results provided a fruitless suggestion to disable the "Ignore other applications DDE" that doesn't appear to be checked by default in 2010 anymore.

The problem with this is that stripping DDE from the FTA's for excel fixes double clicking on a file locally or on a network share, but when launching a spreadsheet via SharePoint you get an error saying '%*.xslx" could not be found.

Uninstalling and reinstalling the client WILL fix this in almost every case (just make sure to reboot after the uninstall, even if it doesn't prompt you) but the idea is to fix the client for in-production machines.

The default values for SP1 for those two keys are as follows:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface]

"DDELaunchMSICommand"="-0Ej4Sf'k=UZDv3uJ4{IRelease_Merge_Modules>OO5hSGuIH?xoVn&wQ(Ex \"<APP>\" <DDE>"

"DDELaunchCommand"="\"C:\\Program Files (x86)\\Microsoft Application Virtualization Client\\sftdde.exe\" \"<APP>\" <DDE>"

This is from a Win7x64 machine with App-V 4.6 SP1 (no HF's applied).

Update on 2011-12-07 00:30 by Paul Fulbright

Ok, so I sadly do not have nearly enough time to really get to the bottom of this so the following is pure speculation.

I THINK the difference in this case between Excel and, say, Word is that Excel seems to be tripping a MSI self-repair check, it's blink-and-you'll-miss-it fast but I THINK the MSIDDELaunchComand not being fixed was why just changing DDELaunchCommand didn't solve the problem.

Something doesn't set right with me about that but the net result is, setting both keys correctly, works.

REALLY love to hear the excuse for why this happens.

XenServer: Add/Remove Network Interface.

Remove:

• xe vm-list
• Copy the uuid for the VM you want to remove the interface.
• xe vif-list vm-uuid=<vm-uuid>
• Copy the uuid for the vif you want to destroy.
• xe vif-destroy uuid=<vif-uuid>

Note you will need to know which device you want to remove if there is more than one interface attached to the VM.

Add:

• xe list-network (you can add "name-label=<label>" if you know the networks name, in my case Bond 0+1)
• Copy the networks uuid.
• xe vif-create network-uuid=<network-uuid> vm-uuid=<vm-uuid> device=#

See above for how to find the VM's uuid, for device replace # with the device number, you can find a list of supported VIF devices by typing "xe vm-param-list uuid=<vm-uuid> | more" and looking for allowed-VIF-devices, if theres no interface currently on the VM you will most likely use 0.

As for why you would want to do all of this...well, sometimes you either don't have access to XenCenter, or it decides it doesn't want to play, it's always a good idea to bring your own ball.

Service Manager 7.11: Command Line Options

Don't ask me why I'm posting this here, Service Manager is one of the worst written things I've ever used, and I use App-V. No surprise it's written in Java. The developers need to be drawn and quartered.

-silent

-options-record <answer file>

-options <answer file>

For a silent default install just use -silent, for one that uses the answer file, just do -option AND -silent.

Ugh.