InTrust script to enumerate laptop or desktop computers by AD Site.

In our AD forest they have put all desktop and laptop computers from all AD sites in the same OU. All the desktop computer names begin with "D" and all the laptop computer names begin with "L".
I would like to be able to build separate InTrust sites for gathering jobs for the laptop and desktop computers by site. 
As an end result would like to have InTrust Sites organized -
   AD Site A Desktops
   AD Site A Laptops
   AD Site B Desktops
   AD Site B Laptops
   ... and so on
I would like to do this by InTrust enumeration script, perhaps filtering the computer names in the OU examining all the ones that begin with D or L and then filtering the results by site from the command "nltest /server:<computername> /dsgetsite".  Unclear how to do this most efficiently/reliably in an InTrust script.  And there might be a more eloquent way.
Thinking perhaps somebody has already travelled this path and can provide tips or even a script.
  • The below works in powershell but don't know how to connect it to the InTrust scripter:

    function Get-ADComputerSite($ComputerName)
    {
       $site = nltest /server:$ComputerName /dsgetsite 2>$null
       if($LASTEXITCODE -eq 0){ $site[0] }
    }
     
    Get-ComputerSite "computername"

  • Hi Chris,

    The most elegant solution is described here, citation: "computer/site information is not stored in AD. BUT, there is nothing stopping you from putting it there". It  requires some effort on distributing a startup script to all computers in your environment. The whole solution including InTrust part might be the following:

    $obj = new-object -com ADSystemInfo
    $type = $obj.gettype()
    $adsite = $type.InvokeMember("sitename","GetProperty",$null,$obj,$null)
    if($adsite -eq $null){$adsite = "UNKNOWN"}
    $root = [ADSI]"LDAP://DC=Contoso,DC=com"
    $search = [adsisearcher]$root
    $name = $ENV:COMPUTERNAME
    $Search.Filter = "(&(SamAccountName=$name$))"
    $computer = $Search.FindOne() | foreach{$cproperties=$_.GetDirectoryEntry()}
    $adsiteinad = $cproperties.extensionattribute8
    if($adsiteinad -eq $adsite){}else{
    $cproperties.extensionattribute8 = [string]$adsite
    $cproperties.SetInfo()
    }

    1. Change DC=Contoso,DC=com to your domain or add some code to detect current domain.
    2. Distribute a script using GPO or Ops Manager or other way to run on all computers on start-up or on schedule.
    3. Create a site in InTrust Manager, use script "Enumeration Script: LDAP query" as site object.
    4. In the script properties set:
      1. Attribute Name = dnsHostName
      2. Bind String = LDAP://DC=Contoso,DC=com ( change to your domain)
      3. Filter = (&(objectCategory=computer)(extensionattribute8=Default-First-Site-Name)(name=D*)) (Default-First-Site-Name = change to your Site, D* for Desktops, L* for Laptops)
      4. Need Deep Search = 1
      5. Search Scope = 2
    5. Check if the site works.
    6. Create a number of similar sites for each AD Site, D and L.

    What do you think if it can be implemented in your environment?

  • Please use the site version, not the version from e-mail, I have changed the query, name=D* without exclamation mark !

  • Hi Igor,  Thanks, I had seen that option and agree it would probably be the most simple.  Yet it requires changing privileges on the forest AD OUs for Self object to have RW and this requires going through the corporation change control board, getting people to agree, listening to arguments about which LDAP attribute should or shouldn't be used.   

    I have tried to incorporate a solution totally via InTrust script. But while the code runs in JScript, it frustratingly doesn't work in InTrust.

  • OK, here goes even more simple solution. Do you know the joke that at present time good developer should not write code, he'd better delete code. So we'll try to get rid of script modifications. The second attempt is based on the assumption that site info comes through GPO and is stored in the registry. We have registry filtering in our sites. Please evaluate the following:

    1. Create a site in InTrust Manager, use script "Enumeration Script: LDAP query" as site object.
    2. In the script properties set:
      1. Attribute Name = dnsHostName
      2. Bind String = LDAP://DC=Contoso,DC=com ( change to your domain)
      3. Filter = (&(objectCategory=computer)(name=D*)) (D* for Desktops, L* for Laptops)
      4. Need Deep Search = 1
      5. Search Scope = 2
    3. In the site properties go to Filter tab
    4. Click Attribute - New - Registry Value - Next
    5. Set Registry Value to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Site-Name, String, =, Default-First-Site-Name (Default-First-Site-Name = change to your Site name)
    6. Set the attribute name equal to the AD Site Name.
    7. Commit, go to enumeration tab of the site (in the right html pane of InTrust Manager) and check if the site works.
    8. Create a number of similar sites for each AD Site, D and L.
  • That is the best solution for this!  To follow up, the filter that I used was:  (&((objectCategory=computer)(operatingSystem=Windows 10 Enterprise)(CN=L*))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

    (The userAccountControl exclusion removes stale AD objects from the query results. This may be superfouous as there is similar option on the InTrust Site Domain Enumeration tab for stale objects, but can't find any mention on when and how this option gets invoked and whether disabled objects are already filtered from LDAP queries.)

    The Site appears in three different Registry keys.  Probably any of them would work for this purpose

    "Site-Name"  in key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine"

    or

    "SiteName" in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\DataStore\Machine\0

    or

    "DynamicSiteName" in key "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters"