App-V: Cisco UCIntegration for Microsoft Lync 8

Here is a really fun one, made ten times worse by Ciscos complete and UTTER lack of interest in helping their customers out AT ALL.

A quick opinion here: STEER CLEAR of Cisco. Their support is notorious for being a joke, if they have an excuse to tell you to take a hike, they will do exactly that. Their software is poorly written, pathetically supported, and just generally not worth much. And no matter how many millions of dollars you just handed them they wont lift a finger to help you with a problem they KNOW the solution to (or imply they do) and would have been easily solvable by any one of the developers in an INCREDIBLY short period of time.

Avoid Cisco at all cost.

Now, on to the show.

This one gets a little hairy in that when you sequence CUCIMOC (the not so short name for the atrociously long "TM" included product mentioned in the header) and try to launch it on a client machine you get an error saying an unhandled exception has occured. Dig through the poorly laid out and nearly useless PRT result log and you find it is because the listening port of 44442 cannot be accessed. The full error is in the report but the net result is...it doesn't work.

In order to solve this problem you need one key thing from the CUCIMOC installer. NewBinary24. This is a binary (and this is poor form because all it seems to do is run netsh, this just seems to obfuscate the exact tasks) that uses netsh to reserve ports and quite possibly register listening ports for the CUCIMOC plugin. Without these being setup (and the sequencer fails to capture them) you will get the, as intended by MS, error that it doesn't have rights.

In my case I used Wise Package Studio 7, clicked on Setup Editor at the bottom of the Windows Installer Editor (after loading the MSI of course), clicked Tables, then on the Binary table, found NewBinary24, double clicked on the data field (sometimes takes three clicks) and wrote the contents out to c:\cisco.dll

On the target machine you then copy the cisco.dll to wherever, in this case c:\ and open an elevated command prompt (this can all obviously be automated by either a WiseScript or MSI and deployed via the task sequence or SCCM deliverable) and type the following:

RunDLL32 c:\cisco.dll, _netshOperations@4

This will call the DLL with the "_netshOperations@4" entry point and perform the functions from the install that were not captured, as the name implies this just runs netsh commands, it's hard to tell how many but there are at least 6 (which is why simply trying to reserve the 44442 port and setup the listener on 0.0.0.0:44442 didn't solve the problem, even though doing so didn't cause the PRT to move on to the next error, which leads me to believe the specific netsh command is not the obvious).

I've verified on a VM three times now that before running this DLL I get an error, and after, it works. This is a TREMENDOUS boon as if you intend to use this software with MOC 2007 then you know that MOC2007 has poorly thought out two-way communication with Outlook, which means you need to sequence the two together, well if you need the UC plugin for cisco you are stuck either taking ALL of office out of App-V, breaking the MOC integration (which is a bigger inconvenience than the ones added by UC) or ditching the UC plugin altogether.

Hope this helps!

Oh also there is a cert in the installer too that if you've gone this far you should be able to find (you can get it and the cdpinstaller.exe in the common files\cisco systems subfolder. I haven't determined yet if it is needed but...if so, it's in there, and the command line is in the MSI. Might as well post it I guess.

certmgr.exe -add -all "CDPCert.cer" -s -r localMachine trustedpublisher

I would include some of these files but who the heck knows how annoyed that might make cisco. If you have specific problems you can post below and I'll do my best to get you through.

App-V: RunAsAdmin, an ACTUAL workaround.

If you've used App-V for very long at all chances are you've discovered that it doesn't really handle applications that need admin rights with UAC prompting very well.

There are two problems, the first is the AppCompat layer, it doesn't except arguments, so you CAN right click the shortcut for an application and set it to run as admin, thinking it will run "sfttray.exe" "Application Name 1.0" as admin, but in reality it only sees sfttray.exe, meaning you just set ALL your applications to RunAsAdmin. Which if locked down now means only administrators can run appv apps, or, if you have admin rights, you've just mooted the entire point of UAC and may as well just turn it off.

The second problem is, App-V was not built with ANY real intelligence when it comes to elevation. They say it's a "design choice" but then say a design choice is their way of saying they know it can't do it yet but they didn't have enough time to fix it. I guess they were too busy introducing bugs and useless UI fixes in SP1 to bother.

So given their two "workarounds" are, well, ones flat out not a workaround because you'd have to be an idiot to do it (and even they say only do it for testing, which...makes it not a workaround) and the other involes installing one of the WORST "powertoys" I've ever used (including over 30 files you need to push locally to the machine) I finally came up with what I would call an ACTUAL workaround.

Ready?

Copy sfttray.exe, rename it to sfttrayad.exe, point your shortcut for the App-V Console or whatever else to IT and not sfttray.exe, and set the compatability to Run As Administrator.

Now anything you know needs admin rights to run simply modify the shortcut, adding "ad" to the end of "sfttray" and tada...no more right click runas, no more shift+right click if it's on your taskbar.

Dear App-V guys. I don't even really care if you can't figure out a better solution, but surely even implementing something like this (where a flag in the admin console tells the client to point to a different copy of sfttray if you specify it as needing admin rights) is better than NOTHING.