Archive for June, 2007

PowerShell session at St. Petersburg .NET Usergroup – July 6th

Next Friday, July 6th 2007 I will be presenting at St. Petersburg (Russia) .NET Usergroup.

The usergroup will start at 6 pm local time and will go till approximately 9. We will start with Gaidar Magdanurov demoing some of his WCF work, and then I will do a PowerShell for developers session, sharing our experience and evangelizing PowerShell as the best command-line you can implement for your applications.

If you happen to be in St. Petersburg, Russia please register and drop by:

http://sp.ineta.ru/Events/EventInfo.aspx?ID=2b472d76-b54f-41dd-b753-4a793eba19ff

Tags: , , , , , ,

Get a list of ALL user properties

Learning something new every day. There was a question in the forums on PowerGUI.org today on obtaining a list of all attributes a user object has.

I used to think that the way to get the list of attributes exposed directly via PowerShell is to call:

PS:\> Get-QADUser | Get-Member

Or use a user as an example:

PS:\> Get-QADUser "Dmitry Sotnikov" | Format-List

And if you want to get to the more advanced AD properties (such as for example Msds-ResultantPSo in this example of managing fine-grained password policies) you are screwed and have to go to MSDN and read the AD schema docs.

As it turns out, this is not the case! You can get the full list of attributes available for a user object with this one call:

PS C:\> Get-QADUser -ReturnPropertyNamesOnly -IncludeAllProperties

objectClass
cn
instanceType
nTSecurityDescriptor
objectCategory
objectSid
sAMAccountName
...

Thanks to Rostislav for the tip!

In my network this gave 458 attributes so I am not providing the full output here.

See the whole thread here.

Tags: , , , , , , ,

UPDATE: Changed Format-Table to Format-List. Format-Table with no property names specified after it is more or less useless – it just gives the default output. Format-List by default lists all properties exposed directly via PowerShell with their values.

PowerShell Answers site and blog

I stumbled across this new (for me) PowerShell site: http://www.powershell-answers.com/

The site is run by Trevor Barry who is also delivering PowerShell training. He has just blogged about PowerGUI as well:

“…it has just made the job of building your own PowerShell based management tools so much easier :-)”

(Of course I made sure to take only the most complimentary words out of the post. ;))

Tags: , ,

Webcast: Active Directory Management Made Easy with PowerShell

On July 12 I will be co-presenting (with Bob Bobel – Quest’s Senior Product Manager for Active Directory products) at a webcast:

Webcast: Active Directory Management Made Easy with PowerShell

When: Thursday, July 12, 2007 – 10 a.m. PDT/1 p.m. EDT

In this session, we will talk about using Windows PowerShell to manage Active Directory. We’ll cover different approaches ranging from ADSI to AD cmdlets, and demo the features that are backwards-compatible with Windows 2000/2003 and the ones unique to Windows Server 2008 (e.g. Server Core and Read Only Domain Controller).

In the first half of the session, we will also highlight how you can customize and extend provisioning with Quest ActiveRoles Server through PowerShell. In the second half of the session, we’ll demo how you can use PowerGUI to build custom administrative consoles for PowerShell enabled systems, such as Active Directory, IIS, Exchange and Operations Manager.

Register at the webcast page

As you can see from the description besides the general introduction to PowerShell and AD cmdlets you will get exposed to Quest commercial products as well – which can still be pretty handy if you are planning using PowerShell to manage AD in enterprise infrastructure.

You can register here (you might want to pre-register and login in advance because I think those webcasts have limited number of connections).

Tags: , , , , , , , , , ,

Are Exchange and AD cmdlets compatible?

This is one of the questions I get asked a lot: When and how would you use Exchange 2007 and AD cmdlets together?

The short answer is that the libraries are perfectly compatible and you can mix and match the cmdlets on one machine using the Exchange ones to manage Exchange-related objects/attributes and AD cmdlets for the rest.

For example, AD cmdlets don’t have all the mailbox data, but I can get this from Exchange cmdlets:

Get-QADUser DSotnikov | ForEach { Get-Mailbox $_.DN }

The opposite example would be when I need to reset a password for a mailbox owner – this is something I cannot do with Exchange cmdlets but can do with the QAD stuff:

Get-Mailbox DSotnikov | ForEach { Set-QADUser $_.Identity -UserPassword "M%NewP@ssw0rd" }

Note that instead of piping in the cmdlets directlyI am joining them with ForEach and using DN from AD, or Identity from Exchange to do the match.

System Requirements would be:

  1. Exchange 2007 management tools installed on the local computer (it does not have to be an Exchange server – just a computer with the Exchange 2007 Management Console).
  2. AD cmdlets (again, just the cmdlets installed locally – not necessarily on a DC.)
  3. Have both registered in the same PowerShell console. This can be done by running the following commands in the PowerShell prompt:

PS:\> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
PS:\> Add-PSSnapin Quest.ActiveRoles.ADManagement

You obviously need to run just one of them if you are using a PowerShell console shipping with either of the cmdlet libraries so you simply add the other library.

If you want more information about Exchange 2007 cmdlets I would highly recommend to subscribe to Evan Dodd’s blog at http://blogs.technet.com/evand (and if you are at a conference with him presenting – make sure you attend the session or chalk-talk – I saw him at this TechEd and he was great!)

Tags: , , , , ,

PowerGUI Roadmap Updated

I’ve updated the PowerGUI roadmap and version history page at PowerGUI.org.

Based on the feature poll and discussions in the community we will provide a few pretty significant improvements in our next release (1.0.8 in a week or two from now) in the following areas:

  • Stability and performance:
    • More stable in various PowerShell environments even with corrupt PowerShell installations or third-party snapins. For example, with 1.0.8 there won’t be any need to comment out community extensions start-up commands from the profile, etc.
    • Slightly faster start-up time and less memory consumption.
    • No restart required when linking to PowerShell snapins (libraries).
  • More control of PowerGUI UI from script nodes, actions, and links
    • PowerPack creators will be able to dynamically create tree nodes (e.g. to give OU or public folder hierarchy) and change the labels in the path control above the object grid.
    • Better system requirements enforcement for PowerPacks.
  • “Smarter” parameter dialog boxes
    • we used to have text edit boxes for all types of parameters now we try to be better than that and provide drop-down boxes for enumerations and booleans, date picker for dates, etc.

I know we’ve been asked for more advanced features as well such as a better built-in script editor and we are working on that but this will take slightly longer than a couple of weeks. Stay tuned!

Is there something else that we are missing? Please comment here or in the discussion forum at PowerGUI.org.

Tags: ,

Autoupgrade for PowerShell snapins?

There’s an interesting side-effect of being agile and releasing updates too often – not everyone is able to keep track of your updates and upgrade to the latest version.

With rich applications this is kind of easier. For example, PowerGUI checks for newer version on start-up (we even have a bug when it manages to display the notification behind the splash screen) and offers to perform the upgrade.

By how would you handle the same issue in the command-line?

AD cmdlets 1.0.0 had issues installing on Vista/Longhorn. We fixed this in 1.0.1. The current version freely available for download is 1.0.3 and there are still people trying to use 1.0.0 and suffering from all the issues we have fixed a long time ago.

Is anyone trying to solve similar issues with other PowerShell snapins? Any advice?

One thing I find useful is making PowerShell at least display the snapin version so you know which computer has which version installed (yes, you can look this up in Add/Remove Programs but that’s not that handy.) For AD cmdlets you can do this by checking the version info with the following command:

(get-command (get-pssnapin Quest.ActiveRoles.ADManagement).ModuleName).FileVersionInfo.ProductVersion

Or even modify your profile to have that displayed at each startup:

# add the following code to your profile
# this gives the greeting message with the version info

"Loaded AD cmdlets v."+ (get-command (get-pssnapin Quest.ActiveRoles.ADManagement).ModuleName).FileVersionInfo.ProductVersion

# this changes the window caption:
function Prompt
{
$host.ui.RawUI.WindowTitle = "ActiveRoles Management Shell for Active Directory (beta) v."+ (gcm (get-pssnapin Quest.ActiveRoles.ADManagement).ModuleName).FileVersionInfo.ProductVersion
"PS> "
}

But this still does not give auto-update… Can you even have the snapins go to the internet, check for latest version, download it and start the upgrade?

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

June 2007
M T W T F S S
« May   Jul »
 123
45678910
11121314151617
18192021222324
252627282930  

%d bloggers like this: