Richard Siddaway's Blog

As stated last time the direct reports is a backlink created from the users who have this particular user as a manager

Displaying this attribute is straight forward

if (-not (Get-Module ActiveDirectory)){            
  Import-Module ActiveDirectory            
}            
            
$ou = "OU=England,DC=Manticore,DC=org"            
$manager = "CN=HORNBLOWER Horatio,$ou"            
            
"`nMicrosoft"            
Get-ADUser -Identity $manager -Properties * |             
select -ExpandProperty directReports            
            
            
"`nAD provider"            
Get-ItemProperty -Path AD:\$manager  -Name directReports |             
select -ExpandProperty directReports            
             
"`nQuest"            
Get-QADUser -Identity $manager -IncludeAllProperties |             
select -ExpandProperty directReports            
            
            
"`nScript"            
$user = [adsi]"LDAP://$manager"            
$user |             
select -ExpandProperty directReports

No real surprises – get the user and display the property. Its a collection so using –ExpandProperty is the easiest way to display

The organization tab on the user properties can hold a number of items – job title, department, company, manager & direct reports

The first four we can set directly. The direct reports attribute is a backlink meaning it is filled with the distinguished names of the users who have  a particular user set as their manager.

The properties we can set are managed like this

if (-not (Get-Module ActiveDirectory)){            
  Import-Module ActiveDirectory            
}            
            
$ou = "OU=England,DC=Manticore,DC=org"            
            
$dept = "Secret Squirrel stuff"            
$comp = "Hush Hush Co Ltd"            
$manager = "CN=HORNBLOWER Horatio,$ou"            
            
"`nMicrosoft"            
$name = "UserA"            
$title = "VP for stuff"            
Get-ADUser -Identity $name |            
Set-ADUser -Title $title -Department $dept -Company $comp -Manager $manager            
            
"`nAD provider"            
$name = "UserB"            
$title = "VP for something or other"            
$dn = "cn=$name,$ou"            
Set-ItemProperty -Path AD:\$dn  -Name title      -Value $title   -Force            
Set-ItemProperty -Path AD:\$dn  -Name department -Value $dept    -Force            
Set-ItemProperty -Path AD:\$dn  -Name company    -Value $comp    -Force            
Set-ItemProperty -Path AD:\$dn  -Name manager    -Value $manager -Force            
             
"`nQuest"            
$name = "UserC"            
$title = "VP for things"            
Get-QADUser -Identity $name |            
Set-QADUser -Title $title -Department $dept -Company $comp -Manager $manager            
            
"`nScript"            
$name = "UserD"            
$title = "VP for other things"            
$dn = "cn=$name,$ou"            
$user = [adsi]"LDAP://$dn"            
$user.title = $title            
$user.department = $dept            
$user.company = $comp            
$user.manager = $manager            
$user.SetInfo()

The cmdlets have parameters for each attribute while the provider and script have to work a bit harder

In AD Users & Computers the user’s properties dialog has a tab for setting address information

if (-not (Get-Module ActiveDirectory)){            
  Import-Module ActiveDirectory            
}            
            
$ou = "OU=England,DC=Manticore,DC=org"            
$street = @"
123 Somewhere Place, 
A big suburb
"@             
            
$PObox = "PO 456"            
$city = "Salisbury"            
$state = "Wiltshire"            
$zip = "SY27 5QW"            
$country = "GB"            
            
"`nMicrosoft"            
$name = "UserA"            
Get-ADUser -Identity $name |            
Set-ADUser -StreetAddress $street -POBox $PObox -City $city -State $state -PostalCode $zip -Country $country            
            
"`nAD provider"            
$name = "UserB"            
$dn = "cn=$name,$ou"            
Set-ItemProperty -Path AD:\$dn  -Name streetAddress -Value $street  -Force            
Set-ItemProperty -Path AD:\$dn  -Name postOfficeBox -Value $POBox   -Force            
Set-ItemProperty -Path AD:\$dn  -Name l             -Value $city    -Force            
Set-ItemProperty -Path AD:\$dn  -Name st            -Value $state   -Force            
Set-ItemProperty -Path AD:\$dn  -Name postalCode    -Value $zip     -Force            
Set-ItemProperty -Path AD:\$dn  -Name c             -Value $country -Force            
             
"`nQuest"            
$name = "UserC"            
Get-QADUser -Identity $name |            
Set-QADUser -StreetAddress $street -PostOfficeBox $PObox -City $city -StateOrProvince $state -PostalCode $zip -ObjectAttributes @{c=$country}            
            
"`nScript"            
$name = "UserD"            
$dn = "cn=$name,$ou"            
$user = [adsi]"LDAP://$dn"            
$user.streetAddress = $street            
$user.postOfficeBox = $PObox            
$user.l = $city            
$user.st = $state            
$user.postalCode = $zip            
$user.c = $country            
$user.SetInfo()

To keep everything consistent I’ve set the address information as a set of variables. The street address is a here-string so we can get multiple lines into the address. The country is designated by the 2 letter ISO code – be careful with this. I tend to set in the GUI and then check the property value in ADSIEdit if I have any doubts.

This is a totally made up address

The Microsoft cmdlet has a parameter for each element of the address. The Quest cmdlet is the same except, bizarrely, the country

The provider and script we have to set each property. Notice that some properties are not intuitive:

