Client management in the domain using PowerShell

On My Mark

Determining Group Membership

Object management in Active Directory (AD) can be handled via two interfaces. The PowerShell cmdlets are based on AD's web service. Working with this container's commands is easy and intuitive, but the performance is not very impressive. Also, the scope of services is not on a par with the classes in the System.DirectoryServices namespace. Here, just two classes share the task of processing the requests. System.DirectoryServices.DirectoryEntry addresses objects in AD. When creating an object, the parameters are the DistinguishedName of the object, a legitimate user account, and the corresponding password. Once the domain context has been determined, the second class can start its work.

The LDAP searcher can be loaded with very efficient search parameters. The search direction can be upwards ascending to the root of the domain. The choice of the search area, the complexity of the search pattern, and the search method affect the time it will take to populate the result field. Armed with this tool, you can quickly create a list of group memberships for a computer object:

$StrUserName = "Administrator@seminar.local";
$StrPasswd = "Pa`$`$w0rd2016";
$StrDom = "LDAP://dc=seminar,dc=local";

This stores the information for the connection with the domain. You can use the DirectoryEntry class and its constructor to save a domain context in the first step:

$context = New-Object System.DirectoryServices.DirectoryEntry($StrDom,$StrUserName,$StrPasswd);
$ComputerDN = "CN=mobil,cn=computers,DC=seminar,DC=local"
$DirectorySearcher = ([ADSISearcher] $context)
$DirectorySearcher.Filter = "(&(member:1.2.840.113556.1.4.1941:=$ComputerDN))"

The LDAP Searcher needs more information before it can start working. You can again define the starting point of the search via the constructor. Alternatively, you can use the Search Base property. The filter browses the directory based on criteria such as class, Common Name (CN), or the AD objects' other attributes. Any desired search directions can be used. The filter used here searches the ancestor axis for all groups of which the computer $ ComputerDN is a member.

In terms of the Searcher class methods, you have a choice between findOne() and findAll(). findOne() would stop searching after the first match; findAll() provides a complete summary field of group memberships for a computer:

$DirectorySearcher.Searchscope="subtree"
$DirectorySearcher.FindAll() |
  Foreach{
  $($_.Properties).cn
  }

You need to compare the summary with the desired group membership $item.GROUPS here:

$GROUP_MEMBER = $FALSE;
if($($_.Properties).cn -eq $item.GROUPS) {$GROUP_MEMBER = $TRUE;}

Setting DNS Records

The next task is entering DNS servers; the interface to the DNS configuration is the CIM class MSFT_DNSClientServerAddress. CIM provides a class structure that is superordinate to WMI. As of PowerShell v3, it is possible to use these classes directly using Get-CimInstance or Invoke-CimMethod. Parallel to this, PowerShell has increasingly bundled more CIM and WMI functions into cmdlets from version to version. The idea is to take the task of programming the object formation off the administrator's hands. Instead, a parameter-based command syntax can be used. This has also happened in this class; the implementation relies on a cmdlet:

Set-DnsClientServerAddress -InterfaceIndex 4 -ServerAddresses $item.DNS

If you are uncertain about the index number for configuring the network adapter, you can query the index number up front.

The following command determines the index number for the Ethernet NIC:

(Get-NetAdapter | where-Object -FilterScript {$_.InterfaceName-eq "Ethernet"}).InterfaceIndex

Installing Windows Features

Finally, the term PowerShell can mean different things on different computers. If you are upgrading a Windows 7 client to PowerShell v4 with the software development kit (SDK), the functionality is still not the same as with the PowerShell on Windows 8.1, despite having the same $Host.Version.

The management of WindowsOptionalFeatures is based on the DISM package. Since PowerShell is a classic consumer language, each command requires an underlying class. If a dynamic-link library (DLL) is not available, this rules out the associated instruction. Because the OS version in this example is higher than 7, the noun WindowsOptionalFeature exists. A listing using a getter provides the return values shown in Figure 1.

Figure 1: Get-WindowsOptionalFeature returns information on Windows features and their status.

If you want the client to add a new feature, the cmdlet

Enable-WindowsOptionalFeature -FeatureName $ item.FEATURE

does the task reliably.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus