Archive for February, 2008

Spanish PowerShell Console and IDE

PowerGUI is now available in Spanish!

Fernando Angelico has translated the user interface for both the admin console and the editor/debugger and made the translation publicly available for download.

PowerGUI welcome screen in Spanish

So if your Windows user interface (or as we say in the PowerShell world [System.Globalization.CultureInfo]::CurrentUICulture) is Spanish (es-ES) you can now enjoy managing your environment and debugging your PowerShell scripts in scripts in your mother-tongue.

This means that besides English, PowerGUI is now available in German, Russian, and Spanish – all versions linked from our downloads page. Great job by Rolf, Vassily, and Fernando!

Bienvenido a PowerGUI!

Tags: ,

Bob Muglia on PowerGUI

Bob Muglia, Senior Vice President of the Server and Tools Business (STB) at Microsoft Bob Muglia is Microsoft’s Senior Vice President of the Server and Tools Business. If you ever attended any major Microsoft conferences like TechEd or IT Forum the chances are that he was the guy delivering that roadmap keynote on the event.

I have just found out that he has commented on the PowerGUI release:

“The availability of PowerGUI to help take advantage of the hugely popular Windows PowerShell is a great example of how Quest Software is enabling customers to derive real value from Windows Server 2008, literally on day one.”

This comes from Quest’s Windows Server 2008 launch press-release. I know that normally press-releases are boring PR stuff, but in this particular case getting a quote like that from someone as senior and important at Microsoft as Bob is a great honor.

And at the end of the day, this is a great way of articulating the value of PowerGUI. Both the admin console and the IDE are aimed to ease the learning curve and let you get the most value out of PowerShell from day 1.

Tags: , ,

PowerGUI RTMs!

PowerGUI 1.0.14 has just got out and this is our first release which does not have the word “beta” in its name!

This RTM labeling is both a sign of the product stability and a result of the feature-richness the product achieved. We believe that PowerGUI is now a great administrative console and scripting IDE for a variety of platforms from AD, Exchange, and Windows Server, all the way to System Center.

Compared to the 1.0.13 beta the following are the key new features:

  1. Debugger: Pipeline debugging – you can go step-by-step through the pipeline and see which objects get processed and how.
  2. Editor: A lot of useful snippets in the editor (just press Ctrl-I or pick the corresponding menu item; we had snippets for a long time but the actual set of them was up to this build very limited.)
  3. Debugger: Breakpoints and Run to Cursor can now be set at any place within any line.
  4. Editor/Debugger options: customize font,select whether you want the PowerShell profile to get loaded, and whether PowerShell runspace needs to be re-initialized for each debug session.
  5. Admin console: Now supports right-click menu and doubleclicks in the data grid so you can use those instead of the Actions pane.
  6. Admin console: You can customize the order of links and actions.
  7. Admin console: Much improved local system, network, AD and Exchange management packs (I am sure Kirk will blog more about this).

And there are tons of other improvements and smaller features. As usual, the full list will be available in the PowerGUI roadmap page.

Needless to say, we are very excited to get the product available on the day of the Windows Server 2008 launch (the first OS to have PowerShell as a built-in component!)

And best of all, the product remains completely free. So whether you are a UI kind of administrator or a scripter – both the PowerShell-based admin console and a great PowerShell IDE are available for you, RTMed, free.

Tags: , ,

PowerShell help broken on localized versions of Windows

ISSUE

PowerShell help system broken on a localized version of Windows.

SYMPTOMS

When you try to get help, the following error messages are displayed:

PS C:\> Get-Help Get-PSSnapin
Get-Help : Error loading help content for Get-PSSnapin from file "System.Management.Automation.dll-Help.xml". Details: System.Management.Automation.dll-Help.xml.
At line:1 char:9
+ Get-Help <<<< Get-PSSnapin

SYSTEMS AFFECTED

In my testing, this was reproduced on German Windows XP with PowerShell v2 CTP.

I suspect that the problem affects:

  • All localized Windows XP and 2003 systems with English PowerShell v2 CTP.
  • All localized Windows Vista systems with English PowerShell v1 or v2.

CAUSE

The problem seems to be that PowerShell v1 for Windows Vista and PowerShell v2 CTP for all systems are storing the language neutral (English) help system in the en-US subfolder of the PowerShell folder.

On a localized versions of Windows, PowerShell seems to be looking for a subfolder with its own locale (e.g. de-DE for Germany, ru-RU for Russia, and so on) and does not fail over to en-US if the folder is not found.

RESOLUTION

Apply the language pack for your language so your local version of help gets added to the system.

