AD Site A Laptops
AD Site B Desktops
AD Site B Laptops
... and so on
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…
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…
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()
}
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:
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"