It’s official: Microsoft’s AD cmdlets in Server 2008 R2

We all knew that Microsoft’s AD team was working on a set of PowerShell cmdlets of their own, but now we know when and how these are going to be shipped. Jeffrey published stats on the PowerShell cmdlets in the upcoming (in 2010) Windows Server R2.

If you look carefully through the list you will see that one of the snapins is called… activedirectory and contains 76 cmdlets. And these are just for the AD itself. There are other related snapins, like GroupPolicy (25 cmdlets) and ADRMS.PS.Admin (15 Cmdlets).

As far as I know AD and RMS are also getting PowerShell providers.

Sounds like in a year and a half or so we will get a pretty comprehensive cmdlets coverage from Microsoft. Meanwhile, there are obviously free 3rd-party solutions providing similar functionality:

• Quest’s AD cmdlets,
• PSCX AD provider,
• SDM Software’s GPO cmdlets.

See full Windows Server 2008 snapin list in Jeffrey’s post.

Tags: AD, AD cmdlets, Active Directory, GPO, Microsoft, PSCX, PowerShell, cmdlets
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Advertisement

PowerShell disk defragmenter

Kuma's PowerPack to defrag your hard disk

Another PowerPack challenge spotlight: the second contestant is Kuma with his Volumes With XP Support powerpack. The PowerPack takes the Volumes pack which we had in the library for ages and makes it work for Windows XP.

The pack gives you a list of hard disk volumes on your computer and allows you to defrag them either with the defrag UI showing up on the screen or without it.

Kuma is actually running the defragmentation process in a pretty cool way. He is using the start-process cmdlet from the PowerShell Community Extensions library – so defrag is being started asynchronously and thus is not locking your PowerGUI console.

You can download Kuma’s powerpack here. And you have about two more weeks to get you chance to become of of the first round winners. 😉

Tags: PSCX, PowerGUI, PowerPack, PowerPack Challenge, PowerShell
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

PowerGUI now fully supports PowerShell providers!

For some time PowerGUI gave great experience for cmdlet-based operations but didn’t let users browse through PowerShell providers that easily. Not anymore!

See the screenshot below. If you install the latest version of PowerGUI (which at the moment is 1.0.8) and instead of the default Local System pack install the one I have just uploaded to the library you will get UI which will let you browse through any providers installed on the computer:

• File system drives, files, and folders
• Registry
• Certificate stores
• Environment
• Variables
• Aliases
• Functions

What’s more, third-party providers (such as AD and feed store from PSCX) will automatically show up as well.

We will include this pack by default into our next (1.0.9) release. But you don’t have to wait for that. Just download the localsystem.snapin file attached to the library entry and import it into the PowerGUI tree – then click the Drives node and the magic will begin. 😉

Tags: PowerPack, PSCX, PowerGUI, PowerShell

PowerGUI and PSCX are now fully compatible!

Another important new feature which I forgot to mention yesterday is that now with 1.1.1 release of PowerShell community extensions (more on their new features here) and 1.0.8 release of PowerGUI, the products are fully compatible! You can install them on the same box, add the extensions in PowerGUI’s File/PowerShell Libraries menu, and next time you add a node (or link, or action) all the PSCX cmdlets will also be available there.

Tags: PSCX, PowerGUI, PowerShell

Longhorn RDP Airlift Slides

Here are the slides I was showing on the Longhorn Airlift AD PowerShell session:

LonghornAirlift_ADPowerShell_PowerGUI_Dmitry_Sotnikov.ppt

Overall the session went well. I was surprised that a big part of the audience was not that familiar with PowerShell as such but everyone seemed pretty interested and I saw people taking notes during the session.

We used Longhorn Beta 3 for the demos and everything went surprisingly well. I even demoed experimental cmdlets for granular password policies.

P.S. In case you get the DVD and listen to the session or just were there. During the demo I completely forgot to mention that the new-account.ps1 script I was showing while demonstrating the ADSI approach is from Adam Bell. Thanks to Adam for providing that on his blog!

Tags: AD cmdlets, ActiveRoles Server, PSCX, Server Core, cmdlets, Windows Server 2008, PowerGUI, Airlift, AD, Longhorn, Active Directory, ARS, PowerShell, RDP, Conferences

AD and PowerShell at Longhorn Airlift

I’ve been asked to present at the Microsoft Windows Server “Longhorn” RDP Airlift conference in Seattle on May 16 and needless to say was happy to accept the invitation. This is a great event where you can find enterprise customers participating in Microsoft’s “Longhorn” Rapid Deployment Program – i.e. deploying “Longhorn” beta in their production.

In case you are coming, the session will be on Wednesday, May 16 at 9:00am.

The title is: Managing Active Directory with PowerShell and creating custom administrative consoles (300 Level)

I am thinking of the following agenda:

1. Quick introduction to PowerShell.
2. AD management in PowerShell using:
   • ADSI, .NET.
   • AD provider.
   • AD cmdlets.
3. Showing PowerGUI and custom UIs administrators can create for their own AD management tasks.

During the demos I am thinking of showing of a few AD-specific management tasks such as:

1. Browsing AD, reporting, statistics.
2. User account-, group-, OU-management.
3. Provisioning from CSV files, cloning accounts.
4. A few Longhorn-specific scenarios – such as granular password policies.

