Isn’t it annoying when a customer has a “bad” AD-structure that makes it impossible to run user-discovery or system discovery often enough? By “bad” AD-structure I mean putting computers or users for an entire organization in one OU for example. The drawback of not being able to run User/System-discovery often enough is that users will have to wait for their applications after the computer is installed since SCCM doesn’t know about the group memberships until the discovery tasks are run.
I’ve come up with a method for inventoring only one computer/user. In this first post of two I’ll describe the process for users, which is useful if you run user-based installations.
The short summary of what I do is that I use a Status Filter rule to trigger a script immediately after operating system deployment of the computer. The script checks the computername of the computer and then looks up the Managed By attribute in Active Directory for that computer in order to find the user for the computer. If you know who the user is for the computer by other means (MDT for example) you can always remove the part of my script that checks for the ManagedBy attribute to find the user.
After the script has found the user it checks all group memberships for that person and then it creates a DDR-file which it uploads to the SCCM-server. The script will need some light customization for your organization so be sure to take change your top SCCM server and domain name in the script.
You may also run the script from the Task Sequence itself. See notes in the script for more info.
1. Download the script UserDiscovery_1.2.vbsRename it to *.vbs after you’ve downloaded it.
2. Download the SCCM SDK to give support for DDR-creation and run the installation program on your top SCCM-site server.
3. Copy smsrsgenctrl.dll and smsrsgen.dll from C:\Program Files (x86)\Microsoft System Center Configuration Manager 2007 SDK\Redistributables to c:\windows\SysWOW64
4. Open a command-prompt as admin, navigate to C:\windows\SysWow64 and run regsvr32 smsresgenctrl.dll
Important: For the script to be able to run it is important that you always start the Cscript.exe from the C:\Windows\SysWOW64-folder. Otherwise you’ll recieve the following error:
“Microsoft VBScript runtime error: ActiveX component can’t create object: ‘SMSResGen.SMSResGen.1’
5. In the SCCM console, navigate to Status Filter Rules and create a new rule.
This rule will listen to all SCCM statusmessages from the Task Sequence Engine that are successful.
If you have a lot of task sequences you can also select a specific Task Sequence like this:
The drawback is that you will need to change PackageID if you use a new TS as your OSD-Task Sequence.
In the next window we will enter the path to Cscript.exe and the path to where you choose to store the script followed by the parameters /Computername:%msgsys /Sitecode:%msgsc
Example:
C:\Windows\SysWOW64\cscript.exe D:\Tools\UserDiscovery.vbs /Computername:%msgsys /Sitecode:%msgsc
The %msgsys -variable is the name of the computer that generated the status message.
The %msgsc-variable is the site to which the computer belongs to. (For more parameters, look here.)
Note the path to Cscript.exe which is important for the DLL to work. Do the Next-Next-Finish dance and you are actually done now! Computers that finish a task-sequence will run a user discovery that detects groups for the user and then feed them back into SCCM. What my script does is that it puts the DDR-record file in the “auth” folder of SCCM which is the “Authenticated” folder for SCCM. That means that the files is automatically approved by SCCM. If you have a multi-site hierarchy, the script automatically chooses the correct site-server.
The advantage of running the script by a status filter rule is that it’s done by your SCCM-primary system which has all rights on (possible) child site servers and it can easily put DDR-files in the auth-folder.
You can also run the script with the parameter /Local so that you can run it at the end of the Task Sequence if you like. The script will then find site code and computer name from the client the script is running on.
