Archive for July, 2007

PowerGUI 1.0.9 Released

I am happy to announce that we have released the next update to PowerGUI – version 1.0.9.

It took us a month (which for PowerGUI is a lot – we used to have new releases once every 2-3 weeks before), but hopefully you will find it worth the wait.

The new features include:

  1. Rich editor for PowerShell scripts.
  2. Support for string parameters with spaces (PowerGUI automatically adds quotes when generating PowerShell code.)
  3. Automated PowerGUI configuration backup (so you can easily roll back to the last good known configuration.)
  4. Automated configuration save on each tree/link/action edit.
  5. Improved Export dialog box with ability to type in pack description and specify sysrtem requirements.
  6. Imporoved Import dialog which shows those.
  7. Update Exchange 2007 management pack.
  8. Updated local system pack with native PowerShell providers support.
  9. Smart controls for script actions.
  10. Drag-and-drop in navigation tree.
  11. Configurable debug logging.
  12. Ability to override type association for links and actions.
  13. Multiple other features and bugfixes.

As usual, the new version is available from the PowerGUI downloads page

Issues fixed in AD PowerGUI pack

The recently posted new version of Active Directory PowerPack generated a lot of interest and a lot of feedback. So today we have updated the pack with a few fixes such as:

  • Removing the default 1000 object display limit.
  • Fixed a few issues related to filers not working and properties not being displayed when browsing OUs.
  • Added a warning message box when resetting user passwords (so you don’t accidentally reset passwords for all users in your AD and forget to save the new passwords anywhere).

Feature-wise it has all the same great features of user, group, OU management, provisioning from CSV, password reset, recursive group membership, and much more.

Go download the Active Directory pack here.

Tags: , , , ,

PowerShell Security

SANS Institute has started offering PowerShell security classes. I guess this means PowerShell is clearly getting traction. This also got me thinking of PowerShell security features in general.

PowerShell has been obviously designed with much more security in mind than VBScript or cmd.exe:

  1. By default .ps1 script files are associated with Notepad. Double-clicking a script does not start it.
  2. To reference a script in PowerShell you have to specify file path, so even if a script is called dir.ps1 typing in dir will not start it. The shortest way to reference it is .\dir.ps1.
  3. And finally execution policies by default won’t allow you to run any scripts at all. You can lift the limitation up a bit by allowing to run scripts signed by trusted authorities.

(Anything else I am missing?)

There are a few things I personally would like to see added in next releases:

  1. Make execution policies more granular to specify that scripts need to be signed by a specific certificate (the one my company’s IT is using) and not just any trusted one.
  2. Add built-in protection against code-injection. Right now each script creator needs to handle that him-/herself. Once the protection is in the platform everything is going to be much more secure!
  3. Fix the ability to retrieve clear text password from credentials prompt (issue found by Martin):

PS C:\> $creds = get-credential
PS C:\> $creds.GetNetworkCredential()

UserName                                Password--------                                --------

Admin                                   Qwerty!

(Anything else? Comments are welcome!)

There are some additional security features which are already available commercially from companies like Quest and SAPIEN (sorry if there are more which I have not referenced – please add in the comments) like:

  1. Impersonating scripts/command-line for helpdesk and other limited rights scenarios.
  2. Auditing.
  3. Approval workflows.

So I think that the summary would be that PowerShell has gone a long way to become a much more secure command-line and scripting environment than we used to have before. There is room for improvements but this is only v1, right? I am sure there’s more to come!

Dmitry

Tags: ,

PowerGUI – “possibilités énormes”

Can’t help linking to this quick PowerGUI review in French. I don’t really speak French but I could understand (and just loved a lot) the summary: “Voici un Tool qui offre des possibilités énormes !”

Thanks David!

Tags: ,

Set ANY AD attribute with PowerShell

How can you set an arbitrary AD attribute with PowerShell?

Of course Get-QADUser and Set-QADUser have a set of default most common attributes the cmdlets retrieve and operate. Thus, for example moving me to marketing could be as simple as:

