Search results for 'app:weblogs' matching tags 'Windows PowerShell' and 'graphical'

PowerShell Community and the Windows System Administration Tool

Anonymous — Fri, 06 Jan 2012 06:00:00 GMT

Summary: See how guest blogger, Rich Prescott, leveraged the Windows PowerShell community as he built his popular ArPosh Client System Administration tool.

Microsoft Scripting Guy, Ed Wilson, is here. We are really starting the new year off correctly. We have another very strong guest blogger today. Rich Prescott, is currently working as an infrastructure architect and Windows engineer at a large media company, with his main areas of focus on automation and Active Directory. The automation responsibilities allow him to work with a wide-range of technologies including virtualization, storage, and monitoring. He started learning Windows PowerShell in 2009 while he was working as a desktop engineer, and he is the lead scripting guy for his organization. He is also a moderator on the Official Scripting Guys Forum, and was recently rewarded as a Microsoft Community Contributor.

Blog: Engineering Efficiency: Scripts, Tools, and Software New in the IT World
Twitter: @Rich_Prescott

Take it away Rich…

When I first joined the IT world, I was working at the Help desk for a large company. Being new to IT and troubleshooting, I always wondered why there was no single tool for troubleshooting remote computers. I would receive a call about a computer being slow, and I would have to go through four tools to try to diagnose the issue. I began searching for an easy solution, and that is when a coworker introduced me to Windows PowerShell. After reading blog posts from Hey, Scripting Guy! and the Scripting Wife, I was writing basic scripts to gather the information that I needed for troubleshooting. This is an example of a basic script I wrote back then.

$PC = “PC01”
Get-WmiObject Win32_OperatingSystem –ComputerName $PC
Get-WmiObject Win32_StartupCommand –ComputerName $PC
Get-WmiObject Win32_Process –ComputerName $PC

After the underlying issue was targeted, I needed a way to remediate the issue, such as removing a hung process. This was possible remotely by querying the Win32_Process class on a remote computer, filtering for the process that was causing an issue, and invoking the Terminate method. Here is an example of using the Terminate method to stop a process on a remote computer.

(Get-WmiObject Win32_Process –ComputerName $PC |
Where-Object {$_.Name –eq “HungProcessName”}).Terminate()

At last, I was able to efficiently troubleshoot issues remotely and even resolve some of them without ever having to leave my desk. As I became more familiar with Windows PowerShell, I thought, “Wouldn’t it be cool if I could share the efficacy of Windows PowerShell with others, even if they don’t know any scripting?” After a few months of researching, scripting, and testing GUI creation with Windows PowerShell, the Arposh Client System Administration tool (ACSA) was released.

As with any technology that you learn rapidly, when you look back on what you were doing a year ago, you think to yourself, “What was I thinking when I wrote that? I could write that in half the code and make it twice as fast.” So I set out to find resources to help me rebuild the script from scratch, and I used this opportunity to remove some of the prerequisites, make it compatible with servers, and improve the overall user experience.

PowerShellGroup - #PowerShell chat room

One of the advantages of using Internet Relay Chat (IRC) is that there are chat rooms for almost any topic you can think of and when you are learning a new technology, having a live discussion can be really helpful. While revamping the ACSA tool, one of the user-experience features that I wanted to add was to give the user the ability to decide which feature sets to use through a configuration file.

I joined the #PowerShell chat room on PowerShellGroup.org, and I asked about an easy way to give users configuration options. Jaykul, a Windows PowerShell MVP, responded with a way to read settings from an XML file. By using the following XML code and three lines of Windows PowerShell, a user is able to set a default domain to connect to when using the GUI. To have the GUI use the current domain of the logged on user, simply update the Enabled option of the default domain to “False” in the XML configuration file.

<?xml version="1.0" standalone="no"?>
<Domain Default="LDAP://DC=RU,DC=lab" Enabled="True"/>

In the first line of code, we use Get-Content on the XML configuration file and specify that it is XML code by using [XML]. We then check to see if the default domain option is enabled, and if so, we set the Domain variable to what is specified in the XML. If the option is disabled, the GUI sets the Domain variable to the currently logged on domain.

