Posts RSS Comments RSS 253 Posts and 411 Comments till now

Windows 2008 R2 RTM availble now on MSDN


Win7 Released to MSDN/Technet

Go get it… later after I am done downloading πŸ™‚

Getting users group membership (tokengroups)

Around the same time as I wrote my Linked-Value Attribute script I also came up with this little gem. It also uses a constructed attribute provided with Windows 2003 called “tokengroups.” (Did I mention this includes recursive groups?)

Effectively it gets the attribute which returns an array of SIDs (in byte array form) for each group. I then use a function I posted about eariler called ConvertTo-Name to convert that BYTE array into a friendly group name we humans like.


  • – Account: Can be User samAccountName or DN of the user
  • – Verbose: Enables verbose output

More Info:
You may notice the GetInfoEx call I make on the user object. This is because tokengroups is not an actual attribute and does not get “populated” until you specifically request it. The GetInfoEx does exactly that.

MSDN: GetInfoEx
MSDN: tokenGroups




Write-Verbose " – Account: $Account"
Write-Verbose " – Verbose: $Verbose"

function ConvertTo-Name($sid,[switch]$FromByte) {
        $ID = New-Object System.Security.Principal.SecurityIdentifier($sid,0)
        $ID = New-Object System.Security.Principal.SecurityIdentifier($sid)
        $User = $ID.Translate([System.Security.Principal.NTAccount])
function GetDNfromName{
    $root = [ADSI]""
    $filter = "(sAMAccountName=$name)"
    $props = @("distinguishedName")
    $Searcher = new-Object System.DirectoryServices.DirectorySearcher($root,$filter,$props)

if($Account -notmatch "CN=(.*),((OU|DC)=\w*)*")
    Write-Verbose " + Getting User DN for [$Account]"
    $Account = GetDNfromName $Account
    Write-Verbose "   – GetDNfromName returned [$Account]"

Write-Verbose " – Getting User Object"
$UserAccount = [ADSI]"LDAP://$Account"

Write-Verbose " – Calling GetInfoEx"

Write-Verbose " – Getting tokengroups"
$groups = $UserAccount.Get("tokengroups")

Write-Verbose " + Processing Groups"
foreach($group in $groups)
    $GroupName = ConvertTo-Name $group -FromByte
    Write-Verbose "   – Found group [$GroupName]"


Constructed Properties and LVR (Linked-Value Replication)

There was an interesting question that came up on the news group that discussed getting Active Directory replication metadata and while the question really wasn’t directly a Powershell question I found it intriguing. I knew I had the answer to the question back in my brain, but I couldn’t retrieve it.

Here is the Question:

“I’m working on a script where I need to compare the last time the member
attribute of a distribution group was modified (not the AD group object
itself) with the time stamp on a file (I’m exporting distribution group
memberships to a file, but only ones that have changed). The problem
I’m running into is that some Active Directory distribution groups
aren’t returning the member attribute when I look at the replication
meta data.

Any one have any thoughts on why some distribution groups return the
member attribute when I run GetReplicationMetadata and some don’t? This
returns all kinds of other attributes and their metadata, but naturally
not the one I’m interested in (it does some times, on some groups, but
not all). I could run my script by the actual AD object WhenChanged
attribute, but I’ll be processing a large number of lists and I want it
to run as fast as possible and since other attributes can change on a
group object, I don’t want to have to export a 8,000 member group if the
displayName changes, for example (I’m only interested in the member
As always, any insight is appreciated.”

I thought about this for a bit and also consulted some AD friends and we determined the issue was LVR (Link Value Replication.) This was introduced in Windows 2003 (specifically 2003 Native Mode.)

Basically, LVR changed the unit of replication for some attributes to be the actual values. Prior to LVR if you changed group membership the entire attribute member would have to replicate. With LVR, just the link you added for user replicates.

As one can imagine this changed the Metadata and therefore GetReplicationMetadata() didnt get retrieve the data for you. Where does this leave us?

There were also a few constructed attributes that were added with 2003. One of which is called “msds-replvaluemetadata.” This attribute provided the metadata for these links in wonderful XML format. You will find code using this XML below.

Some Useful Links regarding LVR and Constructed Attributes:

Below is the script that resulted from the investigation




$GroupMembers = @()

$root = [ADSI]""
$filter = "(&(objectclass=group)(name=$GroupName))"
$props = @("msDS-ReplValueMetaData")
$Searcher = new-Object System.DirectoryServices.DirectorySearcher($root,$filter,$props)
foreach($Group in $Searcher.findall())
    foreach($childMember in $Group.Properties."msds-replvaluemetadata")
        $GroupMembers += [”>XML]$ChildMember

foreach($Member in $GroupMembers)

Setting the WriteProperty on Members (ManagedBy Check box)

This has come up three times in the last week which triggers my auto blog response πŸ™‚

Below is a function called New-ADAce. This function creates an Access Control Entry that can be applied to an AD Object (in this case the member property of an AD object.)

Basically what the code below does is:

  • Gets the ID object of the Manager
  • Creates ACE that gives the Manager Write access to the member property
  • Gets the Object to be managed
  • Gets the existing ACL
  • Addes the ACE to the ACL
  • Sets the ManagedBy Property to the DN of the Manager
  • Commits the changes
   $myGuid = "bf9679c0-0de6-11d0-a285-00aa003049e2", #GUID for the Members property
   $DN = "cn=jloser,cn=users,dc=corp,dc=lab",
   $domain = $env:UserDomain,
   $manager = "jmanager",
   $MangedByDN = ""cn=jmanager,cn=users,dc=corp,dc=lab""

function New-ADACE {

   $help = @"
      Object Type of the property
      The schema GUID of the object to which the access rule applies.
   $ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($identity,$adRights,$type,$guid)

# Some example code on how to use the New-ADACE function

# Create ACE to add to object
$ID = New-Object System.Security.Principal.NTAccount($domain,$manager)
$newAce = New-ADACE $ID "WriteProperty" "Allow" $myGuid

# Get Object
$ADObject = [ADSI]"LDAP://$DN"

# Set Access Entry on Object

# Set the manageBy property

# Commit changes to the backend

Tracing LDAP calls with Powershell

Spat had an eerily coincidental blog post the other day (HERE). The reason I say eerily is because the night before I was fighting trying to get a LDAP trace, this trace was to help figure out EXACTLY how SDS.ActiveDirectory got replication cursors from a Domain Controller (another joe Richards discussion.) Anyway, I digress, I found the blog entry EXTREMELY useful as it allowed me to get what I needed. I proceeded to leave a comment suggesting that this looked like a good job for Powershell as the resulting file from the tool is a CSV. This has led to a β€œchallenge” from Spat and this is my response. I hope I did it justice.

Useful Links about Tracelog.exe
Details about TraceLog.exe
LDAP tracing with TraceLog
ADSI tracing with TraceLog

Details about Script

Here are the functions in the script

-flag: Hex value for the flags you want to pass (Default Value = “0x1FFFDFF3”)
-guid: GUID or File for tracing (Default Value = “LDAP”)
-SessionName: Unique Name for the actual trace (Default Value = “mytrace”)
-exe: The full name with extension of the EXE to add to registry to enable tracing. This only has to be done the first time you want to trace for an EXE.
[switch]Start: If set it enables logging. If not set, logging is disabled.
[switch]ADSI: If set it passes the ADSI GUID for tracing
[switch]LDAP: If set it passes the ADSI GUID for tracing

-Source: Trace (etl) file to convert to csv (Default Value = “.\ldap.etl”)
-file: File to set the results to (Default Value = “TraceResults.csv”)
[switch]$import: If set it will return a custom object with results

Below is a video that shows a demo of the script in use. I hope to do another one of these showing how to trace ADSI as well as LDAP. Make sure to read the Comments in Green. I tried to allow enough time. You can click to pause.

Download Tracelog Transcript (right click | Save Target As…)
Best Viewed Full Screen

Get the Flash Player to see this content.

Download Trace Log Functions (right click | Save Target As…)

function Trace-Log {
    Param($file = ".\ldap.etl",
        $flag = 0x1FFFDFF3,
        $guid = "LDAP",
        $SessionName = "mytrace",
    if($ADSI){$guid = "ADSI"}
    switch -exact ($guid)
        "LDAP"  {$myguid = ‘#099614a5-5dd7-4788-8bc9-e29f43db28fc’}
        "ADSI"  {$myguid = ‘#7288c9f8-d63c-4932-a345-89d6b060174d’}
        Default {$myguid = "’$_’"}
        Write-Host " Action: Start" -fore Yellow
        Write-Host " GUID:   $GUID" -fore Yellow
        Write-Host " File:   $file" -fore Yellow
        Write-Host " Flag:   $flag" -fore Yellow
        if($exe){Write-Host " Exe:    $exe" -fore Yellow}
        Write-Host " State: Disabled" -fore Red
    if(!(test-Path "HKLM:\System\CurrentControlSet\Services\ldap\tracing\$exe") -and $exe)
        new-Item -path "HKLM:\System\CurrentControlSet\Services\ldap\tracing" -name $exe | out-Null
        $cmd = "Tracelog.exe -start ‘$SessionName’ -f ‘$file’ -flag ‘$flag’ -guid ‘$myguid’"
        $cmd = "tracelog -stop $SessionName"
    Write-Host "==========================" -fore White -back black
    write-Host "Running Command:" -fore White
    Write-Host " ==> $cmd" -fore Yellow
    invoke-Expression $cmd
    Write-Host "==========================" -fore White -back black
function Convert-TraceFile{
    $cmd = "tracerpt.exe $Source -o $file -of CSV -y"
    invoke-Expression $cmd
        import-Csv $file

Back From the MVP Summit

Well… Just got back from a week in Redmond. It was awesome!

First I want to thank MS for putting this all together. It was a testament to their commitment to the community and desire to see their products succeed.

While this was my first MVP summit, I did hear several others comment on how this was the best one yet.

I was VERY lucky to have a seasoned MVP vet (Dean Wells) show me the ropes and introduce me to some of the (IMO) smartest technical people on the planet. These guys/gals are not only incredibly smart… but they were an absolute blast to hang out with.

I doubt they subscribe to my blog but I wanted to do a shout out and link their blogs/Sites

Dean Wells: Absolute Great Trainer/Consultant
joe Richards (joeware):
Joe Kaplan :
Brian Desmond:
Laura Hunter:
Mr Hunter (Mark Arnold) :
Gil Kirkpatrick (NetPro):
Ulf B. Simon-Weidner’s:
Tony Murray (founder Blog:
Little Jimmy:
Darren Mar-Elia (SDMSoftware):
Princess Jorge!:
Brett Shirley:
Eric Fleischman: (currently VERY slow to post)

I can not tell you (literally I am under NDA πŸ™‚ ) How much I learned this past week.

What I can say is that for Powershell… the future is VERY BRIGHT!

The time with the Powershell Dev team was great. Again… can’t say much, but they have great plans.

I spent about 5hrs with the Active Directory team discussing their plans. If the AD Team can pull off what they have planned… OMG it is awesome. AD administration will never be the same.

The next version of SCVMM looks great.

Interpreting > Parsing (who knew!)

I found out some interesting information yesterday. I thought I would share it.

Back Story:
A question was asked on how to include $env:ComputerName to a string. I quickly piped up “HA! That is easy just wrap $() around the variable and it will work.” While this indeed works and is what I have been doing for the last couple of years… There was a better way!

It turns out that Jim Truher was watching this particular thread discussion and quickly informed me that this was “quite inefficient” and I should use ${} instead. So of course, I had to know why. Luckily Bruce Payette was also watching this thread and explained the following.

I hope he doesn’t mind if I quote him.

“The big difference is whether the parser gets involved or not. In the ${foo} case, the interpreter simply extracts the string, looks up the variable and inserts the result. In the $($var) case, the string is extracted, parsed and then executed which is more overhead.”

More Info (provided by Keith Hill):
$() is used within strings to evaluate statements (potentially multiple statements) and the results are converted into a string (Using OFS.)

${} is simply used to prevent the interpreter from “interpreting” the name of the variable instead it is treated as the literal name of the variable

Moral of the Story?
From now on I am using ${} when no evaluating is needed.

Jims Blog

Keith Hill has an awesome Series called Effective Powershell

Bruce hangs out on the Powershell Forum

Bruce also wrote Windows Powershell in Action

p.s. I tested this with this code

# with ${}
( Measure-Command {1..10000 | %{ "${env:path}" } } ).TotalMilliseconds
# vs with $()
( Measure-Command {1..10000 | %{ "$($env:path)" } } ).TotalMilliseconds

Format-XML (Journey to Pretty XML output)

I ran across a need to use Export-CliXML to produce human readable XML. Since, I never really cared what the output looked like so I let the blob go.

Now I care πŸ™‚

I sent a message to the Powershell Dev Team and as always they are super speedy in response. (less than 1hr… that is INSANE.)

Enter Format-XML

Help for Export-Clixml

Thanks Again Jeffrey and Team!

p.s. I dont believe I ever said the output (Export-CliXML) looked like crap… just not Pretty πŸ™‚

C# to PowerShell Translation Thought Process

A gentleman on the powershell news group the other day was asking about executing SQL stored procedures and I provided him with example that I had posted earlier in my blog (Click Here) While I’m not sure my answer was exactly what he was looking for he was a little curious as to how I went about translating the original C# code. To be clear I am not a coder nor do I truly know C#, but I know enough to translate. Anyway, I decided this would be a good idea for a post

So… Here we GO!

First… I used this as the C# example

I will show you my thought process by section I will include my comments and after I will post Both code Sections

This was fairly simple. In C# you have the ability to take namespace shortcuts by using ‘using ;’ In PowerShell we dont as of yet have that ability so I had to figure out what class SqlConnection was. A MSDN query returned System.Data.SqlClient.SqlConnection. The resulting PowerShell code is

The C# Code:

// Setup
conn = new SqlConnection("Server=(local);DataBase=Northwind;Integrated Security=SSPI");

The Powershell Code:

$srv = "srv1"
$db = "Northwind"
$conn = new-Object System.Data.SqlClient.SqlConnection("Server=$srv;DataBase=$db;IntegratedSecurity=SSPI")
$conn.Open() | out-null # The out-null is because the method returns a value and I dont want that output

Again… I had to find out what SqlCommand was referencing so… back to MSDN… System.Data.SqlClient.SqlCommand. BTW… I think I should take time now to tell you it is a REALLY GOOD idea to get use to the idea of constructors (how the object should be created) and how to use MSDN to determine the correct way to create an instance of the class/object. It really helps to know what a class is expecting. In this example its good to know the constructor is wanting a string of the SP and A connection OBJECT to use.

The C# Code:

// 1.  create a command object identifying
//     the stored procedure
SqlCommand cmd  = new SqlCommand("CustOrderHist", conn);

Here is the PowerShell Code:

$cmd = new-Object System.Data.SqlClient.SqlCommand("CustOrderHist", $conn)

Here was the tricky part (at least sorta.) From the C# code its not clear if the CommandType.StoredProcedure is a property and it turns out its not. It is an enumeration. It took me a few clicks to figure it out. The first clue was when looking for CommandType… I got an enum and it turns out the valid options was StoredProcedure, TableDirect, or Text (MSDN LINK) Clearly this was an enum, but I was a little unsure how do to enums in powershell. I found this blog by /\/\0\/\/ that helped a lot (/\/\o\/\/ Link)

The C# Code:

// 2. set the command object so it knows
//    to execute a stored procedure
cmd.CommandType = CommandType.StoredProcedure;

I ended up with this Powershell Line:

$cmd.CommandType = [System.Data.CommandType]‘StoredProcedure’

This was fairly simple as well… Just had to drop the new sqlparameter because strongly typing was not required. Again the out-null was because the method returns data I did not want as well as set the parameters.

The C# Code:

// 3. add parameter to command, which
//    will be passed to the stored procedure
cmd.Parameters.Add(new SqlParameter("@CustomerID", custId));

The PowerShell Code:

$cmd.Parameters.Add("@CustomerID","ANATR") | out-Null

These two parts are really just the excution of the the previous code. I think the only difference is the way PowerShell Writes output

The C# Code:

// execute the command
rdr = cmd.ExecuteReader();

// iterate through results, printing each to console
while (rdr.Read())
 "Product: {0,-35} Total: {1,2}",

The Powershell Code:

$rdr = $cmd.ExecuteReader()
    Write-Host "Product Name: " $rdr[‘ProductName’]
    Write-Host "Total: " $rdr[‘Total’]

Here is the Complete PowerShell Code.

$srv = "srv1"
$db = "Northwind"
$conn = new-Object System.Data.SqlClient.SqlConnection("Server=$srv1;DataBase=$db;Integrated Security=SSPI")
$conn.Open() | out-null
$cmd = new-Object System.Data.SqlClient.SqlCommand("CustOrderHist", $conn)
$cmd.CommandType = [System.Data.CommandType]‘StoredProcedure’
$cmd.Parameters.Add("@CustomerID","ANATR") | out-Null
$rdr = $cmd.ExecuteReader()
    Write-Host "Product Name: " $rdr[‘ProductName’]
    Write-Host "Total: " $rdr[‘Total’]