App-V & Config Manager 2007 Integration troubleshooting

Wow, long time since last post..
I've got some more bits and pieces to put up as results of recently integrating our App-V Full Infrastructure model into Config Manager 2007.

I had a lot of drama with one high profile user whose app-v applications were not republishing after the integration was taking place.
The Config Manager VirtualApp log was showing success:

Executing command line: "C:\Program Files\Microsoft Application Virtualization Client\SFTMIME.COM" PUBLISH PACKAGE:"{EBFB37EC-50F8-4AA1-B252-B665C057E2B0}" /GLOBAL /MANIFEST "C:\\WINDOWS\\system32\\CCM\\Cache\\INT00289.1.S-1-5-21-1093918724-1084531541-3253023803-7346\\SapGui20.V01_manifest.xml"

The command completed with exit code 0.

Successfully published the shortcuts and file type associations for package SapGui20.V01.

So, all good i thought. But the application was not loaded into WMI, no shortcuts were visible etc.
Next step was to take a look at the App-V log (sftlog.txt). I noticed errors in this log :

Could not load OSD file: \\servername\content\blahblah.osd

This server is part of the old App-V full infrastructure! Which is obviously why the app wasn't actually being published successfully. I had a look at that machines registry, compared it to some functional machines and saw that the OSDSourceRoot App-V key had been set to \\servername\content.
Once I cleared this and reran the advertisement, it was all happening.

So what I take from this is that the OSDSourceRoot actually overrides the OverrideURL, which i didn't expect at all. If you have this set via policy, you may be in for some pain when you go to integrate App-V into Config Manager.

Hope that helps someone!

ConfigManager Task Sequence not continuing - Clients in Provisioning Mode

Recently we had a problem where a lot of clients were not completing their OSD Task Sequence, instead showing up in reporting as still running.
These clients were unable to be managed, and would often be in Provisioning Mode.

Turns out this was due to one of the steps in the task sequence requiring a reboot. The software (in this case it was Cisco VPN Client) would install, and then reboot after about 2-3 minutes of installing. This reboot was not handled by the TS and was unhandled. This would cause the client to stop running the TS, boot into windows and leave the client in provisioning mode.

To resolve: suppresed the reboot in the software installation package, and clients would then finish running TS.

The easiest way to find the trouble software is look for the step before the stuck running step. In my case, client would stay running step 79. Step 78 was the troublesome package.

Hope this helps anyone, took me a long time to figure out.