« Previous 1 2 3 Next »
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.
If you want the client to add a new feature, the cmdlet
Enable-WindowsOptionalFeature -FeatureName $ item.FEATURE
does the task reliably.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)