How do you find the user accounts which take up the most space in Active Directory database?

I have just had this very question from a customer who has some BLOB attributes added to user objects and suspect that some of these got much bigger than the others. As result, the overall AD database is now way bigger than the customer would like to have (affecting performance, backups, replication, and so on.)

The problem they had is finding these objects.

My first reaction was: just do a Get-QADUser and sort the objects by size – how much easier can it get? Well, the problem is that there is just no SizeOf function in PowerShell – the system would not tell you how big a given object is.

The workaround I found was very simple. If we cannot get the in-memory size of an object – we can still export it to a file and measure the file size.

So here is my script:

# Use a different value of SizeLimit 
# if you want a subset of accounts to test the script
Get-QADUser -SizeLimit 0 -IncludeAllProperties | ForEach {
    $_ |  Export-Clixml "$($_.samAccountName).xml"
}
dir | sort Length -Descending

In a nutshell, all it does is goes through all AD user accounts, and exports each into xml file.

Then I just sort them by size.

The cool part about using ForEach-Object and not keeping all objects in an array is that this is actually very efficient from memory consumption perspective – each object gets cleared from memory after it is saved to xml.

Throughout running the script powershell.exe process was consuming only about 30-40MB of RAM.

One thing to note is that in most domains this script will take a long time to execute (hours). You can make it faster if you can limit the scope of Get-QADUser either by some attributes (SearchRoot, Enabled/Disabled, City, and so on) or properties (I was retrieving all, but if you actually know which properties contribute the most to the size you can include just these properties.) Again, see this post for more consideration on optimizing the script.

Tags: AD, AD cmdlets, Active Directory, PowerShell, cmdlets, one-liner, oneliner
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Another great new feature in Quest’s free AD cmdlets 1.2 is ability to locate deleted (tombstoned) Active Directory objects and restore them back.

Locating is very straight-forward: you just add the -Tombstone switch to the Get-* cmdlet of your choice and now your query searches deleted rather than live objects.

Restoring is even easier – all you need is pipeline the deleted objects into Restore-QADDeletedObject.

And the best thing of all is that this works great with Windows 2003 Active Directory – so you can start taking advantage of the feature right away!

For example:

# List all tombstoned user accounts
Get-QADUser -Tombstone

# Restore accounts deleted from a specific OU
Get-QADUser -Tombstone -LastKnownParent 'OU=People,DC=company,dc=local' | Restore-QADDeletedObject

# Restore accounts deleted today
Get-QADUser -Tombstone –LastChangedOn (get-date) | Restore-QADDeletedObject

# Restore a specific deleted user
Get-QADUser -Tombstone –Name 'John Smith*' | Restore-QADDeletedObject

One gotcha to keep in mind is that when objects are tombstoned computer and user objects are stored in AD exactly the same way. This makes Get-QADUser actually return both user and computer objects. Shay found this workaround to make sure that only user objects are returned:

# Return all tombstoned user accounts but no computer objects
Get-QADUser -Tombstone -SizeLimit 0 -ldap '(&(!samAccountName=*$))'

Other Get-* cmdlets which now have these -Tombstone and -LastKnownParent parameters are:

• Get-QADComputer
• Get-QADGroup
• Get-QADObject
• Get-QADPasswordSettingsObject

For more information on what a tombstoned object is and how tombstone-based undelete is different from full recovery see Gil’s article here.

Suppose you have a CSV file (a text file with columns separated by commas) with the properties for AD user accounts you want to update. How do you do this in PowerShell?

Turns out, that we talked a lot about creating new accounts from CSV files before, but not about updating existing ones. Let’s fix this right away.

I will be using AD user accounts in my examples, but it is fairly easy to adapt them to other AD objects: groups, computers, OUs, DNS records, and so on.

The command actually depends on the CSV you get. The easiest case is when the column names are exactly the same as Set-QADUser parameters. For example, let’s say you have a CSV file in which you have a samAccountName column which you want to use to locate the accounts to update and Title and Department columns with the new values to set:

samAccountName,Title,Department
test1,Manager,Accounting
test2,Developer,RD
test3,SC,Pre-Sales

The onliner to apply this file to your AD is as simple as:

Import-Csv c:\update.csv | Set-QADUser -Identity { $_.samAccountName }

You basically pipe import into Set-QADUser and specify which column to use as the identity anchor.

Easy!

Now, suppose that life is not so easy and either you do not control the column labels or you need to update attributes which either do not match the parameter names or have no matching parameters at all. Like:

samAccountName,Job,ExtensionAttribute1,ExtensionAttribute2
test1,Manager,M,Yes
test2,Developer,S,No
test3,SC,XXL,Maybe

The automated column matching will not work here but we can use ForEach-Object loop and match the parameters manually + use ObjectAttributes for attributes with no parameters:

Import-Csv c:\update.csv | ForEach-Object {
Set-QADUser $_.samAccountName -Title $_.Job `
-ObjectAttributes @{ExtensionAttribute1=($_.ExtensionAttribute1);
ExtensionAttribute2=($_.ExtensionAttribute2)}
}

Now we can update from CSV any account properties we want!

Tags: AD, AD cmdlets, Active Directory, Examples, PowerShell, cmdlets, one-liner, oneliner
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Constructed (or computed) Attributes are an important part of the way Active Directory is functioning. Basically, these are not real attributes, in the sense that they do not really exist, but are calculated by AD when being queried. They contain very useful info (for example well known primaryGroupToken and modifyTimeStamp) but they obviously have a few limitations such as not being “settable” or not available for filtering, so knowing which are which is quite useful!

Here’s how you get a list of all computed attributes in your AD:

Get-QADObject -SearchRoot “CN=Schema,CN=Configuration,dc=MyDomain,dc=COM“ -Type attributeSchema -IncludedProperties systemFlags -SizeLimit 0 | where {$_.SystemFlags -band 4}

Basically, this one-liner retrieves all (-SizeLimit 0) attributes (-type attributeSchema) from the Schema partition (-SearchRoot "CN=Schema,CN=Configuration,dc=MyDomain,dc=COM"), together with their system flags (-IncludedProperties systemFlags), and leaves just the ones with FLAG_ATTR_IS_CONSTRUCTED (where {$_.SystemFlags -band 4}).

Thanks to Andrey Moiseev who shared this with me recently!

[UPDATE] Check out Aleksandar’s post on making this oneliner run 40 times faster.

Tags: AD, AD cmdlets, Active Directory, Examples, PowerShell, cmdlets, one-liner, oneliner
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

How do you find out when was the last time a particular user logged on?

(Get-QADUser username).lastLogon looks like an obvious answer but there are a few gotchas to be aware of.

The main of them: lastLogon attribute is actually not replicated between domain controllers so if you have more than one DC (which I am sure you do) you need to get it from all of them and get the latest of them.

Here’s the PowerShell code which does that:

Get-QADComputer -ComputerRole DomainController | foreach {
(Get-QADUser -Service $_.Name -SamAccountName username).LastLogon.Value
} | Measure-Latest

Basically, we are getting a list of all DCs in the company, then prompting each of them for the user’s lastLogon time, and then picking the latest of the values (I am using my Measure-Latest function – just copy/paste if before executing this command or put in your script.)

Note that there are utilities which can do that querying and comparison for you. NetWrix guys even have a PowerShell cmdlet described here, so you can do something like:

Get-NCInactiveUsers -domain example.com -days 15

You should also keep in mind that if your users do not log off and simply lock their workstations they do not log on either – Kuma is describing here how he has a script logging off users every night to avoid this.

Another alternative is using lastLogonTimeStamp attribute instead. This one does indeed get replicated. It was introduced in Windows 2003 (make sure your schema is 2003-level or later). But keep in mind that this one is not real-time as it is only replicated every 9-14 days.

So as long as you are looking for users who have not logged on for something bigger than 2 weeks you should be good using Shay’s script for locating inactive users:

$now=get-date
$daysSinceLastLogon=60

Get-QADUser -sizeLimit 0 | where {
$_.lastlogontimestamp.value -and (($now-$_.lastlogontimestamp.value).days -gt $daysSinceLastLogon)
} | Format-Table Name, LastLogonTimeStamp

Tags: AD, AD cmdlets, Active Directory, PowerShell, one-liner, oneliner
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Darren has just posted a couple of cmdlets that let you list recently deleted AD objects and restore the ones you want back.

Get-SDMADTombstones -Filter Evans | Restore-SDMADTombstones

Very cool! You can download them from SDM Software freeware page.

And if you are still not sure about using this in a command line, I have hacked together a simple PowerGUI pack on top of Darren’s snapin:

The AD tombstone reanimation pack is available for download from the PowerGUI library. Now you have free command line and free admin UI to handle AD tombstone reanimation!

Tags: AD, AD cmdlets, Active Directory, Examples, Freeware, PowerGUI, PowerPack, PowerShell, cmdlets, one-liner, oneliner
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Broken permissions inheritance can be a source of multiple issues – with PowerShell you can get such issues located and fixed with an easy oneliner.

Getting security inheritance blocked is easy – locating and setting it back can be hard. One big customer of ours once had most of their mail transport paralyzed with a branch administrator clearing the inherit permissions checkbox he thought should not have been there. Nicolas is reporting similar issues with Exchange 2007 deployments.

Seeing whether an AD object has permissions inheritance blocked is as easy as checking the object’s DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected property.

So for example, to get a list of all users in the domain who has inheritance off you just need to run:

Get-QADUser -SizeLimit 0 | where {$_.DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected}

I am using -SizeLimit 0 so I retrieve all users and not just the default 1000.

Fixing inheritance is even easier with the new Set-QADObjectSecurity cmdlet introduced in AD cmdlets 1.1.

So if you want to fix inheritance for all AD users (caution: you might want to just get the list of the accounts first using the command above to make sure you do not “fix” legitimate exceptions) you just need to pipe the collection into Set-QADObjectSecurity -UnlockInheritance:

Get-QADUser -SizeLimit 0 | where {$_.DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected} | Set-QADObjectSecurity -UnlockInheritance

Easy!

Tags: AD, AD cmdlets, Active Directory, Examples, Exchange, Exchange 2007, PowerShell, Security, cmdlets, one-liner, oneliner
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

I’ve recently blogged about retrieving AD security with PowerShell, as you can probably guess for every Get-* there is a Set-* and AD cmdlets 1.1 provide you an easy way to change the permissions set on any AD object.

Add-QADPermission and Remove-QADPermission are your biggest friends here.

Well, obviously and the power of the PowerShell pipeline. My favorite example is copying permissions from one object to another with that simple oneliner:

Get-QADPermission “Dmitry Sotnikov” | Add-QADPermission “Evil Tween”

This simple line is incredibly powerful. It takes all permissions directly set on the first objects and adds them onto the second one. Of course you could put where in the middle to do some filtering if you need.

Of course you can explicitly grant specific rights on specific objects. Suppose you want to give Administrator full control over an OU and everything in it. Easy:

Add-QADPermission ‘OU=Demo,DC=mydomain,DC=local‘ -Account Administrator -Rights ‘GenericAll‘

You can use the -Deny parameter to deny access, -PropertySet to work with property sets and -ApplyTo to select whether you want to give rights only to this object or its children or any possible combination. So for example you could do:

Add-QADPermission dirObjectIdentity -Deny -Account trusteeIdentity -Rights ‘WriteProperty‘ -PropertySet (‘General-Information‘,‘Web-Information‘) -Property ‘samAccountName‘ -ApplyTo ThisObjectOnly

You can also pipe any AD object into these cmdlets (similar to reading the objects) for bulk operations:

Get-QADUser -City Orlando -SecurityMask Dacl | Add-QADPermission -Account ‘Dmitry Sotnikov‘ -Rights ‘ReadProperty‘

And, as you can easily guess Remove-QADPermission can delete any ACE in much the same way. For example, let’s remove all the Deny ACEs from a particular object:

Get-QADPermission objectIdentity -Deny | Remove-QADPermission

You can find more information and examples in the user’s guide and by typing get-help for any of these cmdlets.

Download the cmdlets and give us your feedback at the AD PowerShell discussion forums.

Tags: AD, AD cmdlets, Active Directory, Examples, PowerShell, Security, cmdlets, one-liner, oneliner
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

One of the biggest advances of AD cmdlets 1.1 is support for AD security operations. In this post we will look at the Get-QADPermission cmdlet and how you can use it to read permissions set on AD objects.

To get a list of permissions set on an AD objects directly you just need to use:

Get-QADPermission Identity – where identity is Name, DN, Canonical name, Domain\Name, and so on. For example:

Get-QADPermission ‘Dmitry Sotnikov‘

As usual you can pipeline a set of objects into the cmdlet to get results for all of them, e.g.:

Get-QADUser -SearchRoot domain.local/employees/chicago -SecurityMask DACL | Get-QADPermission

Here I am getting access control for all permissions directly set on users in the domain.local/employees/chicago OU. Note that I am also using the -SecurityMask parameter to tell the Get-QADUser cmdlet to retrieve the access list (DACL – Discretionary Account Control List). This is optionally but highly recommended because if you use this parameter Get-QADPermission does not have to retrieve the DACL again – less calls to the DC, better performance.

The examples above deal only with the permissions set on the object directly, you can add inherited permissions by simply adding -Inherited. In a similar fashion, the -SchemaDefault parameter adds Account Control Entries (ACE) that came from the default security descriptor. So this will give you everything:

Get-QADPermission “Dmitry Sotnikov“ -Inherited -SchemaDefault

Or the same but much faster:
Get-QADUser -Name “Dmitry Sotnikov“ -SecurityMask DACL | Get-QADPermission -Inherited -SchemaDefault

You can look for the rights which specific trusties have:

Get-QADPermission “Dmitry Sotnikov“ -Account (‘domain\bill‘, ‘self‘) -UseTokenGroups

Note that I have added -UseTokenGroups to make sure I get Bill’s rights even if he got those via group membership.

Or for specific rights set on specific properties:

Get-QADPermission “Dmitry Sotnikov“ -Rights ‘WriteProperty‘ -Property (‘samAccountName‘,‘name‘)

You can also check for extended rights. Let’s see if I can change my password:

Get-QADPermission “Dmitry Sotnikov“ -account “self“,“everyone“ -Allow -ExtendedRight “User-Change-Password“ -Inherited –SchemaDefault

-Allow and -Deny parameters allow to check specifically for allowing and denying ACEs.

And there’s much much more: just check out:

get-help Get-QADPermission -detailed

Good job by the team trying to cover each and every case they could think of. If you can think of something they have not covered or implemented in a suboptimal way – please provide your feedback in the AD PowerShell forum – the team is there and listening.

Here’s the AD cmdlets download page which has the latest 1.1 beta drop.

Tags: AD, AD cmdlets, Active Directory, Examples, Password management, PowerShell, Security, cmdlets, one-liner, oneliner
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Terminal Services properties is definitely a set of properties you would want to bulk-manage, and as we all know PowerShell is the best tool for any bulk operations.

We have recently (in the AD cmdlets 1.0.6 drop) improved the experience here (thanks to requests from Simon and George) and there are a few gotchas to keep in mind – so I thought I would summarize this all in one blog post.

Getting TS attributes

Retrieving terminal services properties is easy. You just execute Get-QADUser and the objects retrieved will have the corresponding properties – for your convenience, all starting with Ts.

PS C:\> get-qaduser "Dmitry Sotnikov" | format-list Ts*

TsProfilePath : \\server\tsprofiles\DSotnikov
TsHomeDirectory : \\server\tshome\DSotnikov
TsHomeDrive : P:
TsAllowLogon : True
TsRemoteControl : 0
TsMaxDisconnectionTime : 00:00:00
TsMaxConnectionTime : 00:00:00
TsMaxIdleTime : 00:00:00
TsReconnectionAction : 1
TsBrokenConnectionAction : 0
TsConnectClientDrives : True
TsConnectPrinterDrives : True
TsDefaultToMainPrinter : True
TsWorkDirectory : c:\
TsInitialProgram : C:\Program Files\Quest\Initialize.exe

Important: Terminal services properties are only available when AD cmdlets are run on Windows Server 2003 or 2008. Workstation operating systems (XP, Vista) do not support programmatic TS administration so the properties will not be retrieved.

[Update] See these instructions on enabling Terminal Services management on XP and Vista.

Changing TS attributes

TS properties are not (yet) available as Set-QADUser parameters and need to be changed as properties of retrived objects as shown in the example below:

$u = get-qaduser dsotnikov
$u.TsProfilePath = 'c:\profile'
$u.CommitChanges()

[Update] With AD cmdlets 1.1.1 Set-QADUser exposes all the TS attributes as its parameters so changing TS attributes is now much easier:

get-qaduser -searchroot mydomain.local/uk/london | set-qaduser -TsHomeDrive 'P:'

Again, make sure you follow the system requirements.

Property reference

Here’s a quick reference to the properties (I borrowed some of the descriptions from the MSDN page):

Tags: AD, AD cmdlets, Active Directory, Examples, cmdlets, one-liner, oneliner
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |