Learn about Windows PowerShell
Summary: Learn how to keep your Windows PowerShell versions straight, and avoid errors while using a one-line command to add computers to domain.
Microsoft Scripting Guy, Ed Wilson, is here. Earlier this week I wrote Use PowerShell to Replace netdom Commands to Join the Domain. It turned out to be a very popular post. To be honest, however, when I started writing that blog, I intended to show that it could be done as a one-liner. This is because I have been using Windows Server “8” Beta for long time now, and I was used to some of the new parameters in the Add-Computer cmdlet.
But I will predict that for the next several months, things are going to be a bit squirrely as people attempt to balance working with Windows PowerShell 2.0 with the various iterations of Windows PowerShell 3.0. It happened in the transition between Windows PowerShell 1.0 to Windows PowerShell 2.0, and I am sure it will happen again this time around.
To be sure, Windows PowerShell 3.0 in Windows Server "8" Beta brings much goodness to the table, and it also simplifies syntax in a great many areas. Don’t panic, though. If you don’t know if something you wrote in Windows PowerShell 3.0 will work in Windows PowerShell 2.0, just go ahead and add the Requires statement to your script, and you will be safe. The use of the Requires statement is shown here.
#Requires -version 3.0
Yep, you are seeing that right; it is preceded with a pound character (the normal comment character). When I attempt to run a script that uses new functionality, and I know that the new functionality only resides in a specific version of Windows PowerShell, I add the Requires statement to the first line in the script. When the script runs on a down-level system, a message displays. The use of the Requires statement, and the accompanying message are shown in the image that follows.
Keep in mind that the Requires statement only works in scripts, not in functions, cmdlets, or snap-ins. In addition, when developing in the Windows PowerShell ISE, if the script is not saved, it is not considered a script. Therefore, it will not work. In the image that follows, an error appears stating that a ComputerName parameter cannot be found, instead of the version information that was presented in the previous image.
Removing a computer from the domain in Windows Server “8” Beta is a one-line command. It also reboots the computer. In addition, the ComputerName parameter permits the command to accept an array of remote computer names. Here is the basic command to remove a computer from the domain, join a workgroup called myworkgroup, and reboot.
Remove-Computer -computername win8c5 -workgroup myworkgroup –restart
As shown in the image that follows, using the Remove-Computer cmdlet without the Force switched parameter causes a warning message to appear. With the Force switched parameter in effect, no warning appears.
Now…to get back to adding a computer to a domain by using Windows PowerShell. In Windows PowerShell 3.0, the Add-Computer cmdlet gains additional parameters. One useful parameter is the Restart parameter. This permits the use of a one-line command to add a computer to the domain. The use of this feature is shown here. (The following command is a single command; I have not added any line continuation characters to it.)
Add-Computer -DomainName iammred -Credential iammred\administrator -restart -OUPath 'ou=charlotte,dc=iammred,dc=net'
The image that follows illustrates using the previous command to add a computer to the domain.
If you need to rename the computer while adding it to the domain, the command would appear as follows:
Add-Computer -DomainName iammred -Credential iammred\administrator -restart -OUPath 'ou=charlotte,dc=iammred,dc=net' –newname mynewcomputername
Keep in mind that Windows PowerShell 3.0 and Windows Server “8” Beta are beta software, and as such the features will change. But I hope you will download them and let us know how you like them. There is some good stuff here.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
a first sign of Powershell V3 ... good news at the horizon, I suppose ...
Well, we should organize version dependent scripts accordingly.
But I hope that our v2 scripts will continue to run on V3 without significant changes!
v2 scripts run fairly unchanged in v3. One difference I have seen is that some of my scripts complain about running in a UNC location, even though it's a mapped drive. So what I've started to do is store my original location, change to a local path (like C:\Windows\) and then revert to the original loc at the end. It only sucks if the script stops halfway, but you just have to code around that.
This is the kind of thing we want to know. We need to document changes in behavior of scripts.
It would be best to try to understand why these behavioral changes are happening.
Great post ..Ed !!
It'll definitely help.
Yeah, for the life of me I can't understand that one - it seems like a completely unecessary complication.
What about forward compatibility? Will #Requires -version 2.0 work in PowerShell 3? I assume so, but don't know for sure.
@Scott Copus (WKU) Yes #Requires 2.0 works in PowerShell 3.0. So, if you have #Requires -Version 2.0 you script will run in PowerShell 3.0. If, on the other hand, you have #Requires -Version 4.0 your script will NOT work on PowerShell 3.0. ALSO, keep in mind, from a testing perspective, that you MUST save the script prior to running it. At that time, it is considered a script in the ISE ... until it is saved, it is simply a listing of commands, and #Requires -VErsion XXX is ignored.