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!

App-V Visio 2010 Licensing Errors

We have recently deployed Visio 2010 via App-V to generally good results. However every few days I would receive notification from the service desk of a user who had a licensing error when launching Visio 2010 :


The help desk were fixing this by repairing the Microsoft Office 2010 Deployment Kit for App-V.
Seemed a bit strange to me, so I investigated the one or two of the troublesome machines and found that the Office Software Protection Platform service had stopped.
Further to that, I saw that the service was set to Manual start, with no recovery options.
This basically means that once this service fails, its failed for good.

I checked out a few more machines that had Visio deployed, and yup, all of them had the OSPP service set to manual start. It seems the Office 2010 Deployment kit installer creates this serrvice with a manual start type.

To resolve, I needed to create a transform for the OffVirt.MSI file.
I used Microsoft's tool, Orca to do this.

First step: Open the MSI with Orca.
Right click the MSI, and select 'Edit with Orca'. Orca will open, and you will see all the MSI tables.


Then select transform > new transform
This will give you the screen displayed below:


From there, go to the ServiceInstall table, and change the StartType value from 3 (Manual) to 2 (automatic)


Click Transform > Generate Transform and enter a name for your transform, and save it.


Alright, transform created! Now just run the MSI with the transform as follows:
msiexec /i offvirt.msi TRANSFORMS="yourtransformname.mst"

With any other options you need in there.

And with that you have an install that will set the Protection service to 'Automatic'. Phew.

Windows Deployment Service not starting

One of our ConfigMgr PXE Service points was not functioning as it should, was not servicing any clients.
When I went to restart the WDS Service, I received the following error:


Very odd. I enabled Tracing on the WDS Service (by switching the EnableFileTracing key located here - HKLM\Software\Microsoft\Tracing\WDSSERVER - from a 0 to a 1) and reviewed the log generated when I tried to restart the service again.

I was receiving errors such as :
[5108] 10:30:04: [d:\rtm\base\ntsetup\opktools\wds\wdssrv\server\src\wdsprovhdl.cpp:169] Expression: , Win32 Error=3238332162
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxeprov.cpp:172] Expression: , Win32 Error=2
[5108] 10:30:05: [1762][WDSPXE] [SMSPXE] Initialization failed (rc=2)
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxeprovhdl.cpp:481] Expression: , Win32 Error=2
[5108] 10:30:05: [1762][WDSPXE] -> CBannedGuids::Shutdown
[5108] 10:30:05: [1762][WDSPXE] <- CBannedGuids::Shutdown=0
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxeprovhdl.cpp:598] Expression: , Win32 Error=2
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxemain.cpp:201] Expression: , Win32 Error=2
[5108] 10:30:05: [d:\rtm\base\ntsetup\opktools\wds\wdssrv\server\src\wdsprovider.cpp:147] Expression: , Win32 Error=2
[5108] 10:30:05: [WDSPXE] Initialization Failed (rc=2)

Error code 2 is a file not found error. Something had gone seriously amiss with the SMSPXE provider.
This had to be up and running ASAP, so I did not have time to remove the packages off the PXE point, remove the PXE role, Re-add the role, and redistribute the images.

To resolve, I ran PXE.MSI on the affected server (this is located [SMSINSTALLDIR]\Bin\PXE.MSI).

This repaired the PXE setup on that machine, re-registered providers etc. The service would then start, and the server is now servicing pxe clients.

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.

SMS_MP_CONTROL_MANAGER Warnings 5416 & 5418

After extending the sms_def.mof and configuration.mof I noticed a large amount of 5416 and 5418 warnings in the SMS_MP_CONTROL_MANAGER with the text:

"MP could not find some class or property definitions when processing Hinv as they are apparently missing in sms_def.mof. Unknown classes and properties have been ignored and a MIF file generated with all the classes and properties that could be found.

Possible cause: This might indicate that the report has become obsolete due to a new HW inventory policy or that a customer's private definitions haven't been properly propagated to the sms_def.mof at the PSS.
Solution: See if the missing classes or properties are genuinely missing in the current sms_def.mof and find out why the client put them in the xml report."

Uh-oh!

So, I had to find out what was going on here, obviously something related to the changes made.
I had a look at DATALDR.LOG on the primary site, no errors there to speak of.

Checked out MP_HINV.LOG and found quite a few warnings..

"Hinv: property name not found in the mapping table: KeyName"

So looks like theres a problem with KeyName.

