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


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
« Jan   Mar »
 123
45678910
11121314151617
18192021222324
2526272829  

%d bloggers like this: