Björn Österman's Infrastructural Programming?

New CmdLets: New-BOList, Join-BOList

2007-08-30T20:47:00Z

PowerShell has a lot of the things one might find i SQL; select, where, group, sum. But one thing it lacks i "JOIN". So I've created 2 new CmdLets, New-BOList and Join-BOList to try to fill that void.

New-BOList is to used place a arbitrary list inside a BOList-object and give it a name.

Join-BOList takes two BOList-objects and joins it's list's based on a script-block which is added as a parameter. The output will be a list of PSObjects, each with 2 properties named after the names of the 2 BOLists.

Join-BOList can be used with the parameters -left, -right, -inner and -outer in the same way SQL works.

"BO" in BOList stands for Björn Österman and is more an effect of poor imagination than an act of hybris. =). I would love some feedback about a better name for it.

You can download BOListCommands from here

Disclaimer: This software is provided "AS IS" with no warranties of any kind. The entire risk arising out of the use or performance of the software is with you.

Installation:

Download and install the MSI-packet
Add the CmdLet to the Powershell environment by running:
Add-PSSnapIn BOList

You need to do the last step everytime you start PowerShell if you don't add it to your PowerShell profile.

So, how can we use it?

One example is comparing 2 directories. The setup is as shown in the picture below:

The 2 directories differ both in the names of the files, and in one case the size.

First we use "dir" on each directory to get the list of files and put it inside a BOList-object

The next step is to join the two lists, but first I want to explain why we need the BOList-object at all.

Actually, I could have created Join-BOList as Join-List and skipped the the BOList-objects, but I really wanted to give the lists a name, this is because it's going to be used several times, and without the names i would have been forced to use generic names like "a" and "b", or "first" and "second".

Now, this is how we join the lists:

Let's start by explaining the command.

The 2 lists are specified as the 2 first arguments. And as the "-where"-argument there's a scriptblock. The scriptblock is executed once for each combination of one row from each list and needs to return a bool indicating whether the 2 rows should be joined. Inside the scriptblock there will be 2 variables with the same names as the names we specified for the BOLists.

In the example above, join-bolist returns the files that match each other (by name at least). But it would also be interresting to show that are NOT in both directories.

There are a couple of switches we can use.

-inner (default)
-left
-right
-outer

These work the same way as in SQL. Here's some examples:

Here we see all the files missing from the compared directories and also the files existing in both directories. If we want to concentrate on the missing files we can filter them out like this:

Now we see the files missing from each directory.

But if we remeber correctly, there are 2 files with the same name but different sizes. Lets change the scriptblock to take that into account:

Ah, and there's the file "Pic 064"!

I'll try to get you another example of how you can use it in my next post

PowerShell-pipes and Chunky vs Chatty

2007-08-15T23:14:01Z

Oneliners! I do like them, but no matter how nice those oneliners might look, they sometimes just isn't the best solution.

I'll give you an example:

In my last post where I wrote of using the Convert-Username CmdLet, I decided to put 2 lists of information in separate variables. $adUsers and $qUsers, like this:

$qUsers = get-quota c:\homefolders\* | where { $_.usage -gt .8 }
$adUsers = $qUsers | foreach { "MYDOMAIN\$(split-path $_.quotapath -leaf)" } |
convert-username -i nt4account -o dn | foreach { [adsi]"LDAP://$($_.Name)" }

0..($qUsers.length-1) | foreach {
    $qUser = $qUsers[$_]
    $adUser = $adUsers[$_]

    .... <"send an email"-code was here> ....
}

One alternativ to this could have been:

  get-quota c:\homefolders\* |
         where { $_.usage -gt .8 } |
         foreach {
              add-member NoteProperty User ([ADSI](convert-username "MYDOMAIN\$(split-path $_.quotapath -leaf)" -i nt4account -o dn)) -pass
              } | foreach {
              .... <"send an email"-code was here> ....
              } (Disclaimer: I haven't actually tested the code above, but it should work)

Even though the last example is shorter (I'm not saying easier) and doesn't use any variables, it does come with a performance-penalty.

Before I tell you what that is, I need to explain a few things:

In programming-world there's a notion about Chunky and Chatty code.

The thing is that as soon as you go on to the wire (ie the network) things take time. A Chatty application sends many small requests, paying the performance-penalty many time (no matter how small the requests are). A Chunky application on the other hand builds one big meaty request, paying the penalty only once.

Convert-Username uses the Microsoft API DsCrackNames which has the possibility to send a whole bunch of names to the DC/GC and get all those names converted in a single operation. When I created Convert-Username, I wanted to utilize that feature, so when the strings (names) are piped to Convert-Username, it just collects all of them first and then sends one request, thus making Convert-Username a Chunky CmdLet.

The problem with the second code-segment above is that instead of piping all the names to Convert-Username directly, it's used inside a foreach-loop and executed once for every name and by that forcing it to be Chatty.

So, next time you have a slow running oneliner; think about when things go on the wire and see if you can eliminate some of them.

Fun with Convert-Username

2007-08-14T23:28:53Z

In my last blog I promised that I would do a little more fun example for using the Convert-Username CmdLet. So here goes.

Example: How you send a mail to everyone who's homedirectory's FSRM-directory-quota is over 80%

First we need to get all the Windows Server 2003 FSRM Directory Quota from the homedirectories. I have an earlier blog about this here.

From the information in that post we can construct a little function that returns the Quota-objects for a specific path

function Get-Quota ([string] $path) {
(New-Object -com "srmsvc.srmquotamanager").EnumQuotas($path) |
foreach { add-member -pass -input $_ NoteProperty Usage ($_.QuotaUsed/$_.QuotaLimit) }
}

To get the quotas where the percentage is over 80% and put that in a variable:

$qUsers = get-quota c:\homefolders\* | where { $_.usage -gt .8 }

Change "C:\homefolders" to where you have your home-directories. If you want to access FSRM Directory Quotas on an other computer look att the bottom of the post I mentioned earlier.

The next step is where the Convert-Username magic happens.

$adUsers = $qUsers | foreach { "MYDOMAIN\$(split-path $_.quotapath -leaf)" } |
convert-username -i nt4account -o dn | foreach { [adsi]"LDAP://$($_.Name)" }

Lets analyse the command above a little.

First we take the $qUsers-variable and pipe all those to a foreach-command. Inside that command we construct a new string starting with MYDOMAIN. MYDOMAIN have to be replace with the domain-name where your accounts are. Next we use split-path to extract the last part of the path. I am assuming here that the names of the homedirectories is the same as the SAM Account Names of your users.

Next we pipe it to Convert-Username, telling it that the strings (names) that are coming in is of the format "NT4Account" (ie DOMAIN\SAM) and the result we want is the distinguished name of the accounts. And finally we pipe it to a foreach-command that uses the distinguished names to create ADSI-objects.

Here I want to make a little detour:

I really like that part of Convert-Username; that you can get the DN of the user(s). So if want to get a ADSI-object for a specific user and don't want to write a long LDAP-path, you can write this instead:

$aduser = [ADSI]"LDAP://$((convert-username 'Björn Österman' -o dn).name)"

Okey, back to the example...

So far we have 2 arrays. One with quota-information ($qUsers) and one with DirectoryEntries pointing to users ($adUsers). These two arrays will be ordered in the same way. Next we want to iterate through the 2 arrays, fetching the quota and the user that "owns" the directory.

0..($qUsers.length-1) | foreach {
    $qUser = $qUsers[$_]
    $adUser = $adUsers[$_]

    ...
    ...
}

Now inside that foreach-command we have the 2 objects. Lets send some mails.

First create a message object:

$message = new-object "net.mail.mailmessage"

Then we add the user as a recipient.

$message.To.Add( (new-object "net.mail.mailaddress" $adUser.mail,$adUser.displayname) )

"$adUser.mail" will return the email-address and "$adUser.displayname" will return the fullname.

Next we add a nice subject to the email:

$message.Subject = "Warning: Youre using $($qUser.Usage.ToString('###%')) of your home directory space"

The format string '###%' tells ToString() to multiply the number with 100, strip any decimals and place a '%' at the end.

Now add the sender to the message:

$message.From = new-object "net.mail.mailaddress" "admin@company.com","Administrator from Hell"

And then send the message:

(new-object "net.mail.smtpclient" "mymailserver").send($message)

"mymailserver" has to be changed to mail-server of your choice.

Thats it!, just put it all together in function like this:

function Warn-WastingUsers {

function Get-Quota ([string] $path) {
(New-Object -com "srmsvc.srmquotamanager").EnumQuotas($path) |
foreach { add-member -pass -input $_ NoteProperty Usage ($_.QuotaUsed/$_.QuotaLimit) }
}

0..($qUsers.length-1) | foreach {
$qUser = $qUsers[$_]
$adUser = $adUsers[$_]

    $message = new-object "net.mail.mailmessage"
    $message.To.Add( (new-object "net.mail.mailaddress" $adUser.mail,$adUser.displayname) )
    $message.Subject = "Warning: Youre using $($qUser.Usage.ToString('##%')) of your home directory space"
    $message.From = new-object "net.mail.mailaddress" "admin@company.com","Administrator from Hell"
    (new-object "net.mail.smtpclient" "mymailserver").send($message)
}

}

New CmdLet: Convert-Username

2007-08-13T09:28:31Z

I've created a CmdLet called Convert-Username. It's a wrapper around the Microsoft API DsCrackNames, that can be used to translate between different username formats by sending the request to a DC or GC.

Chrisse Andersson uses the API in his MMC-Console for Fine Grained Password Policies and I thougth it could be very useful having as an CmdLet.

The list of Formats you can convert between is:

DN
NT4Account
DisplayName
Guid
CanonicalName
Upn
CanonicalNameEx
Spn
Sid

You can download Convert-Username from here

Disclaimer: This software is provided "AS IS" with no warranties of any kind. The entire risk arising out of the use or performance of the software is with you.

I haven't created any Setup program yet but the installation is easy:

Download the CmdLet
Unzip the 2 files and put them in a directory of your chioce
Start PowerShell and run the following:
cd <path where you put the files>
&"$env:systemroot\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe" Convert-Username.dll
Add the CmdLet to the Powershell environment by running:
Add-PSSnapIn Convert-Username

You need to do the last step everytime you start PowerShell if you don't add it to your PowerShell profile.

Example:
_______________________________________________________________________________________________________

C:\PS>Convert-Username "John Doe" Upn

QueriedName                   Domain                        Name                          Status
-----------                   ------                        ----                          ------
John Doe                      somewhere.local               john.doe@somewhere.local      NoError

_______________________________________________________________________________________________________

In my next blog I'll give you a longer and more fun example of what you can do with Convert-Username

-----------------------------------------------------------------------------------------------------------------------

PS#> Get-Help Convert-Username -Full

-----------------------------------------------------------------------------------------------------------------------

NAME
    Convert-Username
SYNOPSIS
    Converts usernames to other formats.
SYNTAX
    Convert-Username [-name] <String[]> [-outFormat] {<DN> | <NT4Account> | <DisplayName> | <Guid> | <CanonicalName> |
    <Upn> | <CanonicalNameEx> | <Spn> | <Sid> | <DnsDomain>} -inFormat {<DN> | <NT4Account> | <DisplayName> | <Guid> |
    <CanonicalName> | <Upn> | <CanonicalNameEx> | <Spn> | <Sid> | <DnsDomain> | <Unknown>} [-credential <PSCredential>]
     [-noBatching <SwitchParameter>] [-domainController <String>] [-dnsDomain <String>] [<CommonParameters>]
DETAILED DESCRIPTION
    The Convert-Username cmdlet uses the Active Directory to convert usernames from one format to an other.

PARAMETERS
    -name <String[]>
        Specifies the names for conversion is to be made.
    -outFormat
        Is used to specify in what format the converted usernames will be. Valid values for <CommandTypes> are:

                  DN                 NT4Account
                  DisplayName        Guid
                  CanonicalName      Upn
                  CanonicalNameEx    Spn
                  Sid                DnsDomain

                  You can use OutFormat or its alias, o.
    -inFormat
        Is used to specify in what format the names to be converted will be. Valid values for <InFormat> are:

                  DN                 NT4Account
                  DisplayName        Guid
                  CanonicalName      Upn
                  CanonicalNameEx    Spn
                  Sid                DnsDomain
                  Unknown

                  The default InFormat is Unknown
                  You can use InFormat or its alias, i.
    -credential <PSCredential>
        Specifies the credential used to validate access. If a PSCredential object obtained earlier using get-credentia
        l is supplied, it will be used as is. If a user name is supplied, there will be a prompt for a password.
    -noBatching <SwitchParameter>
        Forces conversion to take place directly when an item is recieved through the pipe instead of batching the name
        s for one large request to the Active Directory.
    -domainController <String>
        Forces the use of a specific DomainController.
    -dnsDomain <String>
        Forces the use of a specific DnsDomain.
    <CommonParameters>
        This cmdlet supports the common parameters: -Verbose, -Debug,
        -ErrorAction, -ErrorVariable, and -OutVariable. For more information,
        type, "get-help about_commonparameters".
REMARKS
    For more information, type: "get-help Convert-Username -detailed".
    For technical information, type: "get-help Convert-Username -full".

Why "dir *.txt -recurse" doesn't work in PowerShell

2007-08-07T13:18:28Z

The "dir"-command (alias for get-childitem) in PowerShell does have some differences from dir in cmd.exe. It's more powerful, but it also takes more typing.

One of the things that might strike some people as odd is that "dir *.txt -recurse" doesn't work as "dir *.txt /s" in cmd.exe. The reason to this is that in PowerShell you actually use 2 parameters for this type of command.

Where to look
What to look for

So, what you should write is:

PS#> dir . *.txt -recurse (noticed the lonely dot?)

What this is saying is: Look for all *.txt-files in the current (.) directory, and subdirectories.

But, hey! Then why does "dir *.txt" (without -recurse) work the way you would think? Well "where to look" can include files.

The thing is that the pattern "*.txt" doesn't very often include any directories. In fact, if you would have a directory named "mydirectory.txt"; then "dir *.txt -r" would return all files in that directory and subdirectories, not only .txt-files. (Because "what to look for" hasn't been specified)

Using PowerTab for NestedPrompt

2007-08-03T22:47:08Z

In my last post I wrote about using TabExpansion for entering a NestedPrompt.

/\/\o\/\/, who's the (powershell) guy who created PowerTab commented about how to do the same in PowerTab.

add-tabExpansion nest '$host.enternestedprompt();cls;""' invoke

To invoke the nesting just type nest& and press the Tab-key. The &-character at the end of "nest", is the default charactar in PowerTab for running added tabExpansions of type "Invoke".

I mention in that post that I wasn't that happy with my "cls"-solution for clearing up the text left over from the nested prompt, so I decided to enhance it a little.

Instead of ju clearing the whole screen I wanted to do the following:

Copy the last active row on the screen
Enter the nested Prompt
After the exiting from the nested prompt: Redraw the copied line
Clear the screenbuffer on all lines below

Instead of squeezing all that into the add-tabExpansion-line I created a function:

function EnterNestedPrompt {
#Add some shortcuts for typenames etc
$rectangleType = "System.Management.Automation.Host.Rectangle"
$coordinatesType = "System.Management.Automation.Host.Coordinates"
$buffercellType = "System.Management.Automation.Host.BufferCell"
$RawUI = $Host.UI.RawUI
#Get the current cursorposition and the current line
$currentPosition = $RawUI.cursorposition
$currentPosition.X = 0
$currentPosition.Y--
$currentRowIndex = $currentPosition.Y
$currentLineRectangle = new-object $rectangleType 0,$currentRowIndex,($RawUI.WindowSize.width-1),$currentRowIndex
$currentLineBuffer = $RawUI.getbuffercontents($currentLineRectangle)
#Enter the nested prompt
$Host.EnterNestedPrompt()
#Redraw the original line
$RawUI.SetBufferContents($currentPosition, $currentLineBuffer)
#Create an empty space to redraw on the lower buffer to clear the garbage
$EmptyBufferCell = new-object $buffercellType ' ',$RawUI.ForegroundColor,$RawUI.BackgroundColor, "Complete"
$EmptySpace = $RawUI.NewBufferCellArray(($RawUI.BufferSize.Height-$currentRowIndex), $RawUI.BufferSize.Width, $EmptyBufferCell)
$CurrentPosition.Y+=2
#Clear lower screenbuffer
$RawUI.SetBufferContents($currentPosition, $EmptySpace)
}

Now, to add this to PowerTab

add-tabExpansion nest 'enternestedprompt;" `b"' invoke

Notice that i've also changed the return-string from "" to " `b", this is because an empty string doesn't do anything for some reason. The result is that "nest&" just remains there after returning from the invoked command. By sending a space and then a backspace the desired effect is achieved.

Using PowerShell TabExpansion for PromptNesting

2007-08-02T00:32:00Z

I've been thinking about extending PowerShell to solve some of the dilemmas i've encountered while working in the console. I was looking into MoW's latest version of PowerTab and was wondering how he was able to hook up the key-event. After som probing I found out that PowerShell implements a function called TabExpansion that's called when the TAB-key is pressed.

I was hoping for a real key-hooking mekanism so that I would be able to react to a key of my choice, but TabExpansion isn't that bad actually.

So what dilemmas can we solve with with TabExpansion? Well imagine the following senario:

You're writing a long line in the PowerShell-console and after a lot of typing you find yourself wondering about some syntax for some command. Now you want to write and test some things but without discarding what you've written so far. You could start a whole new PowerShell Console, but perhaps you also want to inspect some variables that wont exist in a fresh Console.

Now, PowerShell does include a function called EnterNestedPrompt, that's used while debugging scripts. Wouldn't it be great to be able to call EnterNestedPrompt while writing that line?

The default "TabExpansion"-function is created automatically when the PowerShell Console is loading. PowerTab and also PSCX exchanges the function for their own implementations. We wish to insert some logic of our own before calling the real TabExpansion.

So first we copy the existing TabExpansion to TabExpansionOld

copy Function:\TabExpansion Function:\TabExpansionOld

Next we create a new TabExpansion-function:

function TabExpansion {
param($line, $lastWord)
if ($lastWord -eq "nest" ) {       # Check if the lastword on the commandline is "nest"
    $host.enternestedprompt()        # Enter the nested prompt
    cls                              # When returning from the nested prompt; clear the screen
    ""                               # Return an empty string, this will remove the word "nest"
} else {
    TabExpansionOld $line $lastword # If the word isn't "nest", to ordinary TabExpansion
}
}

The "cls"-row in the script is there because the console doesn't handle the exiting from the nested prompt very well. A lot of garbled text. The "cls"-solution isn't very good either, but it's better. In the future i migth extend the function to do a temporary copy of the whole screen-buffer before entering the prompt, and restoring it when returning.

You can try the nesting like this:

PS C:\> dir | group Extension | select-string nest <-- PRESS TAB HERE

The prompt will look quite strange:

PS C:\> dir | group extension | select nestPS C:\>>>

But now you can test things. When you're done, write Exit and press enter, and you're back on the original line.

How do I construct that object in PowerShell?

2007-07-24T20:58:00Z

One of the things that make PowerShell soo powerful is that you have access to .Net Framework and all the objects that it includes. Quite often I use the Get-Member (gm) CmdLet to find out what Methods and Properties that can be used, however one of the methods on the object isn't exposed, and that's the constructor.

The constructor(s) is the method that is used when creating the object. Information about the constructor is interresting when using the New-Object (new) CmdLet.

Lets say that you want to know what arguments you could/should/must use when creating a System.DateTime, then you can use the following line:

1# ([datetime]).GetConstructors() | foreach { $_.ToString() }
Void .ctor(Int64)
Void .ctor(Int64, System.DateTimeKind)
Void .ctor(Int32, Int32, Int32)
Void .ctor(Int32, Int32, Int32, System.Globalization.Calendar)
Void .ctor(Int32, Int32, Int32, Int32, Int32, Int32)
Void .ctor(Int32, Int32, Int32, Int32, Int32, Int32, System.DateTimeKind)
Void .ctor(Int32, Int32, Int32, Int32, Int32, Int32, System.Globalization.Calendar)
Void .ctor(Int32, Int32, Int32, Int32, Int32, Int32, Int32)
Void .ctor(Int32, Int32, Int32, Int32, Int32, Int32, Int32, System.DateTimeKind)
Void .ctor(Int32, Int32, Int32, Int32, Int32, Int32, Int32, System.Globalization.Calendar)
Void .ctor(Int32, Int32, Int32, Int32, Int32, Int32, Int32, System.Globalization.Calendar, System.DateTimeKind)

This gives you good information about the types you need to use, but it would be useful to see the names of the arguments too.

The following function shows the constructors with the parameternames. I've tried to make look a little more PowerShellish than the example above.

function Get-Constructor ([type]$type) {
$type.getconstructors() |
    foreach -process {
      $tmp = "[void] .ctor" +
                 ($_.GetParameters() |
                        foreach -begin {$s=@()} `
                                -process {$s+="[$($_.ParameterType.ToString().ToLower())] `$$($_.Name)"} `
                                -end {"(" + [string]::Join(', ',$s) + ")"})

      $tmp -replace "Boolean","bool" `
       -replace "Int32", "int" `
       -replace "System.IO." `
       -replace "System.Text." `
       -replace "System." `
       -replace "System.String", "string"
    }
}

And the result looks like this:

59# get-constructor datetime
[void] .ctor([int64] $ticks)
[void] .ctor([int64] $ticks, [datetimekind] $kind)
[void] .ctor([int] $year, [int] $month, [int] $day)
[void] .ctor([int] $year, [int] $month, [int] $day, [globalization.calendar] $calendar)
[void] .ctor([int] $year, [int] $month, [int] $day, [int] $hour, [int] $minute, [int] $second)
[void] .ctor([int] $year, [int] $month, [int] $day, [int] $hour, [int] $minute, [int] $second, [datetimekind] $kind)
[void] .ctor([int] $year, [int] $month, [int] $day, [int] $hour, [int] $minute, [int] $second, [globalization.calendar] $calendar)
[void] .ctor([int] $year, [int] $month, [int] $day, [int] $hour, [int] $minute, [int] $second, [int] $millisecond)
[void] .ctor([int] $year, [int] $month, [int] $day, [int] $hour, [int] $minute, [int] $second, [int] $millisecond, [datetimekind] $kind)
[void] .ctor([int] $year, [int] $month, [int] $day, [int] $hour, [int] $minute, [int] $second, [int] $millisecond, [globalization.calendar] $calendar)
[void] .ctor([int] $year, [int] $month, [int] $day, [int] $hour, [int] $minute, [int] $second, [int] $millisecond, [globalization.calendar] $calendar, [datetimekind] $kind)

Accessing Windows Server 2003 R2 File Server Resource Manager in PowerShell

2007-07-18T17:40:00Z

Microsoft Windows Server 2003 R2 includes a new File Server Resource Manager for files, including directory-quota and file-screening.

The APIs for accessing R2 FSRM hasn't been made official by Microsoft, but that doesn't mean that they can't be used.

FSRM has a couple of COM-object you can use, one is "SrmSvr.SrmQuotaManager". Let's create it and see what methods we can use.

PS C:\> $qm = New-Object -com "srmsvc.srmquotamanager"
PS C:\> $qm | get-member

   TypeName: System.__ComObject#{b6aa2c73-bb7c-432a-9d09-bae30eca29d4}

Name                MemberType Definition
----                ---------- ----------
CreateAutoQuota     Method     ISrmAutoQuota CreateAutoQuota (string)
CreateQuota         Method     ISrmQuota CreateQuota (string)
CreateQuotas        Method     SAFEARRAY(Variant) CreateQuotas (ISrmCollection)
DeleteQuotas        Method     SAFEARRAY(Variant) DeleteQuotas (ISrmCollection)
EnumAutoQuotas      Method     ISrmCollection EnumAutoQuotas (string)
EnumEffectiveQuotas Method     ISrmCollection EnumEffectiveQuotas (string)
EnumQuotas          Method     ISrmCollection EnumQuotas (string)
EnumQuotasByTag     Method     ISrmCollection EnumQuotasByTag (string)
GetAutoQuota        Method     ISrmAutoQuota GetAutoQuota (string)
GetQuota            Method     ISrmQuota GetQuota (string)
GetRestrictiveQuota Method     ISrmQuota GetRestrictiveQuota (string)
ModifyQuotas        Method     SAFEARRAY(Variant) ModifyQuotas (ISrmCollection)
NewCollection       Method     ISrmCollection NewCollection ()
Scan                Method     void Scan (string)

Lots of interresting methods there.

Let's create a new quota:

PS C:\> $quota = $qm.CreateQuota("C:\TestQuota")
PS C:\> $quota | get-member

   TypeName: System.__ComObject#{ac042e22-0db4-4a90-be5a-54513a3631de}

Name                     MemberType Definition
----                     ---------- ----------
AddThreshold             Method     void AddThreshold (int)
ApplyTemplate            Method     void ApplyTemplate (string)
Commit                   Method     void Commit ()
CreateLimitAction        Method     ISrmAction CreateLimitAction (_SrmActionType)
CreateThresholdAction    Method     ISrmAction CreateThresholdAction (int, _SrmActionType)
Delete                   Method     void Delete ()
DeleteThreshold          Method     void DeleteThreshold (int)
EnumLimitActions         Method     ISrmCollection EnumLimitActions ()
EnumThresholdActions     Method     ISrmCollection EnumThresholdActions (int)
GetLimitAction           Method     ISrmAction GetLimitAction (string)
GetSourceTemplateName    Method     void GetSourceTemplateName (string, bool)
GetThresholdAction       Method     ISrmAction GetThresholdAction (int, string)
ModifyThreshold          Method     void ModifyThreshold (int, int)
RefreshUsageProperties   Method     void RefreshUsageProperties ()
ResetHighWaterMark       Method     void ResetHighWaterMark ()
QuotaFlags               Property   int QuotaFlags () {get} {set}
QuotaHighWaterMark       Property   uint64 QuotaHighWaterMark () {get}
QuotaHighWaterMarkString Property   string QuotaHighWaterMarkString () {get}
QuotaHighWaterTime       Property   Date QuotaHighWaterTime () {get}
QuotaLimit               Property   uint64 QuotaLimit () {get} {set}
QuotaLimitString         Property   string QuotaLimitString () {get} {set}
QuotaPath                Property   string QuotaPath () {get}
QuotaTags                Property   SAFEARRAY(Variant) QuotaTags () {get} {set}
QuotaUsed                Property   uint64 QuotaUsed () {get}
QuotaUsedString          Property   string QuotaUsedString () {get}
Thresholds               Property   SAFEARRAY(Variant) Thresholds () {get}

Okey, the quota isn't really created yet. So let's set a property and then "save" it.

PS C:\> $quota.QuotaLimit = 200mb
PS C:\> $quota.QuotaLimit
209715200
PS C:\> $quota.Commit()
PS C:\>

Now the qouta is created. Observe PowerShells support for kb, mb, etc.

Let's see the usage information. I've put some files in C:\TestQuota

PS C:\> $qm.GetQuota("C:\TestQuota")

QuotaLimit               : 209715200
QuotaLimitString         : 209715200
QuotaFlags               : 256
QuotaTags                : {}
Thresholds               : {}
QuotaPath                : C:\TestQuota
QuotaUsed                : 101997568
QuotaUsedString          : 101997568
QuotaHighWaterMark       : 101997568
QuotaHighWaterMarkString : 101997568
QuotaHighWaterTime       : 2007-07-18 20:31:11

If we want to create a simple report of the disk usage in the homedirectories (given that qouta has been enabled for them).

PS C:\> $qm.EnumQuotas("C:\HomeFolders\*") | format-table QuotaPath, QuotaLimit, QuotaUsed

QuotaPath                  QuotaLimit QuotaUsed
---------                  ---------- ---------
C:\TestQuota                209715200 101997568
C:\HomeFolders\arthur.dent 104857600 33999872
C:\HomeFolders\dilbert      104857600 101997568
C:\HomeFolders\jane.doe     104857600 100689920
C:\HomeFolders\john.doe     104857600 90228736

And now a little more fun report:

PS C:\> $qm.EnumQuotas("C:\HomeFolders\*") |
>> foreach { add-member -pass -input $_ NoteProperty Usage ($_.QuotaUsed/$_.QuotaLimit) } |
>> where { $_.usage -gt .8 } |
>> sort Usage -desc |
>> select -first 3 |
>> format-table QuotaPath, QuotaLimit, QuotaUsed, @{Label="Usage";expression={$_.Usage.ToString("00.00%")}}
>>

QuotaPath                                        QuotaLimit                     QuotaUsed Usage
---------                                        ----------                     --------- -----
C:\HomeFolders\dilbert                            104857600                     101997568 97,27%
C:\HomeFolders\jane.doe                           104857600                     100689920 96,03%
C:\HomeFolders\john.doe                           104857600                      90228736 86,05%

The previous commands was executed on local machine. How can we do this on a remote machine? Well it requires some wacky .NET-functions.

This is actually a pretty useful technique, so lets create a nice general function for it:

function New-RemoteComObject {
param(
    [string] $progID             = $(throw "Must specify ProgID for remote objekt"),
    [string] $remoteComputername = $(throw "Must specify remote computername")
    )

$remoteType = [Type]::GetTypeFromProgID($progID, $remoteComputername, $true)
$remoteInstance = [Activator]::CreateInstance($remoteType)
$remoteInstance
}

For this to work, you have to have the same COM-object registered on your local computer, and the COM-object have to support remote instanciation. (hmm... wonder if that word was spelled correctly?)

If your running from an other W2K3R2-machine and your don't have FSRM installed, then you have to run "regsvr32 %WINDIR%\system32\srm.dll"

I don't know if your can make FSRM work from a XP-machine.

Lets see how to use it:

PS C:\> $qm = new-remotecomobject srmsvc.srmquotamanager rnd-exch-01
PS C:\> $qm.EnumQuotas() | format-table QuotaPath, QuotaLimit, QuotaUsed

QuotaPath                  QuotaLimit QuotaUsed
---------                  ---------- ---------
C:\TestQuota                209715200 101997568
C:\HomeFolders\arthur.dent 104857600 33999872
C:\HomeFolders\dilbert      104857600 101997568
C:\HomeFolders\jane.doe     104857600 100689920
C:\HomeFolders\john.doe     104857600 90228736

As you can see it's almost the same. You just have to use the New-RemoteComObject-function instead of the New-Object-cmdlet.

If you want some more examples please add a comment.

Chrisse's FGPP Beta 1 släppt

2007-07-15T21:55:00Z

I Windows Server 2008 kommer en ny funktion som heter "Fine-grained Password Policy" (FGPP) som innebär att man till skillnad från förrut får möjligheten att specificera olika lösenordskrav för olika användare och grupper. Innan kunde man bara specificera en uppsättning lösenordskrav för varje domän.

Tillägget av funktionen kom dock så pass sent i utvecklingsprocessen hos Microsoft så att de inte har lagt in något GUI för att administrera funktionen.

Jag har dock haft möjligheten att hjälpa Chrisse Andersson på TrueSec att utveckla en MMC-Console och en PowerShell-SnapIn för att administrera FGPP.

Chrisse har nu släppt Beta 1 av programmet. Ni kan läsa om funktionerna och ladda ner programmet från http://blogs.chrisse.se/blogs/chrisse/pages/fine-grain-password-policy-tool.aspx

Jag tycker att det är kul att han har släppt en PowerShell SnapIn. Det ger oss tekniker möjlighet att jobba med FGPPs utanför begräsningarna av de GUI:n som ofta presenteras för oss.

De CmdLets som följer med är:

Get-PasswordPolicy
New-PasswordPolicy
Modify-PasswordPolicy
Rename-PasswordPolicy

Exempel 1: Visa alla FGPPs som har MaximumPasswordAge satt till 9 dagar eller mer:

PS C:\Program Files\FGPP> Get-PasswordPolicy | ? { $_.Maximumpasswordage.totaldays -ge 9 }

DN                                  : CN=testelitest,CN=Password Settings Container,CN=System,DC=slumsoft2,DC=local
Name                                : testelitest
CN                                  : CN=testelitest
PasswordSettingsPrecendence         : 1
PasswordReversibleEncryptionEnabled : True
PasswordHistoryLength               : 2
PasswordComplexityEnabled           : True
MinimumPasswordLength               : 2
MinimumPasswordAge                  : 7.00:00:00
MaximumPasswordAge                  : 1000.00:00:00
LockoutThreshold                    : 1
LockoutObservationWindow            : 00:18:00
LockoutDuration                     : 00:18:00
PSOAppliesTo                        : {}

Exempel 2: Ändra MaximumPasswordAge utan att använda Modify-PasswordPolicy

PS C:\Program Files\FGPP> $pp = Get-PasswordPolicy gurka2
PS C:\Program Files\FGPP> $pp.maximumpasswordage.totaldays
8
PS C:\Program Files\FGPP> $pp.maximumpasswordage = [timespan]::fromdays(15)
PS C:\Program Files\FGPP> $pp.CommitChanges()
PS C:\Program Files\FGPP> (Get-PasswordPolicy gurka2).maximumpasswordage

Days              : 15
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 0
Ticks             : 12960000000000
TotalDays         : 15
TotalHours        : 360
TotalMinutes      : 21600
TotalSeconds      : 1296000
TotalMilliseconds : 1296000000

PS C:\Program Files\FGPP>

Chrisse vill gärna ha feedback angående buggar, och vilka önskade funktioner ni skulle vilja se till nästa version. Skriv och berätta i forum-tråden på ITProffs:

http://www.itproffs.se/forumv2/tm.aspx?m=108699&mpage=1&key=&#108930

Peeking inside the PowerShell Pipe

2007-07-06T20:55:00Z

Pipe (|) i PowerShell används för att skriva objekt från ett kommando till ett annat. Det är en nyhet från t ex cmd.exe eller även Linux:s olika shell där det alltid är ren text som skickas.

När jag skrev min blog om gruppering och summering av filer baserat på Extension så blev jag då och då osäker på vad det var för typ av objekt som olika CmdLets skickade vidare.

För att se vad som skickades i pipe:n skrev jag en liten funktion:

function peek-pipe {
process {
#Skriv ut namnet på det aktuella objektets typ till skärmen i grönt
write-host $_.GetType() -foregroundcolor Green

#Skicka vidare objektet
$_
}
}

Så ifall ni vill köra ett kommando som t ex "dir | format-table" och vill se vilka objekt som skickas igenom pipe:n skriver ni istället "dir | peek-pipe | format-table"

En interresant detalj som man kan se är att format-table-kommandot börjar skriva ut listan redan vid första objektet och sedan fyller på listan allt eftersom dir-kommandot skickar vidare fler objekt.

Ett litet PowerShell ADSI-tips

2007-07-05T12:18:00Z

Ifall man vill hämta ett DirectoryEntry i PowerShell kan man skriva på följande sätt:

$ou = new-object System.DirectoryServices.DirectoryEntry("LDAP://OU=Company,DC=slumsoft,DC=local")

Ett enklare sätt är att använda PowerShell-klassen ADSI

$ou = [ADSI]"LDAP://OU=Company,DC=slumsoft,DC=local"

I huvet på en powershellare

2007-07-02T00:16:00Z

När jag höll på och skriva mitt förra inlägg tänkte jag först använda ett lite längre skript som exempel, det scriptet skrev jag i VB.NET och grupperar alla filer baserat på extension och summera ihop storlekarna. Det skriptet ser ut som nedan:

Imports System.IO
Imports System.Collections.Generic
 Module GetFileSizesByExtension
   Sub Main(ByVal args() As String)
 
      'Check arguments
      If Not args.Length = 1 Then
         Console.WriteLine("Syntax: getfilesizesbyextensions.exe <path>")
         Return
      End If
 
      Dim dict As New SortedDictionary(Of String, Integer)
 
      'Iterate through the files
      For Each filename As String In Directory.GetFiles(args(1))
         Dim fi As New FileInfo(filename)
         Dim extension As String = fi.Extension.ToLower()
 
         If dict.ContainsKey(extension) Then
            dict(extension) += fi.Length
         Else
            dict.Add(extension, fi.Length)
         End If
      Next
      
      'Print results
      For Each extension As String In dict.Keys
         Console.WriteLine("{0,-5} - {1}", extension, dict(extension))
      Next
   End Sub
End Module

När jag satt och skrev programmet slog det mig att Powershell troligen skulle passa utmärkt för att göra motsvarande, så jag tänkte att vi skulle försöka oss på detta.

Första steget är att få ut alla filerna, inga konstigheter där:

PS# dir C:\windows\system32

Det finns ett en CmdLet med namnet Group-Object ("group") och -property används för att berätta vad man skall gruppera på. Vi testar:

PS# dir \windows\system32 | group Extension

Count Name                      Group
----- ----                      -----
   49                           {1025, 1028, 1031, 1033...}
    5 .inf                      {$ncsp$.inf, $winnt$.inf, homepage.inf, ieuinit.inf...}
    2 .cpx                      {12520437.cpx, 12520850.cpx}
1283 .dll                      {6to4svc.dll, aaaamon.dll, aaclient.dll, acctres.dll...}
   24 .cpl                      {access.cpl, appwiz.cpl, bthprops.cpl, desk.cpl...}
304 .exe                      {accwiz.exe, actmovie.exe, ahui.exe, alg.exe...}

Kalas, vi är på rätt väg. Låt se, nu har vi en uppsättning objekt av type GroupInfo, där varje objekt innehåller namnet på extensionen, en lista med filerna som har den extensionen, samt antalet filer. Nu behöver vi ta reda på vad summan av storlekarna för filerna är.

Hmm... Alltså, för varje GroupInfo-objekt så vill vi ta listan (som finns i propertyn Group), och för varje objekt i listan vill vi ta ut storleken.

Det finns en CmdLet med namnet Measure-Object som kan summera och räkna på information i objekt:

PS# dir c:\windows\system32 | group Extension | % { ($_.Group | measure-object Length -sum).Sum }
Measure-Object : Property "Length" cannot be found in any object(s) input.
At line:1 char:75
+ dir c:\windows\system32 | group Extension | % { ($_.Group | measure-object <<<< Length -sum).Sum }
59520
4384
295688942
5656920
43885527
2947615
1588512

Okey, Det var en del på en gång, vi skall försöka dela upp det.

%-tecknet är förkortning för "ForEach-Object"; den CmdLet:en kör efterföljande scriptdel en gång för varje objekt (i det här fallet GroupInfo-objekt). I scriptet representeras det aktuella objektet med $_.

Så för varje GroupInfo-objekt så tar vi .Group och skickar in till Measure-Object. Där berättar vi att det är propertyn Length (den innehåller filstorleken) som vi vill summera. Measure-Objekt kommer att skicka tillbaka ett GenericMeasureInfo som bl a innehåller en Sum-property, vilken vi vill använda.

I ovanstående text ger Measure-Object ett felmeddelande för den första listan. Anledningen till detta är att "dir" ger tillbaka både FileInfo-objekt och DirectoryInfo-objekt. Det senare innehåller ingen Length-property. Så för att få bort felmeddelandet kan vi lägga in ett filter lite tidigare i kommandosträngen:

PS# dir c:\windows\system32 | ? { $_.GetType().Name -eq "FileInfo" }

? är förkortning för "Where-Object".

Nästa problem att lösa är att vi vill inte bara ha en lista med summerade storlekar. Om inte annat så vill vi ju veta vilken extension som genererat varje summering. Ett alternativ är att utöka GroupInfo-objektet med den summerings-informationen som Measure-Object gav or. Det vi kan göra är att använda "add-member":

PS# dir c:\windows\system32 | ? { $_.GetType().Name -eq "FileInfo" } | group Extension | % { $_ | add-member NoteProperty Size ($_.Group | measure-object Length -sum).Sum -pass}

Count Name                      Group
----- ----                      -----
    5 .inf                      {$ncsp$.inf, $winnt$.inf, homepage.inf, ieuinit.inf...}
    2 .cpx                      {12520437.cpx, 12520850.cpx}
1283 .dll                      {6to4svc.dll, aaaamon.dll, aaclient.dll, acctres.dll...}
   24 .cpl                      {access.cpl, appwiz.cpl, bthprops.cpl, desk.cpl...}

Så vi har använt add-member för att lägga till en NoteProperty med namnet Size och värdet av summeringen till GroupInfo-objektet. Vi har också lagt till "-passthru" för att berätta för add-member att objektet skall skickas vidare. De flesta andra CmdLets gör detta utan att man behöver säga åt dem.

Men i listan som skrivs ut så syns inte våran Size. För att se ifall den egentligen är där så testar vi att skicka vidare objekten till Get-Member (eller lite kortare "gm"). Get-Member kommer att titta på det första av de objekten som den får, och skriva ut vilka properties och sånt som objektet har.

PS# dir c:\windows\system32 | ? { $_.GetType().Name -eq "FileInfo" } | group Extension | % { $_ | add-member NotePropert
y Size ($_.Group | measure-object Length -sum).Sum -passthru} | gm

TypeName: Microsoft.PowerShell.Commands.GroupInfo

Name        MemberType   Definition
----        ----------   ----------
Equals      Method       System.Boolean Equals(Object obj)
GetHashCode Method       System.Int32 GetHashCode()
GetType     Method       System.Type GetType()
get_Count   Method       System.Int32 get_Count()
get_Group   Method       System.Collections.ObjectModel.Collection`1[[System.Management.Automation.PSObject, System....
get_Name    Method       System.String get_Name()
get_Values Method       System.Collections.ArrayList get_Values()
ToString    Method       System.String ToString()
Size        NoteProperty System.Double Size=59520
Count       Property     System.Int32 Count {get;}
Group       Property     System.Collections.ObjectModel.Collection`1[[System.Management.Automation.PSObject, System....
Name        Property     System.String Name {get;}
Values      Property     System.Collections.ArrayList Values {get;}

Där finns våran Size. Anledningen till att den inte syntes var att standard-output:en för GroupInfo inte innehåller Size, så vi får skicka vidare objekten till Format-Table ("ft") och berätta vad vi vill se:

PS# dir c:\windows\system32 | ? { $_.GetType().Name -eq "FileInfo" } | group Extension | % { $_ | add-member NotePropert
y Size ($_.Group | measure-object Length -sum).Sum -passthru} | ft Name, Count, Size -auto

Name      Count      Size
----      -----      ----
.inf          5     59520
.cpx          2      4384
.dll       1283 295688942
.cpl         24   5656920
.exe        304 43885527

Nästan klara. Det vi har kvar är att sortera informationen, och begränsa antalet rader till 10 (så att listan blir lite smidigare, texterna ovan har jag klippt för läsbarhet). Vi skickar det till Sort-Object ("sort") och sedan till Select-Object ("select") innan det skickas till Format-Table:

PS# dir c:\windows\system32 | ? { $_.GetType().Name -eq "FileInfo" } | group Extension | % { $_ | add-member NoteProperty Size ($_.Group | measure-object Length -sum).Sum -passthru} | sort Size -desc | select -first 10 | ft Name, Count, Size -auto

Name Count      Size
---- -----      ----
.dll 1283 295688942
.exe   304 43885527
.bin     4 13196206
.TMP    17   7090705
.ocx    19   7074594
.cpl    24   5656920
.nls    68   5138370
.dat    13   4468086
.scr    11   2739200

Så, vilka CmdLet:s har vi stött på nu:

Get-ChildItem (dir)
Where-Object (?)
Group-Object (group)
ForEach-Object (%)
Add-Member
Measure-Object
Sort-Object (sort)
Select-Object (select)
Format-Table (ft)
Get-Member (gm)

Eftersom jag är ganska ny på blog-arenan så skulle jag gärna vilja ha feedback. Skriv och berätta huruvida ni finner ovanstående fullständigt ointerresant, felaktigt eller förhoppningsvis lärorikt.

Skriv gärna ifall ni har några förbättringar på den resulterande kommando-raden.

skripta.NET

2007-06-30T11:43:00Z

Hej alla

Eftersom detta är mitt första blogg-inlägg så får jag väl börja med att introducera mig.

Jag heter Björn Österman och är 30 år gammal. Jag har jobbat mycket både som tekniker och programmerare, nästan uteslutande med Microsoft-teknologier.
Mitt favorit-språk (förutom svenska) är C#.

De flesta tekniker som leker "programmering" använder idag VBScript som favorit-massförstörelsevapen. C# (och VB.NET) används ju inte, eftersom det är ett programmeringsspråk snarare än ett scriptspråk.

Själv delar jag inte den uppfattningen, då jag är förälskad i C# och använder det oavsett ifall det är vettigt eller inte.

Det jag tänkte skriva om är hur man som tekniker kan skriva sina script i .NET

Den stora fördelen med att använda sig av .NET är den stora flora av objekt som .NET innehåller, samt styrkan i språket jämfört med VBScript.

Och nu när PowerShell har gjort sin intågan så kommer man att ha nytta av att känna till de objekten.

Några av skillnaderna mellan VBScript och VB.NET är:

VB.NET använder .vb som filextension istället för .vbs
VB.NET behöver kompileras innan det kan köras.
I VB.NET behöver man lägga in starten av programmet i en Sub med namnet Main

En stor fördel med att kompilera är att många fel kan hittas innan ni kör programmet, vilket är bättre än att scriptet beteer sig felaktigt under testning (mot produktionsmiljön)

Det många inte vet är att en VB.NET-kompilator följer med .NET Framework när det installeras, så man inte måste använda program som Visual Studio.

Step-by-step guide för att skriva ett "VB.NET-script"

1. Skapa en textfil med namnet hejsan.vb
2. Lägg in följande text i filen:

Module MyModule
Sub Main()
Console.WriteLine("Hejsan ITProffs")
End Sub
End Module

3. Kör c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\vbc.exe hejsan.vb

Du har nu skapat en fil med namnet hejsan.exe