This sounds like a pretty exciting session and a good chance to start enterprises (not just geeks like you and me) thinking about PowerShell.

Any comment/suggestions?

Tags: PowerGUI, AD cmdlets, PSCX, Airlift, RDP, Longhorn, AD, Active Directory, Conferences

AD provider vs. AD cmdlets

Richard has interesting considerations in his blog about AD provider potentially being too dangerous as its use might be error-prone, so someone could type del * without understanding the current context and thus the consequences.

When we started working on our AD cmdlets we surely had a lot of discussions of the approach to take: cmdlets or provider. Frankly, we didn’t think of this danger of inadvertent AD changes that Richard mentions. We picked cmdlets as a way to give administrators more intuitive and functional commands to accomplish their tasks.

You see if you want add an account to a group it is probably more natural for you to type something like: add-groupmember than to use file-system metaphor for this not file-system-related task. Cmdlets also make the functionality more discoverable with tab-completion letting you easily see what parameters are available for that particular command on that particular object.

Does this mean that cmdlets are always a better choice though?

I am not sure really. I still think that being able to use the provider to browse AD, cd into OUs, dir their contents, etc. – is very impressive and in fact highly intuitive.

I guess bottom-line is that it is great that both projects exist and both are available as free downloads.

In his DEC session by the way Richard demoed how you can use those together piping out provider output into AD cmdlets. That was pretty cool. Richard promised to publish his demo transcript in his blog later on – if you could not attend his DEC session make sure you grab the transcript once it gets published.

Tags: AD cmdlets, PSCX, Directory Experts Conference, get-psuguk, DEC, Active Directory, PowerShell, AD

PowerGUI 1.0.5 is out!

We have just released version 1.0.5 of PowerGUI. You can get it free from the PowerGUI community web site and no registration is required.

Most new features and fixes are listed on the roadmap page.

Some of them are minor improvements which will hopefully make everyone’s life easier: the Actions pane is open by default, most commands are duplicated on the toolbar, setup has the latest packs for network management, Exchange (with UI for certificate management!) and Operations Manager, etc.

We’ve made a few improvements in the architecture as well. The biggest is asynchronous work with PowerShell so PowerGUI no longer waits for all objects to be retrieved before it starts displaying you what it got.

We have also moved to a new setup which should have less issues than the Visual Studio one we used before (it might require you to uninstall 1.0.4 though – but will preserve all you settings during the upgrade anyway.)

One gotcha that I want to mention is that 1.0.5 checks whether PowerShell Community Extensions are installed and if it detects version 1.1 or earlier would not let you install PowerGUI. We had to do this due to the incompatibility issues the extensions had.

If you do use the extensions there’s a workaround to that check:

1. Comment out the extensions’ lines in the PowerShell profile which cause the issue:

lines 98 and 138 in your profile.ps1:

(line 98)
# Start-TabExpansion

(line 138)
# . '.\TabExpansion.ps1'

the ‘#’ prevents the line from executing when powershell/powergui starts up.

2. Download the PowerGUI 1.0.5 setup from PowerGUI.org and run the file from the command-line using the following command:

msiexec.exe /i PowerGUI.1.0.5.22.msi IGNOREPSCX=1

Thanks to Austin for locating the issue and suggesting the workaround! Austin, please redownload the setup and use the command above!

Tags: OpsMan, OpsManager, PSCX, PowerPack, Systems Center Operations Manager 2007, PowerGUI, MOM, PowerShell, Exchange 2007, SCOM, Exchange

PowerGUI incompatible with Community Extensions 1 & 1.1

An error in PowerShell Community Extensions and the fact that they add their snapin to PowerShell profile cause PowerGUI to exit if extensions v1 or 1.1 are installed.

This is an acknowledged issue which is already fixed in the extensions but has not yet made into their release.

The symptoms are pretty straight-forward. You run PowerGUI on a computer which already has PSCX installed, PowerGUI displays a message “Object reference not set to an instance of an object” or “The invoked member is not supported in a dynamic assembly” and exits.

The reason is that PSCX has an issue that throws this exception and the exception is thrown in asynchronous code so it escapes PowerGUI catches and just happens after PowerGUI startup even if you don’t use any PSCX functionality in PowerGUI. The worst part about that is that this happens even if you don’t want to use PSCX in PowerGUI at all. Normally, if you want to use a PowerShell snapin (like PSCX, AD cmdlets, or any other library available on the market) you would execute Add-PSSnapin in the PowerShell command prompt or go to File/Snapins in PowerGUI and select the snapin there. Unfortunately, PSCX is doing something which is pretty bad: they are adding PSCX load code to PowerShell profile – and this makes their libraries load automatically without user consent – this is similar to applications adding themselves to a Startup group in Windows.

PowerGUI uses PowerShell profiles and gets this unhandled exception as result.

Bottom-line:

• Cmdlet creators, please, don’t load your libraries in the profile. This is a pretty bad practice which can affect other applications even if they are not using your code.
• PSCX is still a great effort and once the guys will fix the issue you will be able to use their cmdlets in PowerGUI.
• Meanwhile you can either uninstall PSCX or remove the code loading the library from your PowerShell profile.

For more information see these discussion threads:

• http://www.codeplex.com/PowerShellCX/WorkItem/View.aspx?WorkItemId=9154
• http://powergui.org/message.jspa?messageID=6736

Dmitry