[XML]$XML = Get-Content “AWSA.Options.xml”
if($XML.Domain.Enabled –eq $True){$Domain = $XML.Domain.Default}
else{$Domain = ([DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).Name}

TechNet Wiki

My next task was to make the GUI easy to use, and this meant removing any unnecessary pre-requisites included in the original release. My first stop was the TechNet Wiki to find a way to query Active Directory for computers without the need to import a Windows PowerShell module that was not freely available on all systems. After a quick search, I landed on a wiki contribution from Richard Mueller, another MVP, for ADSI searches, which showed me the syntax necessary to build my custom function.

function Get-RPADComputer{
if($ComputerName -match "."){$ComputerName = $ComputerName.Split('.')[0]}
$searcher=[adsisearcher]"(&(objectClass=computer)(name=$ComputerName*))"
$Properties = $XML.Options.Search.Property
$searcher.PropertiesToLoad.AddRange($Properties)
$searcher.FindAll()
}

This function checks the $ComputerName parameter that is specified in the textbox of the GUI, and if a fully qualified domain name (FQDN) is specified, it translates it to a short name. It then creates a query that will search for any computers that match the new $ComputerName variable. The third line reads a list of properties that the user specifies in the XML settings file and adds them to the list of properties to load. The final line of the function executes the query and returns the results.

TechNet forums

After adding in the ability to set a default domain when launching the GUI, the user needed a way to change domains without having to edit the XML file and relaunch the script. I was not familiar enough with the ADSI scripting techniques that I found on the TechNet Wiki, and I decided to head over to the Official Scripting Guys Forum on the TechNet Forums and ask for some assistance.

I posted my question with some examples of the input and output that I wanted, and within four hours, I received multiple responses from the community. And what do you know—Richard Mueller again came to the rescue with a way to prompt for a domain and then convert the response into the LDAP path for that domain. By slightly tweaking his code, I was able to add the ability to search alternate domains to my custom Active Directory computer search function.

TechNet ScriptCenter

There are many new features in this update of the GUI, but I want to highlight one that many administrators will find very useful and sigh at the mention of: local administrator rights. Every system administrator has received a request along the lines of, “I need to install XYZ software right now!” or “I am using VPN from home, and I need to add a local printer.” One way to get around this (not always the best way) is to grant the user temporary local administrator rights. To find out how to do this the Windows PowerShell way, I headed over to the TechNet ScriptCenter Repository to search for some examples.

Using the Categories listing in the left pane, I drilled down into Local Account Management, and I immediately saw what I was looking for: Local User Management Module. I clicked through to the details page and looked through the included functions. I was in luck! By using ADSI code in the Set-LocalGroup function, I morphed it into my own function as shown here.

Function Add-LocalAdmin {
  [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic') | Out-Null
  $Input = [Microsoft.VisualBasic.Interaction]::InputBox("Enter a username to add (Domain\Username)", "Add Local Admin", "")
  $Group = [ADSI]("WinNT://" + $ComputerName + "/Administrators, group")
  $Group.Add("WinNT://" +$Input.Replace(‘\’,’/’)
}

The first line of the function loads the Visual Basic assembly; this allows me to create a custom input box, which prompts the user for the username to add to the local administrators group and then stores it in the $Input variable. The function then binds to the Administrators group on the remote computer using ADSI. Now we call the Add method of ADSI to add the desired user account to the administrators group. But there is a snag, the username is specified as Domain\Username, whereas ADSI requires a forward slash. To get around this, we use the Replace method to turn the back slash into a forward slash.

Arposh Windows System Administration tool

Whether you are new to Windows PowerShell and only need a simple script to get you going or you are a Windows PowerShell guru and need a nudge in the right direction, there are numerous resources for everyone. Thanks to all of these resources, I was able to take a simple GUI that I created for myself to make tasks easier and improve it enough to where the Windows PowerShell community would also find it useful. Without further ado, here is the Arposh Windows System Administration tool.

~Rich

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Create a Simple Graphical Interface for a PowerShell Script

Anonymous — Sun, 24 Jul 2011 05:00:00 GMT

Summary: Learn how to create a simple graphical interface for a Windows PowerShell script.

Weekend Scripter: Extending PowerShell to the GUI with Sapien Tools

Microsoft Scripting Guy Ed Wilson here. Sean Kearney joins us again today as our guest blogger. Read more about Sean and his previous blog posts.

Here is Sean!

While playing with Sapien Primal Forms, I was thinking, “If you never used this, how could you figure out how to make it work with Windows PowerShell?” Stop falling down on your faces. I don’t hate the GUI. Windows PowerShell is not about shutting down one interface for another. It’s about enabling the tools you have for the best purpose to meet your job.

Think about it. There is absolutely nothing wrong with Active Directory Users and Computers. It works. It’s a great generic interface that applies to multiple needs and works well across a variety of platforms. But it isn’t necessarily the best interface for a specific job. But each one of us has a need that it may be too much for. A simple example is the person that works the Help Desk and just unlocks user accounts. (It's not the only thing they do of course, but just an example.) In Active Directory they would have to find the account, pull up the properties of the account, reset the unlock field, and maybe reset the password.

You get the idea. When really all I want to do is type in the name and have the job done. The computer should ask me want I need to do. The workflow for unlocking an account would typically be this:

WHO do you want to Unlock?

Unlock the Account

WHO do want to Reset?

WHAT will their new password be?

Unlock the Account

So in Windows PowerShell, I might do something like this for an unlock user script:

$USERFIRSTNAME=READ-HOST ‘First Name’
$USERLASTNAME=READ-HOST ‘Last Name’
GET-QADUSER –FirstName $USERFIRSTNAME –LastName $USERLASTNAME | UNLOCK-QADUSER

Or if I knew the structure of the SAM account, I could just key this in:

UNLOCK-QADUSER ‘SAMAccountName’

This is obviously far more efficient that searching Active Directory, finding the darn button, clicking it, and so on. With little difficulty, I could pipe in a list of users and unlock them.

So great, the administrator is happy. So how does this help our your local Help Desk?

With Sapien Primal Forms Community Edition, you can create a basic GUI to extend that Windows Powershell script into a GUI interface for that Help Desk so that you don’t need to retrain them. You can provision an interface to meet their job needs without incurring heavy development costs.

Here’s a bonus too you may not realize: the generated Windows PowerShell script from Sapien is a stand-alone script. All it does when you’re done is generate the needed code within a Windows PowerShell script to call up forms in Windows. All features of those forms are fully supported because they are features of the GUI.

So here’s a simple form.

The Windows PowerShell script generated by Sapien to do this is shown here.

--------------------------------------HELPDESK.PS1-----------------------------------------------

#Generated Form Function
function GenerateForm {
########################################################################
# Code Generated By: SAPIEN Technologies PrimalForms (Community Edition) v1.0.8.0
# Generated On: 7/3/2011 11:35 AM
# Generated By: sean.kearney
########################################################################

#region Import the Assemblies
[reflection.assembly]::loadwithpartialname("System.Windows.Forms") | Out-Null
[reflection.assembly]::loadwithpartialname("System.Drawing") | Out-Null
#endregion

#region Generated Form Objects
$HelpDeskForm = New-Object System.Windows.Forms.Form
$UnlockAccountButton = New-Object System.Windows.Forms.Button
$InitialFormWindowState = New-Object System.Windows.Forms.FormWindowState
#endregion Generated Form Objects

#----------------------------------------------
#Generated Event Script Blocks
#----------------------------------------------
#Provide Custom Code for events specified in PrimalForms.
$handler_UnlockAccountButton_Click=
{
#TODO: Place custom script here

}

$OnLoadForm_StateCorrection=
{#Correct the initial state of the form to prevent the .Net maximized form issue
$HelpDeskForm.WindowState = $InitialFormWindowState
}

#----------------------------------------------
#region Generated Form Code
$HelpDeskForm.Text = "Our Help Desk"
$HelpDeskForm.Name = "HelpDeskForm"
$HelpDeskForm.DataBindings.DefaultDataSourceUpdateMode = 0
$System_Drawing_Size = New-Object System.Drawing.Size
$System_Drawing_Size.Width = 265
$System_Drawing_Size.Height = 55
$HelpDeskForm.ClientSize = $System_Drawing_Size

$UnlockAccountButton.TabIndex = 0
$UnlockAccountButton.Name = "UnlockAccountButton"
$System_Drawing_Size = New-Object System.Drawing.Size
$System_Drawing_Size.Width = 240
$System_Drawing_Size.Height = 23
$UnlockAccountButton.Size = $System_Drawing_Size
$UnlockAccountButton.UseVisualStyleBackColor = $True

$UnlockAccountButton.Text = "UNLOCK Account"

$System_Drawing_Point = New-Object System.Drawing.Point
$System_Drawing_Point.X = 13
$System_Drawing_Point.Y = 13
$UnlockAccountButton.Location = $System_Drawing_Point
$UnlockAccountButton.DataBindings.DefaultDataSourceUpdateMode = 0
$UnlockAccountButton.add_Click($handler_UnlockAccountButton_Click)

$HelpDeskForm.Controls.Add($UnlockAccountButton)

#endregion Generated Form Code

#Save the initial state of the form
$InitialFormWindowState = $HelpDeskForm.WindowState
#Init the OnLoad event to correct the initial state of the form
$HelpDeskForm.add_Load($OnLoadForm_StateCorrection)
#Show the Form
$HelpDeskForm.ShowDialog()| Out-Null

} #End Function

#Call the Function
GenerateForm
--------------------------------------HELPDESK.PS1-----------------------------------------------

The first time I looked at one of these, I almost fell down! So much code! But most of it is actually comments and object generation. Just look for the spot near the top where it states:

#TODO: Place custom script here.

If you look above, you’ll see it says:

$handler_UnlockAccountButton_Click=

This is the portion generated for WPF that says “When I click this, the code gets run”. You could happily click it, and it would do nothing, because there is no code attached to the button. But we can easily create some new code that does an account unlock. We can take this same block from before and attach it to the button:

$handler_UnlockAccountButton_Click=
{
#TODO: Place custom script here

$USERFIRSTNAME=READ-HOST ‘First Name’
$USERLASTNAME=READ-HOST ‘Last Name’
GET-QADUSER –FirstName $FIRSTNAME –LastName $LASTNAME | UNLOCK-QADUSER

}

Now this will try to work but can’t from a form as it will try to get in the console. What we’ll have to do is create another form or maybe add some input fields to this one. With Primal Tools, I’ve added two parts to the form: two text boxes and two labels. I’ve tried to give them some meaningful descriptive names such as FirstNameLabel.

I could reproduce the code but the important stuff is near the top where you see the objects defined as variables:

#region Generated Form Objects
$HelpDeskForm = New-Object System.Windows.Forms.Form
$LastnameLabel = New-Object System.Windows.Forms.Label
$FirstNameLabel = New-Object System.Windows.Forms.Label
$LASTNAME = New-Object System.Windows.Forms.TextBox
$FIRSTNAME = New-Object System.Windows.Forms.TextBox
$UnlockAccountButton = New-Object System.Windows.Forms.Button
$InitialFormWindowState = New-Object System.Windows.Forms.FormWindowState
#endregion Generated Form Objects

The rest of it is the form calling up and adding the objects to the form. Now look at the bottom of your script where it says GenerateForm. Everything up to but not including that is a function being defined. This is important to know because if I change the function so that it’s seen in the global context and don’t run it from the script, I can now just call it from the command line.

Knowing this is important. If you put it in the global context and switch your variables to global (for testing purposes), you can easily pull up the properties of those variables to see how your data is stored.

So to figure out where the information could be accessed on the $FIRSTNAME text box, I switched both the defined function at the top called GenerateForm and my $FIRSTNAME variable to global. I then removed the GenerateForm from the bottom of the script:

function global:GenerateForm {.

#region Generated Form Objects
$HelpDeskForm = New-Object System.Windows.Forms.Form
$LastnameLabel = New-Object System.Windows.Forms.Label
$FirstNameLabel = New-Object System.Windows.Forms.Label
$LASTNAME = New-Object System.Windows.Forms.TextBox
$GLOBAL:FIRSTNAME = New-Object System.Windows.Forms.TextBox
$UnlockAccountButton = New-Object System.Windows.Forms.Button
$InitialFormWindowState = New-Object System.Windows.Forms.FormWindowState
#endregion Generated Form Objects

With this done, I just run…

GENERATEFORM

…from the Windows PowerShell console and key in some stuff such as is shown in the following figure.

And then afterward, I close the form.

To reveal all the properties and their values, I can now type:

$FIRSTNAME | Format-List

I can now see there is a field called Text, which has the value I entered in for $FIRSTNAME.

With this knowledge I can now extend the values I entered there into my Unlock Account button by changing the Read-Host to simply point to the values in $FIRSTNAME.TEXT and $LASTNAME.TEXT:

$handler_UnlockAccountButton_Click=
{
#TODO: Place custom script here
$USERFIRSTNAME=$FIRSTNAME.TEXT
$USERLASTNAME=$LASTNAME.TEXT
GET-QADUSER –FirstName $USERFIRSTNAME –LastName $USERLASTNAME | UNLOCK-QADUSER
}

We now remove GLOBAL: before GenerateForm and $FIRSTNAME, and resave the script.

Now running the GenerateForm will produce our new UNLOCK USER piece for the Help Desk and allow them to just type in the first and last name to unlock a user.

We can of course go much further with this such as setting up some confirmations, maybe closing the Window, verifying we found the proper user account. But the point of all this is to give you some baby steps and with that maybe you can build something a lot more powerful.

Thanks Sean. That wraps up another weekend.

Ed Wilson, Microsoft Scripting Guy

Use ShowUi to Easily Create Graphical Interfaces for PowerShell

Anonymous — Sun, 10 Jul 2011 05:00:00 GMT

Summary: Use ShowUi, a free Windows PowerShell module, to simplify creating graphical interfaces for scripts.

Microsoft Scripting Guy Ed Wilson here. Today, I have a guest article from my good friend James Brundage. Here is a little bit about him.

James Brundage is the founder of Start-Automating, a company dedicated to saving people time and money by helping them automate. Start-Automating offers Windows PowerShell training and custom Windows PowerShell and .NET Framework development. James formerly worked on the Windows PowerShell team at Microsoft. You can follow James on Twitter (@jamesbru) or on the Start-Automating company blog.

Take it away, James!

Some people say I love Windows PowerShell a little too much.

I strongly believe that a script a day keeps Dr. Scripto away. I easily spend more time scripting with PowerShell than any other recreation activity (except maybe Xbox), and I take any statement along the lines of “you can’t do that in Windows PowerShell” as a challenge.

Today, I’m going to showcase an answer to one of those “you can’t do that in Windows PowerShell” lines.

An astoundingly large number of people don’t know that you can write user interfaces in Windows PowerShell. Some small technical changes in Windows PowerShell 2.0 enabled scripting of a really cool UI platform called Windows Presentation Foundation (WPF).

In June 2011, scripting WPF reached a whole new level of easy with the release of ShowUI. ShowUI is a Windows PowerShell module that makes it simple to write UI in Windows PowerShell with WPF. You can download ShowUI at http://showui.codeplex.com/. Now, not only can you write user interfaces in Windows PowerShell, but they’re almost always a lot shorter.

In This Weekend Scripter article, I’ll show and explain a fun sample: How to Write a Drag-and-Drop Video Player in 12 Lines of Script. Here’s the code:

New-Window -AllowDrop -On_Drop {

$videoPlayer.Source = @($_.Data.GetFileDropList())[0]

$videoPlayer.Play()

} -On_Loaded {

$videoPlayer.Source = Get-ChildItem -Path "$env:Public\Videos\Sample Videos" -Filter *.wmv |

Get-Random | Select-Object -ExpandProperty Fullname

$videoPlayer.Play()

} -On_Closing {

$videoPlayer.Stop()

} -Content {

New-MediaElement -Name VideoPlayer -LoadedBehavior Manual

} –asjob

It’s a pretty simple app. I create a window, and I allow it to accept dropped items. Whenever an item is dropped (On_Drop), I look into that items data and get out the list of files. Then I select the first one, and make the video player’s source that item. Then, I start up the video player.

Whenever a window is loaded, I go find all the sample videos, pick a random one, and make that the video player’s source. I then start the video player. Whenever the window is closing, I make sure to stop the video player as well, or else the media actually keeps playing in an invisible window. The window only has a little bit of content. That content is a media element called VideoPlayer. This MediaElement is what’s providing the value for $videoplayer everywhere in the script. Because we want to be able to stop and play the video manually, I set LoadedBehavior to Manual. To make sure that I can watch the videos and script at the same time, I launch my UI in the background with –AsJob.

ShowUI lets you build richer solutions than you ever thought possible with Windows PowerShell. Download it for yourself at http://showui.codeplex.com/, and keep watching our YouTube channel for more videos. And the next time a colleague of yours doubts the power of Windows PowerShell, just say:

“Hey, I’ve got a little video to show you.”

Splatting and ShowUI

Splatting is a nifty technique that lets you use a hash table as the input for your scripts or cmdlets. I cover this in greater detail in A Series on Splatting (Part 1, Part 2, Part 3, Part 4, Part 5).

This example shows how we can make a frontend for the world’s simplest function: Out-LastNameFirstName. Watch the YouTube video.

Import-Module ShowUI

function Out-LastNameFirstName

{

param($firstName,$lastName)

"$lastName, $firstName"

}

$in = New-UniformGrid -Columns 2 -ControlName Get-FirstAndLastName -Children {

'First Name'

New-TextBox -Name FirstName

'Last Name'

New-TextBox -Name LastName

' '

New-Button "OK" -IsDefault -On_Click {

$parent | Set-UIValue -passThru | Close-Control

}

} -show

Out-LastNameFirstName @in

The function is simple enough. Out-LastAndFirstName will simply print out a firstName and lastName packed together in lastName, firstName format. The UI is also really simple, because of the magic of ShowUI.

$in will set the window’s value when we close. A UniformGrid is a control that will automatically put items in a uniformly arranged grid. By giving the grid two columns, I can guarantee that the odd-numbered items go on the left and the even-numbered items go on the right.

The grid has a ControlName: Get-FirstAndLastName. –ControlName is a parameter in ShowUI that lets you anchor all of the values to a particular part of the UI. –ControlName helps determine which variables are there in your event handler, and where the UI will get values.

‘First Name’ is just a string, and, if you put a string inside a collection in ShowUI, it will automatically try to turn it into a label. The text box comes right after it, and will appear on the right side. By giving the text box a name, two things happen:

A variable $FirstName will appear in all of the event handlers pointing to that object.
Whenever we go to output the value of Get-FirstAndLastName, it will create an entry in a hash table which contains the text in the text box.

The ‘ ‘ simply forces a space. This just helps alignment within the uniform grid. The OK button is where the magic is. When it is clicked, the automatic variable $parent (which points to the nearest –ControlName) is piped into a command Set-UIValue. At this point, Set-UIValue creates a value for the control based on what was typed in the text boxes.

Thanks again to James Brundage! I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Expert Solution for 2011 Scripting Games Advanced Event 8: Use PowerShell to Resize Images and to Remove EXIF Data

Anonymous — Wed, 27 Apr 2011 05:00:00 GMT

Summary : Microsoft PowerShell MVP, Marc van Orsouw, resizes images and removes EXIF metadata while solving 2011 Scripting Games Advanced Event 8. Microsoft Scripting Guy, Ed Wilson, here. Marc van Orsouw (MoW) is our expert commentator for Advanced Event...(read more)

The 2011 Scripting Games Advanced Event 8: Use PowerShell to Remove Metadata and Resize Images

Anonymous — Wed, 13 Apr 2011 05:00:00 GMT

Summary : Advanced Event 8 in 2011 Scripting Games uses Windows PowerShell to remove metadata from image files and to resize those images. About this event Division Advanced Date of Event 4/13/2011 12:15 AM Due Date 4/20/2011 12:15 AM Event scenario You...(read more)

Use PowerShell to Add Commands to the Windows Explorer Command Bar

Anonymous — Sun, 27 Feb 2011 06:00:00 GMT

Summary : Learn how to use Windows PowerShell to add commands to the Windows Explorer command bar in Windows 7 and Windows Vista. Weekend Scripter Microsoft Scripting Guy, Ed Wilson, here. Did you ever have one of those times when a seemingly simple project...(read more)

Draw Boxes and Lines in the Windows PowerShell Console Host

Anonymous — Sun, 19 Sep 2010 05:00:00 GMT

Summary : Microsoft MVP Sean Kearney shows how to draw boxes and lines in the Windows PowerShell console while scripting three reusable functions. Microsoft Scripting Guy Ed Wilson here. Just when I thought it was safe to open my email, I get a tweet...(read more)

Hey, Scripting Guy! How Can I Use the Windows Forms TreeView Control?

Anonymous — Tue, 15 Jun 2010 05:00:00 GMT

Today we have a guest article by Ravikanth who works at Dell, Inc., as a lead engineer in the SharePoint Solutions Team. He loves automation and is a Windows PowerShell fanatic. He writes regularly on his blog about topics related to Windows PowerShell...(read more)

Expert Solutions: Advanced Event 7 of the 2010 Scripting Games

Anonymous — Tue, 25 May 2010 05:00:00 GMT

( Note : These solutions were written for Advanced Event 7 of the 2010 Scripting Games .) Advanced Event 7 (Windows PowerShell) James Brundage is a former software developer engineer in testing for Microsoft. He has been a frequent poster on the Windows...(read more)

Hey, Scripting Guy! Quick-Hits Friday: The Scripting Guys Respond to a Bunch of Questions (5/14/10)

Anonymous — Fri, 14 May 2010 05:00:00 GMT

In this post : How Can I Use the Ver Command in Windows PowerShell? What Do These Numbers Mean That Are Returned by This WMI Class? How Can I Change the Color of Text Displayed in the Windows PowerShell Console? How Can I Get the User Name That Runs Services...(read more)