/build/static/layout/Breadcrumb_cap_w.png

Debug or Test WMI Filter

I am going to deploy the Office 2007 Compatibility Pack, and only want this to go to machines with a flavor of Office 2003 installed. Obviously don't need it for Office 2007, and we don't have Office XP in our environment.

I think I have the query right, which will cover all versions (we have Basic and Pro)

SELECT * FROM Win32_Product
WHERE Name Like 'Microsoft Office %2003%'

My question is this - how can I view the output so that I can do some manual verification first? This is my first query and I want to make sure it filters correct before deploying. Is there a way I can run this and have it export or display the computers that meet the critieria? I tried doing it in PowerShell, but must have gotten the syntax wrong.

0 Comments   [ + ] Show comments

Answers (3)

Posted by: anonymous_9363 15 years ago
Red Belt
0
Restrict the deployment to a group. You can use the Group Policy Modelling Wizard to "test" the target. Also, I'd avoid using product names for things like this. Use the Product Code instead.
Posted by: derek.rose 15 years ago
Yellow Belt
0
Thanks for the reply!

I prefer not to use the group approach for the deployment, because I don't want to have to manage it going forward. Such as creating a group for the package, that means I have to manually add/remove objects from that group as necessary. I wanted to point that out, although I have a feeling you are talking about using a group for the testing purposes as well.

What I ended up doing was creating a testing OU, adding a few computers to it with mixed results. Some would meet the criteria, some wouldn't, and then I ran gpresult on each to see if the filtered policy would apply. I left it empty during testing, just so I could test the filtering. Once I verified the query was correct, I felt a little safer to proceed.

I don't really have a true domain I can use for testing, so testing OUs and filtering GPO's is all I can really work with. Group Policy Modeling seems very interesting, and I'll read up more on that.

I'm curious as to your statement around the Product Code instead of the product names. One thing I noticed during testing and research is that using product names, or at least my approach with wild cards, will install on a machine that has Office 2007 but web components for Office 2003 - such as the Powerpoint viewer 2003. I assume using product codes would avoid that. Are you referring to the GUID codes for each product in the registry? http://support.microsoft.com/kb/832672

Would you have an example of a query that I could look at, covering Office 2003 Basic and Office 2003 Professional?
Posted by: anonymous_9363 15 years ago
Red Belt
0
Derek,

I'd persist with using groups, especially for testing. Once you're happy that everything works, you can simply use 'Authorised Users' as the target group. That covers users and computers, of course. Nice and easy...

Using Product Codes is probably safer than Product Names, as the GUIDs are unique. And yes, those are the GUIDs I meant, e.g. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{90110409-6000-11D3-8CFE-0150048383C9} for Office Pro 2003. If you wanted to test for more than one product, use an 'AND' in the query.

I'm afraid I don't have any sample queries. My current client doesn't use WMI filters. In fact, I only stumbled on them answering a post in another AppDeploy forum http://itninja.com/question/ie7-wmi-filter
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