• l = city
• st = state
• c = country

On the Account tab of an AD user’s properties there is a button labelled “Logon to …” that can be used to restrict the computers a user can logon onto. The default is that users can log onto any machine. If you want to script the restriction

if (-not (Get-Module ActiveDirectory)){            
  Import-Module ActiveDirectory            
}            
            
$ou = "OU=England,DC=Manticore,DC=org"            
$ws = "Comp1,Comp2,Comp3,Comp4,Comp5"            
            
"`nMicrosoft"            
$name = "UserA"            
Get-ADUser -Identity $name |            
Set-ADUser -Replace @{userWorkstations = $ws}            
            
"`nAD provider"            
$name = "UserB"            
$dn = "cn=$name,$ou"            
Set-ItemProperty -Path AD:\$dn  -Name userWorkstations -Value $ws -Force            
            
"`nQuest"            
$name = "UserC"            
Get-QADUser -Identity $name |            
Set-QADUser -ObjectAttributes @{userWorkstations = $ws}            
#>            
"`nScript"            
$name = "UserD"            
$dn = "cn=$name,$ou"            
$user = [adsi]"LDAP://$dn"            
$user.userWorkstations = $ws            
$user.SetInfo()

Create a list on computer names – notice that there aren’t any spaces between the computer names – this is required.

Otherwise the scripts work in the same way as setting any other property

By default a user can logon 24/7.  Is this acceptable – should users be able to logon during the night or weekends. AD Users and Computers has a GUI to set the hours users can logon. But we don’t need a GUI we can do this

if (-not (Get-Module ActiveDirectory)){            
  Import-Module ActiveDirectory            
}            
            
$ou = "OU=England,DC=Manticore,DC=org"            
            
## allow logon 8am - 6pm Monday to Friday            
[byte[]]$hours = @(0,0,0,0,255,3,0,255,3,0,255,3,0,255,3,0,255,3,0,0,0)            
            
"`nMicrosoft"            
$name = "UserA"            
Get-ADUser -Identity $name |            
Set-ADUser -Replace @{logonhours = $hours}            
            
"`nAD provider"            
$name = "UserB"            
$dn = "cn=$name,$ou"            
Set-ItemProperty -Path AD:\$dn  -Name logonhours -Value $hours -Force            
            
"`nQuest"            
$name = "UserC"            
Get-QADUser -Identity $name |            
Set-QADUser -ObjectAttributes @{logonhours = $hours}            
            
"`nScript"            
$name = "UserD"            
$dn = "cn=$name,$ou"            
$user = [adsi]"LDAP://$dn"            
$user.logonhours[0] = $hours            
$user.SetInfo()

We’ll use the four test users we created earlier in the England OU.

The important point is how we represent the hours users can logon.

The information is stored as a byte array – 3bytes per day with 1 bit per hour

We want to restrict the users to 8am-6pm Monday to Friday so we use

[byte[]]$hours = @(0,0,0,0,255,3,0,255,3,0,255,3,0,255,3,0,255,3,0,0,0)

Sunday is the start of the week – no logons allowed so first three bytes are 0. Monday’s three bytes starts with a 0 as don’t want logons between midnight and 8am. The 8 hours of logons followed by two hours. etc

A few other examples might help

Deny all logon

[byte[]]$hours = @(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)

Allow logon at all hours

[byte[]]$hours = @(255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255)

Allow 8am-6pm – 7 days a week

[byte[]]$hours = @(0,255,3,0,255,3,0,255,3,0,255,3,0,255,3,0,255,3,0,255,3)

If you are in doubt about generating the array – set in the GUI then copy the values using ADSIEdit

The scripts are straightforward – the cmdlets get the user and pipe to set. The difference is the parameter we use

The provider uses Set-Itemproperty and the only oddity in the script is we use logonhours[0] as the property. This forces acceptance of the byte array

Creating an OU is a fairly common activity. The GUI is quick enough for a single OU but we need PowerShell for bulk creation.

Its a straight forward activity

if (-not (Get-Module ActiveDirectory)){            
  Import-Module ActiveDirectory            
}            
            
$ou = "OU=BlogTests,DC=Manticore,DC=org"            
            
"`nMicrosoft"            
$name = "OUM"            
New-ADOrganizationalUnit -Path $ou -Name $name            
            
"`nAD provider"            
$name = "OUP"            
New-Item -Path AD:\$ou -Name "OU=$name" -ItemType Directory            
            
"`nQuest"            
$name = "OUQ"            
New-QADObject -ParentContainer $ou -Type 'OrganizationalUnit' -NamingProperty 'ou' -Name $name            
            
"`nScript"            
$name = "OUS"            
$target = [adsi]"LDAP://$ou"            
$user = $target.Create("organizationalunit", "ou=$name")            
$user.SetInfo()

There is a Microsoft cmdlet specifically for this activity. Just give it a path and a name.  The Quest cmdlet is marginally more complicated but still easy.

The script you will recognise as a variant of creating a user. This pattern works for most things in ADSI – get the parent container and use the Create() method.

The provide uses New-Item as you would expect – notice the ItemType is Directory!

Alternatively the provider supplies the ultimate shortcut code for creating an OU.  Yes md (or mkdir) work

cd ad:\$ou

md "ou=testing"