Have you ever wondered why a ConfigMgr client takes a long time to run the advertised programs after you deploy this client using ConfigMgr OSD? Well, this is because as soon as the machine is imaged, it gets added to the ‘All Systems’ collection and gets the advertisements/policies that are targeted to the All Systems collection. But what if your advertisements are not targeted to the default All Systems collection, and instead are targeted to a custom query based collection? In that case, the newly imaged machine doesn’t get added to the custom collection until it sends the inventory AND the collection updates based on its schedule and finds the machines that fulfill the query condition to add the machine(s) to the collection, and in turn triggering the creation of policies for these clients. Until this happens, there are no Advertisements for this newly imaged client to run(unless of course, they were targeted to the All Systems collection). This is why you may notice a delay of up to 24 hours or more until you see the newly imaged clients processing all the Advertisements that you expect them to execute.
One way to workaround this delay is to add the machine to the desired collection(s) manually, and give it about an hour to request for new policies. However, this is a tedious task. Another way is to somehow add the computer to the desired collection during the OSD Task Sequence run-time. This would result in the computer pulling all the policies targeted to the desired collection immediately after it is imaged. I wrote a script that can be used to do just that. All you need to do is to add a ‘Run Command Line’ task to the Task Sequence and specify the following Command line:
cscript AddMeToCollection.vbs <SiteServerName> <CollectionID> %_SMSTSClientIdentity%
In the above command line,<SiteServerName> needs to be replaced with the SMS Site Server Name<CollectionID> needs to be replaced with the desired Collection ID
Thats all that you need to edit in the above command line. However, you need to make sure that you run this command line as an account which has rights to connect to the SMS Provider. If the account running this command does not have the required rights, then the script will fail to execute. Regardless of the Success/Failure, you would see the return code in the SMSTS.log, which may be useful during troubleshooting.
You can find this script attached here. I hope you find this post useful.
IMPORTANT: Using the example above works in my lab, however information in this post is provided "AS IS" with NO Warranties, or Support.
Vinay Pamnani | Support Engineer
The default All Systems collection is special in the sense that it has a unique Collection ID (SMS00001). In case you end up 'accidentally' deleting the All Systems collection from your SMS/SCCM console, the only way to restore it with the default Collection ID is programmatically. Here's a script that does that, along with adding the Collection Query and the Update Schedule.
strSMSServer = "."
strParentCollID = "COLLROOT"
strCollectionName = "All Systems"
strCollectionComment = "This is the All Systems Collection."
Set objLoc = CreateObject("WbemScripting.SWbemLocator")
Set objSMS = objloc.ConnectServer(strSMSServer, "root\sms")
Set Results = objSMS.ExecQuery ("SELECT * From SMS_ProviderLocation WHERE ProviderForLocalSite = true")
For each Loc in Results
If Loc.ProviderForLocalSite = True Then
Set objSMS = objLoc.ConnectServer(Loc.Machine, "root\sms\site_" & Loc.SiteCode)
End if
Next
Set newCollection = objSMS.Get("SMS_Collection").SpawnInstance_()
'Create new "All Systems" collection
newCollection.Name = "All Systems"
newCollection.OwnedByThisSite = True
newCollection.Comment = strCollectionComment
newCollection.CollectionID = "SMS00001"
newCollection.Put_
'Set the Relationship
Set newCollectionRelation = objSMS.Get("SMS_CollectToSubCollect").SpawnInstance_()
newCollectionRelation.parentCollectionID = strParentCollID
newCollectionRelation.subCollectionID = ("SMS00001")
newCollectionRelation.Put_
'Add the Query Rule
Query = "SELECT * FROM SMS_R_SYSTEM"
Set objQueryRule = objSMS.Get("SMS_CollectionRuleQuery").SpawnInstance_
objQueryRule.QueryExpression = Query
objQueryRule.RuleName = "All Systems"
newCollection.AddMembershipRule objQueryRule
'Add the Schedule
Set Token = objSMS.Get("SMS_ST_RecurInterval")
Token.DaySpan = 1
newCollection.RefreshSchedule = Array(Token)
newCollection.RefreshType = 2
'Refresh Collection Membership
newCollection.RequestRefresh False
Run the script as follows on the Site Server, and you should have the default collection back:cscript.exe RecreateAllSystemsCollection.vbs
Although the Configuration Manager Hardware Inventory Client Agent reports on approximately 1,500 hardware properties from almost 100 different WMI classes by default, there is always a time when you want MORE. One such scenario is when you’re looking to collect information about the Driver Version of the Wireless NIC or even the Wired NIC for that matter. This post specifically talks about reporting on the Wireless NIC Driver Version, however with some modifications to the query mentioned at the end, it is possible to report on the Driver Version of the Wired NIC as well.
Starting off with some research. By default, Network Adapter information is queried from Win32_NetworkAdapter Class within the root\cimv2 namespace, however none of the properties defined within this class talk about the Driver and hence it is not possible to collect this piece of information without having to extend the Hardware Inventory MOF Files. But before I even began to think about extending the MOF files, I needed to first know where is the Driver Version information stored. Now, while searching about this, I stumbled on this link which talks about getting this from Win32_PnPSignedDriver class. Only problem getting the Driver Version from here is that you may end up collecting a lot of information that is not required. So after searching some more, I found that Driver Version is also stored within the following Registry key:
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}
Moreover, *MediaType DWORD value within each sub-key corresponding to each Network Adapter can also be used to identify a Wireless Adapter. Specifically, a decimal value of 16 of *MediaType would correspond to a Wireless Adapter. So after querying what’s required from each sub-key within this registry key, a custom report/collection can be created based on the *MediaType value to identify Wireless Driver Version.
On to the actual MOF editing now. This involves SMS_DEF.mof and Configuration.mof. Configuration.mof file is used to define the data classes to be inventoried by the hardware inventory client agent. In other words, if the data you need doesn’t already reside in WMI, you need to define it in form of a Data Class in Configuration.mof. SMS_DEF.mof defines the reporting classes to determine whether or not specific client Data Class information is reported. You can read more about these two files, here.
First off, defining the registry key and values by editing and adding the below section to the Configuration.mof file:
#pragma namespace ("\\\\.\\root\\cimv2")
[ dynamic,
provider("RegProv"),
ClassContext("local|HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Class\\{4D36E972-E325-11CE-BFC1-08002bE10318}")
]
class Win32Reg_NetworkDrivers
{
[key]
string Index;
[PropertyContext("DriverDesc")]
string DriverDesc;
[PropertyContext("DriverVersion")]
string DriverVersion;
[PropertyContext("DriverDate") ]
string DriverDate;
[PropertyContext("*MediaType") ]
string MediaType;
};
Now, adding the following to the SMS_DEF.mof:
#pragma namespace ("\\\\.\\root\\cimv2\\sms")
[ SMS_Report (TRUE),
SMS_Group_Name ("Network Drivers"),
SMS_Class_ID ("MICROSOFT|NETWORK_DRIVERS|1.0"),
Namespace ("\\\\\\\\localhost\\\\root\\\\cimv2") ]
class Win32Reg_NetworkDrivers : SMS_Class_Template
[SMS_Report (TRUE), key ]
[SMS_Report (TRUE) ]
Once these changes are received on the clients in the form of a Policy, they will add the relevant Data and Report classes, which will then be reported by the Hardware Inventory Client Agent based on the Inventory Schedule.
Finally, to convert this into a Custom Report, following query can be used to run this report on a Collection to get a list of machines with Wireless Adapters (MediaType = 16), along with the Driver Version:
SELECT RS.Netbios_Name0, NAD.DriverDesc0, NAD.DriverVersion0, NAD.DriverDate0
FROM v_R_System RS
INNER JOIN v_GS_NETWORK_DRIVERS NAD on NAD.ResourceId = RS.ResourceId
INNER JOIN v_FullCollectionMembership FCM ON FCM.ResourceID = RS.ResourceID
WHERE NAD.MediaType0 = 16 AND FCM.CollectionID = @CollectionID
where, CollectionID is the Prompt Name with the following SQL Statement:
SELECT CollectionID, Name FROM v_Collection
OR, if you’re looking to make a custom collection based on a specific Network Adapter Driver Version, a WQL query similar to this can be used:
SELECT SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client
FROM SMS_R_System
JOIN SMS_G_System_NETWORK_DRIVERS ON SMS_R_System.ResourceID = SMS_G_System_NETWORK_DRIVERS.ResourceID
WHERE SMS_G_System_NETWORK_DRIVERS.DriverVersion = '6.0.6001.18000'
So, if you’re someone who’s looking to get the Network Adapter Driver Versions inventoried by Configuration Manager, I hope you find this useful. And as always, be careful when modifying these MOF files. If you modify them, first verify the size of a typical client's complete hardware inventory and make sure it is acceptable for your networking environment. Then, test the new file in a test lab before replacing the default MOF files in production.