locked
SCCM R2 -mof edit to inventory App-V cache %free or %used RRS feed

  • Question

  • Is there a mof edit to extend the SCCM R2 inventory to include App-V client cache %free and/or %used? 

    I know that it is well documented for inventorying the regular SCCM client cache... just wondering if anyone has done this for the App-V cache....

    Thanks
    Friday, March 20, 2009 9:35 PM

Answers

All replies

  • It's been a long time since I had the, erm, pleasure to edit SMS's MOF so pardon me if I'm completely wrong here, but could you take the [all/some of the] lines from App-V client's MOF file and incorporate those into SCCM's?

    It's the SGCliprv.Mof -file in client's installation directory.

    br,
    Kalle

    Monday, March 23, 2009 7:40 AM
    Moderator
  • If you open up and look at the bottom 2 classes of the SMS_Def.mof(located in the share SMS_Sitecode\inboxes\Clifiles.src\hinv), you'll see both of the App-V classes that clients will report inventory against. The reports are turned on by default and the cache values are enabled, so clients should be reporting those values up.
    If your not seeing values come through, you could open one of the web reports, Edit SQL statement, scroll down the views to v_GS_Virtual_Application_Package, click any of the objects in the column window and hit value. There should be values populated in there if you have vapps deployed by ConfigMgr.

    Also, new in ConfigMgr is a new Configuration.mof in the same directory as above. While the default classes being reported on are only from WMI, if you want to gather additional info like regkey values for the AppV client, then that is the file to update. ASR key could be useful for history values on clients over the internet, bad setups values ect. Sounds like a good topic for a blog...
     
    Have a look and see what ya got!
    Troy
    TroyW
    Tuesday, March 24, 2009 5:15 AM
  • Thanks for the replies, but specifically in response to TroyW, those two .mof entries aren't giving me the cache info I want.  Those entries give cache information for specific applications.


    What I'm asking for is the cache % free and/or used for the ENTIRE App-V cache.

    What we want to do is rollout say a 5GB, static cache.  Because we're going to tip-toe into this App-V thing, we'll be gradually rolling out apps - some streamed, some DL/E (can I patent that as the official shorthand for Download & Execute?).  We want to gradually monitor our clients to ensure none of them run out of cache....

    Thanks

    mark

    //************************************************************************************
    //* Class: Package
    //* Derived from: (nothing)
    //*
    //* Key = PackageGUID
    //*
    //* This Package class provides Virtual Package information
    //*
    //************************************************************************************
    [ SMS_Report     (TRUE),
      SMS_Group_Name ("Virtual Application Packages"),
      SMS_Class_ID   ("MICROSOFT|VIRTUAL_APPLICATION_PACKAGES|1.0"),
      SMS_Namespace  (False),
      Namespace      ("\\\\\\\\localhost\\\\root\\\\Microsoft\\\\appvirt\\\\client") ]
    class Package : SMS_Class_Template
    {
        [SMS_Report (TRUE), key ]
            string PackageGUID;
        [SMS_Report (TRUE)      ]
            string Name;
        [SMS_Report (FALSE)     ]
            string SftPath;
        [SMS_Report (TRUE)      ]
            string Version;
        [SMS_Report (TRUE)      ]
            string VersionGUID;
        [SMS_Report (TRUE)      ]
            uint64 LaunchSize;
        [SMS_Report (TRUE)      ]
            uint64 CachedLaunchSize;
        [SMS_Report (TRUE)      ]
            uint64 TotalSize;
        [SMS_Report (TRUE)      ]
            uint64 CachedSize;
        [SMS_Report (TRUE)      ]
            uint16 CachedPercentage;
    };


    //**************************************************************************
    //* Class: Application
    //* Derived from: (nothing)
    //*
    //* Key = Name, Version
    //*
    //* This Application class provides Virtual Application information
    //*
    //**************************************************************************
    [ SMS_Report     (TRUE),
      SMS_Group_Name ("Virtual Applications"),
      SMS_Class_ID   ("MICROSOFT|VIRTUAL_APPLICATIONS|1.0"),
      SMS_Namespace  (False),
      Namespace      ("\\\\\\\\localhost\\\\root\\\\Microsoft\\\\appvirt\\\\client") ]
    class Application : SMS_Class_Template
    {
        [SMS_Report (TRUE)]
            string PackageGUID;
        [SMS_Report (TRUE), key ]
            string Name;
        [SMS_Report (TRUE), key ]
            string Version;
        [SMS_Report (TRUE)      ]
            datetime LastLaunchOnSystem;
        [SMS_Report (FALSE)      ]
            uint32 GlobalRunningCount;
        [SMS_Report (FALSE)      ]
            boolean Loading;
        [SMS_Report (FALSE)      ]
            string CachedOsdPath;
        [SMS_Report (FALSE)      ]
            string OriginalOsdPath;
    };

    Tuesday, March 24, 2009 9:55 PM
  • This seems an odd thing for SCCM.  One normally thinks of SCOM for a monitoring function like that.  I developed a MOM pack that includes this.  It requires looking beyond the mof for the missing parts.
    Tuesday, March 24, 2009 10:55 PM
    Moderator
  •  Yes, it looks like it would provide per app values versus entire cache on the whole like you said. The only thing I can think of is to add the .fsd extension to the software inventory agent(.exe is there by default). Then wait or force software policy refresh. Then through either a query or more preferrably, a custom web report (clone All systems with a specific file) and modify it to collect the file name, file size and file modify date to track the size of the cache across all desktop systems. 
      Above that you could add a new extension to the configuration.mof to collect the Minfreespace/FreeSpace regkeys. Then in a web report, have columns showing current fsd file size, set cache limit size, and percentage value of remaining space. (I know easier said then done) 

    For OpsMgr, it would be good for the terminal server side of the house, but most all customers I've seen using OpsMgr almost never put clients agents on their workstation environments. Some business critical desktops maybe. DCM in ConfigMgr is the desktop side client monitoring piece which could be looked at here. Create CI's to capture the regkey values, file propteries values and add criteria based on both. If threshold is below value, it falls out of compliance. Then through a query based collection based on failed cache compliance, advertise a script to increase the cache. (Seems like a lot of work though given the cache mechanisms in App-V)

    Download WMI explorer and dig into the AppV WMI clas and see what all you can leverage out of it and get creative.  
      
    TroyW
    Wednesday, March 25, 2009 4:27 AM
    • Proposed as answer by znack Wednesday, April 29, 2009 8:36 AM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 3:42 PM
    Monday, April 6, 2009 4:53 PM