If the language pack is not available, copy or rename the en-US folder to match your Windows locale. To learn your locale run the following command in the PowerShell prompt:

[System.Globalization.CultureInfo]::CurrentUICulture

See this screenshot for details:

Error loading PowerShell help on localized Windows

REFERENCES AT MICROSOFT

Vote for this issue to be fixed at the Microsoft Connect site.

Tags: , , , ,

Make PowerShell record everything you do

How many times you wished you had a log of the management activities you did yesterday, or last week, a a month ago?

Luckily, PowerShell has the ability to do that! Start-Transcript cmdlet outputs all the commands you enter and the results you get into a specified text file. Now all you need to do is add the function starting a new transcript file every day which Shay shared yesterday to your PowerShell profile.

And every day everything you do is going to be preserved. Pretty powerful if you combine that with a desktop search engine!

Tags: ,

PowerShell Adoption by Platform

I have always wondered how much is PowerShell adopted across various administrative tasks. Now I finally found the stats.
Windows Server and Active Directory are far ahead, with Windows Desktop being a runner-up, Exchange on distant 3rd and everything else far behind.

PowerShell use survey statistics by application and platform

My take on the data:

  • Server and AD management tasks are far ahead of everything else. Too bad the survey didn’t distinguish between the two.
  • It is a bit surprising the desktops took number 2. My guess is that respondents just meant using PowerShell on their desktop for their personal needs. Despite existing 3rd-party solutions I doubt PowerShell v1 can be used that widely for mass desktop management. I think we will need to wait for v2 and remoting to see this taking off.
  • Not surprisingly almost a 3rd of respondents are not using PowerShell for admin tasks at all. After all, there is some learning curve involved here and PowerShell is not yet available for any platform.
  • Almost a quarter of PowerShell users employ it for Exchange 2007. A very good result! After all, Exchange 2007 was released not that long ago, and has just got its SP1.
  • In general, it looks like platforms with no cmdlets available don’t really get PowerShell fans. .NET can be used to manage SQL and SharePoint – but look how much behind are they! Exchange 2003 can actually be managed with PowerShell, but there are no native cmdlets built-in – and as result PowerShell use is just 1.5%. Compare that to 23.4% Exchange 2007 got!
  • I wonder why Operations Manager is relatively low. Less adopted than Exchange 2007? OpsMgr admins less willing to script? OpsMgr tasks not really requiring scripting and command-line use?

The survey was carried out by Quest Software and took place in the very end of December 2007 and early January 2008. It was promoted at PowerGUI.org, this blog, myITForum.com and a few other PowerShell blogs. About 200 people responded. The exact question was: “Select the systems you are currently managing with Windows PowerShell“.

Tags: , , , , , , ,

Managing Terminal Services attributes with PowerShell

Terminal Services properties is definitely a set of properties you would want to bulk-manage, and as we all know PowerShell is the best tool for any bulk operations.

We have recently (in the AD cmdlets 1.0.6 drop) improved the experience here (thanks to requests from Simon and George) and there are a few gotchas to keep in mind – so I thought I would summarize this all in one blog post.

Getting TS attributes

Retrieving terminal services properties is easy. You just execute Get-QADUser and the objects retrieved will have the corresponding properties – for your convenience, all starting with Ts.

PS C:\> get-qaduser "Dmitry Sotnikov" | format-list Ts*

TsProfilePath : \\server\tsprofiles\DSotnikov
TsHomeDirectory : \\server\tshome\DSotnikov
TsHomeDrive : P:
TsAllowLogon : True
TsRemoteControl : 0
TsMaxDisconnectionTime : 00:00:00
TsMaxConnectionTime : 00:00:00
TsMaxIdleTime : 00:00:00
TsReconnectionAction : 1
TsBrokenConnectionAction : 0
TsConnectClientDrives : True
TsConnectPrinterDrives : True
TsDefaultToMainPrinter : True
TsWorkDirectory : c:\
TsInitialProgram : C:\Program Files\Quest\Initialize.exe

Important: Terminal services properties are only available when AD cmdlets are run on Windows Server 2003 or 2008. Workstation operating systems (XP, Vista) do not support programmatic TS administration so the properties will not be retrieved.

[Update] See these instructions on enabling Terminal Services management on XP and Vista.

Changing TS attributes

TS properties are not (yet) available as Set-QADUser parameters and need to be changed as properties of retrived objects as shown in the example below:

$u = get-qaduser dsotnikov
$u.TsProfilePath = 'c:\profile'
$u.CommitChanges()

[Update] With AD cmdlets 1.1.1 Set-QADUser exposes all the TS attributes as its parameters so changing TS attributes is now much easier:

get-qaduser -searchroot mydomain.local/uk/london | set-qaduser -TsHomeDrive 'P:'

Again, make sure you follow the system requirements.

Property reference

Here’s a quick reference to the properties (I borrowed some of the descriptions from the MSDN page):

Property Description
TsProfilePath Roaming or mandatory profile path to use when the user logs on to the terminal server. The profile path is in the following network path format:\\ServerName\profiles folder name\UserName

Note A Terminal Services profile path is used only for logging on to a terminal server.

TsHomeDirectory Home directory for the user. Each user on a terminal server has a unique home directory. This ensures that application information is stored separately for each user in a multi-user environment.To set a home directory on the local computer, specify a local path; for example, C:\Path. To set a home directory in a network environment, you must first set the TsHomeDrive property, and then set this property to a UNC path.
TsHomeDrive Home drive for the user. In a network environment, this property is a string containing a drive specification (a drive letter followed by a colon) to which the UNC path specified in the TsHomeDirectory property is mapped.To set a home directory in a network environment, you must first set this property and then set the TsHomeDirectory property.
TsAllowLogon Value that specifies whether the user is allowed to log on to the terminal server.
TsEnableRemoteControl Value that specifies whether to allow remote observation or remote control of the user’s Terminal Services session. For a description of these values, see the RemoteControl method of the Win32_TSRemoteControlSetting WMI class.

Name Value
Disable 0
EnableInputNotify 1
EnableInputNoNotify 2
EnableNoInputNotify 3
EnableNoInputNoNotify 4
TsMaxDisconnectionTime Maximum amount of time, in minutes, that a disconnected Terminal Services session remains active on the terminal server. After the specified number of minutes have elapsed, the session is terminated.
TsMaxConnectionTime Maximum duration, in minutes, of the Terminal Services session. After the specified number of minutes have elapsed, the session can be disconnected or terminated.
TsMaxIdleTime Maximum amount of time, in minutes, that the Terminal Services session can remain idle. After the specified number of minutes have elapsed, the session can be disconnected or terminated.
TsReconnectionAction Value that specifies whether to allow reconnection to a disconnected Terminal Services session from any client computer. The value is 1 if reconnection is allowed from the original client computer only, and 0 if reconnection from any client computer is allowed.

Note This property currently is not used by Windows Server Terminal Services.

TsBrokenConnectionAction Value that specifies the action to take when a Terminal Services session limit is reached. The value is 1 if the client session should be terminated, and 0 if the client session should be disconnected.
TsConnectClientDrivesAtLogon Value that specifies whether to reconnect to mapped client drives at logon. The value is 1 if reconnection is enabled, and 0 if reconnection is disabled.

Note This property currently is not used by Windows Server Terminal Services.

TsConnectClientPrintersAtLogon Value that specifies whether to reconnect to mapped client printers at logon. The value is 1 if reconnection is enabled, and 0 if reconnection is disabled.
TsDefaultToMainPrinter Value that specifies whether to print automatically to the client’s default printer. The value is 1 if printing to the client’s default printer is enabled, and 0 if it is disabled.
TsWorkDirectory Working directory path for the user.To set an initial application to start when the user logs on to the terminal server, you must first set the TsInitialProgram property, and then set this property.
TsInitialProgram Path and file name of the application that the user wants to start automatically when the user logs on to the terminal server.To set an initial application to start when the user logs on, you must first set this property and then set the TsWorkDirectory property. If you set only the TsInitialProgram property, the application starts in the user’s session in the default user directory.

Tags: , , , , , ,

Mail-Enabling Objects in Exchange 2003

How do you create thousands of mail-enabled user accounts and contacts on Exchange 2000 or 2003?

With Exchange 2007 the answer is obvious – use PowerShell!

With Exchange 2000 and 2003 the answer is… – use PowerShell. These systems don’t have native Exchange Management Shell, but WMI and AD cmdlets still give much easier solutions than VBScript and other alternative.

See this forum thread in which someone is providing PowerShell one-liners he used to create and mail-enable 18,000 users and 79,000 contacts.

Talk about productivity gains… 😉

Tags: , , , , , , ,

Shakespeare and IT

It occurred to me yesterday while discussing one of PowerGUI dialog boxes that the following is probably the way Hamlet would have been expressed these days:

To be, or not to be - Shakespear’s Hamlet in 21st century

Frankly, I have always thought that in the original play, the great Bard have not made the choice obvious enough. It’s all about usability…

Tags: ,

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.Windows 7 screenshot with PowerShell v2

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: , , , ,


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

February 2008
M T W T F S S
 123
45678910
11121314151617
18192021222324
2526272829  

%d bloggers like this: