The PowerShell script discussed here allows you to change the local administrator password on multiple remote computers. You can also use the script to change the password of other accounts.

I still remember the days (way back in 2003-2004) when we were asked to change the local administrator password manually on all 2000+ computers in a weekend. Back then, system administrators in my region were pretty far removed from automation. But things evolved greatly after that, and system administrators started using programming languages (like VBScript) to automate tasks. Automation tasks have become much easier these days with the introduction of PowerShell.

So, let us see how we can change the local administrator password for a given list of computers using a PowerShell script.

Changing the administrator password with PowerShell

$password = Read-Host "Enter the password" -AsSecureString
$confirmpassword = Read-Host "Confirm the password" -AsSecureString
$pwd1_text = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($password))
$pwd2_text = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($confirmpassword))
if($pwd1_text -ne $pwd2_text) {
    Write-Error "Entered passwords are not same. Script is exiting"
    exit
}

(more…)

This tutorial discusses a few PowerShell scripts that allow you to query and kill a process on a remote computer using WMI (Windows Management Instrumentation).

Querying processes running on local and remote computers is one of the most common jobs of system administrators. We sometimes need to know which user is running some XYZ application. If you know the process name of the application, then you can quickly scan all your network computers to see how many hosts are running that particular process, and for how long, so that you can prepare an application usage report.

Query process information

Let’s first see how we can check if a process is running or not. For example, the following command checks if Notepad is running and, if so, displays information about the process:

Get-Process -Name notepad.exe

You will get information about the process, if it is running. You can use the -ComputerName parameter with the command to check if the process is running on a given remote computer. For example:

Get-Process -ComputerName PC1 -Name notepad.exe

(more…)

VBScript vs. PowerShell is the question that many admins face. This article compares VBScript with regard to functionality, performance, compatibility, learning curve, security, and brevity.

VBScript is definitely fading, and PowerShell is rightfully gaining traction, but PowerShell’s learning curve and backwards compatibility issues will keep VBScript around a bit longer.

VBScript was once unquestionably the preferred scripting language of most systems administrators, offering them the ability to automate routine tasks and interact with Windows features like IIS, Active Directory, and Terminal Services. Using the Windows Scripting Host, VBScript performed tasks that the Windows shell (batch scripts) simply could not handle. Then, in 2006, Microsoft released an alternative to VBScript – and an extension to the basic shell – known as Windows PowerShell. Since then, VBScript has remained the same while PowerShell 2 has been released.

Of course it’s always nice to have more options. At the same time, the existence of two viable scripting languages poses some new questions for the budding admin. As we compare them head to head, let’s look a bit further into the benefits and drawbacks of each.

(more…)

In this article you will learn how to manage Windows Server 2008 roles and features by using Windows PowerShell.

This is the sixth part of the Windows PowerShell series. PowerShell beginners should also read the previous parts.

In Windows Server 2008 a server role represents an installable unit of functionality that defines the primary function of a server. For instance, you may install Active Directory Domain Services (AD DS) to create a dedicated domain controller for your forest.

By contrast, Windows Server 2008 features are a bit more slippery to define. Like a server role, a feature is an installable unit of functionality. However, whereas a server role typically defines the chief duty of a server, a feature (at least according to Microsoft marketing literature) “provides auxiliary or supporting functions” within a system. Thus, a single server may be the holder of several features.

(more…)

In this article you will learn how to use PowerShell Scriptomatic to perform WMI system administration by using Windows PowerShell.

This is the fifth installment of a multi-part series on Windows PowerShell for Windows systems administrators. To become current with our subject matter, I encourage you to read the four previous articles of this PowerShell tutorial.

As we discussed in a previous entry in this series, learning the syntax of the WMI Query Language (WQL) is tough enough without having the understand the WMI-related PowerShell cmdlets as well. In this essay I will introduce you to the nifty Microsoft PowerShell Scriptomatic utility. By the conclusion of this piece you will be integrating WMI and PowerShell with the best of ‘em!

Let’s get right to work.

(more…)

In this article you will learn how to leverage PowerShell to obtain system information in Windows Server 2008 and Windows desktop systems.

This is the fourth installment of a multi-part series on Windows PowerShell for Windows systems administrators. To get caught up on our subject matter, you might want to read the three previous article about cmdlets and pipeline, aliases and drives, and running scripts.

Now that we have a preliminary understanding of Windows PowerShell, it is time to turn our attention to practical application of the technology. To wit, in this blog post we will learn how to leverage PowerShell in order to ascertain metadata (that is to say, data about data) from a Windows Server 2008 computer. Of course, the same cmdlets apply for obtaining metadata from Windows client machines as well. Let’s get to work!

(more…)

In this article you will learn the basics of running PowerShell script files.

This is the third installment of a multi-part series on Windows PowerShell for Windows systems administrators. To get caught up on our subject matter, you might want to read the two previous articles about cmdlets and the pipeline and about aliases and drives.

Now, then—on with the show. While issuing ad-hoc PowerShell cmdlets from a PowerShell prompt is all well and good for occasional or on-demand use, you don’t truly begin to leverage the strengths of Windows PowerShell until you aggregate your code (which can include variables, branching, looping, error handling, etc.) into script files.

(more…)

Part 2 of the PowerShell tutorial for Windows admins introduces aliases and drives.

In the first part of this miniseries on Windows PowerShell terminology for administrators we briefly described what PowerShell is an introduced you to the cmdlet and the pipeline.