Comparing the sms_def to the configuration mof files I saw the problem:
sms_def.mof
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("ProvisioningMode", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("ProvisioningMode"),SMS_Class_ID("HEALTH|ProvisioningMode|1.0")]
Class ProvisioningMode: SMS_Class_Template
{
[SMS_Report(TRUE)] String ProvisioningMode;
};

configuration.mof
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("ProvisioningMode", NOFAIL)
[DYNPROPS]
Class ProvisioningMode
{
[key] string KeyName;
String ProvisioningMode;
};
[DYNPROPS]
Instance of ProvisioningMode
{
keyname="SystemCenter.fr";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\CCM\\CcmExec|ProvisioningMode"),Dynamic,Provider("RegPropProv")] ProvisioningMode;
};


See the problem? I had forgotten to add KeyName to the sms_def.mof, meaning it couldnt map this, in turn causing my warnings.

Added the missing line to sms_def ([SMS_Report(TRUE),key] string KeyName;) and the problem has now been resolved. No more warnings, and MP_HINV is processing inventory data very happily.

Sweet deal!

Config Manager and AppV Full Infrastructure Model - Config Manager Reporting

I have an App V setup that is a little unorthodox..(AppV in the Full infrastructure model alongside Configuration Manager). This was done to take advantage of the active upgrade and dedicated reporting/licensing features of the AppV Management Server.

We have multiple sites across two countries, but do not have AD Sites for each of these locations. This makes managing AppV a bit tricky, as we need clients in each site to go to their nearest streaming server (streaming server role has been installed on each Config Manager DP).

I have done this by a similar mechanism as Config Manager's Boundaries. A GPO was created, and a Group Policy Preference Registry collection was created for each site, specifying the Application Source Root and Icon Source Root to be the Streaming Server for that site. This was filtered to only the subnets in that site.

So this looks kinda like this:

Registry Collection
Site1 (targeted to subnet 192.168.1.x)
Application Source Root : Server1

Site2 (targeted to subnet 192.168.2.x)
Application Source Root : Server2
Etc etc.

While this may look cumbersome, it actually works very well and enables easy roaming of clients between sites if they need to.

The problem I had was actually having some way of checking the Application Source Root location.

This was quickly resolved by adding to Config Managers inventory to inventory reg keys.
This was done by adding the following to the SMS_DEF.MOF file:
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("AppVLocation", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("AppVLocation"),SMS_Class_ID("CUSTOM|AppVLocation|1.0")]
Class AppVLocation: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String ApplicationSourceRoot;
[SMS_Report(TRUE)] String IconSourceRoot;
};

And this to the Configuration.mof file:
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("AppVLocation", NOFAIL)
[DYNPROPS]
Class AppVLocation
{
[key] string KeyName;
String ApplicationSourceRoot;
String IconSourceRoot;
};
[DYNPROPS]
Instance of AppVLocation
{
keyname="SystemCenter.fr";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SoftGrid\\4.5\\Client\\Configuration|ApplicationSourceRoot"),Dynamic,Provider("RegPropProv")] ApplicationSourceRoot;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SoftGrid\\4.5\\Client\\Configuration|IconSourceRoot"),Dynamic,Provider("RegPropProv")] IconSourceRoot;
};

Hey presto, reg keys being collected.

Once I had kicked off inventory and one machine, and confirmed that the new table (dbo.AppVLocation_DATA) had been created, it was time to write a report to make use of these values:

select v_R_System.Netbios_Name0 , v_GS_AppVLocation0.ApplicationSourceRoot0 AS 'Application Source' from v_R_System inner join v_GS_AppVLocation0 on v_GS_AppVlocation0.ResourceID = v_R_System.ResourceID where v_R_System.Operating_System_Name_and0 LIKE 'Microsoft Windows NT Workstation%'

This gives me a nice, basic report telling me which machines are assigned to which streaming server, and also more importantly, any machines that do not have an Application Source Root set for any reason.

Choice!

Unable to edit Task Sequences - SCCM

Today it was discovered that any task sequences I tried to edit and save the changes to, were failing with a "Unable to Store Task Sequence" error. Neat.

Had a look in the TaskSequenceProvider log, and found the following :

[PID: 29436] Invoking method SMS_TaskSequence.SaveToXml TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Failed verifying schema version property in wmi sequence 0x80004005 (2147500037) TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Failed to store the WMI task sequence as XML 0x80004005 (2147500037) TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)

Seems WMI went belly up on the Primary Site Server.. A restart of the
Windows Management Instrumentation service fixed this right up, and task sequences are working once more. A real good start to the day..