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?
 
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
 
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
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
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
 
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.