Set-QADUser "Dmitry Sotnikov" -Department Marketing

However, sometimes (extended schema or necessity to operate a not-so-common sets of attributes) makes you want to go beyond the most common parameters.

In a few recent posts I’ve blogged about:

Now let’s (hopefully) finish the series by talking about how you can set any attribute in AD.

In most cases, when you need to set any of the attributes beyond the default scope, you can do that using the -ObjectAtributes parameter.

For example:

Set-QADUser jsmith -ObjectAttributes @{l=’New York’;description='Reallocated Jan 1'}

changes city and description attributes for user jsmith.

Or

Set-QADUser ‘mycompany.com/usersOU/User1′ -objectAttributes @{otherTelephone=@(’555-34-67′,’555-34-68′)}

sets multivalued otherTelephone attribute to values 555-34-67 and 555-34-68.

Or

[Collections.DictionaryEntry] $de = new-object Collections.DictionaryEntry -argumentList ‘Append, @(’555-34-
67′,’555-34-68′)’

Set-QADUser User1 -objectAttributes @{otherTelephone=$de}

Appends multivalued otherTelephone attribute with values 555-34-67 and 555-34-68.

In some cases you might also need to make sure you supply data in right format because -ObjectAttributes does not convert values of attributes before passing them to AD. For INTEGER8 attributes like accountExpires this
means you must pass only values of types accepted by Microsoft LDAP ADSI:
IADsLargeInteger, string or int.

This means that you would need to do the conversion manually with something like this:

$dateOfExpiration = (get-date -year 2007 -month 10 -day
15).ToFileTime().ToString()

set-qaduser user1 -ObjectAttributes @{accountExpires =
$dateOfExpiration}

Hope this helps (and hope that in most cases the default set of attributes will be more than enough so you won’t need all these advanced tricks).

Dmitry

Tags: , , , , , ,

Optimize PowerShell Performance and Memory Consumption

PowerShell can be pretty resource intensive especially if you use it to retrieve data from your directory. I thought it will be useful to share this issue and workaround which were recently discussed in the PowerShell newsgroup.

SYMPTOMS

When trying to retrieve all user objects for subsequent processing with the following code:

$users = Get-QADUser -IncludeAllProperties -SizeLimit 0

the computer throws the following exception:

Get-QADUser : Exception retrieving members: "Exception of type
'System.OutOfMemoryException' was thrown."

(Looks like a correct line, right? SizeLimit set to zero makes PwerShell retrieve all user objects, IncludeAllProperties makes it retrieve whole user objects (not just the default set of attributes), then the collection is assigned to a variable for subsequent use. So why the exception? Read on!)

CAUSE

In reality on a fairly big domain this single line quoted above consumed all the RAM the machine had by basically retrieving the whole AD database wrapped into PowerShell objects.

You should avoid retrieving and keeping in memory the data you don’t need in your scripts. See information on how this can be done below.

RESOLUTION

Here are a few important tips to keep in mind to optimize your PowerShell code when working with Active Directory:

Use Pipeline

Don’t save the whole collection of objects to a variable. This way you make PowerShell retrieve all the objects and keep them the whole session. Use pipeline instead – which makes PowerShell pass the retrieved objects one by one to the next cmdlet.

So instead of:

$users = Get-QADUser
ForEach ($user in $users) { here goes the code }

Use:

Get-QADUser | ForEach { here goes the code }

Retrieve Only What You Need

-IncludeAllAttributes is a dangerous parameter because it, well, includes all attributes. Even the binary blobs you won’t have any idea on how to use. If you are ok with the attributes the cmdlets retrieves by default (to get the list just run Get-QADUser | Get-Member) simply use:

Get-QADUser -SizeLimit 0

If you need a couple additional parameter, use -IncludedProperties switch to add them and just them (not all the attributes!)

Get-QADUser -SizeLimit 0 -IncludedProperties proxyAddresses

If you need to optimize even further, limit the retieval only to the attributes you need by using the DontUseDefaultIncludedProperties switch:

