Zoho Banner September 2011

Archive for June, 2012

After an absence of a couple of years, the Wellington Windows Infrastructure User Group has been brought back to life!  If you’re in Wellington on Wednesday 4th July, come along and watch me and Daniel Bowbyes presenting on some Windows Server 2012 goodness.

http://www.mscommunities.co.nz/Events/Wellington-Windows-Infrastructure-User-Group—Win.aspx

For a number of years now I have been using OldCmp  to find and remove inactive user and computer accounts.  The other day I thought I would have a crack at using the AD Powershell cmdlets to at least do the finding part.  It wasn’t as difficult as I thought.  Here’s an example looking for enabled accounts that have been inactive for 90 days or more:

# Find inactive user accounts

$now = Get-Date
$old = $now.AddDays(-90)
Get-ADUser -Filter * -Properties lastlogondate `
| ? {($_.enabled -eq $true) -and ($_.lastlogondate -le $old)} `
| select samaccountname, lastlogondate `
| Export-Csv .\inactive_users.csv -NoTypeInformation

# Find inactive computer accounts

$now = Get-Date
$old = $now.AddDays(-90)
Get-ADComputer -Filter * -Properties lastlogondate `
| ? {($_.enabled -eq $true) -and ($_.lastlogondate -le $old)} `
| select name, lastlogondate `
| Export-Csv .\inactive_computers.csv -NoTypeInformation

I normally use LDAP filters for all searches, but in this case I used a standard Powershell filter.  Why? Well, because the cmdlets expose two pseudo attributes: “enabled” and “lastlogondate”.  I call these pseudo attributes because you won’t find them anywhere in the AD schema.  They are provided to make life easier.   The alternative would be to query userAccountControl with a bitwise filter  to find the enabled/disabled state and to do some formatting with lastLogonTimestamp, which is stored in AD as a large integer value.

I hope you find these useful.

I’ve had the script shown below for quite a while, but as I recently tested it successfully against Windows Server 2012 AD (Release Candidate), I thought I would share it with the community.

Note that I have only tested it with single domain forests.

Import-Module activedirectory

[string] $menu = @'

    Active Directory FSMO Role Holder mover script
    Please select an option from the list below

    1) Move all roles
    2) Move the Schema Master (forest)
    3) Move the Domain Master (forest)
    4) Move the Infrastructure Master (current domain)
    5) Move the PDC Emulator (current domain)
    6) Move the RID Master (current domain)

Select an option.. [1-6]?
'@

Write-host "Last command: " $opt -foregroundcolor Blue
$opt = Read-Host $menu
$target = Read-Host "Target DC for the role(s)?"

switch ($opt)    {
    1 { Move-ADDirectoryServerOperationMasterRole $target DomainNamingMaster, SchemaMaster, PDCEmulator, InfrastructureMaster, RIDMaster -confirm:$false }
    2 { Move-ADDirectoryServerOperationMasterRole $target SchemaMaster -confirm:$false }
    3 { Move-ADDirectoryServerOperationMasterRole $target DomainNamingMaster -confirm:$false }
    4 { Move-ADDirectoryServerOperationMasterRole $target InfrastructureMaster -confirm:$false }
    5 { Move-ADDirectoryServerOperationMasterRole $target PDCEmulator -confirm:$false }
    6 { Move-ADDirectoryServerOperationMasterRole $target RIDMaster -confirm:$false }
    default { write-host "You haven't selected any of the available options."; exit }
} # End switch loop

 

Recently, I have been working in an Windows Server 2008 R2 AD environment that has a number of RODCs in branch offices.   The environment uses DFSR (i.e. not FRS) for SYSVOL replication an I wondered whether I could simply remove the connection objects named “RODC Connection (FRS)”.  To me, the use of “FRS” in the name indicated that it was a probably a legacy object.  Rather than going ahead with the removal, I thought I would first check on-line and with some fellow MVPs as well as Microsoft employees.  Here’s what I found….

The FRS connection objects are not required by DFS Replication” in the RODC Frequently Asked Questions article on Technet (note: this has since been reworded).

http://technet.microsoft.com/en-us/library/cc754956(v=WS.10).aspx

I also found this statement in the Directory Services Team Blog…

Despite the mention only of FRS in this article, the 0×40 value is required for both DFSR and FRS

http://blogs.technet.com/b/askds/archive/2010/10/08/friday-mail-sack-cluedo-edition.aspx#rodc

The two statements are contradictory and it was only after helpful clarification from Microsoft’s Kurt Hudson that it transpires the connection object is required for SYSVOL replication using either method (i.e. FRS or DFSR).  In other words if you are using DRSR for SYSVOL don’t delete these connection objects or you will need to manually recreate them (being sure to set the 0×40 bit in the options attribute as described in the DS team blog article).

I fired up an RODC on Windows Server 2010 Release Candidate yesterday and was pleased to see the connection object has been renamed to avoid confusion.

Windows Server 2008 R2

RODC_Connections_2008R2

Windows Server 2012 Release Candidate

RODC_Connection_Objects

Well done Kurt!  It’s great to see this sort of thing getting resolved.