PowerShell in Windows 7 – not in XP/Vista

One of the leaked and presumably real screenshots of Windows 7 has PowerShell v2 command-line window on it.

Which actually leads to a few thoughts:

1. It is great to finally have PowerShell (and especially v2) a part of the client OS (it is a part of the upcoming Windows Server 2008 already).

2. At the same time, this is not a big surprise because Windows 7 ships after the PowerShell deadline at Microsoft goes into effect so I guess Windows team had no choice anyways.

A colleague of mine just today asked me whether Microsoft was going to push PowerShell into XP SP3 or Vista SP1. The answer is no. For XP and Vista, PowerShell remains an optional download.

I would argue that there actually is a rationale for that. Today, PowerShell is not a desktop management tool. With no real remoting in the platform there’s just no value in having PowerShell on each and every computer in the network. It would just be there and not give you a way to mass-manage the systems (unless a 3rd-party product is used.)

With PowerShell v2 remoting capabilities, the system goes beyond the admin console value, and becomes the desktop management platform. So having v2 on each and every Windows box suddenly starts making a lot of sense.

Thus (a complete speculation below), we might eventually see PowerShell v2 getting into some Vista SP (e.g. SP2) or being pushed to Vista via Windows Update (I doubt that XP is going to be included).

Tags: PowerShell, PowerShell v2, Vista, Windows 7, XP
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Advertisement

AD Cmdlets 1.0.2 Released: Support Vista and Longhorn

Andrei posted an announcement on release of v1.0.2 of AD cmdlets.

Vista/Longhorn Support

To me this is the main new feature. Not any particular cmdlet but just the ability to install and run the cmdlets on Windows Vista and Windows Server 2008 (Longhorn). My desktop computer runs Vista and my demo lab is 2008 so I am glad I no longer need to use a dev build not being available publicly.

However, besides that there are multiple other improvements such as:

Remove-QADObject cmdlet

Supports pipelining so you could run something like:

Get-QADGroupMember *Managers | Remove-QADObject -whatif

to get read of all managers in your company.

Seriously though, please execise with caution. Deleting accounts, groups, OUs, etc. can be pretty dangerous. Always use -whatif before really running the command, and when you do run it, carefully read the “Are you sure” note before confirming.

There is also the-DeleteTree parameter for objects within OUs:

Remove-QADObject 'company.com/UsersOU' -DeleteTree

Obviously, there are multiple other parameters (such as -Force) which you can find in documentation, help, or just by using tab-completion.

Output limits

1.0.1 had a couple of get- limitations:

All get- cmdlets returned by default just the first 1000 objects and if you wanted more (e.g. all) you had to use the -SizeLimit parameter with some huge number. In 1.0.2 the default limitation is still there(which is great in large environments) but unlimited mode is implemented. To remove the limitation simply use zero as your size limit.

(Get-QADUser -SizeLimit 0).Count

should return you the number of user accounts in your AD even if you have more than a 1,000 of those.

Get-GroupMember is also now not limited to the AD default retrieve set (was that 1,000 as well?) and always returns full list of members. You don’t have to use any parameters to achieve that:

Get-GroupMember "World-Wide Everyone"

will give you a list of all accounts in the group no matter how big it is.

You can create enabled user accounts

1.0.1 did not support setting UserAccountControl flags during creation so you had to first create an account and then use Set-QADUser to enable it. Now you can do it all with one cmdlet:

New-QADUser -Name 'User1' -OU 'company.com/UsersOU' -UserPassword 'Qwerty123' -ObjectAttributes @{userAccountControl=512}

Smart wildcard mode

Before that you had to manually switch cmdlets to PowerShell-wildcard mode for advanced wildcards. With 1.0.2 cmdlets are smart enough to make the decision for you:

• If wildcards you are using are LDAP compatible they will be put into LDAP query and thus efficiently executed on DC.
• If you are using advanced wildcards PowerShell filtering is used instead.

Everything that was there before

All the functionality they had in 1.0.1 is of course still there as well.

Tags: one-liner, oneliner, AD cmdlets, cmdlets, PowerShell, Active Directory, Examples, Longhorn, AD, Vista

“XP can be ‘green’ too” – if you use Group Policy!

Going “green”, making sure the computers and monitors are off when not needed, and thus reducing emissions and energy bills is something most enterprises want to achieve. Group Policy seems to be the best technology to do this. I tried to find a PowerShell alternative but so far was not successful.

In all the discussions last month about whether Vista is more capable of saving energy than XP one thing was missing: although XP indeed has power management settings – they are local and thus cannot be set centrally across the enterprise. The only solution which I see is using some kind of group policy extensions product to distribute the settings.

For those who missed the story: on March 21 Microsoft announced that a UK research company came to the conclusion that “Vista’s power management features could help a business with 200 PCs to reduce its carbon dioxide emissions by 45 tons a year and cut the annual energy bill for each PC by £46 ($90).” On March 26 Gartner published their response, saying that XP can be as green as Vista and that “just about the same savings in electricity and carbon dioxide emissions can be made with XP-based systems by tackling people and process issues through user education and motivation”. (Here’s the coverage in ComputerWorld, bink.nu, Neowin, and by Paul Thurrott.)

For some reason I don’t believe that “user education and motivation” is the best way to change desktop settings across the enterprise. Group Policy, SMS, various desktop management suites, PowerShell, etc. – are much more effective. Vista provides for automated centralized power management by exposing power options via GPOs. For XP, this is also possible but you will need a third-party tool.

One of the ways to do that is using a product like Quest’s Group Policy Extensions (I am sure other products with similar functionality exist – I am just more familiar with Quest’s product line) so you specify the timeouts after which the monitors needs to be switched off, the computers need to hibernate, etc. and link these policies to the sets of users/computers to which they need to apply (I assume different departments might want different settings):

 

I am not sure everyone has electricity bills as high as in UK but it looks like a technology like that might actually easily pay off within the first year of its use.

P.S. I tried to look for an alternative to Group Policy and to find a way to change the settings via PowerShell (thinking we could add this to computer management pack for PowerGUI) but failed. It looks like neither native cmdlets not WMI expose the settings and one would need to work directly against the registry for each remote computer. Any suggestions are welcome!

Controling Vista activations How to activate Vista & KMS (Key Management Service) with

Just found a cool way to get information on Vista activations without having to manually go through event logs or use various scripts.

Basically Windows Vista is the first Microsoft product to use Volume Activation (VA) v2. The main difference from what was there before is that now even enterprises need to have their installations activated and that they need to set up a Key Management Server in their intranet so that:

• Each Vista computer will keep connecting to this server on a regular basis both before and after activation.
• The server itself goes to Microsoft every 180 days to report on potential misuse.

You can find a really good write-up on KMS on 4sysops blog.

As you might have guessed by now KMS actually becomes a pretty important piece of one’s infrastructure. The overall experience can be pretty frustrating, and to make things worse the main source of information on what is going on on KMS is its event log where most of the data is put in just one Data field.

Wouldn’t it be great to have a better way to see how Vista deployments in your network are doing?

Actually it turns out that such a way exists: someone has just posted a snapin to PowerGUI.org library which, once imported into PowerGUI gives you a nice UI with all the activation events shown in the grid, each value in a separate column so you can sort, filter, etc. – even save to html or copy to clipboard:

Nice and really helpful if you want to be compliant with Microsoft licensing.