Get-QADUser -DontUseDefaultIncludedProperties -IncludedProperties
SamAccountName,proxyAddresses

Filter Using cmdlet Parameters

Finally, if you need only a subset of objects use cmdlet parameters to do the filtering – and not the where clause.

So instead of:

Get-QADUser | where { $_.City -eq Amsterdam} | { here goes the code }

Use:

Get-QADUser -City Amsterdam | { here goes the code }

The difference is huge. In the former case, PowerShell retrieves all user objects and then does the filtering on the client. In the latter, the filtering becomes a part of the LDAP query and thus is made automatically on the domain controller during data retrieval.

SUMMARY

The ideal PowerShell script:

  1. Does not keep the whole set of objects but processes them one by one upon retrieval.
  2. Retrieves only the attributes it needs.
  3. Filters objects during retrieval.

Get-QADUser -City Amsterdam -DontUseDefaultIncludedProperties -IncludedProperties
SamAccountName,proxyAddresses | ForEach { here goes the code }

Tags: , , , , , , ,

Longhorn UG in UK, Scotty and Austin Blogging

Just found from Austin Osuide that not only has Windows Server 2008 started (congratulations, Scotty!), they already have the website up and running, and Scotty made Austin start blogging too.

Scotty and Austin have been active members of the PowerShell Usergroup so now the Longhorn group is surely in good hands!

Also, both Austin and Scotty are among the top IT consultants in UK so I hope some of their insight is going to be leak through their blogs. (And thanks for the congratulations, Austin!)

Tags: , , ,

Exchange 2007 PowerGUI Tutorials

Henrik Walther has just published his part 2 on managing Exchange 2007 with PowerGUI at MSExchange.org:

In part 2 he goes through managing public folders, setting permissions, provisioning mailboxes from csv files, reporting, as well as extending the tool.

(Too bad these were written before we extended the pack to cover all the functionality missing in the native Exchange Management Console.)

Henrik’s posts are good step-by-step tutorials with lots of screenshots and easy to follow. Highly recommended!

Tags: , , , , ,

Kandinsky design for iPod

I normally try not to put personal stuff into the blog but this time I just could not help it.

Here goes the photo I made today – painting by Wassily Kandinsky (dated 1925!) featuring an iPod music player:

Fragment of Kandinsky’s painting featuring iPod

Long story: The painting is called Gelb-Rot-Blue and I found it in Parisian modern art museum – Centre Pompidou. I am in Paris this week on a business trip meeting various Quest’s business partners and customers, and being a big fan of fine arts tried to find some time for the art galleries as well. Who would have thought that there’s no escape from technology even there?!

So now that we know who was behind iPod design, can anyone find the original iPhone and Zune paintings?

Tags: , ,

Updated PowerGUI Active Directory Pack

Our AD PowerPack has been quite outdated for a long time. I think it has been more or less the way it was initially created to demo AD cmdlets 1.0.1 integration at MMS. Not anymore! Last week we’ve set down and added a bunch of new features to the pack taking advantages of the enhancements introduced to both cmdlets (in versions 1.0.2 and 1.0.3) and PowerGUI itself (the pack now works with PowerGUI 1.0.8 or later).

Here’s the quick what’s new:

  • Description and system requirements shown/enforced on import
  • User password reset
  • OU browsing
  • Remove the default 100 item limits
  • User CSV Provisioning (!)
  • Enable User
  • Recursive Member Of
  • New User
  • New Group
  • Remove User
  • Remove Group

And here’s how it looks like:

Updated Active Directory PowerPack for PowerGUI

And don’t forget that all of that comes with the standard PowerGUI sorting, filtering, reporting, and bulk operations capabilities. And, if you are using Windows Server 2008 it integrates with the new Fine-Grained Password Policies UI. And, everything you do is also output as PowerShell code on the corresponding tab. And, you can add/remove/modify any node, link, or action. Etc., etc.

Go download it here.

Tags: , , , , ,


My Recent Tweets

Legal

The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

July 2007
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

%d bloggers like this: