Adam's AD Admin

Download the release .... http://support.microsoft.com/kb/968929 Powershell blog post ... http://blogs.msdn.com/powershell/archive/2009/10/27/windows-management-framework-is-here.aspx Enjoy!

Whilst doing some research into indexed attributes, I posted this  a while back on how to find your index attributes.  Since then, I have looked a little deeper into what indexing really means and found this excellent explanation on the numbers that can be found in the searchflags attribute of a schema object. Using Florian’s reference, I built the following script (which is both powershell v1 and v2 compatible) to get the schema attributes from the forest schema and return (among other things) the breakdown of your attributes search flags. $forest = [System.DirectoryServices.ActiveDirectory.forest]::getcurrentforest() $schema = [ADSI]('LDAP://CN=Schema,CN=Configuration,dc=' + ($($forest).name -replace "[.]",",dc=")) $attributes = $schema.psbase.children | where {$_.objectClass -eq "attributeSchema"} $collection = @() foreach ($attr in $attributes){ $store = "" | select "Name","lDAPDisplayName","singlev

For all the windows 7 shortcuts you'll ever need.  Added to links too!

I have been meaning to get my head around a lot of different aspects of powershell, one of which is hash tables.  As we are currently going through a DC upgrade, I wanted to know how many DC's we had of each different operating system.  I wondered if hash tables would help me. First, I got all DC's in my domain :  $DClist = get-ADDomainController -server domain.com -filter {enabled -eq $true} You may notice the get-ad portion of the command....this means that this command runs only on powershell 2 when connected to an Windows 2008 R2 DC or a 2003 / 2008 DC with ADMGS installed.  So, $DCList is now all the DC's from domain.com (-server domain.com) that are set to enabled (-filter {enabled -eq $true}).  NOTE: The only DC's that are not enabled are pre-staged RODC accounts ... by that i mean accounts that have been created but the server has not come online yet.  These servers do not have any OS information in them anyway. It is more helpful to filter these w

I have been fortunate enough to be involved in quite a large RODC deployment in a Windows 2008 domain. Even more fortunate is that we are currently upgrading this domain to R2 so I am getting the chance to try out the new powershell 2 AD cmdlets. I have been looking quite a lot into RODC operations, and the importance of the Password Replication Policy (PRP from now on) component has become increasingly more apparent. My first thoughts of PRP were entirely user based. "It allows users to logon to a remote site when the WAN link is down" was my impression. But, when a user logs on to a domain from a trusted computer, there is 2 parts to the authentication - user AND computer. Therefore it is just as important to add the computer objects to the allow PRP as it is the users. While you are there, add any server that is in the same site as the RODC as they will need to authenticate too. My preferred way of doing this create 3 groups and add them to the PRP policy : all users, al