Let’s now continue our journey by learning two additional core terms that every PowerShell scripter should know.

Aliases

One of the things that I really love about Windows PowerShell is how much thought the Microsoft developers put into making the environment as user-friendly for existing Windows (and even *NIX) scripters as possible. To me, aliases represent the best example of this universality aspect of Windows PowerShell.

(more…)

In part 1 of this PowerShell tutorial for Windows admins you will learn about the cmdlet and pipeline concepts.

Microsoft Windows PowerShell was conceived as the next-generation replacement for the old and reliable cmd.exe command shell environment. What’s especially cool about PowerShell is that it has a lot to offer both Windows systems administrators as well as .NET solution developers.

Trouble is, you have doubtless discovered that the PowerShell documentation, whether published by Microsoft or a third party, rarely differentiates between these two very different audiences. Therefore, administrators get confused and frustrated while trying to wade through PowerShell developer terminology, and .NET developers get befuddled and angry while trying to comprehend PowerShell administrator nomenclature.

(more…)

More than 1,100 4sysops readers took part in this poll. I asked whether a graphical user interface (GUI) or a command line interface (CLI) was preferred when it comes to Windows administration. The results are quite clear: 66% prefer a GUI tool, 17% prefer the command line, and for another 17%, it doesn’t make a difference.

(more…)

The introduction of PowerShell was a major improvement for all administrators who are not afraid of the CLI. However, it also has some drawbacks. For instance, it is not included in the OS and it lacks many features. Microsoft wanted to correct those shortcomings. PowerShell Version 2 is now a part of Windows 7 and Windows Server 2008 RC2 and offers many new Cmdlets. One area that was improved is the management of the Active Directory (AD).

If you want to use these new features, you have to add the Cmdlets first. PowerShell v2 is now modularized. This only works under Windows Server, because you need to install the role “Active Directory Services” and the feature “Remote Server Administration Tools.” You can use the Server Manager for the installation, or if you prefer typing the following commands, you will have the same results:

import-module servermanager Add-WindowsFeature -Name “RSAT-AD-PowerShell” -IncludeAllSubFeature import-module ActiveDirectory

(more…)

Coincidentally, shortly after I wrote the article for the GUI vs. CLI poll I came across a related topic. PowerShell did not only make the renaissance of the command line possible, the marketing buzz around it also tempts Windows administrators who never wrote a line of code before to program scripts to “automate” administration tasks. I would like to cite a paragraph from Robert B. Laughlin’s (winner of the Nobel Prize in Physics) book “A different Universe” (p. 68) that I am currently reading. (I highly recommend this book to everyone who is interested in Physics and the Philosophy of Physics).

One of the more interesting trends of the computer age is that physical science students are increasingly unwilling or unable to write computer code. I was very upset when I first observed this and took stern measures in my department to counteract it, much to the students’ chagrin, for I myself am very good at coding and consider it something any self-respecting technologist should know how to do. Eventually, however, I realized that the students were right and I was wrong, and stopped the crusade. Computer programming is one of those things in life, like fixing one’s own car, that is fascinating, fun, useful–and unacceptably time-consuming. The truth is that it is no longer cost-effective for most well-educated people to program their own computers, or even to learn how to do so. The wise use of a time is to spend a few bucks to buy a program that does what one wants, or in extreme cases, search the internet for free software.

(more…)

Recently, I stumbled upon a sentence in a Microsoft blog that made me wonder if there is a paradigmatic change happening in Redmond. Ned Pyle discussed the Windows Server 2003 adminpak tool RepImon (Active Directory Replication Monitor utility) as a replacement for the Windows Server 2008, Repadmin (Replication Diagnostics Tool). Both tools allow you to view the Active Directory replication status and to force synchronization between domain controllers. What is interesting here is that RepImon has a graphical user interface, whereas Repadmin is a command line tool.

To some extent, the article reads as if Repadmin is a new tool, yet both tools have already been introduced in Windows 2000. Therefore, Microsoft dropped a GUI tool in favor of the command line version. This is in contradiction to Microsoft’s official policy, i.e., that command line and graphical admin tools are supported in the same manner. It has occurred to me several times, however, that this is really no longer the case. Ned Pyle indicates why:

Windows administrators are much more comfortable with the command-line, and that’s great…

(more…)

PowerShell ISE (Integrated Scripting Environment), formerly known as Graphical PowerShell, is a graphical development environment and Command Prompt alternative. It is part of PowerShell 2.0, which has been integrated into Windows 7 and Windows Server 2008 R2, and is available as a Community Technology Preview (CTP) for Windows XP and Windows Vista.

I believe PowerShell’s integration into Windows will bring its breakthrough. As far as I’m concerned, the “DOS Command Prompt” is finally dead. Even if you haven’t found the time to learn PowerShell yet, it makes sense to use PowerShell ISE whenever you need a command line, because a graphical user interface is much more convenient.

(more…)

PowerGUI is a free tool that allows you to create PowerShell scripts with a graphical user interface (GUI). It also comes with a nice PowerShell script editor that supports debugging. Version 1 has been available for some days already.

The main idea behind PowerGUI is to create PowerShell code by selecting objects, and performing actions on them. For instance, you can select Active Directory objects or Exchange objects manually or by using filters. Then you tell PowerGUI that you want to move these objects to a new location and it will create the corresponding PowerShell script which you can enhance with your own code.

(more…)

Rate this tool: (8 votes, average: 3.25 out of 5)

 Loading ...

Submit a free admin tool | Free admin tools index | Browse free admin tools