GPO for (only) MDT deployed computers

Hello,
We need to apply a GPO policy ONLY for thoose computers deployed from MDT.
Other computers should not be applied by this GPO.

Windows 2008 R2 domain environment and Windows 7 deployment through MDT 2010.
Present computers are Windows XP (SP3) and forward.

Thanx in advance for you help!
AITPAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jakethecatukCommented:
Do you which computers were deployed thru MDT 2010?  If you do, place all the computers in a security group and apply the GPO to that security group only.
0
merowingerCommented:
Create a WMI Filter for the Group Policy which queries on the OS Version.

select version from win32_operatingsystem where version like '6%'

or

select version from win32_operatingsystem where caption like '%Windows 7%'
0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

AITPAuthor Commented:
More info, they have also Windows 7 computers not deployed through MDT, these should not be applied.

One possible solution would be to check for HKLM\Software\Deployment 4\ keys via WMI filter but not sure how to do that.
0
merowingerCommented:
Using WMI filters with Registry values: It is sometimes desirably to apply GPOs only when a Registry value contains, or not contains, a specific value. The problem is that the Registry provider by default only supports methods, not properties, but there is a, somewhat cumbersome, way around this that makes it possible to create a WMI filter that queries the Registry.

The Registry WMI provider can actually support instance properties, a requirement for WMI filters, if you tell it to, but it requires some work and in many cases it is not worth the effort. The steps to do it can be summarized as follows:

1. Create a MOF (text) file that defines the keys and values that should be accessible.
2. Run Mofcomp.exe on EACH computer to add the values from the MOF file into the WMI Repository. The syntax is: "mofcomp -class:forceupdate <path to MOF file>"
3. Create your WMI filter using your preferred GP admin tool.

The problem here is of course to execute mofcomp on the computers, but this could be run from the Startup script, or something like that, since administrative permissions are required. Although some sort of flag should be used so that it is not run each time the computers boot, only when the MOF files has been changed.

Since MOF files isn't very easy to explain, especially for dynamic WMI providers such as the Registry Provider, below is an generic example that can be modified by changing paths and values or adding new paths just copy the text into a text file and make sure that no extra line breaks has been added. Observe that the MOF file below only support String registry values.

///////////////////////////////////////////////////////////////////////
// MOF File that makes it possible to query for build number and registered owner with GP WMI filter.
///////////////////////////////////////////////////////////////////////

#pragma namespace ("\\\\.\\Root\\cimv2")

[DYNPROPS]
class WindowsInfo
{
     [key]string  Keyname="";
     string       BuildNumber;
     string       Organization;
};
[DYNPROPS]
instance of WindowsInfo
{
     KeyName="BuildInfo";
     [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion|CurrentBuildNumber"), Dynamic, Provider("RegPropProv")] BuildNumber;
     [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion|RegisteredOrganization"),Dynamic, Provider("RegPropProv")] Organization; };

//////////////////////////////////////////////////////////////////////////////


After the MOF file has been compiled on the client machines, a WMI filter can be used that looks like this in the root\cimv2 namespace:

SELECT * FROM WindowsInfo WHERE BuildNumber="2600" AND Organization="My Organization"

This will match all the computers with build number 2600 (XP) registered to "My Organization" by reading from the Registry keys and not the "normal" OS WMI classes.

Again the problem is to compile the MOF file on all computers to enable WMI to access the Registry keys as properties, but after that everything works as expected.
0
merowingerCommented:
As you see this is complicated. Easier would be in this case to have a script which finds all computers with this key and add them into a AD group. Then a permissons is defnied on the GPO for this AD group
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
AITPAuthor Commented:
I'll go for the "dummy file" -solution and create WMI filter if file exist. Easy to create through MDT task sequence.

Thanx!
0
merowingerCommented:
You mean like this?
Select * From CIM_DataFile Where Name = 'C:\DummyFile.txt'
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Software

From novice to tech pro — start learning today.